Masterarbeit Informatik

Größe: px
Ab Seite anzeigen:

Download "Masterarbeit Informatik"

Transkript

1 Masterarbeit Informatik Konzeption und prototypische Implementierung eines Werkzeugs zur dreidimensionalen Mehrbenutzer-Interaktion mit Geschäftsprozessmodellen in OMEGA-Notation vorgelegt von cand. Master Michael Hilus Matr.-Nr Betreuer: Prof. Dr. Gerd Szwillus Prof. Dr. Gitta Domik-Kienegger Dipl.-Wirt.-Ing. Hessam Omumi Paderborn, 01. Juli 2014

2 Konzeption und prototypische Implementierung eines Werkzeugs zur dreidimensionalen Mehrbenutzer-Interaktion mit Geschäftsprozessmodellen in OMEGA-Notation am: 01. Juli 2014 Universität Paderborn Fakultät für Elektrotechnik, Informatik und Mathematik Institut für Informatik Prof. Dr. Gerd Szwillus Fürstenallee 11 D Paderborn >> progresso group GbR B. Sc. Michael Hilus Technologiepark 21 D Paderborn

3 Eidesstattliche Erklärung: Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbstständig und ohne unerlaubte fremde Hilfe angefertigt, keine anderen als die angegebenen Quellen und Hilfsmittel benutzt und die den benutzten Quellen wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht habe. Paderborn, 01. Juli 2014

4

5 Zusammenfassung Seit jeher wird versucht die Produktivität und Effizienz in Unternehmen zu steigern. Ein Ansatz dabei ist es, die Abläufe in einem Unternehmen, die sogenannten Geschäftsprozesse zu optimieren. Dies wird unter anderem mit der an der Universität Paderborn entwickelten OMEGA-Methode realisiert. Prozesse werden erfasst und in der OMEGA-Notation aufgezeichnet und in späteren Phasen verbessert und umgesetzt. Die Aufzeichnung der Prozesse ist jedoch problematisch, weil zwar die OMEGA-Methode eine 3D-Visualisierung von Prozessmodellen vorsieht, diese jedoch von keinem bestehenden Werkzeug realisiert wird. Auch für die Interaktion mit Geschäftsprozessmodellen von mehreren Teammitgliedern gleichzeitig existiert kein adäquates Werkzeug. In Zusammenarbeit mit der progresso group GbR wird in dieser Arbeit deshalb ein Konzept zu einem Werkzeug ausgearbeitet, welches die bisher fehlenden Funktionalitäten umsetzen soll. Im Fokus steht die Benutzbarkeit und Mehrbenutzerinteraktion von Geschäftsprozessdiagrammen im dreidimensionalen Raum. Zunächst werden Anwendungsfälle aus der Definition der OMEGA-Methode und der Praxis gesammelt und mit bereits existierenden Lösungen aus der Literatur und der Praxis abgeglichen. Vorhandene Lösungen werden kombiniert und gegebenenfalls erweitert. Die abschließende Implementierung eines Prototyps zeigt die Machbarkeit des aufgestellten Konzepts. Der Einfachheit halber wird in dieser Arbeit für manche Nomen (zum Beispiel Mitarbeiter) ausschließlich die maskuline Form gewählt, wobei damit natürlich die feminine Form nicht ausgeschlossen ist.

6

7 Inhaltsverzeichnis Seite 1 Inhaltsverzeichnis 1 Einleitung Motivation Zielsetzung Vorgehensweise Grundlagen Geschäftsprozesse Definition Geschäftsprozess Business Process Reengineering Modellierungssprachen Unified Modeling Language Erweiterte ereignisgesteuerte Prozessketten Business Process Model and Notation OMEGA Geschäftsprozessmodell OMEGA-Methode Modelle Vorgehen Vorgeschlagenes Modellierungswerkzeug D-Modellierung D Visualisierung zur Verständlichkeitsförderung D-UML im Browser Mehrbenutzer-Interaktion Kollaborative Systeme Awareness Beispiele für Mehrbenutzer-Anwendungen BSCW-System POLITeam Google Docs Problemanalyse Problematik Anforderungen Visualisierung und Navigation Modellierung... 50

8 Seite 2 Inhaltsverzeichnis Mehrbenutzer-Interaktion Plattformunabhängigkeit Stand der Technik OMEGA-Editoren Visio OMEGA Process Modeller von Unity Online-Editoren für Geschäftsprozesse Process Live IBM BlueworksLive Editoren von 3D-Modellen ds Max von Autodesk Blender Bewertung Entwicklung des Konzeptes Ansatz Ermittlung der Anwendungsfälle Ermittlung aus der OMEGA-Methode Ermittlung aus der Arbeit von Mayr Ermittlung aus Visio Ermittlung aus OMEGA Process Modeller Ermittlung aus Anforderungen Strukturierung und Priorisierung Strukturierung der Anwendungsfälle Priorisierung der Anwendungsfälle Analyse der Anwendungsfälle Visualisierung Navigation Interaktion Zusammenführung und Ergebnis Prototypische Umsetzung und Bewertung Umgebung Vorgehen Implementierung Technologieauswahl Architektur Frameworkentwicklung Editorentwicklung... 98

9 Inhaltsverzeichnis Seite Umsetzungen Test Bewertung Zusammenfassung und Ausblick Zusammenfassung Ausblick Literaturverzeichnis Anhang A1 Fragenkatalog von Gutwin... A-3 A2 Ermittelte Anwendungsfälle... A-4 A2.1 Anwendungsfälle aus der OMEGA-Definition... A-4 A2.2 Anwendungsfälle aus Mayrs Arbeit... A-8 A2.3 Anwendungsfälle aus Visio... A-9 A2.4 Anwendungsfälle aus OMEGA Process Modeller... A-12 A2.5 Anwendungsfälle aus Anforderungen... A-16 A2.6 Priorisierter, Strukturierter Katalog... A-17

10

11 Einleitung Seite 5 1 Einleitung Für den Erfolg heutiger Unternehmen reicht es längst nicht mehr, Produkte in besserer Qualität günstiger anzubieten, als die Konkurrenz. Vielmehr sind die Globalisierung der Märkte, kürzere Produktlebenszyklen und schnell wechselnde Präferenzen der Kunden nur einige zusätzliche Probleme denen es sich zu stellen gilt [OF03]. Ein Ansatz, um den immer weiter steigenden Anforderungen an Unternehmen zu begegnen, ist das Business Process Reengineering (BPR). Es ist ein Ansatz zur völligen Neustrukturierung von bestehenden Abläufen, den so genannten Geschäftsprozessen 1, in Unternehmen [OF03]. Dazu werden Geschäftsprozesse in mehreren Phasen zunächst schriftlich dokumentiert, analysiert, verbessert und umgesetzt. Die OMEGA 2 -Methode baut auf diesem Ansatz auf und liefert neben einer Modellierungssprache für Geschäftsprozesse eine definierte Anleitung, nach der historisch gewachsene oder ineffektive Geschäftsprozesse in geordneten Phasen optimiert werden [Fah95]. 1.1 Motivation Die OMEGA-Methode sieht für die Optimierung von Geschäftsprozessen vier Phasen vor. In der Phase Ist-Erfassung werden zunächst die bestehenden Geschäftsprozesse als Modelle aufgenommen. Die zweite Phase Analyse dient zur Untersuchung der erstellten Modelle auf ihre Verbesserungspotenziale. Im nächsten Schritt werden in der Phase Soll-Konzeption die Prozessmodelle hinsichtlich der ermittelten Potenziale um- oder neustrukturiert. Die letzte Phase Umsetzung schließt die Methode ab, indem die Modelle im Unternehmen umgesetzt werden [Fah95]. Die leichte Verständlichkeit der Prozessmodellierungssprache von OMEGA führt dazu, dass sie sich in immer mehr Unternehmen und Unternehmensberatungen etabliert [May10]. Dennoch ist der Verbreitungsgrad im Vergleich zu anderen Sprachen, wie der Notation der erweiterten ereignisgesteuerten Prozessketten oder der Business Process Model and Notation gering. Die Ursache dafür liegt zum einen in der ausschließlich deutschsprachigen Verwendung, zum anderen in der geringen Unterstützung durch geeignete Werkzeuge begründet. Dabei ist eine leichte Verständlichkeit gerade bei der Kommunikation von Geschäftsprozessen wichtig, denn die am BPR beteiligten Personen sind nicht nur 1 Eine genaue Definition von Geschäftsprozessen findet sich im Grundlagenkapitel. 2 Objektorientierte Methode für die Geschäftsprozessmodellierung und -analyse

12 Seite 6 Kapitel 1 Fachexperten der Prozessoptimierung, sondern auch ungeschulte, im Umgang mit Modellierungsmethoden unerfahrene Unternehmensmitarbeiter [Fah95]. Diese heterogene Gruppe wird durch herkömmliche Werkzeuge zur Modellierung von OMEGA-Geschäftsprozessmodellen nur unzureichend unterstützt. Gleichzeitiges Arbeiten mehrerer Personen an denselben Geschäftsprozessmodellen ist beispielsweise nicht möglich, da eine Mehrbenutzerinteraktion in den Programmen nicht vorgesehen ist. Auch die Datenintegrität bei gleichzeitiger Bearbeitung ist nicht sichergestellt, weil entweder Dateien auf mehreren Systemen verteilt sind oder Speichervorgänge Änderungen eines jeweils anderen Bearbeiters unkontrolliert überschreiben. Weitere Schwierigkeiten bei der Modellierung liefern bestehende Werkzeuge durch die fehlende Unterstützung von 3D-Modellierung, wenig oder keine Unterstützung von Analysen und unzureichende Prüfungen auf korrekte Syntax. Geschäftsprozessmodelle in der OMEGA-Notation werden momentan nicht mehr als eine Komposition von 3D-Bildchen auf einer 2D-Zeichenfläche erstellt und behandelt, obwohl eine dreidimensionale Darstellung von komplexen Prozesshierarchien das Verständnis erleichtern würde [KN09]. Diese Arbeit stellt ein Konzept für ein Werkzeug zur kollaborativen 3D-Modellierung von Geschäftsprozessen vor. Die Annahme ist, dass so ein Werkzeug zu einer Steigerung der Arbeitsgeschwindigkeit und einer Verminderung von Fehlern während der Modellierung führt. Diese soll erheblich vereinfacht werden und die Kollaboration zu einer verbesserten Kommunikation beitragen. Dies wird im Laufe der Arbeit gezeigt. 1.2 Zielsetzung Ziel dieser Arbeit ist es, ein Konzept für solch ein Werkzeug zur Mehrbenutzer- Interaktion mit OMEGA-Geschäftsprozessmodellen zu erhalten, das sowohl die Kommunikation zwischen den beteiligten Personen verbessert, komplexe Modelle durch eine übersichtliche dreidimensionale Darstellung visualisiert und den Prozess des Modellierens durch eine Syntaxprüfung erleichtert. Das Konzept muss zeigen, wie die Interaktion zwischen beteiligten Personen und dem Modell verläuft, wie das Modell visualisiert wird und wie der Benutzer des Werkzeugs durch das Modell navigiert. Zur Evaluation erfolgt eine prototypische Umsetzung einer Computergraphikanwendung in Form eines Editors für OMEGA-Modelle. Der Editor soll als Webanwendung laufen und gleichzeitiges Arbeiten mehrerer Personen an denselben Modellen erlauben.

13 Einleitung Seite Vorgehensweise Die folgende Abbildung 1-1 zeigt die Vorgehensweise in einer Phasendiagramm-Darstellung. Zunächst wird untersucht, auf welche Art und Weise ein Werkzeug die Modellierung von OMEGA-Modellen verbessern und beschleunigen kann. Dazu werden Anwendungsfälle aus drei Bereichen der OMEGA- Modellierung betrachtet. Der erste Bereich ist die Definition der OMEGA-Methode selbst. Diese erlaubt eine direkte Ableitung von Anwendungsfällen aus den Schritten der einzelnen Phasen. Der zweite Bereich sind bestehende Werkzeuge. Diese ermöglichen bereits, wenn auch nur eingeschränkt, eine Erstellung von OMEGA-Modellen. Es werden Anwendungsfälle aus den Funktionen dieser Werkzeuge abgeleitet. Abbildung 1-1: Phasendiagramm zur Vorgehensweise dieser Arbeit Den dritten Bereich bilden fertig modellierte Geschäftsprozessmodelle aus der Praxis. Diese dienen zur Untersuchung der Häufigkeit von Anwendungsfällen,

14 Seite 8 Kapitel 1 indem zum Beispiel die Anzahl von Modellelementen gezählt und deren Positionen betrachtet werden. Die Anwendungsfälle werden nach ihrer Häufigkeit priorisiert. Die Sammlung der Anwendungsfälle und deren Priorisierung bilden einen Katalog, auf dem das Konzept des Werkzeugs aufgebaut wird. Jeder Anwendungsfall wird hinsichtlich der Aspekte Interaktion, Visualisierung und Navigation untersucht. Dabei wird zu jedem Aspekt geprüft, ob für den jeweiligen Anwendungsfall bereits ein geeignetes Umsetzungskonzept aus der Literatur oder Praxis existiert und gegebenenfalls erweitert oder neu entworfen. Insbesondere werden hier bestehende Werkzeuge für 3D-Modellierung und Konzepte zu Mehrbenutzerinteraktionen betrachtet. Die ermittelten Umsetzungskonzepte zur Interaktion, Visualisierung und Navigation werden anschließend zu einem Gesamtkonzept zusammengeführt. Zuletzt wird das Werkzeug in Form einer prototypischen Web-Anwendung umgesetzt, um die Machbarkeit des Konzepts zu zeigen, dieses zu evaluieren und die Ergebnisse der Arbeit zu bewerten.

15 Grundlagen Seite 9 2 Grundlagen Dieses Kapitel widmet sich der Einführung in die Thematik. Der erste Teil stellt Geschäftsprozesse, Modellierungssprachen und Methoden zur Prozessoptimierung vor. Danach folgen eine Vorstellung verschiedener Konzepte zur 3D-Modellierung und eine Übersicht verbreiteter Editoren für 3D-Modelle. Der letzte Teil geht auf Mehrbenutzer-Interaktion ein und stellt Konzepte aus anderen Arbeiten vor, die diese Interaktion näher beschreiben. 2.1 Geschäftsprozesse Das folgende Unterkapitel erläutert was Geschäftsprozesse sind, wofür sie eingesetzt werden und wie mit ihnen gearbeitet wird. Es startet mit der Definition von Geschäftsprozessen, stellt die wichtigsten Modellierungssprachen vor und schließt mit der Erläuterung der OMEGA-Methode ab Definition Geschäftsprozess Im Rahmen dieser Arbeit wird unter Geschäftsprozess die in der Literatur vielzitierte Definition von Hammer und Champy [HC03] verstanden. Ein Geschäftsprozess ist in diesem Sinne als ein Bündel von Aktivitäten zu verstehen, welches ein oder mehrere unterschiedliche Eingaben benötigt und ein Ergebnis liefert, das für den Kunden einen Wert besitzt [HC03]. Vereinfacht gesagt besteht ein Geschäftsprozess aus einer Menge von Eingaben, einer Menge von Aktivitäten oder Tätigkeiten und einer definierten Ausgabe. In einem Unternehmen gibt es typischerweise mehrere Geschäftsprozesse, die jedoch nicht losgelöst voneinander existieren. Vielmehr gehen Geschäftsprozesse ineinander über, wiederholen sich, teilen sich auf und vereinen sich. Die Kommunikation zwischen Geschäftsprozessen funktioniert dabei über deren Ein- und Ausgaben in Form von Material oder Information [Fah95]. Ein Geschäftsprozessmodell ist eine abstrakte Beschreibung eines Geschäftsprozesses. Die Notation solch eines Modells kann entweder textueller oder graphischer Natur und entweder informell oder formal sein[of03]. Geschäftsprozessmodelle werden zur Dokumentation und Analyse von Geschäftsprozessen genutzt. Wenn im Laufe dieser Arbeit von Modellierungssprachen, bezogen auf Geschäftsprozesse, die Rede ist, sind graphische Notationen von Geschäftsprozessmodellen gemeint. Einige dieser Sprachen werden später genauer beschrieben.

16 Seite 10 Kapitel Business Process Reengineering Seit dem 19. Jahrhundert passen sich Unternehmen an ihre Umwelt an, um am Markt bestehen zu können. Seitdem haben sich unter anderem die Qualifikationen der Beschäftigten radikal geändert. Während früher überwiegend ungeschulte Landarbeiter beschäftigt waren, können Unternehmen heute auf eine breite Masse gut ausgebildeter Mitarbeiter zurückgreifen. So wurde früher auch eine höhere Produktivität durch strikte Arbeitsteilung erreicht, wobei diese Aufteilung heutzutage durch die Notwendigkeit häufiger Abstimmung eher hinderlich ist und zum Beispiel zu Irrtümern und Fehlern führt [OF03]. Eine fortwährende Anpassung der Unternehmensstruktur und den damit eingehenden Geschäftsprozessen ist allerdings nicht nur unbequem, sondern auch teuer, da neue Prozesse allen Mitarbeitern kommuniziert und diese unter Umständen neu geschult werden müssen. Aus diesem Grunde halten viele Unternehmen über lange Zeiträume an ihren traditionellen Strukturen fest und verpassen den Zeitpunkt, an dem eine Neustrukturierung zu einer besseren Effizienz führt als eine Fortführung bestehender Prozesse [OF03]. In den 90er Jahren wird dieses Problem besonders deutlich und Hammer und Champy begegnen diesem Problem mit dem Konzept des Business Process Reengineering. Als Business Process Reengineering (BPR) wird das fundamentale und radikale Überdenken und Restrukturieren von Unternehmen oder wesentlichen Unternehmensprozessen (Geschäftsprozessen) verstanden. Das Ergebnis ist eine Verbesserung in wichtigen Leistungsgrößen in den Bereichen Kosten, Qualität, Service und Zeit. Im methodischen Ansatz der BPR werden die Geschäftsprozesse systematisch neugestaltet, so dass diese auf die Unternehmensziele und Markterfordernisse ausgerichtet werden [HC03, Fah95]. Dies geschieht in vier Phasen. Die erste Phase besteht aus der Ist-Erfassung. In dieser Phase wird der Ist-Stand der Unternehmensprozesse aufgenommen, indem durch Umfragen und Beobachtungen alle Geschäftsprozesse ermittelt und mit Hilfe einer Modellierungssprache erfasst werden. Das Resultat schafft Transparenz und eine Übersicht über die aktuelle Unternehmenssituation und ist gleichzeitig der Ausgangspunkt für die zweite Phase, die Analyse. Die Phase Analyse dient der Identifizierung von kritischen Stellen in den Prozessen. Eine kritische Stelle ist ein Punkt im Prozess, für den Handlungsbedarf für Neugestaltung besteht. Ein Grund für solch eine Neugestaltung ist beispielsweise ein Prozessschritt, der durch Änderungen in vorhergehenden oder nachfolgenden Schritten weggelassen werden kann und sich dadurch der Gesamtprozess beschleunigt. Eine kritische Stelle wird in einen Katalog eingepflegt und als Verbesserungspotenzial im Modell markiert.

17 Grundlagen Seite 11 Die Analyse liefert die Basis für die dritte Phase, die Soll-Konzeption. In diesem Schritt werden die Ergebnisse der Analyse genutzt, um Soll-Prozesse zu definieren. Die kritischen Stellen aus den Ist-Prozessen werden durch Neustrukturierung eliminiert und es wird bestrebt, das Potenzial von IT auszuschöpfen. Die letzte Phase Umsetzung ist der Schritt, in dem die Soll-Prozesse im Unternehmen umgesetzt werden. Bestehende Kompetenzbereiche und die Reihenfolge von Prozessschritten werden auf die neue Struktur angepasst [HC03, Fah95]. Abbildung 2-1 zeigt den Ansatz des Business Process Reengineering in einem Phasendiagramm. Abbildung 2-1: Phasendiagramm zum Ansatz des Business Process Reengineering [HC03, Fah95] Modellierungssprachen Dieser Abschnitt beschäftigt sich mit der Notation von Geschäftsprozessmodellen und stellt die am weitesten verbreiteten vor. Da sich diese Arbeit besonders mit der OMEGA-Notation beschäftigt, wird in diesem Kapitel besonders auf graphische Modellierungssprachen eingegangen.

18 Seite 12 Kapitel 2 Geschäftsprozessmodelle dienen nicht nur als reine Wissensträger und zur Dokumentation von Geschäftsprozessen, sondern werden auch als Kommunikationsmedium genutzt [FMN10]. Im Laufe der Zeit ist eine Vielzahl von Modellierungssprachen entstanden, die sich in der Syntax und dem Grad ihrer formalen Semantik unterscheiden. Textbasierte Notationen, wie zum Beispiel die Business Process Execution Language (BPEL) [LLN11], haben in der Regel eine sehr formale Notation, die an Programmiersprachen angelehnt und dementsprechend als Kommunikationsmedium für ungeschulte Mitarbeiter durch ihre schwierige Lesbarkeit ungeeignet ist [Gad08]. Der Vorteil textbasierter Sprachen liegt jedoch in ihrer Maschinenlesbarkeit. Diese erlaubt die direkte Simulation oder sogar die Umsetzung von Geschäftsprozessmodellen in eine Software [OF03]. Graphische Sprachen dienen vorwiegend der Dokumentation und Kommunikation und kommen beispielsweise in Schulungen bei Einführungen neuer Geschäftsprozesse zum Einsatz. Ihre formalen Notationen reichen von sehr strikt bis sehr interpretierbar und bildhaft [FMN10, Fah95]. Die Unified Modeling Language (UML) [Oes12] ist ein Beispiel für eine strikt formale Notation. Die in dieser Arbeit besonders beachtete OMEGA-Notation [Fah95] ist dagegen hochgradig interpretierbar und eignet sich aufgrund der bildhaften Darstellung besonders für Vermittlungen von Geschäftsprozessmodellen an ungeschulte Mitarbeiter [May10]. Im Folgenden werden zunächst die am weitesten verbreiteten Sprachen [FMN10] vorgestellt, die Unified Modeling Language (UML), erweiterte ereignisgesteuerte Prozessketten (eepk) [KNS92, Sta06] und die Business Process and Notation (BPMN) [All09, Völ10]. Danach folgt die Vorstellung der OMEGA-Notation Unified Modeling Language Die Unified Modeling Language (UML) wird vornehmlich zur Spezifikation, Konstruktion, Visualisierung und Dokumentation von Software-Systemen genutzt, kommt aber auch bei der formalen Modellierung von Geschäftsprozessen zum Einsatz [Gad08]. Ihre insgesamt 15 verschiedenen Sprachen zur Beschreibung von Abläufen, Strukturen und Zusammenhängen werden in einem Metamodell präzise beschrieben. Zur Modellierung von Abläufen und damit auch Geschäftsprozessen eignen sich Zustandsautomaten und Aktivitätsdiagramme [Oes12]. Die Sprachen der UML bestehen aus graphischen Sprachkonstrukten, die nicht intuitiv verstanden werden können, sondern erlernt werden müssen [Hil10]. Deshalb und auf Grund ihrer formalen Notation eignet sich die UML besser für die Spezifikation von Geschäftsprozessmodellen für UML-Kundige, als zur Beschreibung und Vermittlung von Prozessen für ungeschulte Mitarbeiter. Dies

19 Grundlagen Seite 13 macht die UML besonders interessant für Geschäftsprozessoptimierungen, die Hand in Hand mit einer Einführung, Entwicklung oder Weiterentwicklung eines prozessbegleitenden IT-Systems gehen [Gad08]. Ein Verfahren dazu stellt Oestereich et al. [OWS03] als objektorientierte Geschäftsprozessmodellierung mit der UML vor. Das Verfahren macht sich zu Nutze, dass mit der UML erstellte Geschäftsprozessmodelle als eine gemeinsame Plattform für sowohl Systemanalytiker und IT-Fachkräften dienen. Durch Verschachtelung und Generalisierung von Geschäftsprozessmodellen wird eine geordnete, hierarchische Struktur dieser Modelle realisiert. Die korrekte Semantik der erstellten Geschäftsprozessmodelle wird durch ein genau spezifiziertes Vorgehen sichergestellt, bei dem zunächst die Organisationsstruktur als Klassendiagramm, dann Geschäftspartner und deren Anwendungsfälle als Use-Case-Diagramme und schließlich einzelne Geschäftsprozesse als Aktivitätsdiagramme modelliert werden [OWS03]. Für diese Arbeit sind der Schritt der Geschäftsprozessmodellierung und die Erstellung von Aktivitätsdiagramme besonders interessant. Aus diesem Grund werden im Folgenden Aktivitätsdiagramme vorgestellt und ein Beispiel eines modellierten Geschäftsprozess gegeben. Aktivitätsdiagramm Ein Aktivitätsdiagramm beschreibt einen Ablauf. Dieser wird durch eine Menge von Aktions- Kontroll- und Objektknoten dargestellt, die durch Objekt- und Kontrollflüsse miteinander verbunden sind. Das Aktivitätsdiagramm wird als großes Rechteck mit abgerundeten Ecken und seinem Namen als Text links oben dargestellt. [Oes12]. Der Ablauf (oder Aktivität) wird als eine Reihe von elementaren Ablaufschritten definiert. Ein Ablaufschritt wird als ein Aktionsknoten beschrieben und als Rechteck mit abgerundeten Ecken und dem Namen des Ablaufsschritts in der Mitte dargestellt. Ein einzelner Aktionsknoten kann selbst auf eine andere Aktivität verweisen. Auf diese Weise können Aktivitätsdiagramme ineinander verschachtelt und damit eine Hierarchie von Aktivitäten aufgebaut werden. Um die Reihenfolge von Ablaufschritten zu modellieren, werden die Aktionsknoten mit gerichteten Pfeilen verbunden und damit ein Kontrollfluss definiert. Der Ablaufschritt eines Aktionsknoten auf den ein Pfeil zeigt wird zeitlich nach dem Ablaufschritt des Aktionsknotens ausgeführt, von dem der Pfeil weg zeigt. Eine Aktivität hat immer einen Startknoten von dem aus der Kontrollfluss initiiert wird und ein oder mehrere Endknoten, die alle Kontrollflüsse terminieren.

20 Seite 14 Kapitel 2 Für Nebenläufige oder verzweigte Kontrollflüsse werden Kontrollknoten eingesetzt. Diesen sind mehrere ein- und ausgehende Kontrollflüsse zugewiesen. Rautenförmige Kontrollknoten werden Entscheidung oder Zusammenführung genannt. Entscheidungsknoten teilen den eingehenden Kontrollfluss in mehrere ausgehende Kontrollflüsse und deren textuell notierten Bedingungen. Nur Kontrollflüsse, deren Bedingungen zum Zeitpunkt der Prüfung erfüllt sind, werden weitergeführt. Zusammenführungsknoten führen den ausgehenden Kontrollfluss weiter sobald einer der eingehenden Flüsse ankommt. Quaderförmige schwarze Kontrollknoten werden Teilung oder Synchronisation genannt. Teilungsknoten führen den eingehenden Kontrollfluss als nebenläufige ausgehende Kontrollflüsse weiter. Synchronisationsknoten führen den ausgehenden Kontrollfluss erst weiter, wenn alle eingehenden Flüsse angekommen sind [Oes12]. Der Ansatz von Oestereich et al. modelliert jeden Geschäftsprozess als Aktivitätsdiagramm. Sehr komplexe Geschäftsprozessmodelle werden dabei in mehrere Aktivitätsdiagramme aufgeteilt und in einem übergeordneten Aktivitätsdiagramm zusammengeführt. Dies ist durch die Möglichkeit der Verschachtelung von Aktivitäten realisiert und wird Drill-Down-Mechanismus genannt [OWS03]. Die bloße Darstellung eines Geschäftsprozesses als Aktivitätsdiagramm reicht für eine vollständige Abbildung desselben jedoch nicht aus. Nach der in dieser Arbeit verwendeten Definition eines Geschäftsprozesses fehlt noch die Modellierung dessen Eingaben und Ergebnissen. Zu diesem Zweck fügt Oestereich et al. zu jedem Aktivitätsdiagramm eine tabellarische Darstellung hinzu, die ebendiese Informationen als textuelle Beschreibungen enthält [OWS03]. Die nachfolgende Abbildung 2-2 zeigt beispielhaft, wie ein Geschäftsprozess mit dem Namen Kfz reservieren in der UML-Notation für Aktivitätsdiagramme umgesetzt ist. Das Beispiel macht deutlich, wie eine Abteilung Kfz- Reservierungen und Schadensmeldungen behandelt und wie der Prozess aussieht um einem Kunden ein Kfz zu vermieten. Der Geschäftsprozess beginnt damit, dass ein Kunde ein Kfz reservieren möchte, abgebildet durch den Startknoten oben links. Danach werden die Aktivitäten Kfz reservieren und Nutzungsbeginn abwarten durchgeführt. Wird dieser geändert, wird die Aktion Kfz-Reservierung ändern durchgeführt. Die Bedingung dazu ist als ändern auf dem Übergang zwischen den beiden Aktivitäten modelliert. Soll die Reservierung widerrufen werden, modelliert durch die Bedingung stornieren, wird die Aktion Kfz-Reservierung stornieren durchgeführt und der Prozess im Endknoten Reservierung wurde storniert beendet. Anderenfalls tritt das Ereignis Nutzung beginnen ein und die Aktionen Kfz vermieten und im Anschluss Kfz nutzen werden ausgeführt. Bei einer Schadensmeldung (Schaden melden) wird der Prozess nach der Akti-

21 Grundlagen Seite 15 vität Schadenmeldung bearbeiten im Endknoten Kfz-Nutzung wg. Unfall abgebrochen beendet. Anderenfalls wird Kfz zurücknehmen nach Nutzung beenden ausgeführt und der Prozess im Endknoten Kfz wurde zurückgenommen beendet. Abbildung 2-2: Geschäftsprozess Kfz reservieren als UML-Aktivitätsdiagramm modelliert [OWS03] Erweiterte ereignisgesteuerte Prozessketten Die ereignisgesteuerte Prozesskette (EPK) wurde von Scheer et al. [KNS92] als eine semi-formale Methode zur Dokumentation und Analyse von Geschäftsprozessen entwickelt und ist ein Bestandteil des SAP-Konzepts zur Unternehmensmodellierung [Kel95, Sta06]. Bei ihrer Modellierungssprache handelt sich um eine an Petri-Netzen [Pet62] angelehnte Notation mit Knoten und Kanten. Ein Geschäftsprozess wird darin durch eine Menge von Funktionen und Ereignissen definiert, die als Knoten in einem Graphen mit gerichteten Kanten verbunden werden. Die Richtung der Kanten gibt den Kontrollfluss innerhalb des Geschäftsprozesses in einem zeitlich-logischen Zusammenhang wieder [Mor10]. Die EPK wurde später durch die erweiterte ereignisgesteuerte Prozesskette (eepk) abgelöst, in der auch die Modellierung von Ein- und Ausgabeparametern, durch sogenannte Informationsobjekte, und die Definition von Zuständigkeiten, durch Organisationseinheiten, möglich ist [NZ98]. Im Folgenden werden die einzelnen Modellelemente und die Definition ihrer Abhängigkeiten im Geschäftsprozessmodell vorgestellt.

22 Seite 16 Kapitel 2 Die untenstehende Tabelle 2-1 zeigt eine Übersicht über alle eepk-modellelemente, deren visuelle Repräsentationen und Kurzbeschreibungen zu jedem Element. Jedes Element wird im Anschluss genauer erläutert. MODELLELEMENT DARSTELLUNG KURZBESCHREIBUNG Funktion Ausführung einer Tätigkeit Ereignis Prozessfluss Organisationseinheit Auslöser von und Ausgelöste in Prozessen Richtung der zeitlichen Abhängigkeiten Zuständigkeitsbeschreibung für Funktionen Informationsobjekt Ein- oder Ausgabeparameter von Funktionen Prozesswegweiser Verknüpfungsoperator Hilfsmittel zur Aufteilung von Modellen Steuerung des Prozessflusses Tabelle 2-1: Zusammenfassung der eepk-modellelemente [Sta06, Mor10] Das zentrale Modellelement der eepk ist die Funktion. Eine Funktion stellt die Soll-Leistung durch eine physische oder geistige Tätigkeit dar. Tätigkeiten werden bei Bedarf in mehreren Funktionen aufgeteilt modelliert (Zerlegung) oder mehrere Einzeltätigkeiten zu einer Funktion zusammengefasst (Aggregation). Die Zerlegung einer Tätigkeit wird nur so weit durchgeführt, wie es betriebswirtschaftlich sinnvoll ist, das heißt solange wie eine Funktion in einem Arbeitsschritt erledigt werden kann. Die Darstellung einer Funktion ist ein Quader mit abgerundeten Ecken und seiner Bezeichnung in der Mitte [KNS92, Sta06]. Das Modellelement Ereignis ist als betriebswirtschaftlich relevantes Ereignis zu verstehen, das die Abläufe im Unternehmen und speziell im Geschäftsprozess beeinflusst und steuert. Es stellt einen eingetretenen Zustand des Unternehmens dar [KNS92]. Ereignisse lösen Funktionen aus und werden von Funktionen ausgelöst. Für die Ausführung von Funktionen werden sie als Bedingung verstanden. Äquivalent zur Zerlegung oder Aggregation von Funktionen werden auch Ereignisse zerlegt bzw. zusammengefasst. Deren Struktur orientiert sich dabei

23 Grundlagen Seite 17 an die der mit ihnen verknüpften Funktionen. Ein Ereignis wird als Sechseck mit seiner Bezeichnung in der Mitte dargestellt [Sta06]. Ein Geschäftsprozess startet und endet immer mit einer Funktion und führt abwechselnd Ereignisauslösungen und Funktionsausführungen aus. Miteinander in Beziehung stehende Funktionen und Ereignisse werden mit gestrichelten, gerichteten Pfeilen dargestellt. Die gängige Modellierungskonvention für den Prozessfluss in der eepk ist die Darstellung von oben nach unten [Sta06, Mor10]. Das Modellelement Organisationseinheit beschreibt einen Teil der Organisationsstruktur eines Unternehmens, wie zum Beispiel eine Abteilung oder Stelle. Organisationseinheiten werden Funktionen zugewiesen und damit beschrieben, wer für die Erfüllung welcher Aufgaben verantwortlich ist. Bei Bedarf werden mehrere Organisationseinheiten einer Funktion zugewiesen. Die graphische Repräsentation solch einer Zuweisung ist eine ungerichtete Linie zwischen der Funktion und der Organisationseinheit. Eine Organisationseinheit wird durch ein Oval dargestellt, das eine vertikale Linie im linken Bereich und seine Bezeichnung enthält [Sta06]. Informationsobjekte sind Modellelemente zur Beschreibung der informationellen Umwelt oder der Datenbestände eines Unternehmens, wie zum Beispiel Auftrags- und Kundendaten oder Marktpreise. Informationsobjekte werden als Eingabeparameter und Ausgabeergebnisse von Funktionen modelliert und beschreiben damit, welche Informationen eine Funktion für ihre Durchführung braucht beziehungsweise welche Informationen die Funktion erzeugt. Die Funktion transformiert ihre Eingabeobjekte durch Lesen, Verändern, Löschen oder Erzeugen und gibt diese oder neue Objekte als Ausgabe zurück. Die Beziehung zwischen einer Funktion und einem Informationsobjekt wird durch einen gerichteten Pfeil graphisch dargestellt. Die Richtung des Pfeils gibt dabei an, ob ein Informationsobjekt als Eingabeparameter oder als Ergebnis einer Funktion definiert ist. Zeigt der Pfeil vom Informationsobjekt auf die Funktion, dient dieses als Eingabe. Zeigt der Pfeil anders herum von der Funktion auf das Informationsobjekt, ist dieses ein Ergebnis. Ein Informationsobjekt wird als ein Quader mit seinem Namen in der Mitte dargestellt [Sta06]. Das Modellelement Prozesswegweiser ist ein Hilfsmittel zur Aufteilung eines Geschäftsprozessmodells in mehrere Teilmodelle. Ein Prozesswegweiser wird in den Prozessfluss integriert und verweist auf ein anderes Geschäftsprozessmodell. Wird der Prozesswegweiser im Fluss erreicht, springt die weitere Ausführung an den Beginn des verknüpften Modells [Mor10]. Ein komplexer Prozessfluss wird mit dem Modellelement Verknüpfungsoperator modelliert. Dieses regelt im Sinne der Aussagenlogik den Prozessfluss und erlaubt die Modellierung von verzweigten, nebenläufigen und bedingten Ge-

24 Seite 18 Kapitel 2 schäftsprozessflüssen [Mor10]. Ein Verknüpfungsoperator wird in den Prozessfluss eingefügt und hat mehrere ein- und ausgehende Prozessflusskanten, wobei jeweils ein- und ausgehende Kanten entweder nur mit Funktionen oder nur mit Ereignissen verknüpft sind. Die eepk definiert UND- ODER- und XODER-Operatoren und verwendet für deren Kennzeichnung die äquivalenten Symbole aus der Aussagenlogik [Sta06]. Der UND-Operator definiert für eingehenden Prozessfluss, dass erst alle eingehenden Ereignisse eingetreten oder alle eingehenden Funktionen getätigt sein müssen, bevor der ausgehende Prozessfluss fortgesetzt wird. Für ausgehenden Prozessfluss definiert der Operator, dass alle ausgehenden Ereignisse eintreten oder alle ausgehenden Funktionen getätigt werden. Der ODER-Operator definiert, dass mindestens eines der eingehenden Ereignisse eingetreten oder eines der eingehenden Funktionen getätigt sein muss, bevor der ausgehende Prozessfluss fortgesetzt wird. Der XODER-Operator definiert, dass genau eines der eingehenden Ereignisse eingetreten oder genau eine der eingetretenen Funktionen getätigt sein muss, damit der ausgehende Prozessfluss fortgesetzt werden kann. Verknüpfungsoperatoren werden als Kreise dargestellt, die durch eine horizontale Linie zweigeteilt werden. Ober- und unterhalb der Linie wird jeweils mit einem Symbol dargestellt, wie eingehender Prozessfluss (oberes Symbol) oder ausgehender Prozessfluss (unteres Symbol) behandelt werden [Sta06]. Zum besseren Verständnis aller Anhängigkeiten der Elemente zeigt Abbildung 2-3 auf der folgenden Seite die vollständige Modellierung eines Geschäftsprozesses zur Überprüfung von Lagerkapazitäten. Der Prozess startet mit einer eintreffenden Anfrage, modelliert durch das Ereignis Anfrage eingetroffen. Darauf werden die beiden Funktionen Prüfung Fertigungskapazität und Prüfung Lagerbestand ausgeführt. Der modellierte UND-Verknüpfungsoperator gibt an, dass beide Funktionen ausgeführt werden. Für jede der beiden Funktionen ist jeweils eine Abteilung verantwortlich, welches durch die beiden Organisationseinheiten Fertigung und Lager beschrieben ist. Außerdem ist über die beiden Informationsobjekte Fertigungsdaten und Lagerdaten festgelegt, welche Daten die Funktionen als Eingabe für ihre Ausführung brauchen. Nach der Ausführung der Funktionen kann jeweils die Kapazität oder der Bestand entweder ausreichen oder nicht, was durch einen XODER-Verknüpfungsoperator dargestellt ist und zu den Ereignissen Kapazität reicht, Kapazität reicht nicht, Lagerbestand ausreichend und Lagerbestand zu gering führt. Das Auftreten eines dieser Ereignisse beendet den Prozess.

25 Grundlagen Seite 19 Abbildung 2-3: Geschäftsprozess Anfrage beantworten als eepk modelliert [NZ98, Sta06] Business Process Model and Notation Die Business Process Model and Notation (BPMN) ist ein von der Object Management Group (OMG)[Obj14a] verabschiedeter Standard zur Notation von Geschäftsprozessmodellen. Wie auch die UML ist die BPMN durch ein Metamodell formal definiert und hat ein exakt formuliertes Austauschformat, das die Bearbeitung von BMPN in zahlreichen unterschiedlichen Werkzeugen von verschiedenen Herstellern ermöglicht [Völ10]. Version 1.0 der Sprache wurde 2006 offiziell von der OMG verabschiedet [Obj06]. Version 2.0 wurde 2011 standardisiert [Obj11] und seit 2013 ist BPMN ein internationaler Standard [Int14]. Bei der Modellierung von Prozessen wird zwischen der fachlichen und der technischen Modellierung unterschieden. Die fachliche Modellierung hat als Ziel, Prozesse verständlich zu dokumentieren und zu kommunizieren. Die Prozesse werden hier nicht bis ins kleinste Detail vollständig aufgenommen, sondern nur soweit sie von Menschen gut verständlich sind. Die technische Modellierung dagegen hat den Anspruch, Prozesse vollständig abzubilden. Sie kommt dann zum Einsatz, wenn ein BPMN-Modell in ein maschinenlesbares Modell der Business Process Execution Language (BPEL) überführt und dann durch eine sogenannte Engine in einem Business Process Management System (BPMS) ausgeführt werden soll [All09]. Die BPMN konzentriert sich ausschließlich auf die Modellierung von Geschäftsprozessen und lässt andere Aspekte eines Unternehmens, wie zum Beispiel die Modellierung von Aufbauorganisation und IT-Landschaften, weitestgehend au-

26 Seite 20 Kapitel 2 ßen vor. Diese werden vielmehr mithilfe anderer Diagrammtypen, wie zum Beispiel dem Objekt- oder Klassendiagramm der UML [Oes12] modelliert. Die BPMN enthält jedoch Elemente, die sich auf Konstrukte dieser Diagrammtypen beziehen und wird oft mit anderen Diagrammtypen kombiniert. Im Folgenden werden die wichtigsten Modellelemente der BPMN und deren Verwendung vorgestellt. Als Elementnamen werden die von Freund et al. [FR12] vorgeschlagenen deutschen Bezeichnungen verwendet. Folgende Tabelle 2-2 gibt zunächst eine Übersicht der wichtigsten Modellelemente der BPMN. Die linke Spalte gibt den Name des Modellelements an, die mittlere seine visuelle Repräsentation und die rechte Spalte eine kurze Beschreibung des jeweiligen Elements. MODELLELEMENT DARSTELLUNG KURZBESCHREIBUNG Aufgabe Ausführung einer Tätigkeit Ereignis Sequenzfluss Gateway Auslöser von und Ausgelöste in Prozessen Richtung der zeitlichen Abhängigkeiten Steuerung des Sequenzflusses Pool Lane Zusammenfassung von Zuständigkeitsbereichen Repräsentant für Zuständigkeit Datenobjekt Datenassoziation Ein- und Ausgabeparameter von Aufgaben und Prozessen Steuerung des Datenflusses Tabelle 2-2: Zusammenfassung der BPMN-Modellelemente [FR12] Eine Aufgabe ist ein Modellelement, welches eine zu verrichtende Tätigkeit durch eine Person, Abteilung, Rolle oder ein IT-System repräsentiert. Es wird durch ein Quader mit abgerundeten Ecken und der Bezeichnung in seiner Mitte dargestellt. Komplexe Vorgänge werden durch mehrere Aufgaben modelliert, die durch den Sequenzfluss, der Definition einer zeitlich-logischen Reihenfolge der Aufgaben, miteinander in Form von Pfeilen verbunden sind [FR12].

27 Grundlagen Seite 21 Das Modellelement Ereignis ist das Äquivalent zu einem betriebswirtschaftlich verstandenen Ereignis. Als Beispiel ist in diesem Sinne Buchungsanfrage geht ein für ein Kino ein Ereignis. Ereignisse steuern die Prozesse, indem sie diese entweder starten und in Prozessen Reaktionen auslösen oder von Prozessen selbst ausgelöst werden. Startereignisse lösen Prozesse aus und stehen somit am Anfang des Sequenzflusses. Zwischenereignisse markieren den aktuellen Status eines Systems, zum Beispiel einen Meilenstein und werden vom Prozess ausgelöst. Endereignisse beschreiben den Status, der am Ende eines Prozesspfades erreicht wird. Zur Unterbrechung eines Sequenzflusses wird ein Ereignis an eine Aufgabe angeheftet, dargestellt durch die Platzierung eines Ereignisses an den Rand einer Aufgabe. Diese wird dann während ihrer Ausführung unterbrochen, wenn das Ereignis eintritt [FR12]. Ereignisse treten in verschiedenen Variationen auf und können durch einen Typ näher beschrieben werden. So gibt es zum Beispiel die Typen Nachricht, Zeit und Fehler. Nachrichtenereignisse werden zur Kommunikation zwischen Prozessen genutzt und werden mit einem Briefumschlagsymbol versehen. Ein von einem Prozess ausgelöstes Nachrichtensignal kann in einem anderen Prozess als Auslöser verwendet werden. Zeitereignisse dienen zur zeitabhängigen Steuerung von Prozessen und erhalten ein Uhrsymbol. Mithilfe dieser Ereignisse ist es möglich, Prozesse zu bestimmten Uhrzeiten, in Intervallen oder zu einem einmaligen Zeitpunkt zu starten oder zu bestimmten Uhrzeiten oder für eine gewisse Zeit zu unterbrechen. Fehlerereignisse dienen der Modellierung von möglichen auftretenden Fehlern in Prozessen, wie zum Beispiel der Erschöpfung eines Lagerbestandes. Fehlerereignisse erhalten ein Blitzsymbol zur Kennzeichnung [FR12]. Die Darstellungsform eines Ereignismodellelements ist ein Kreis mit seinem nach Typ variierendem Symbol darin. In der Nähe des Kreises werden bei Bedarf weitere textuelle Informationen angezeigt, wie zum Beispiel der Name bei Nachrichtenereignissen oder einer Uhrzeit bei Zeitereignissen [FR12]. Das Modellelement Gateway dient zur Steuerung des Sequenzflusses und erlaubt nebenläufige und bedingte Ausführung von Aufgaben. Es hat einen oder mehrere ein- und ausgehende Sequenzflüsse und tritt als XOR-, AND-, OR-, und komplexes Gateway auf. Das Gateway wird als Raute und einem typisierenden Symbol in seiner Mitte dargestellt. Bei einem XOR-Gateway mit mehreren ausgehenden Sequenzflüssen werden diese mit Bedingungen beschriftet. Nur genau dem Sequenzfluss wird gefolgt, dessen Bedingung erfüllt ist. Mehrere eingehende Sequenzflüsse werden zusammengeführt, so dass die Fortführung beginnt sobald einer der eingehenden Sequenzflüsse ankommt. Das Symbol eines XOR- Gateways ist ein Kreuz.

28 Seite 22 Kapitel 2 Das AND-Gateway ermöglicht parallele Ausführungen von Aufgaben. Eingehende Sequenzflüsse werden synchronisiert, d.h. der Sequenzfluss wird erst fortgesetzt, wenn alle eingehenden Sequenzflüsse angekommen sind. Das Symbol eines AND-Gateways ist ein Plus. Das OR-Gateway wird für selektives, paralleles Ausführen von Sequenzflüssen genutzt. Ausgehende Sequenzflüsse werden wie beim XOR-Gateway mit Bedingungen beschriftet. Alle Flüsse, deren Bedingung erfüllt ist, können nebenläufig ausgeführt werden. Eingehende Sequenzflüsse werden in dem Sinne synchronisiert, als dass nur auf diejenigen Flüsse gewartet wird, deren Bedingung bei der Aufteilung erfüllt war. Das Symbol eines OR-Gateways ist ein Kreis. Das komplexe Gateway wird dazu verwendet um Zusammenführungen von Sequenzflüssen zu modellieren, die mit keinem der drei anderen Gateway-Typen möglich ist. Komplex bedeutet in diesem Sinne, dass die Bedingung für die Weiterführung des Sequenzflusses als Anmerkung zum Gateway frei formuliert und entsprechend komplex ausfallen kann. Bei einer Zusammenführung von vier Sequenzflüssen ist beispielsweise die Anmerkung Mindestens zwei Eingaben akzeptieren eine einfache Möglichkeit um zu definieren, dass der Sequenzfluss erst nach zwei beliebigen angekommenen Sequenzflüssen fortgeführt werden kann. Bei bedingten aus Gateways ausgehenden Sequenzflüssen kann einer der Flüsse als sogenannter Standardfluss markiert werden und erhält in der Darstellung einen kleinen Strich auf seiner Linie. Dem Standardfluss wird immer nur dann gefolgt, wenn die Bedingungen aller anderen Flüsse nicht erfüllt sind. Verzweigungen von Sequenzflüssen lassen sich eingeschränkt auch ohne Gateway-Modellelemente darstellen. Unbeschriftete Flüsse, die direkt aus einer Aufgabe zeigen, werden wie AND-Gateways interpretiert und stellen damit Nebenläufigkeit dar. Beschriftete Sequenzflüsse mit einer kleinen Raute an ihrem Ursprung werden wie OR-Gateways interpretiert [FR12]. Die Modellelemente Pool und Lane dienen der Zuordnung von Verantwortlichkeiten. Eine Lane wird einer Rolle, Abteilung, IT-Anwendung oder Person aus dem Unternehmen zugeordnet. Für alle Aufgaben, die sich in einer Lane befinden ist die der Lane zugeordnete Entität verantwortlich. Pools sind Zusammenfassungen von Lanes und dienen damit zur Organisation der Verantwortungsbereiche. Die Begriffe des Pools und der Lane sind ein Analogon zu einem Swimmingpool (Pool) und seinen Schwimmbahnen (Lanes). Die visuelle Repräsentation eines Pools ist ein Quader mit seinem vertikal dargestellten Namen auf der linken Seite und einer Aufteilung durch horizontale Linien. Die Aufteilung ergibt eine Menge von Quadern, die die Lanes bezeichnen und ebenfalls links durch jeweils ihre vertikal dargestellte Bezeichnung beschriftet sind [FR12].

29 Grundlagen Seite 23 Datenobjekte sind Modellelemente, die für jede Art von Daten stehen, die im Prozess benötigt werden. Das sind unter anderem Papierdokumente, abstrakte Informationen oder elektronische Datensätze. Datenobjekte werden als Eingabeparameter und Ausgabeergebnisse von Aufgaben genutzt und graphisch als Papierseite mit einer abgeknickten Ecke dargestellt. Ein Datenobjekt wird immer mit seiner Bezeichnung und bei Bedarf mit einer kurzen Statusbeschreibung in eckigen Klammern beschriftet. Wird ein Datenobjekt als Ausgabe von einer Aufgabe erzeugt, wird dies mit einer gerichteten Datenassoziation, einem Pfeil mit gepunkteter Linie, dargestellt, welche von der Aufgabe auf das Datenobjekt zeigt. Anders herum wird ein Eingabeparameter als Datenobjekt mit einer Datenassoziation modelliert, welche vom Objekt auf die Aufgabe zeigt [FR12]. Die folgende Abbildung 2-4 zeigt beispielhaft, wie ein Geschäftsprozess mit der BPMN modelliert aussieht. Das Diagramm beschreibt den Prozess Bestellung bearbeiten eines Restaurants. In diesem Prozess sind zwei Personen, Kunibert und Alfons, involviert und als Lanes von dem Pool Restaurant zusammengefasst. Der Prozess beginnt mit dem Startereignis Bestellung eingegangen links oben. Kunibert führt daraufhin die Aufgabe Rezepte aussuchen durch und entscheidet dann, welche Speise zubereitet werden muss. Dies ist durch ein OR-Gateway modelliert. Kunibert kann sich hier also auch für mehr als eine Speise entscheiden, was von der eingegangenen Bestellung abhängig ist. Da diese hier nicht explizit modelliert ist, ist dieses Diagramm als fachliche Modellierung zu betrachten. Nach der Entscheidung wird die Aufgabe Pasta kochen von Kunibert oder die Aufgabe Salat anrichten von Alfons oder es werden beide Aufgaben durchgeführt. Das OR-Gateway kurz vor Ende des Prozesses sorgt dafür, dass auf den Abschluss aller Zubereitungen gewartet wird, bevor der Prozess durch das Endereignis Bestellung abgearbeitet beendet wird. Abbildung 2-4: Beispielgeschäftsprozess Bestellung bearbeiten in BPMN modelliert [FR12]

30 Seite 24 Kapitel OMEGA Geschäftsprozessmodell Die OMEGA-Methode umfasst neben der Erstellung und Neugestaltung von Geschäftsprozessmodellen auch die Modellierung der Aufbauorganisation [Fah95]. Diese Arbeit konzentriert sich jedoch auf die Geschäftsprozessmodellierung und stellt deshalb im Folgenden nur die dazu verwendete Modellierungssprache und deren Modellelemente vor. Folgende Tabelle 2-3 gibt zunächst eine Übersicht. MODELLELEMENT DARSTELLUNG KURZBESCHREIBUNG Geschäftsprozess Ausführung einer Tätigkeit Ein- / Ausgabe, enthält IT-Informationen Ein- / Ausgabe, enthält Informationen in Papierform Ein- / Ausgabe, enthält Informationen in mündlicher Form Zusammenfassung von Informationen unterschiedlicher Art Ein- / Ausgabe, repräsentiert verwendetes Material Verarbeitung von IT-Informationsobjekten Speicherung von Information in Papierform Speicherung und Zurverfügungstellung von Material Interaktionsobjekt außerhalb der Organisation Richtung der zeitlich-logischen Ausführung Steuerung des Ablaufplans IT-Informationsobjekt Papierinformationsobjekt Mündliches Informationsobjekt Informationsgruppe Materialobjekt IT-Applikation Papierspeicher Materialspeicher Externes Objekt Kommunikationsbeziehung Verknüpfungsoperator Tabelle 2-3: Übersicht der Modellelemente in der OMEGA-Prozesssprache [Fah95]

31 Grundlagen Seite 25 Geschäftsprozesse werden ähnlich wie bei der UML, den eepk und der BPMN als gerichtete Graphen modelliert und beschreiben jeweils eine Tätigkeit. Ein Geschäftsprozess besteht aus einer verzweigten, parallelen oder sequenziellen Abfolge von Unterprozessen, wobei jeder Unterprozess für sich beliebig komplex und somit auch ein ganz eigener Geschäftsprozess sein kann. Diese Abfolge wird Ablaufplan genannt und durch gerichtete Pfeile dargestellt, welche die Geschäftsprozesse in eine zeitlich-logische Beziehung setzen. Ein Geschäftsprozess wird durch seinen eindeutigen Namen identifiziert, so dass Aggregationsbeziehungen zwischen Geschäftsprozessen über die Vergabe und Verwendung gleicher Namen geschieht. Für Simulationszwecke besitzt der Geschäftsprozess eine Eigenschaft, die seinen Status beschreibt und durch einen der Werte aktiv, wartend oder beendet ausgeprägt ist. Die Darstellungsform eines Geschäftsprozesses ist ein Prozesspfeil in Form eines horizontalen Balkens mit einer Kerbe an der linken Seite und einer Spitze an der rechten Seite und dem Namen in der Mitte [Fah95]. Die Modellierung komplexer Ablaufpläne wird mittels Verknüpfungsoperatoren realisiert, welche den Ablaufplan um Und-, Oder-, und XOder-Verzweigungen/Vereinigungen bereichert. Ausgehende Pfeile aus Verzweigungen werden mit Bedingungen beschriftet, die zum Zeitpunkt der Prozessausführung erfüllt sein müssen damit diesen Pfeilen gefolgt werden kann. Bei Und-Verknüpfungen müssen die Bedingungen aller Pfeile erfüllt sein, damit fortgefahren werden kann. Bei Oder- reicht mindestens eine der Bedingungen. Bei XOder muss genau eine Bedingung erfüllt sein. Diesen Kommunikationsbeziehungen zwischen den Prozessen und den Verknüpfungsoperatoren werden Bearbeitungsobjekte zugewiesen. So wird nicht nur der Kontrollfluss modelliert, sondern auch bestimmt auf welche Art Prozesse miteinander kommunizieren [Fah95]. Der Folgende Abschnitt beschreibt die Bearbeitungsobjekte im Detail. Bearbeitungsobjekte sind Eingabeparameter und Ergebnisse von Prozessen und stellen dar, welche Informationen oder Materialien für die Durchführung eines Prozesses gebraucht werden und welche Informationen oder Materialien durch einen Prozess entstehen. Sie bilden die informationelle Schnittstelle zwischen Geschäftsprozessen indem die Ergebnisse eines vorhergehenden Prozesses von darauffolgenden Prozessen als Eingaben genutzt werden. Es gibt mehrere Typen von Bearbeitungsobjekten um die Art und Weise der Verarbeitung von Informationen zu modellieren. Das IT-Informationsobjekt stellt Informationen dar, die durch ein IT-System verarbeitet werden können. Ein elektronischer Datensatz ist ein Beispiel hierfür. IT-Informationsobjekte werden um das Attribut Format angereichert, welches zur näheren Kennzeichnung der Informationsverarbeitung und der Beurteilung von Kompatibilität und Austauschbarkeit

32 Seite 26 Kapitel 2 des Datensatzes dient. Das Modellelement wird als Kugel dargestellt, welche mit seinem Namen beschriftet ist. Das Papierinformationsobjekt steht für schriftliche Information auf Papier und kann zum Beispiel ein Formular, eine Rechnung oder ein Laufzettel oder aber eine Kopie eines IT-Informationsobjektes in Form eines Ausdrucks sein. Das Modellelement wird als Quadrat mit einer abgeknickten Ecke und seinem Namen in der Mitte dargestellt. Mündliche Informationsobjekte repräsentieren Informationen, die mündlich kommuniziert und möglicherweise nicht formal fixiert oder reproduzierbar sind. Der Einsatz von mündlichen Informationsobjekten deutet darauf hin, dass ein Prozess optimiert werden kann, weil informelle Kommunikation zwischen Prozessen fehleranfällig ist. Das Modellelement wird als Sprechblase dargestellt, die seinen Namen in der Mitte enthält. Die Informationsgruppe ist ein Modellelement, welches eine Kombination aus IT- Papier- und mündlichem Informationsobjekt darstellt. Es dient der Vereinfachung und Reduzierung von Geschäftsprozessmodellen mit vielen Bearbeitungsobjekten. Das Modellelement wird als eine Gruppe ihrer kombinierten Informationsobjekte dargestellt, also zum Beispiel aus einer Kugel und einer Sprechblase bei der Kombination eines IT- und eines mündlichen Informationsobjekts. Das Materialobjekt ist ein Ein- und Ausgabeobjekt von Prozessen in Form von Material so wie es zum Beispiel Veldspar für das Raffinieren in Tritanium in dem Wirtschaftssimulationsspiel Eve Online [Ccp13] ist. Materialobjekte werden als Pakete symbolisiert, welche mit ihren jeweiligen Namen beschriftet sind. Bearbeitungsobjekte werden bei Bedarf zum Zweck eines variablen Detaillierungsgrades aufgeteilt und aggregiert und dabei mit einem Beziehungsattribut gekennzeichnet, welches einen Verweis auf seine Bestandteile oder sein Aggregat enthält [Fah95]. Technische Ressourcen stehen im engen Zusammenhang mit Bearbeitungsobjekten und stellen dar, durch welche Ressourcen ein Prozess unterstützt wird. Einem Prozess werden eine oder mehrere technische Ressourcen zugewiesen. Bis auf das mündliche Informationsobjekt existiert zu jedem Bearbeitungsobjekt ein zugehöriger Speicher, welcher die Objekte des betreffenden Typs speichert und prozessübergreifend zur Verfügung stellt. Technische Ressourcen werden unterschieden in IT-Applikation, Papierspeicher und Materialspeicher. Eine IT-Applikation stellt ein Hard- oder Softwaresystem wie ein Computerterminal, eine Datenbank oder ein Enterprise-Resource-Planning

33 Grundlagen Seite 27 (ERP) -System [All09] dar. Es enthält die Eigenschaft Kapazität welche die Anzahl der verfügbaren Lizenzen eines Softwaresystems angibt und die Eigenschaft Plattform zur Spezifikation des eingesetzten Systems wie Betriebssystem, PC oder Workstation. Das Modellelement wird durch ein Symbol eines Computerbildschirms beschrieben mit seiner Bezeichnung darin. Der Papierspeicher steht für ein System zur Verwaltung von Papierinformationsobjekten. Er wird durch die Eigenschaften Standort und Art näher beschrieben. Die Art kann zum Beispiel eine Akte, ein Zentralarchiv oder eine Ablage sein. Das Modellelement wird durch einen Aktenschrank dargestellt, welcher mit seiner Bezeichnung beschriftet ist. Der Materialspeicher symbolisiert eine Ressource zur Lagerung von Materialobjekten, wie zum Beispiel eine Lagerhalle. Es enthält die Eigenschaft Standort näher spezifiziert. Das Modellelement wird durch ein Symbol einer Lagerhalle beschrieben, welches mit seiner Bezeichnung beschriftet ist. Ein externes Objekt beschreibt eine Person, Personengruppe, Rolle oder Institution, die nicht Teil des Unternehmens ist aber trotzdem mit deren Geschäftsprozessen in Relation steht. Es bildet die Schnittstelle zwischen dem Unternehmen und seiner Umwelt. Ein externes Objekt wird eindeutig durch seinen Namen beschrieben und enthält eine Eigenschaft, die deren Status beschreibt. Diese nimmt entweder die Werte aktiv oder nicht aktiv an und kommt bei Simulationen des Geschäftsprozess zum Einsatz. Ein externes Objekt wird als Sechseck mit seinem Namen in der Mitte dargestellt [Fah95]. Organisationseinheiten beschreiben den Verantwortlichkeitsbereich eines Prozesses und den mit ihm verknüpften Bearbeitungsobjekten und technischen Ressourcen. Eine Organisationseinheit kann zum Beispiel für einen Mitarbeiter stehen, eine Stelle oder eine Abteilung. Stets jedoch sind sie Teil des beschriebenen Unternehmens. Für jeden Prozess wird bestimmt, welche Organisationseinheit für dessen Ausführung verantwortlich ist und graphisch derart dargestellt, dass die Organisationeinheit als ein Quadrat dargestellt wird mit dem Namen der verantwortlichen Stelle links unten und dem zugehörigen Geschäftsprozesspfeil in seiner oberen Mitte. Zugehörige Bearbeitungsobjekte und technische Ressourcen werden ebenfalls innerhalb des Quadrats der Organisationseinheit dargestellt [Fah95]. In Abbildung 2-5 auf der nächsten Seite wird beispielhaft gezeigt, wie ein Geschäftsprozess Auftrag verarbeiten als OMEGA-Geschäftsprozessmodell aussieht. Der Prozess wird von einem Kunden außerhalb des Unternehmens angestoßen, modelliert durch ein externes Objekt links oben und beginnt mit dem

34 Seite 28 Kapitel 2 Prozess Auftrag erfassen auf der linken Seite. Dieser Prozess wird von der Verwaltung ausgeführt, welches durch eine Organisationeinheit dargestellt wird, und generiert ein IT-Informationsobjekt mit dem Namen Auftrag, der von der IT-Applikation ERP verarbeitet und gespeichert wird. Daraufhin wird mit dem Prozess Auftrag ausführen auf der rechten Seite fortgefahren. Die Produktion ist für diesen Teil des Prozesses verantwortlich und entsprechend durch eine Organisationseinheit repräsentiert. Der Prozess erzeugt ein Papierobjekt mit dem Namen Fertigungsbericht (Fert.-Bericht abgekürzt), das im Papierspeicher Akten abgelegt wird. Mit der Ablage ist der Prozess beendet. Abbildung 2-5: Beispielgeschäftsprozess Auftrag verarbeiten als Geschäftsprozessmodell in OMEGA-Notation [Fah95] OMEGA-Methode Die OMEGA-Methode ist eine Möglichkeit, um Geschäftsprozesse zu optimieren. Sie definiert ein systematisches Vorgehen und orientiert sich dabei am Ansatz des BPR, welches in Kapitel beschrieben ist. Im Folgenden werden zunächst die verwendeten Modelle und eingesetzte Modellierungssprachen beschrieben, dann auf das Vorgehen eingegangen und schließlich das Konzept des vorgeschlagenen Werkzeugs von Fahrwinkel [Fah95] erläutert Modelle Zur vollständigen Beschreibung der Organisations- und Ablaufstruktur eines Unternehmens werden in der OMEGA-Methode zwei Modelle verwendet. Das Modell zur Ablaufbeschreibung ist das OMEGA-Geschäftsprozessmodell, welches bereits ausführlich in Kapitel beschrieben und deshalb hier nicht noch einmal erläutert wird. Die Organisationsstruktur wird durch das Modell der Aufbauorganisation beschrieben, dessen Modellelemente und sein Aufbau im Folgenden vorgestellt wird.

35 Grundlagen Seite 29 Das Modell der Aufbauorganisation erfasst Personen und Personengruppen eines Unternehmens und setzt diese in Beziehung. Es besteht aus den Modellelementen Stelle, Abteilung und Team und deren Relationen zueinander. Diese Modellelemente werden unter dem Namen Organisationseinheiten zusammengefasst. Jedem der Modellelemente wird eine oder mehrere Personen eines Unternehmens oder eine oder mehrere Rollen zugewiesen. Zur genauen Quantifizierung der Personen zu einer Organisationseinheit enthalten die Modellelemente die Eigenschaft Kapazität [Fah95]. Die Stelle ist die kleinstmögliche Einheit in der Aufbauorganisation. Sie beschreibt typischerweise einzelne Personen oder Rollen. Eine Stelle wird über einen Typ genauer spezifiziert, welcher als Leistungsstelle, Stabstelle und ausführende Stelle ausgeprägt ist. Die Abteilung ist die Aggregation mehrerer Stellen oder Stellen und Abteilungen. Es gibt also kein explizites Element, welches Unterabteilung heißt. Dieses wird stattdessen implizit durch die Unterordnung von Abteilungen zueinander festgelegt. Das Modellelement Team dient der Zusammenfassung von Stellen, ähnlich wie es die Abteilung macht. Jedoch fasst ein Teamelement Stellen abteilungsübergreifend zusammen und enthält keine Abteilungen [Fah95] Vorgehen Das Vorgehen in der OMEGA-Methode lehnt sich an die des BPR an und enthält entsprechend ebenso die Phasen Ist-Erfassung, Analyse, Soll-Konzeption und Umsetzung. Sie geht jedoch nicht auf diese Phasen im Speziellen ein, sondern definiert vor allem den Vorgang des Modellaufbaus [Fah95]. Dieser Vorgang wird im Folgenden genauer erläutert. Zum Zweck der Geschäftsprozessoptimierung werden in der Phase Ist-Erfassung die Prozesse eines Unternehmens in einem abstrakten Modell erfasst. Diese Modelle werden in der Phase Soll-Konzeption im betriebswirtschaftlichen Sinn verbessert, indem sie neu entworfen oder geändert werden. Diese Modelle spielen in der BPR also eine zentrale Rolle und werden in der OMEGA-Methode in mehreren Schritten aufgebaut. In der Phase Ist-Erfassung wird zunächst das Modell der Aufbauorganisation modelliert und dann das Modell der Prozessorganisation. In der Phase Soll-Konzeption ist das Vorgehen anders herum, denn der Fokus liegt hier auf der Optimierung der Abläufe [Fah95]. Da das Vorgehen bei der Modellerstellung nicht immer gleich ist, werden im Folgenden die einzelnen Phasen weitestgehend unabhängig voneinander vorgestellt und in der Reihenfolge der Ist-Erfassung beschrieben. Die folgende Abbildung 2-6 zeigt, wie die OMEGA-Methode das Vorgehen für die Phase Ist-Erfassung definiert.

36 Seite 30 Kapitel 2 Abbildung 2-6: Vorgehen der OMEGA-Methode [Fah95] Zunächst wird in der Phase Entwicklung Modell der Aufbauorganisation die Aufbauorganisation abgebildet, welches in den meisten Unternehmen bereits dokumentiert ist. Die Modellierung der Aufbauorganisation erfolgt durch die Aufteilung des Unternehmens in Gruppen, die Abteilungen, Teams und Stellen genannt werden. Diese werden zueinander in Beziehung gesetzt indem festgelegt wird, welche Stelle zu welchem Team gehört, welchen Abteilungen ein Team zugeordnet ist und aus welchen Abteilungen das Unternehmen besteht. Aus dieser Aufteilung ergeben sich die Aggregationsebenen der Aufbauorganisation wobei die höchste Aggregationsebene das Gesamte Unternehmen darstellt und die Niedrigste die Summe aller Stellen [Fah95]. In der Phase Entwicklung Modell der Prozessorganisation wird die Prozessorganisation festgelegt. Dieses passiert im Kontext einer konkreten Aggregationsebene, das heißt der Modellierer bestimmt selbst die Granularität der Modellierung. Die Ausarbeitung aller Aggregationsebenen findet später in der Phase Aufbau Aggregationsebenen statt. Zunächst werden die Geschäftsprozesse erzeugt und gemäß ihrer zeitlich-logischen Reihenfolge angeordnet. Anschließend werden den Prozessen die von ihnen genutzten technischen Ressourcen zugewiesen.

37 Grundlagen Seite 31 Dann folgen die Definition der externen Objekte und die Verbindung aller externen Objekte und Geschäftsprozesse miteinander durch die Erzeugung der Kommunikationsbeziehungen. Einhergehend erhalten die Kommunikationsbeziehungen die mit ihnen assoziierten Bearbeitungsobjekte die gleichzeitig damit als Ein- und Ausgabeobjekte der Geschäftsprozesse definiert werden [Fah95]. Die darauffolgende Phase heißt Entwicklung Geschäftsprozessmodell und ist der Zeitpunkt, an dem die Modelle der Aufbauorganisation und der Prozessorganisation zusammengeführt werden. Jedem Geschäftsprozess wird dazu eine der bereits modellierten Organisationseinheiten zugewiesen. Mehrere Geschäftsprozesse können von der gleichen Organisationseinheit bedient werden [Fah95]. In der letzten Phase Aufbau Aggregationsebenen werden schließlich ausgehend von der bisher modellierten Ebene die höheren und tieferen Aggregationsebenen erstellt. Damit erhält das Modell die Fähigkeit, in verschiedenen Sichten mit einem variablen Detaillierungsgrad untersucht werden zu können. Bei Bedarf wird entweder eine vollständige Aggregation durchgeführt, bei der sowohl die aggregierte oder dekomponierte Aufbau- und Prozessorganisation zu einem vollständigen Geschäftsprozess erstellt wird, oder eine geschäftsprozessbezogene Aggregation, die nur die Geschäftsprozessstruktur über mehrere Ebenen aufbaut, das vollständige Geschäftsprozessmodell jedoch auf dem Detaillierungsgrad der bereits modellierten Ebene belässt [Fah95]. In der folgenden Abbildung 2-7 ist schematisch dargestellt wie die Aggregationsebenen von Aufbau- und Prozessorganisation miteinander zusammenhängen. Das Schaubild ist in drei Spalten aufgeteilt. Die erste Spalte zeigt die Aufbauorganisation mit ihrer Dekomposition von oben nach unten beziehungsweise ihre Aggregation von unten nach oben. Die zweite Spalte zeigt dasselbe für die Prozessorganisation. Die dritte Spalte enthält zu jeder Aggregationsebene eine kurze Beschreibung. Abbildung 2-7: Aggregationsebenen von Aufbau- und Prozessorganisation bei vollständiger Aggregation [Fah95]

38 Seite 32 Kapitel 2 Die Aufteilung in verschiedene Aggregationsebenen mit unterschiedlichem Detaillierungsgrad soll helfen, Geschäftsprozesse zum besseren Verständnis an den gewünschten Stellen zu abstrahieren. Daher muss jede Aggregationsebene ein vollständiges Abbild des Geschäftsprozessmodells sein. Mit der Erzeugung der gewünschten Aggregationsebenen ist der Vorgang des Modellaufbaus abgeschlossen [Fah95] Vorgeschlagenes Modellierungswerkzeug Fahrwinkel skizziert im Zuge der OMEGA-Vorgehensdefinition ein Konzept zu einem computergestützten Modellierungswerkzeug, welches die Arbeit mit OMEGA-Modellen vereinfachen soll. Mit dessen Hilfe können OMEGA-Modelle digital erstellt, bearbeitet, verwaltet und analysiert werden [Fah95]. Das Werkzeug ist als Client-Server-Architektur konzipiert mit dem Ziel eines geregelten Datenzugriffs durch die Speicherung aller Modelldaten an einer zentralen Stelle. Der Server ist für diese Datenhaltung zuständig. Der Client ist für die Visualisierung und Interaktion mit den Modellen gedacht. Fahrwinkel beschreibt voranging die Client-Komponente und geht nicht weiter auf den Server ein [Fah95]. Das Visualisierungskonzept Fahrwinkels sieht eine dreidimensionale Darstellung der OMEGA-Modelle gemäß ihrer Definition vor. Im Gegensatz zu Visio [Hel13] oder anderen Werkzeugen zur Bearbeitung von zweidimensionalen graphischen Sprachen wird der Aktionsraum in Fahrwinkels Werkzeug daher nicht als Arbeitsfläche sondern als Arbeitsraum bezeichnet. Dieser Arbeitsraum ist eine 3D-Umgebung und wird in mehrere Darstellungsebenen untergliedert. Jede Darstellungsebene zeigt jeweils das Modell ganzheitlich in einem bestimmten Detaillierungsgrad an und kann mittels einer virtuellen Kamera aus verschiedenen Perspektiven betrachtet werden. Zur selektiven Betrachtung wird eine gewünschte Ebene als aktiv gesetzt und die Kamera darauf fokussiert. Andere Ebenen werden hintergründig dargestellt und können transparent geschaltet oder ausgeblendet werden. Die Abbildung 2-8 zeigt auf der nächsten Seite schematisch, wie die Darstellungsebenen in Fahrwinkels Werkzeugkonzept angeordnet sind. Die oberste Ebene ist transparent geschaltet und erlaubt den Blick auf die zweite Ebene, welches im Fokus der Kamera liegt und als aktiv gesetzt ist. Darunter werden Ebenen anderer Detaillierungsgrade angeordnet [Fah95].

39 Grundlagen Seite 33 Abbildung 2-8: 3D-Darstellungsebenen im Werkzeug von Fahrwinkel [Fah95] Die virtuelle Kamera ist die Navigationsmethode des Werkzeugs und erlaubt eine freie Bewegung durch den Arbeitsraum auf allen drei Achsen. So kann beliebig nah an Objekte herangefahren oder ein Modellteil selektiv angeschaut werden. Durch eine perspektivische Projektion des Arbeitsraumes erscheinen Objekte kleiner je weiter weg sie sich vom Betrachter befinden. Dadurch ist eine weitere Form der selektiven Darstellung möglich. Neben dieser freien Navigation beschreibt Fahrwinkel eine sogenannte gesteuerte Navigation. Dabei wird zunächst das Objekt des Interesses markiert. Die virtuelle Kamera richtet sich daraufhin so aus, dass dieses Objekt in der Mitte des Bildschirms fokussiert angezeigt wird. Bei der Markierung einer Kommunikationsbeziehung bewegt sich die Kamera anhand des Pfeils durch den Aktionsraum indem zunächst der Anfang und dann das Ende des Pfeiles fokussiert werden. Diese Kamerabewegungen und Ausrichtungen geschehen als animierte Kamerafahrt und verhindern so, dass der Anwender die Orientierung im 3D-Raum durch sprunghafte Perspektivwechsel verliert [Fah95]. Das Konzept zur Interaktion mit Modellelementen beschreibt Fahrwinkel mithilfe von in den 3D-Arbeitsraum integrierten Interaktionselementen. Das Werkzeug verfügt also nicht über 2D-Menüleisten oder ähnliche herkömmliche Bedienelemente, sondern lässt den Anwender alle Aktionen direkt im 3D-Raum ausführen. Dazu stellt Fahrwinkel den sogenannten Operationswürfel vor. Dieser ist wie die virtuelle Kamera ein Bestandteil des Arbeitsraumes und bewegt sich im 3D-Raum so, dass er unabhängig von der Kameraposition und Ausrichtung stets sichtbar bleibt. Auf allen sechs Seiten des Würfels befinden sich Interaktionselemente wie Schaltflächen oder Texteingabefelder. Diese werden je nach Ausrichtung durch Drehen des Operationswürfels sichtbar. Der Operationswürfel ist kontextsensitiv und zeigt je nach markiertem Modellelement unterschiedliche Funktionalitäten an. Ist zum Beispiel ein Geschäftsprozessele-

40 Seite 34 Kapitel 2 ment ausgewählt, wird die Schaltfläche zur Anzeige von Unterprozessen angezeigt. Zusätzlich zum Operationswürfel stehen weitere Funktionalitäten durch Kontextmenüs auf Modellelementen zur Verfügung. Ein Rechtsklick auf eine Kommunikationsbeziehung macht zum Beispiel die Funktionalität sichtbar, mit deren Hilfe Bearbeitungsobjekte zur Kommunikationsbeziehung hinzugefügt werden [Fah95] D-Modellierung Das folgende Kapitel stellt einige Konzepte und Arbeiten aus der Literatur über die Modellierung im dreidimensionalen Raum vor. Das Wort 3D-Modellierung setzt sich als Kombination aus zwei Begriffen zusammen und wird in dieser Arbeit durch folgende Definitionen bestimmt. Für den Begriff 3D wird die Definition von Watt [Wat00] benutzt, der 3D als den Bereich beschreibt, der sich mit dem Prozess der Umwandlung von einer mathematischen oder geometrischen Beschreibung eines Objektes einem Computergrafikmodell in eine Visualisierung eine zweidimensionale Projektion die die Erscheinung eines realen Objektes simuliert, befasst [Wat00]. Modellierung wird hier als der Prozess der Modellbildung verstanden. Ein Modell ist nach Kastens und Kleine Büning [KK05] die Abstraktion eines realen Objektes als vereinfachtes, stilisiertes Abbild. So ist die Zeichnung eines Schiffes zum Beispiel in diesem Sinne ein Modell eines realen Schiffes [KK05]. Im Kontext dieser Arbeit ist in Bezug auf Modellierung besonders die Geschäftsprozessmodellierung interessant. Diese wird wie im Kapitel beschrieben mit Hilfe von graphischen Notationen durchgeführt. Die folgenden Abschnitte beziehen sich daher auf die computergestützte Erzeugung von grafischen Modellen im dreidimensionalen Raum und die damit verbundenen Vorteile und Probleme D Visualisierung zur Verständlichkeitsförderung Die Erstellung von immer größeren und immer komplexeren Modellen macht es immer schwieriger, ein Modell als Ganzes zu erfassen und zu verstehen. Besonders der Einsatz von Verschachtelungen und die Bildung von Hierarchien führen zu einer Segmentierung des Modells und zu einer hohen kognitiven Belastung des Betrachters beim Behalten der Modellstruktur. Herkömmliche Werkzeuge bieten nicht das Maß an Unterstützung, um dieses Problem zu lösen und machen eine manuelle Traversierung durch die Modellhierarchien durch den Benutzer notwendig. Krolovitsch und Nilsson [KN09] versuchen diese kognitive Belastung durch eine dreidimensionale Visualisierung von Modellen zu reduzieren. Sie entwickelten dazu einen sogenannten 3D-Model-Visualizer, welcher UML- Modelle von Zustandsmaschinen und Sequenzdiagrammen anzeigt und führten

41 Grundlagen Seite 35 dazu Benutzertests durch. Diese zeigten, dass eine 3D-Visualisierung von Modellen einen positiven Einfluss auf die Verständlichkeit hat [KN09]. Die Entwicklung des 3D-Model-Visualizers erfolgte in drei Phasen mit jeweils den Schritten Interview, Anforderungsdefinition und Entwicklung. In der ersten Phase wurden die Benutzer zunächst nach Verbesserungsvorschlägen zu herkömmlichen Werkzeugen und ihren Erwartungen bezüglich einer 3D-Darstellung von Modellen befragt. Daraus formulierten Krolovitsch und Nilsson die Anforderungen der ersten Entwicklungsphase des Prototyps und entwickelten diesen. Der Prototyp wurde dann in der zweiten Phase zunächst den Benutzern vorgeführt und diese interviewt. Die daraus entstandenen Transkriptionen wurden einer qualitativen Analyse unterzogen und daraus neue Anforderungen formuliert. Die dritte Phase ist eine Wiederholung der zweiten und diente der weiteren Verfeinerung der Anforderungen. Während der Prototypentwicklung wurden unter anderem diese Anforderungen ermittelt und klassifiziert [KN09]: Visualisierung: Ein Diagramm soll als 3D-Visualisierung dargestellt werden, Visualisierung: Die Zusammenhänge zwischen Ober- und Unterdiagrammen sollen dargestellt werden, Navigation: Eine klassische Baumstruktur soll den Aufbau des Diagramms in einer Übersicht anzeigen und zur Navigation genutzt werden können, Navigation: Es soll eine freie 3D-Navigation möglich sein, so dass sich die virtuelle Kamera beliebig positionieren lässt, Interaktion: Teile des Diagramms sollen ein- / und ausblendbar gemacht werden können, Interaktion: Per Doppelklick soll ein Element durch die virtuelle Kamera fokussiert werden können. Diese Anforderungen wurden sukzessive in jeder Phase gewonnen und der Prototyp danach jeweils entsprechend modifiziert. Die Idee des Prototyps ist es, die hierarchischen Strukturen eines Diagramms von einer 2D- in eine 3D-Perspektive zu bringen. Anders als herkömmliche Werkzeuge, die jeweils nur eine Hierarchieebene gleichzeitig in einem Fenster oder einem Reiter anzeigen, ist der 3D-Model-Visualizer in der Lage das komplette Modell inklusiver aller Hierarchien gleichzeitig anzuzeigen. Die folgende Abbildung 2-9 zeigt die Darstellung einer Zustandsmaschine als 3D-Diagramm.

42 Seite 36 Kapitel 2 Abbildung 2-9: 3D-Model-Visualizer von Krolovitsch und Nilsson [KN09] Zu sehen ist in dieser Abbildung eine Zustandsmaschine mit dem Namen State- Machine1. Sie ist über mehrere Ebenen auf den X-Z-Achsen verteilt. Die oberste Ebene zeigt die Zustandsmaschine ohne Unterdiagramme und nur einem Zustand. Räumlich darunter, auf der Abbildung mittig dargestellt, ist die Konkretisierung dieses einen Zustandes zu sehen. Dieses Unterdiagramm besteht selbst aus mehreren Zuständen und Verbindungspfeilen und ist über eine Linie mit der obersten Darstellung der Zustandsmaschine verbunden. Noch weiter unten sind weitere Konkretisierungen und Unterdiagramme zu sehen. Diese beziehen sich jeweils auf einen Zustand aus der mittleren Zustandsmaschine und sind ebenfalls mit Linien verbunden um deren Zugehörigkeit darzustellen [KN09]. Krolovitsch und Nilsson implementierten den Prototyp einmal als Visualisierung von Zustandsmaschinen und einmal als Visualisierung von Aktivitätsdiagrammen. Die weiter oben dargestellten gewonnenen Anforderungen aus den Benutzertests beziehen sich auf die Auswertung beider Prototyparten D-UML im Browser Während Krolovitsch und Nilsson [KN09] zeigen, dass eine dreidimensionale Darstellung von UML-Diagrammen dem Verständnis von komplexen Sachverhalten dienlich ist, konzentriert sich McIntosh [McI09] auf eine plattformunabhängige Realisierung eines Werkzeugs zur Darstellung von dreidimensionalen UML-Diagrammen. Der Fokus von McIntoshs Arbeit liegt dabei auf der Visualisierung von Zustandsautomaten mit Hilfe von X3D, einem Standard zur Definition von 3D-Inhalten [McI09].

43 Grundlagen Seite 37 X3D wurde 2001 vom W3C-Konsortium [Www14] als Standard für 3D-Inhalte im Internet verabschiedet. Es handelt sich um eine auf XML basierende Beschreibungssprache für 3D-Modelle und wird unter anderem im Ingenieurswesen, für Visualisierungen, Präsentationen und in der Unterhaltungsbranche für Spiele eingesetzt. Die Sprache ist mit dem Ziel konzipiert, 3D-Inhalte auf vielen unterschiedlichen Plattformen darstellbar und nutzbar zu machen [Web13]. McIntosh verbindet die Standards UML und X3D miteinander und implementiert einen Prototyp, der durch die Kombination bewährter Standards auf möglichst vielen Soft- und Hardwaresystemen laufen soll. Dazu erweitert er zunächst die UML mithilfe des XMI (XML Metatata Interchange)-Modells [Obj14b] und fügt den Modellelemente zusätzliche Attribute hinzu, wie zum Beispiel eine z - Komponente für Punktdefinitionen, die damit dann nicht nur im 2D- sondern auch im 3D-Raum genutzt werden können [McI09]. Danach wendet McIntosh die Methode Sequential Evaluation [GDS99] an, eine Methode durch die mit möglichst wenig Kosten und Aufwand in einem iterativen Prozess ein qualitativ hochwertiger Prototyp entwickelt wird. Der Prozess wird durch qualitative und quantitative Auswertungen von Benutzertests begleitet und ist so angelegt, dass die Umsetzung von Anforderungen anfangs mit einfachen Techniken versucht wird und erfolgsversprechende Ansätze im Laufe der Zeit immer feiner und aufwendiger implementiert werden [McI09]. Die erste Version von McIntoshs Prototyp zeigte zwar eine Zustandsmaschine als 3D-Visualisierung, jedoch war diese lediglich als flache Ebene in einem 3D- Raum abgebildet. Trotzdem bewerteten die Benutzer diese einfache Transformation in den 3D-Raum bereits als vorteilig gegenüber der klassischen 2D-Ansicht. Eine freie Positionierung im Raum und die damit einhergehende wechselbare Perspektive auf das Diagramm wurden zum Beispiel als nützlich für eine selektive Betrachtung von Teildiagrammen empfunden. Die Benutzer formulierten Anforderungen zur verbesserten Darstellung von Diagrammhierarchien und machten Verbesserungsvorschläge zur Darstellung und Anordnung von Diagrammen und Diagrammelementen. In weiteren Versionen des Prototyps implementierte McIntosh daraufhin eine hierarchische Darstellung von Zustandsdiagrammen. Diese und deren Unterdiagramme wurden auf verschiedenen Ebenen angezeigt und je nach Ebene unterschiedlich positioniert. Die Anforderungen aus den Benutzertests machten deutlich, dass vor allem der Zustandsübergang zwischen Zustandsmaschinen unterschiedlicher Hierarchieebenen eine zentrale Rolle beim Verständnis der Diagramme spielt. McIntosh implementierte daraufhin einen visuellen Zugehörigkeitsindikator in Form von Schatten, die ein Zustand auf seine Untergeordnete Zustandsmaschine wirft. Der finale Prototyp visualisiert hierarchische Zustandsmaschinen als ein Baum von 2D-Ebenen im 3D-Raum, wobei die Ebenen so positioniert werden, dass versucht wird, die

44 Seite 38 Kapitel 2 Überschneidungen von Ebenen aus verschiedenen Perspektiven zu minimieren [McI09]. Abbildung 2-10 zeigt ein Bildschirmfoto aus einer der letzten Versionen von McIntoshs Prototyp. Es zeigt die Darstellung einer Zustandsmaschine mit Unterzustandsmaschinen in vier Hierarchieebenen. Die oberste Ebene ist auf der rechten Seite abgebildet. Sie besteht aus einigen Zuständen und Kontrollflüssen, wie dem Zustand working. Dieser repräsentiert seinerseits einen komplexen Ablauf, welcher durch eine eigene Zustandsmaschine modelliert ist. Sie ist eine Stufe unter der obersten Ebene abgebildet und dem Zustand durch einen schattenartigen Pfeil zugeordnet. Die Zustandsmaschine besteht ebenfalls aus mehreren Zuständen, von denen einer wiederum einen komplexen Ablauf symbolisiert. Auf diese Weise sind zwei weitere Ebenen mit jeweils einer Zustandsmaschine auf den unteren Stufen abgebildet. Die unterste Zustandsmaschine ist auf der Abbildung links unten zu sehen und enthält keine weiteren Referenzen. Durch die perspektivische Projektion der 3D-Szene erscheinen die Zustände im Vordergrund (die oberste Zustandsmaschine auf der rechten Seite) am größten, während mit zunehmender Spezialisierung der Zustandsbeschreibungen nach unten die Zustände immer kleiner und schwieriger zu entziffern sind. Durch die freie Kamerapositionierungsmöglichkeit kann der Benutzer jedoch jeden beliebigen Teil des Diagramms in den Fokus der virtuellen Kamera bewegen und damit eine selektive Betrachtung von für ihn wichtigen Teilen und Ausblendung von unwichtigen Teilen umsetzen [McI09]. Abbildung 2-10: 3D-UML-Visualisierung von McIntosh [McI09]

45 Grundlagen Seite Mehrbenutzer-Interaktion Der Begriff der Mehrbenutzer-Interaktion ist für diese Arbeit definiert als eine computergestützte gleichzeitige Bearbeitung von virtuellen Objekten von mehreren Personen und deren Kommunikation in einem verteilten System. Die Benutzer solch eines Systems können also räumlich voneinander getrennt sein, kommunizieren über Text, Ton oder Bild und sind sich den Aktionen anderer Benutzer bewusst, indem das System diese Aktionen in visueller oder auditiver Form präsentiert. Ein einfaches Beispiel von Mehrbenutzer-Interaktion in diesem Sinne ist das Chatten, bei dem mehrere Benutzer gleichzeitig eine schriftliche Kommunikation ausüben und Fortführungen anderer Benutzer direkt lesen können. Ein System, das Mehrbenutzerinteraktion erlaubt wird kollaboratives System genannt. Dieses Kapitel stellt einige Konzepte zur Mehrbenutzerinteraktion und den damit verbundenen Schwierigkeiten vor Kollaborative Systeme Die Definition eines kollaborativen Systems (engl. groupware) basiert in dieser Arbeit auf der von Sohlenkamp [Soh99]. Er versteht es als,,[ ] being any software supporting the cooperation of several users through the computer medium. [Soh99], also jede Software, die Kooperation mehrerer Benutzer durch das Medium Computer unterstützt. Im Weitesten Sinne kann diese Definition jedoch auf fast jede Software angewendet werden, denn selbst Single-User-Applications 3 wie zum Beispiel die Open-Source-Lösung LibreOffice [Doc14] werden in der Praxis dazu genutzt um im Team an Dokumenten zu arbeiten, wobei die Kommunikation und der Datenaustausch nicht über die Software realisiert ist. Die Definition von Sohlenkamp wird aus diesem Grunde für diese Arbeit eingegrenzt auf Softwaresysteme, die das gemeinsame Arbeiten im Sinne der anfangs definierten Mehrbenutzerinteraktion erlauben und integrierte Funktionalitäten zum Datenaustausch und Kommunikation beinhalten. Ein sehr abstraktes Beispiel für ein kollaboratives System ist das World Wide Web. Es erlaubt sowohl den verteilten Datenaustausch als auch Kommunikation zwischen vielen Benutzern. Je nach ausgestalteter Webapplikation lassen sich die Kommunikationsformen konkretisieren und reichen von einfachem Nachrichtenaustausch in Internetforen über Echtzeit-Textübermittlung in Chats bis hin zur Videokonferenz wie bei Hangouts [Goo14b]. Da sich diese Arbeit auf 3 Programme, die so konzipiert sind, dass deren Instanz immer nur maximal ein Benutzer gleichzeitig ausführen kann.

46 Seite 40 Kapitel 2 Systeme konzentriert, mit deren Hilfe die Bearbeitung von Objekten im Mittelpunkt steht, werden Seiten wie Google+ [Goo14c] oder Facebook [Fac14] nicht als kollaborative Systeme angesehen. Im späteren Verlauf werden einige konkrete Beispiele von kollaborativen Systemen genannt und deren Merkmale beschrieben Awareness Zur Interpretation von Objekten und der effektiven Bearbeitung von Aufgaben ist es für den Benutzer eines kollaborativen Systems wichtig zu wissen, wer von den anderen Benutzern welche Aufgabe wann bearbeitet und wie diese Ergebnisse die eigene Aufgabe beeinflussen. Dieses Wissen über die Anwesenheit, Aktivität und Verfügbarkeit von Mitgliedern der Arbeitsgruppe wird von Gutwin et al. [GGR96] als Awareness (Bewusstsein) bezeichnet. Die englische Bezeichnung hat sich für diesem Begriff in der Literatur durchgesetzt [Soh99]. Um die Effektivität eines kollaborativen Systems zu steigern, ist es notwendig die Awareness deren Benutzer zu fördern. Die technische Herausforderung dabei ist es, Informationen von anderen Benutzern zu erfassen, zu verarbeiten und zu präsentieren, so dass die Privatsphäre der einzelnen Benutzer gewahrt und sie nicht durch zu viele Informationen in ihrer Arbeit gestört werden. Gross et al. [GST05] schlägt dazu ein Entwicklungsverfahren von kollaborativen Systemen vor, welches nicht funktionsorientiert ist, sondern als human-centered bezeichnet wird und sich die Erkenntnisse aus den Sozialwissenschaften zunutze macht. Dazu wird der Begriff der Awareness näher untersucht und bestehende Systeme auf deren Unterstützung von Awareness untersucht [GST05]. Abbildung 2-11: Die Arten von Awareness nach Gutwin et al. [GGR96] Abbildung 2-11 zeigt eine Kategorisierung verschiedener Arten von Awareness und deren Zusammenhänge. Jede Art von Awareness ist durch eine Kreisfläche symbolisiert. Überschneidende Flächen zeigen, dass Awareness nicht immer in eine einzelne Kategorie einsortiert, sondern möglicherweise mehreren Katego-

47 Grundlagen Seite 41 rien angehören kann. Als informelle Awareness wird das allgegenwärtige Erfahren und Bemerken von Benutzern und Tätigkeiten in unmittelbarer Nähe bezeichnet. Soziale Awareness ist das Wissen über das Interesse, die Aufmerksamkeit und den emotionalen Gemütszustand von Kommunikationspartnern. Diese Informationen werden durch Augenkontakt, Gesichtsausdruck und Körperhaltung vermittelt. Die Awareness der Gruppenstruktur wird durch Informationen über die Status und Verantwortlichkeiten von Gruppenmitgliedern und deren Beziehungen untereinander gewonnen. Die Awareness des Arbeitsraums betrifft die Kenntnis über den Arbeitsraum an sich, den darin enthaltenen Objekten und den Interaktionen anderer Benutzer mit eigenen geteilten Objekten [GGR96]. Bei der Ausarbeitung des Entwicklungsverfahrens zu kollaborativen Systemen bedient sich Gross et al. eines Fragenkatalogs von Gutwin und Greenberg [GG99], dessen Beantwortung Aufschluss über die Qualität der Awareness eines Benutzers gibt. Je mehr Fragen der Benutzer beantworten kann, desto besser ist seine Awareness [GG99]. Tabelle 2-4 listet einige dieser Fragen auf. Die gesamte Tabelle ist im Anhang abgedruckt. FRAGE Ist jemand im Arbeitsraum? Wer tut was? Welches Ziel hat eine Aktivität? Wer schaut worauf? Wer kann was sehen? Wie kam das Objekt in diesen Zustand? Wann passierte ein Ereignis? Was hat eine Person getan? Tabelle 2-4: Auszug aus dem Fragenkatalog zur Awareness nach Gutwin und Greenberg [GG99] Zur Förderung von Awareness gibt es in der Literatur bereits zahlreiche Vorschläge, die bewusst oder unbewusst bereits einige der Fragen von Gutwin und Greenberg adressieren. Greenhalgh und Benford [GB95] implementierten 3D- System in dem der Fokus der Aufmerksamkeit der Benutzer im Vordergrund steht. Sohlenkamp und Chwelos [SC94] schlagen eine synchrone Präsentation

48 Seite 42 Kapitel 2 von Verfügbarkeitsdaten zwischen Benutzern und Benutzergruppen vor. Loevstrand [Loe91] zeigt, dass Awareness-Daten die Effektivität von Kommunikation in Gruppen erhöht. Fuchs et al. [FPP95] schlägt vor, dass Awareness durch so genannte Ereignisse geschaffen wird. Ereignisse sind Nachrichten, die einen Benutzer über die Aktivität anderer Benutzer informieren. Borning und Travers [BT91] schlagen vor, dass Benutzer selbst entscheiden können, welche Awareness-Informationen über sie an andere Benutzer gesendet werden. Weiter untersucht Gross et al. kooperative Systeme, welche Funktionalitäten liefern, die die Awareness bei Benutzern erhöhen und listet diese auf. Diese Funktionalitäten sind eine Sammlung aus verschiedenen Systemen und konkrete Beispiele dafür, wie Awareness gefördert wird. Gross et al. ordnet jeder Funktionalität den Typen der Awareness zu, der jeweils gefördert wird. Tabelle 2-5 listet einige dieser Funktionalitäten auf. BESCHREIBUNG DER FUNKTIONALITÄT Alle Benutzeraktionen werden gespeichert und an alle anderen Benutzer verteilt. Verteiltes Zeichnen: Gezeichnete Objekte erhalten die Farbe des jeweiligen Zeichners. Objekte in aktueller Bearbeitung erhalten eine Markierung durch ein Piktogramm in der Farbe des Bearbeiters. Positionen aller anderen Zeichner werden angezeigt. Änderungen, die in der Vergangenheit liegen, können über eine Historisierungsfunktion sichtbar gemacht werden. Verteiltes zeichnen mit Videochat-Funktion: Gesichtsausdrücke werden per Videochat für Benutzer zugänglich gemacht. Benutzer lassen sich über ein Benachrichtigungssystem über Aktionen anderer Benutzer benachrichtigen und melden sich für bestimmte Benachrichtigungen an oder ab. Erweitertes Benachrichtigungssystem: Der Arbeitskontext, die Position und die in Interaktion befindlichen Artefakte werden mitgeteilt Web-basierte Foren: Benutzer sehen, welche anderen Benutzer gerade online sind, können über Chats und Foren-Themen miteinander kommunizieren AWARENESS-TYP- ZUORDNUNG Awareness des Arbeitsraums Awareness des Arbeitsraums, informelle Awareness Soziale Awareness Informelle Awareness, Awareness der Gruppenstruktur Awareness des Arbeitsraums Informelle Awareness, Awareness des Arbeitsraums Tabelle 2-5: Funktionalitäten, die Awareness fördern [GST05]

49 Grundlagen Seite Beispiele für Mehrbenutzer-Anwendungen Das folgende Kapitel stellt einige Beispiele für Mehrbenutzer-Anwendungen vor. Zunächst wird das BSCW-System von Bentley et al. [BHS95] beschrieben, dann das Projekt POLITeam von Klöckner et al. [Klö95] vorgestellt und zuletzt die Webanwendung Google Docs [Goo14a] erörtert BSCW-System Das Basic Support for Cooperative Work (BSCW) System ist ein kooperatives System, welches auf der Plattform des World Wide Webs (WWW) aufbaut. Es entstand in den Anfangsjahren des WWW aus der Notwendigkeit heraus, dass zwar Benutzer Informationen und Inhalte anderer Benutzer selbständig nutzen und eigene einstellen konnten, eine darüber hinaus gestaltete Art der Kollaboration allerdings nicht gegeben war [BHS95]. Das BSCW System erweitert das WWW um Funktionen, die asynchrone kollaborative Arbeit ermöglichen und die Awareness der Benutzer fördern. Dazu kombiniert das System damalige gängige Methoden wie dem Speichern von Daten auf FTP-Verzeichnissen mit neuen Ansätzen wie der Verwaltung von Benutzern und Benutzergruppen, einer rechtebasierenden Zugriffssteuerung und einem Ereignissystem, welches Benutzer über Änderungen zeitnah informiert. Bentley et al. [BHS95] zeigten mit der Entwicklung dieses Systems die Realisierbarkeit eines kooperativen Systems auf Basis des WWW. Das System besteht aus einem Webserver, welcher eine Menge von so genannten Arbeitsbereichen (workspaces) verwaltet. Diese Arbeitsbereiche dienen zur Ablage und Verarbeitung von geteilten Dokumenten. Ein Benutzer mit Zugriffsrechten auf einen Arbeitsbereich kann die darin enthaltenen Dokumente bearbeiten und Metainformationen, wie dem letzten Bearbeitungsdatum und dem Namen des letzten Bearbeiters, anzeigen lassen. Eine Ereignis-Ansicht des Arbeitsraums zeigt zudem welches Dokument wann von wem bearbeitet wurde. Um als Benutzer an diesem System zu partizipieren, ist eine vorhergehende Registrierung und Authentifizierung an dem Systemserver notwendig. Ein Benutzer mit Zugriffsrechten auf einen Arbeitsbereich kann einem anderen Benutzer Zugriffsrechte erteilen [BHS95] POLITeam POLITeam ist ein Forschungsprojekt von Klöckner et al. [Klö95], das als ein kollaboratives System für verteilte Regierungsarbeit deutscher Ministerien in Bonn und Berlin umgesetzt wurde. Das Hauptziel war die Entwicklung und Einführung eines Systems zur Unterstützung der Kooperation von großen, geographisch verteilten Organisationen. Die tatsächlichen Benutzer von POLITeam

50 Seite 44 Kapitel 2 wurden intensiv in dessen Entwicklungsprozess eingebunden, so dass prototypische Implementierungen direkt unter realen Arbeitsbedingungen getestet werden konnten [Soh99]. Das POLITeam-System unterstützt vor allem die Arbeit des Ministeriums mit Dokumenten. Diese ist durch die Gemeinsame Geschäftsordnung der Ministerien geregelt und sieht, vereinfacht ausgedrückt, folgenden Ablauf vor. Ein Minister oder Abteilungsleiter empfängt Post und fasst alle Dokumente, die eine Angelegenheit betreffen, zu einem Ordner zusammen. Er entscheidet welche Unterabteilungen welche Ordner bearbeiten und versieht dessen Dokumente mit handschriftlichen Markierungen und einem Stift, der seine Position symbolisiert (z.b. grün für Minister, rot für Abteilungsleiter usw.). Die Dokumente werden an die jeweiligen Unterabteilungen gesendet und dort wiederum von Leitern markiert und weitergeleitet. Nach der Bearbeitung auf der niedrigsten Hierarchieebene wandern die Ordner denselben Pfad auf der Bearbeitungshierarchie aufwärts, durchwandern den Pfad allerdings mehrmals, wenn ein Dokument von einem Vorgesetzten zur erneuten Bearbeitung zurückgewiesen wird. Bearbeitete Ordner werden erneut an Unterabteilungen gesendet und dort in Arbeitsschritte aufgeteilt, welche Arbeitsräumen und Mitarbeitern zugewiesen werden [Soh99]. Dieser Arbeitsfluss wird von POLITeam digitalisiert und beschleunigt die Arbeitsgeschwindigkeit unter anderem durch den Wegfall langer Transportwege von Dokumenten. POLITeam basiert auf dem kollaborativen Client-Server-System LinkWorks, einem Produkt von Digital [Dig95]. Es bietet jedem Benutzer einen virtuellen Arbeitsplatz und eine Desktop-Ansicht, wie sie aus weitverbreiteten Betriebssystemen wie Linux [Kof13] und Windows [Häh13] bekannt ist. Auf dem Desktop befinden sich Bearbeitungsobjekte wie Ordner und Dokumente und Symbole über die sich integrierte Funktionalitäten abrufen lassen zur Unterstützung von , Arbeitsflusskoordination und Dokumententeilung mit anderen Benutzern. Die Arbeitsflusskomponente erlaubt die Spezifikation von beliebigen Arbeitsflusspfaden, welche mit beliebigen Dokumenten verknüpft werden können [Soh99]. Zur Unterstützung der Awareness bietet LinkWorks die Möglichkeit, sich bei Änderungen bestimmter Dokumente benachrichtigen zu lassen. Die Benutzer markieren dazu die für sie interessanten Dokumente und registrieren sich als Interessenten. Daraufhin erhalten sie Benachrichtigungen in Form einfacher Textnachrichten sobald eine Änderung eines Dokumentes von einem anderen Benutzer angestoßen wurde [Soh99]. Diese sehr einfache Art um Awareness zu fördern wurde im POLITeam-Projekt weiter ausgebaut und ein alternativer Client namens PoliAwaC entwickelt. Dieser besitzt als zentrales Element einen Ereignis- und Benachrichtigungsdienst. Die Ereignisverteilung basiert auf sogenannten Awareness-Profilen, welche sich

51 Grundlagen Seite 45 unter anderem aus Arbeitssituation heraus berechnen. Jedem Profil ist ein Intensitätswert von 0 bis 4 zugeordnet, der die Art und Weise beschreibt wie Ereignisse beim Benutzer angezeigt werden. Ein niedriger Wert steht für eine geringe Intensität und sorgt zum Beispiel dafür, dass bei einer Änderung eines Dokumentes lediglich sein Symbol die Farbe ändert. Ein hoher Intensitätswert sorgt zum Beispiel dafür, dass bei einem Ereignis eine Textnachricht in der Mitte des Bildschirms angezeigt wird. Ein Benutzer kann zu jedem Arbeitsfluss auswählen, welches Awareness-profil für ihn eingesetzt und über welche Aktionen er informiert werden soll [Soh99]. Abbildung 2-12: Benutzungsschnittstelle von PoliAwaC [Soh99] Abbildung 2-12 zeigt den Client PoliAwaC im Einsatz. Auf der linken Seite sind in einer Baustruktur die Bearbeitungsobjekte zu sehen. Im oberen Bereich werden alle Objekte aus der von der linken Seite ausgewählten Gruppe dargestellt. Darunter befindet sich eine Historie über die Änderung der Gruppenelemente. Am unteren Rand der Anwendung ist die Ereignisanzeige zu sehen [Soh99] Google Docs Ein weiteres Beispielprogramm mit Unterstützung von Mehrbenutzerinteraktion ist Google Docs [Goo14a]. Google Docs ist eine Webapplikation, mit deren Hilfe Text- Tabellen- und Präsentationsdokumente erstellt werden. Die Benutzer greifen über ein Webinterface auf ihre Dokumente zu, welche online im Repository von Google gespeichert sind. Über die Konfiguration von Editor- und

52 Seite 46 Kapitel 2 Sichter-Rollen werden Berechtigungen für einzelne Dokumente festgelegt und gesteuert, wer welche Änderungen durchführen darf [DW06]. Google Docs unterscheidet sich dahingehend von anderen Office-Lösungen wie Microsoft Word [FH13] und LibreOffice [Doc14], als dass Dokumente nicht lokal und von einzelnen Personen bearbeitet werden, sondern über einen Onlineservice von mehreren Benutzern gleichzeitig genutzt werden. Alle 30 Sekunden werden die Änderungen an einem Dokument durch einen Benutzer allen anderen Bearbeitern dieses Dokuments zugänglich gemacht und angezeigt [DW06]. In Konflikt stehende Änderungen, also Modifikationen eines Dokuments an einer Stelle durch mehrere Benutzer gleichzeitig werden markiert und mit Lösungsoptionen versehen. Eine Lösungsoption ist zum Beispiel das Überschreiben der Änderungen aller anderen Benutzer an dieser Stelle des Dokuments. Konflikte bei der Bearbeitung treten jedoch bedingt durch die kurze Zeitspanne zwischen der Verteilung und Aktualisierung des Dokumentes bei allen Benutzern sehr selten auf. Zur Zurückverfolgung und Nachvollziehung von Änderungen kann zu einem Dokument in Google Docs seine Historie angezeigt werden. Diese erlaubt es, sich den Stand des Dokuments zu jedem beliebigen Zeitpunkt seit seiner Erstellung anzeigen zu lassen und beliebige Versionen des Dokuments zu vergleichen. Änderungen sind mit einem Zeitstempel und dem Namen des Bearbeiters hinterlegt [DW06]. Abbildung 2-13: Benutzungsschnittstelle von Google Docs [Goo14a] Abbildung 2-13 zeigt die Benutzungsschnittstelle von Google Docs. Auf der linken Seite ist das aktuell geöffnete Textdokument abgebildet. Zu sehen sind einzelne Absätze des Textes in verschiedenartiger Einfärbung. Auf der rechten Seite ist der Überarbeitungsverlauf zu sehen. Dort sind alle Speichervorgänge

53 Grundlagen Seite 47 und Änderungen seit der Erzeugung des Dokuments aufgelistet. Da der Eintrag vom 19. August 2010 markiert ist und an diesem Zeitpunkt eine Person mit der Zuordnungsfarbe Pink eine Änderung am Dokument durchführte, ist diese Änderung als pinke Einfärbung eines Textabsatzes zu sehen. Der grüne Absatz gehört zu einer Änderung der vorhergegangenen Version durch eine Person mit der Zuordnungsfarbe Grün.

54 Seite 48 Kapitel 3 3 Problemanalyse Das vorhergehende Kapitel zeigte zum einen, dass Geschäftsprozesse auf sehr unterschiedliche Arten modelliert und gehandhabt werden, und zum anderen, dass es bereits vielversprechende Realisierungsansätze gibt was computergestützte Zusammenarbeit vieler Personen an einem Projekt und die Visualisierung von diagrammähnlichen Sprachen angeht. Im Folgenden werden allgemeine Probleme dieser Bereiche beschrieben und auf konkrete Probleme im Zusammenhang mit dieser Arbeit erläutert. Den Schluss des Kapitels bildet eine Auflistung von Anforderungen, welche das Konzept erfüllen muss. 3.1 Problematik Im Bereich der Geschäftsprozessmodellierung ist die OMEGA-Methode ein etabliertes Vorgehen und gut geeignet um bereichsfremden Mitarbeitern komplexe Prozesse näherzubringen. Besonders ihre plakativen Symbole und ihr einfacher Aufbau sind leicht nachzuvollziehen [May10]. Ihr größter Vorteil, die leichtverständliche informelle Sprache, gereicht ihr jedoch auch gleichzeitig zum Nachteil. So lassen sich Prozesse nicht nur lediglich bis zu einem gewissen Grad präzise beschreiben, die Freiheiten bei der Benennung von Objekten und deren Referenzen untereinander führen bei Unachtsamkeit schnell zu fehlerhaften Modellierungen. Durchläuft beispielsweise ein Papierinformationsobjekt Auftrag in einem komplexen Prozess mehrere Arbeitsschritte und erhält in einem der Schritte eine Unterschrift, so muss diese Änderungen behelfsmäßig als Namensänderungen deutlich gemacht und das Objekt zum Beispiel mit dem Namen Auftrag_Unterschrieben weiterverwendet werden. Diese Umbenennung von Objekten ist jedoch keineswegs eine Konvention und wird von Unterschiedlichen Modellierern auch unterschiedlich gehandhabt. Für kleine Prozesse mag dies kein großes Problem sein, für komplexe Abfolgen mit vielen Änderungen eines Objektes wird seine Handhabung schnell undurchsichtig. Auch computergestützte Analysen von Geschäftsprozessmodellen in der OMEGA-Notation mit Objekten dieser Art sind nur noch sehr eingeschränkt möglich. Die OMEGA- Sprache zur Beschreibung von Geschäftsprozessen hat hier noch ein ausgeprägtes Potenzial zur Verbesserung, zum Beispiel durch eine Erweiterung der Sprache. Ein weiteres Problem der OMEGA-Sprache ist das fehlende Konzept zur Darstellung von Modellen aus verschiedenen Sichten. So ist zum Beispiel nicht spezifiziert, wie sich Mitarbeiter einer Organisationseinheit nur die für sie interessanten Prozessschritte anzeigen lassen können. Auch die Nachverfolgung eines Informationsobjektes über mehrere Prozesse und Unterprozesse gestaltet sich aufgrund der Notwendigkeit einer manuellen Traversierung durch alle Modelle als sehr umständlich. Diese Filter- und Analysehilfen sind bisher nicht gegeben.

55 Problemanalyse Seite 49 Krolovitsch und Nilsson [KN09] und McIntosh [McI09] zeigen, dass UML-Modelle von Zustands- und Aktivitätsdiagrammen nicht nur als 3D-Visualisierungen umsetzbar sind, sondern dass diese Form der Darstellung behilflich beim Verständnis von komplexen Diagrammen ist. Zum einen ist der Betrachter in der Lage, eine virtuelle Kamera frei im Raum zu bewegen und erhält dadurch eine sehr genau definierte selektive Ansicht des Modells seines Interesses. Zum anderen werden komplexe Hierarchien im Ganzen sichtbar gemacht und der 3D- Raum für die Verteilung von Hierarchieebenen genutzt, so dass Zusammenhänge einfach erkannt werden. Im Vergleich zu herkömmlichen Werkzeugen, in denen jede Hierarchieebene eine eigene visuelle Repräsentation erhält und oft sogar immer nur eine Ebene gleichzeitig sichtbar ist, spart der Ansatz der 3D- Darstellung viel kognitive Energie von Nutzern, die diese Hierarchien ansonsten manuell traversieren müssten um alle Zusammenhänge nachzuvollziehen und sich zu merken. Eine ausschließliche Darstellungsfunktion ohne die Möglichkeit direkt Änderungen an den Modellen vornehmen zu können ist jedoch nur in einem sehr begrenzten Rahmen praktikabel. Die Prototypen von Krolovitsch, Nilsson und McIntosh bieten diese Möglichkeit nicht. Stattdessen ist es nötig, die Modelle mit alternativen Anwendungen zu öffnen oder sogar die Dateien mit Hilfe eines Texteditors zu ändern. Deshalb ist auch noch nicht erforscht, wie Interaktionen mit Diagrammelementen im 3D-Raum umzusetzen sind. Im Bereich der Mehrbenutzerinteraktion gibt es schon zahlreiche Forschungsarbeiten. Die in dieser Arbeit interessante Form der computergestützten Zusammenarbeit von mehreren Benutzern an unterschiedlichen Standorten bringt unter Anderem das Problem der fehlenden Awareness mit sich [GGR96]. Das heißt, im Vergleich zu einer direkten lokalen Zusammenarbeit, bei der die beteiligten Personen durch den natürlichen Umgang miteinander die Aktionen jeweils anderer Personen bemerken, ist dies hier nicht der Fall. Dieses Defizit muss durch ein kollaboratives System ausgeglichen werden, welches Awareness künstlich herstellt. Dazu gibt es bereits im Basic Support for Cooperative Work (BSCW)- System von Bentley et al. [BHS95] und im POLITeam-Projekt von Klöckner et al. [Klö95] erste vielversprechende Ansätze. Diese stützen sich zum einen auf eine digitalisierte Organisation von Arbeitsgruppenstrukturen und zum anderen auf automatisierte Benachrichtigungssysteme. Google Docs [Goo14a] treibt diese Ansätze weiter und bietet als Office-Lösung die zeitlich sehr kurz verzögerte Nachverfolgung von Änderungen anderer Benutzer. Insgesamt liefern die Bemühungen zur Verbesserung der Awareness in diesen Forschungsarbeiten jedoch meist nur eine nachträgliche Nachvollziehung Aktionen anderer Benutzer. Es wird zwar beantwortet, welche Person zu welchem Zeitpunkt mit welchen Artefakten gearbeitet hat, jedoch nur unzureichend beschrieben, wer zum aktuellen Zeitpunkt genau welche Aktion ausführt. Der Aspekt der Echtzeitübertragung von Ereignissen, Aktionen und Änderungen wurde bisher vernachlässigt.

56 Seite 50 Kapitel 3 Ein möglicher Grund dafür ist sicherlich technischer Natur, denn eine Übertragung aller Aktionen aller beteiligten Personen in einer Arbeitsgruppe untereinander wird mit feinerer Granularität der Übertragungen eine immer größere technische Herausforderung. 3.2 Anforderungen Im Folgenden werden die an das zu entwickelnde Werkzeug gestellten Anforderungen beschrieben. Diese werden gemäß ihrer Merkmale in die Kategorien Visualisierung und Navigation, Modellierung, Mehrbenutzer-Interaktion und Plattformunabhängigkeit eingeordnet Visualisierung und Navigation Die mit dem Werkzeug erstellten OMEGA-Diagramme sollen mit Hilfe von 3D- Computergrafik visualisiert werden. Die Visualisierung soll eine selektive Darstellung von Diagrammen ermöglichen, das heißt die Diagramme sollen in einem beliebigen Detaillierungsgrad betrachtet werden und momentane uninteressante Diagrammteile ausgeblendet werden können. Da Krolovitsch und Nilsson [KN09] durch Benutzertests bei der Entwicklung eines Werkzeugs zur dreidimensionalen Darstellung von Diagrammen bereits Anforderungen an so ein Werkzeug ermitteln konnten, soll das hier zu entwickelnde Werkzeug den folgenden dieser Anforderungen genügen. Die selektive Darstellung soll durch eine im 3D-Raum frei bewegliche virtuelle Kamera ermöglicht werden. Die Perspektive der Kamera soll jedoch so eingeschränkt sein, dass eine versehentliche auf den Kopf gestellte Ansicht der Diagramme vermieden wird. Zur leichteren Erreichung einer Perspektive mit einem für die Darstellung interessantem Modellelement soll es eine Möglichkeit geben, dieses in den Fokus zu setzen und die virtuelle Kamera entsprechend automatisch zu positionieren. Bei komplexen Diagrammen oder Diagrammen mit mehreren Hierarchieebenen soll die Struktur des Diagramms zusätzlich als vereinfachte Baumstruktur dargestellt werden und eine einfache Form der Navigation und Orientierung bieten Modellierung Die Interaktion mit OMEGA-Modellen soll im dreidimensionalen Raum stattfinden. Das Werkzeug muss also nicht nur OMEGA-Modelle mit Hilfe von 3D- Computergrafik visualisieren, sondern auch deren Bearbeitung unterstützen. So sollen sowohl neue Modellelemente erstellt, als auch vorhandene geändert werden können. Die Art und Weise wie dies geschieht kann nicht von herkömmli-

57 Problemanalyse Seite 51 chen Editoren von 2D-Diagrammen übernommen werden, da diese die dritte Dimension nicht berücksichtigen. Das zu entwickelnde Werkzeug soll deshalb ein Konzept zur einfachen, effizienten Modellierung umsetzen Mehrbenutzer-Interaktion Das Werkzeug soll eine Mehrbenutzer-Anwendung sein und muss entsprechend so konzipiert sein, dass Awareness unterstützt und gefördert wird. Der Fragenkatalog zur Awareness von Gutwin und Greenberg [GG99] soll bei der Entwicklung als Leitfaden dienen. Möglichst viele Fragen des Katalogs sollen später von Benutzern des Werkzeugs positiv beantwortet werden können. Eine konkrete Anforderung ist eine nach dem Vorbild von Google Docs [Goo14a] umgesetzte Form der Synchronisierung der Arbeitsstände aller beteiligten Personen. Die Synchronisierung soll anders als in Google Docs jedoch nicht in definierten Intervallen erfolgen sondern zeitlich möglichst nah am Zeitpunkt der Änderung eines Benutzers liegen, so dass Konflikte vermieden werden. Die Positionen und die Blickwinkel aller beteiligten Benutzer sollen allen anderen Benutzern zugänglich gemacht und deren Änderungen am Diagramm nachvollzogen werden können, indem das Werkzeug diese Änderungen speichert und eine entsprechende Visualisierung bietet Plattformunabhängigkeit Einige Anforderungen aus Fahrwinkels Arbeit [Fah95] werden übernommen. So soll das Werkzeug die Datenhaltung der Modelle an einer zentralen Stelle behandeln. Das Client-Server-Pattern ist eine dazu passende Architektur. Das Konzept soll so gestaltet sein, dass sich das Werkzeug als plattformunabhängige Anwendung realisieren lässt. Die Anforderung ist deshalb, das Werkzeug als Webapplikation nach dem Vorbild von Google Docs [Goo14a] umzusetzen. Anders als von Fahrwinkel konzipiert, soll die Serverkomponente jedoch nur für die Speicherung und Verwaltung von Diagrammen zuständig sein. Die Visualisierung und die Interaktion soll in der Client-Komponente realisiert werden. Die eingesetzten Technologien des Prototyps sollen von so vielen Webbrowsern wie möglich unterstützt und im Hinblick auf eine voraussichtlich lange Weiterentwicklung in Zukunft ausgewählt werden.

58 Seite 52 Kapitel 4 4 Stand der Technik Dieses Kapitel stellt einige Lösungen vor, die bereits zur Modellierung von Geschäftsprozessen allgemein und zur Erstellung von OMEGA-Modellen im speziellen existieren und zeigt zudem, wie die Interaktion mit dreidimensionalen Objekten in weitverbreiteten Programmen aussieht. 4.1 OMEGA-Editoren Im folgenden Kapitel werden die beiden existierenden kommerziellen Windows- Programme zur Modellierung von OMEGA-Modellen vorgestellt. Zunächst wird das Programm Visio von Microsoft beschrieben, danach folgt eine kurze Zusammenfassung des Programms Omega Process Modeller von Unity Visio Microsoft Visio 2013 [Mar13] ist ein grafisches Modellierungswerkzeug zur Erzeugung und Bearbeitung einer Vielzahl von grafischen Diagrammsprachen, wie zum Beispiel elektrotechnischen Bauplänen, Gebäudegrundrissen, UML-Diagrammen, BPMN-Diagrammen und OMEGA-Prozessdiagrammen. Die Modellierung geschieht durch das Ziehen mit der Maus von Modellelementen aus einer so genannten Schablonensammlung auf eine Zeichenfläche und deren anschließende Positionierung und Bearbeitung [Mar13]. Abbildung 4-1: Benutzungsschnittstelle von Visio 2013

59 Stand der Technik Seite 53 Abbildung 4-1 zeigt den grundsätzlichen Aufbau der Benutzungsschnittstelle von Visio. Im oberen Bereich befindet sich die Ribbon-Bar, ein in allen Microsoft-Office-Produkten [FH13] wiederzufindendes Benutzungselement. Es bietet Zugriff auf die wichtigsten Funktionen von Visio und ist in Registerkarten eingeteilt. Links darunter befindet sich die schon erwähnte Schablonensammlung. Untereinander werden hier die verfügbaren Diagrammelemente zur Modellierung angezeigt. Rechts davon befindet sich die Zeichenfläche, auf die Instanzen der Diagrammelemente aus der Schablonensammlung per Drag and Drop herübergezogen werden [Mar13]. Visio besitzt von Haus aus keine explizite Unterstützung zur Modellierung von OMEGA-Diagrammen. Es bietet jedoch die Möglichkeit, benutzerdefinierte Modellelemente zu erstellen und diese in einer Schablonengruppe zusammenzufassen und wiederzuverwenden. Benutzerdefinierte Modellelemente werden als zweidimensionale Symbole aus einem Set von einfachen Geometrien wie Quadern und Kreisen zusammengesetzt. Die Erstellung und Nutzung einer entsprechenden Schablonengruppe macht eine einfache Form der Modellierung von OMEGA-Diagrammen möglich. Wollen mehrere Benutzer ihre modellierten Diagramme untereinander austauschen oder arbeiten mehrere Benutzer in einem Projekt miteinander und wünschen eine konsistente Darstellung aller OMEGA- Diagramme, müssen sie alle dieselbe Schablonengruppe nutzen und diese im Vorfeld untereinander verteilen [Mar13]. Die Zeichenfläche ist der Ort, an dem die modellierten Diagrammelemente angezeigt werden. Sie wird durch eine weiße Fläche dargestellt und ist wie ein kariertes Blatt Papier von hellgrauen Strichen durchzogen. Die Modellierung erfolgt auf dieser Fläche ausschließlich im zweidimensionalen Raum durch die Anordnung und Verbindung der zweidimensionalen Modellelementen [Mar13]. Für eine gleichförmige Anordnung von Diagrammelementen bietet Visio mehrere Hilfestellungen. Eine davon ist das am Rande der Zeichenfläche befindliche Lineal mit einer einstellbaren Skala, welches optional ein- oder ausgeblendet werden kann und bei selektierten Modelelementen deren Position und Größe anzeigt. Außerdem bietet Visio mit der Funktion Dynamisches Gitter die Möglichkeit, Modellelemente automatisiert anhand deren Umrisse auszurichten und in immer gleichen Abständen zu positionieren. Die Abstände und die Merkmale anhand derer Modellelemente ausgerichtet werden, sind in einem Dialogfenster umfangreich einstellbar [Mar13]. Erstellte Diagramme und Schablonengruppen werden als Dateien auf dem lokalen System oder auf einem Netzwerklaufwerk abgelegt. Die Arbeit mehrerer Personen an denselben Dateien gleichzeitig muss koordiniert und abgesprochen werden, damit die Benutzer ihre Änderungen nicht gegenseitig überschreiben.

60 Seite 54 Kapitel 4 Die folgende Abbildung 4-2 zeigt auf der linken Seite einen Ausschnitt aus der Zeichenfläche mit aktiviertem dynamischem Gitter und Lineal und auf der rechten Seite einen Teil der Einstellungsmöglichkeiten zu automatischen Ausrichtungen. Auf der Zeichenfläche befinden sich bereits zwei platzierte Entscheidungsknoten. Der dritte Entscheidungsknoten auf der rechten Seite wird gerade mit der Maus positioniert und springt automatisch auf die gerade angezeigte Position, sobald sich der Knoten dieser Position auf einige Pixel nähert. Visio zeigt bei so einem Sprung grüne gestrichelte Führungslinien und kleine Pfeile an, die die neue Ausrichtung und gleichförmige Anordnung verdeutlichen. Die abgebildeten Optionen zur automatischen Ausrichtung zeigen die Einstellbarkeit der Größen von Linealen, Gittern, Punkten und anderen Elementen und auf welche Arten und Weisen Objekte an andere Objekte angebracht (geklebt) werden können [Mar13]. Abbildung 4-2: Automatische Ausrichtungen bei Visio OMEGA Process Modeller von Unity Der OMEGA Process Modeller (OPM) von Unity ist ein graphisches Werkzeug zur Erstellung und Bearbeitung von Geschäftsprozessmodellen in OMEGA-Notation. Er basiert unter anderem auf Microsoft Visio, indem er einige Programmkomponenten von Visio beinhaltet. So kommt zum Beispiel bei der Zeichnung und Darstellung von Modellelementen dieselbe Technologie zum Einsatz wie bei Visio. Entsprechend ähneln sich auch die Bedienkonzepte. Genau wie bei Visio werden auch beim OMEGA Process Modeller zweidimensionale Modellelemente aus einer Seitenleiste auf eine Zeichenfläche gezogen und so neue Prozesselemente definiert [Uni12]. Das Programm liefert neben den von Visio bekannten Funktionen zur automatischen Ausrichtung von Modellelementen die Möglichkeit, den Modellelementen eine semantische Bedeutung zuzuweisen. Im Gegensatz zum reinen Zeichnen von aus technischer Sicht voneinander unabhängigen Modellelementen können zum Beispiel für Organisationseinheiten sogenannte Klassen definiert werden. Haben zwei Organisationseinheiten dieselbe Klasse zugewiesen, so sind diese

61 Stand der Technik Seite 55 eine echte Referenz auf diese Klasse. Diese Verknüpfung führt zu einer verbesserten Wartbarkeit. Anstatt einzelne Modellelemente zu bearbeiten, reicht es eine Klasse zu verändern und sie beispielsweise umzubenennen, um all ihre verknüpften Modellelemente automatisch zu aktualisieren [Uni12]. Die folgende Abbildung 4-3 zeigt den Aufbau des Hauptfensters vom OMEGA Process Modeller. Der obere Bereich wird von der Ribbon-Bar dominiert und liefert Zugriff auf die am häufigsten Funktionen. Auf der linken Seite befinden sich die Schablonensammlung und die darin enthaltenen verfügbaren Modellelemente. Auf der rechten Seite befindet sich die Zeichenfläche auf der modellierte Geschäftsprozesse dargestellt werden [Uni12]. Abbildung 4-3: Aufbau des Hauptfensters vom OMEGA Process Modeller [Uni12] Die Zeichenfläche ist das zentrale Instrument um Prozesse und Prozesselemente anzusehen, zu erstellen und zu bearbeiten. Der OMEGA Process Modeller liefert zusammen mit der semantischen Verknüpfung jedoch eine alternative Methode um Modellelemente zu finden und sie in den Fokus der Betrachtung zu holen. Es existiert dazu der so genannte Explorer, welcher alle Modellelemente in einer Baumstruktur anzeigt. Per Rechtsklick können die Elemente in den Fokus gebracht werden, indem das Programm die Ansicht auf die Zeichenfläche entsprechend automatisch anpasst. Der Explorer wird außerdem dazu genutzt, Kopien eines existierenden Modellelements zu erstellen, indem das entsprechende Element mit der Maus aus dem Baum in die Zeichenfläche gezogen wird. Die Kopie erhält die gleichen Eigenschaften wie das kopierte Element und referenziert unter anderem dieselbe Klasse.

62 Seite 56 Kapitel 4 Abbildung 4-4 zeigt auf der linken Seite die Baumstruktur des Explorers und das Kontextmenü für einen Rechtsklick auf eines der Modellelemente. Auf der rechten Seite ist das Eigenschaften-Fenster eines Modellelements hier beispielhaft das eines Papierinformationsobjektes zu sehen. Über die Eigenschaft Klasse kann in diesem Dialog die semantische Verknüpfung hergestellt werden [Uni12]. Abbildung 4-4: Baumstruktur des Explorers auf der linken Seite und Ansicht des Eigenschaftenfensters eines Papierinformationsobjekts auf der rechten Seite des OMEGA Process Modellers [Uni12] Eine weitere Funktion, die die semantische Verknüpfung möglich macht, ist die Möglichkeit das Programm Auswertungen eines Prozessmodells erstellen zu lassen. Auswertungen beziehen sich sowohl auf die Klassen als auch die Modellelemente und ermöglichen unter anderem anzuzeigen, in welchen Prozessen ein bestimmtes Informationsobjekt genutzt wird oder mit welchen Prozessen eine Organisationseinheit zu tun hat [Uni12]. Erstellte Geschäftsprozessmodelle werden entweder als Dateien auf dem lokalen System oder auf einem Netzwerklaufwerk abgelegt oder aber können in einem Microsoft SharePoint-System [End13] gespeichert werden. SharePoint ist eine Serverapplikation mit einem Webinterface und Funktionalitäten zum Dokumentenmanagement, Wissensmanagement, und Aufgaben- und Projektverwaltung. Der Zugriff auf Speicherorte in einem SharePoint-System wird durch ein Rechtesystem geregelt. Der Einsatz von OMEGA Process Modeller in Verbindung mit einem SharePoint-System erleichtert den geregelten Datenaustausch zwischen Teammitgliedern untereinander. Die parallele Bearbeitung eines Dokuments durch mehrere Personen zeitgleich führt jedoch zu Überschreibungsfehlern und muss entsprechend koordiniert werden [Uni12, End13].

63 Stand der Technik Seite Online-Editoren für Geschäftsprozesse Dieses Kapitel beschäftigt sich mit Webapplikationen, welche die Modellierung von Geschäftsprozessen unterstützen. Da für die OMEGA-Notation noch keine entsprechende Webanwendung existiert, werden im Folgenden Editoren für die am weitesten verbreitete Notationen erweiterte ereignisgesteuerte Prozessketten (eepk) und Business Process and Notation (BPMN) vorgestellt. Die erstere Notation wird von Process Live von der Software AG unterstützt, BPMN-Diagramme werden von BlueworksLive von IBM bearbeitet Process Live Process Live ist ein Editor für Geschäftsprozessmodelle in der eepk-notation. Die Software läuft als Webanwendung im Browser als Software as a Service (SaaS). Sie bietet neben der reinen Erstellung von Prozessmodellen umfangreiche Möglichkeiten zur Verwaltung von Projekten und Prozessen und regelt den Zugriff darauf über eine Benutzerkontenverwaltung. Jedem Benutzer ist ein Konto zugewiesen, welches zum einen entweder Designer-Berechtigungen zum Erstellen und Verwalten von Geschäftsprozessen oder Viewer-Berechtigungen zum reinen Ansehen hat und zum anderen bestimmten Projekten und Prozessen zugeordnet ist auf welche der Benutzer Zugriff erhält [Sof14]. Abbildung 4-5: Aufbau der Benutzungsschnittstelle von Process Live bei der Bearbeitung eines Prozessmodells [Sof14] Abbildung 4-5 zeigt die Benutzungsschnittstelle des Werkzeugs für die Bearbeitung von eepk-diagrammen. Im oberen Bereich befindet sich eine Toolbar zum

64 Seite 58 Kapitel 4 schnellen Zugriff auf häufig genutzte Funktionalitäten wie dem Kopieren und Einfügen von Modellelementen oder dem Formatieren von Elementen. Auf der linken Seite ist eine Liste von verfügbaren Modellelementen zu sehen, die in Process Live als Symbols bezeichnet werden. Auf der rechten Seite befindet sich eine ein- und ausblendbare Leiste mit dem Titel Collaboration. Darin werden Kommentare aller beteiligten Modellierer zum aktuellen Diagramm dargestellt. In der Mitte befindet sich die weiße gepunktete Zeichenfläche. Auf der Abbildung sind einige modellierte Diagrammelemente zu sehen, wie das Ereignis Event1 oder die Funktion Activity1. Zur Erzeugung neuer Modellelemente klickt der Benutzer eines der Symbole aus der linken Leiste an und wählt eine gewünschte Position auf der Zeichenfläche. Zur Änderung eines Modellelements wird das betreffende Element mit der Maus per Klick ausgewählt. Über die sogenannte Minitoolbar werden Elemente miteinander verbunden. Die Minitoolbar ist in der Abbildung als halbtransparentes Element unterhalb der Funktion Activity2 zu sehen. Änderungen am aktuellen Diagramm werden über einen Speichern-Knopf in das System übernommen. Die gleichzeitige Bearbeitung eines Diagramms von mehreren Personen führt dazu, dass sich die Änderungen gegenseitig überschreiben und muss deshalb koordiniert werden um Datenverlust zu vermeiden [Sof14]. Process Live ist ein System zur kollaborativen Arbeit an Geschäftsprozessmodellen und bietet dazu verschiedene Arten der Kommunikation zwischen beteiligten Personen an. Der Hauptort für den Austausch sind so genannte Gruppen. Eine Gruppe ähnelt vom Aufbau und der Funktionsweise her herkömmlichen Internetforen. Alle Mitglieder einer Gruppe können in einer Listenartigen Darstellung Textbeiträge verfassen und anderen Gruppenmitgliedern zur Verfügung stellen. Darüber hinaus ist es möglich, alle modellierten Diagramme mit Kommentaren zu versehen. Die Kommentare können entweder bei der Bearbeitung des betreffenden Diagramms angezeigt werden, so wie in Abbildung 4-5 zu sehen ist, oder in einer separaten Ansicht der Diagramme mit Metainformationen zum modellierten Prozess betrachtet werden. Ein Kommentar ist kann sich inhaltlich auf alle Elemente des Diagramms beziehen, wird technisch jedoch lediglich mit dem Diagramm als Ganzem verknüpft. In allen Beiträgen in Gruppen oder in den Kommentaren können andere Bearbeiter mit vor dem Namen explizit erwähnt werden. Diese erhalten daraufhin eine -Benachrichtigung über den betreffenden Beitrag. Die Startseite von Process Live zeigt nach dem Anmelden eine Übersicht über kürzlich verfasste Beiträge [Sof14].

65 Stand der Technik Seite IBM BlueworksLive BlueworksLive von IBM ist eine Webanwendung zur Erstellung und Verwaltung von Geschäftsprozessmodellen als BPMN-Diagramme und die Organisation und Koordination von Bearbeitern dieser Diagramme. Der Zugriff von Mitarbeitern auf Projekte und Prozesse wird über deren Benutzerkonto und einem umfangreichen Rechte- und Zugriffssystem gesteuert [Ibm14]. Die Anwendung ist für große Teams mit dutzenden Personen unterschiedlicher Rollen konzipiert und liefert Funktionalitäten von Arbeitsbereich-, Projekt-, Gruppen-, und Aufgabenverwaltungen. Über ein umfangreiches Workflow-System werden komplexe Aufgabenstellungen definiert und spezifiziert, welche Benutzer oder welche Rollen in welcher Reihenfolge welche Teilaufgaben bearbeiten und wann an wen welche Benachrichtigungen geschickt werden [Ibm14]. Abbildung 4-6: Aufbau der Benutzungsschnittstelle von BlueworksLive von IBM bei der Bearbeitung eines Prozessmodells [Ibm14] Die Modellierung von Geschäftsprozessmodellen in BPMN-Syntax ist eine zentrale Funktionalität von BlueworksLive. Abbildung 4-6 zeigt, wie die Benutzungsschnittstelle dazu aussieht. Der obere Bereich dient der Navigation. Über diesen wird zur Startseite des Projekts oder zum so genannten Community-Bereich gewechselt oder die aktuelle Ansicht des gerade bearbeiteten Prozesses geändert. Der linke Bereich zeigt das gerade bearbeitete Geschäftsprozessmodell. Auf der rechten Seite befindet sich eine Anzeige über die letzten Aktionen anderer Benutzer an diesem Geschäftsprozessmodell. Links unten ist eine Chatbox

66 Seite 60 Kapitel 4 zu sehen in der Benutzer miteinander kommunizieren. Im Bereich des Geschäftsprozessmodells ist der Prozess Hiring Orientation CD Generation zu sehen. Dieser besteht aus den beiden Bereichen HR Specialist und HR Docs Team, welche am linken Rand zu sehen sind. Die Aktivitäten Generate cd request und Mail orientation cd sind dem ersten Bereich zugeordnet, die Aktivität Burn orientation cd dem zweiten Bereich. Der Prozess ist so modelliert, dass zunächst die erste Aktivität aus dem ersten Bereich, dann die Aktivität aus dem zweiten Bereich und schließlich die zweite Aktivität aus dem ersten Bereich ausgeführt wird, wie die Pfeile es darstellen. Der Benutzer fügt über Schaltflächen neue Bereiche, Aktivitäten und Meilensteine ein. Mit der Maus werden die Modellelemente zwischen den Bereichen oder innerhalb eines Bereichs verschoben. Arbeiten mehrere Benutzer zeitgleich am selben Geschäftsprozessmodell, so werden deren Änderungen mit einer kurzen zeitlichen Verzögerung an alle beteiligten Benutzer verteilt. Jede Interaktion mit dem Geschäftsprozessmodell wird direkt gespeichert ohne dass es eine explizite Schaltfläche für das Speichern gibt. Die Einträge im Bereich mit den letzten Aktionen am Geschäftsprozessmodell werden bei Bedarf mit Kommentaren versehen und dienen als zusätzliche Kommunikationsmöglichkeit bei Diskussionen von Änderungen [Ibm14]. BlueworksLive offeriert zur Förderung der Awareness neben der direkten Verfolgung von Änderungen bei der parallelen Bearbeitung eines Geschäftsprozessmodells einen so genannten Community-Bereich. In diesem werden sowohl alle Änderungen von Projekten und Geschäftsprozessmodellen gesammelt und aufgelistet als auch Beiträge von Benutzern angezeigt um über Aufgaben und Prozesse zu kommunizieren. Der Benutzer hat die Möglichkeit, für ihn interessante Beiträge und Einträge mit einem Sternsymbol zu markieren und so deren automatische Beobachtung einzuschalten. Dadurch wird der Benutzer bei neuen Beiträgen zu einem Thema oder bei Änderungen vom System automatisch informiert und kann sogar von außerhalb der Anwendung per an Diskussionen teilnehmen [Ibm14]. 4.3 Editoren von 3D-Modellen Dieses Kapitel stellt zwei Programme vor, welche zur Erstellung und Bearbeitung von virtuellen dreidimensionalen Objekten verwendet werden. Zunächst wird 3ds Max von der Firma Autodesk kurz vorgestellt. Danach folgt eine kurze Zusammenfassung der Funktionalitäten der Anwendung Blender von der Blender Foundation.

67 Stand der Technik Seite ds Max von Autodesk 3ds Max ist eine Anwendung zur Erstellung und Bearbeitung von 3D-Modellen, Animationen, Simulationen und Renderings 4 und wird bei der Entwicklung von Computerspielen, Filmen und wissenschaftlichen Simulationen und Animationen genutzt [Aut14]. Es erlaubt die Bearbeitung von virtuellen dreidimensionalen Objekten und liefert dazu sowohl eine zweidimensionale als auch eine dreidimensionale Benutzungsschnittstelle, welche beide in Abbildung 4-7 zu sehen sind [DD13]. Abbildung 4-7: Aufbau der Benutzungsschnittstelle von 3ds Max der Firma Autodesk [DD13] In der oberen Abbildung 4-7 werden die Benutzungsschnittstellen von 3ds Max dargestellt. Das Programm untergliedert sich in drei Abschnitte. Im obersten Teil befinden sich Programmmenüs und Toolbars über die der Benutzer alle Funktionalitäten von 3ds Max aufrufen kann. Auf der rechten Seite sind weitere Funktionalitäten, in Tabs organisiert, aufrufbar. Der untere Bereich des Programms 4 Als Rendering wird hier die computergestützte Generierung eines Bildes aus einer virtuellen zwei- oder dreidimensionalen Szene bezeichnet.

68 Seite 62 Kapitel 4 enthält eine so genannte Zeitliste und bietet Optionen um Animationen zu erstellen oder zu bearbeiten. Der wichtigste Teil des Programms befindet sich in der Mitte. Hier wird die virtuelle dreidimensionale Szene aus mehreren einstellbaren Perspektiven angezeigt. In diesem Beispiel zeigt das Programm jeweils eine Ansicht von oben, von vorn, von links und aus einer freien Perspektive. Die Reihenfolge der Fenster in diesem Beispiel ist von links oben nach rechts unten beschrieben. In der virtuellen Szene sind zwei Objekte platziert und so angeordnet, dass in der freien Perspektive ein rosa Quader im Hintergrund und eine blaue Kugel im Vordergrund angezeigt werden. Die Kugel ist das gerade ausgewählte Objekt und erhält deshalb eine weiße Darstellung seiner Gitternetzstruktur und ein so genanntes Gizmo, eine Benutzungsschnittstelle im dreidimensionalen Raum zur Verschiebung, Drehung oder Skalierung des ausgewählten Objektes [DD13]. Die Interaktion mit den Objekten in der dreidimensionalen virtuellen Szene erfolgt bei 3ds Max über Gizmos. Diese werden als Gruppe von zwei- oder drei Pfeilen dargestellt. Jeder Pfeil zeigt auf eine der drei Achsen des Koordinatensystems. Durch Klicken und Ziehen mit der Maus wird je nach Typ des Gizmos das selektierte Objekt auf der betreffenden Achse verschoben, rotiert oder skaliert. Gizmos können auf Objekt- Polygon- oder Punktebene eingeblendet werden, so dass dreidimensionale Objekte in einer sehr feinen Granularität verändert werden können [DD13]. Die Veränderung der Sicht auf die Szene und die Navigation der freien Perspektive wird bei 3ds Max auf zwei verschiedene Arten durchgeführt. Eine davon ist die Nutzung des so genannten ViewCubes. Es handelt sich dabei um einen interaktiven Würfel, welcher in jeder Ansicht rechts oben dargestellt und per Mausklicks bedient wird. Ein Klick auf eine der Flächen, Kanten oder Ecken dreht den ViewCube so zur Kamera, dass sich der angeklickte Teil des Würfels am nächsten zur virtuellen Kamera befindet. Die Ansicht der virtuellen Szene dreht sich dabei genau wie der Würfel. Alternativ zum ViewCube wird die Maus benutzt um die Ansicht zu ändern. Durch Klicken und halten der mittleren Maustaste und Bewegung der Maus in eine Richtung wird die virtuelle Kamera auf dessen X- und Y-Achsen in die betreffende Richtung verschoben. Dies funktioniert in den zweidimensionalen Ansichten analog zur dreidimensionalen Ansicht. Die Bewegung des Mausrades löst in den 2D-Ansichten einen Zoom aus und vergrößert die Objekte. In der 3D-Ansicht wird durch das Mausrad die virtuelle Kamera auf deren Z-Achse bewegt. Damit wird ein ähnlicher Effekt wie der Zoom erzielt. Drückt der Benutzer die Alt-Taste während er bei gedrückter mittlerer Maustaste die Maus bewegt, so bestimmt er eine freie Ausrichtung der virtuellen Kamera, welche das selektierte Objekt in ihrem Fokus behält und sich je nach Mausbewegung konzentrisch auf allen drei Achsen darum positioniert.

69 Stand der Technik Seite Blender Blender ist eine von der Blender Foundation entwickelte freie Software zur Modellierung, Animation und zum Rendern von dreidimensionalen Körpern und wird zur Spieleentwicklung und Videoerstellung genutzt. Sie enthält unter anderem eine Komponente zum Videoschnitt und ist mit einer Spiele-Engine, einem System zur vereinfachten Entwicklung von Computerspielen, ausgestattet. Der Schwerpunkt der Software liegt in der Interaktion mit dreidimensionalen Objekten in Form von Polygonen [Hes10]. Abbildung 4-8: Aufbau des Programmfensters von Blender [Hes10] Abbildung 4-8 zeigt, wie das Programmfenster von Blender aufgebaut ist. An oberster Stelle befinden sich das Dateimenü und einige Elemente zum Wechseln der Sicht auf die aktuelle Szene oder zum Wechseln der bearbeiteten Szene. Am linken Rand sind selektionsbezogene Funktionalitäten in vertikalen Reitern unterteilt aufgelistet, wie zum Beispiel Funktionalitäten zum Verschieben oder Kopieren von Objekten. Rechter Hand befinden sich Steuerelemente zur Verwaltung der Szeneneigenschaften. Hier wird unter anderem eine baumartige, abstrahierte Struktur der aktuellen Szene angezeigt, über welche einzelne Objekte markiert oder ausgeblendet werden. Am unteren Rand des Fensters ist die Animationsliste und Steuerelemente zu Animationen zu sehen. Der wichtigste Teil des

70 Seite 64 Kapitel 4 Programms befindet sich in der Mitte. Standardmäßig wird hier die aktuell bearbeitete Szene in Form einer dreidimensionalen perspektivischen Projektion dargestellt. In dem Beispiel der Abbildung sind ein Würfel und ein Zylinder zu sehen. Der Zylinder im Vordergrund ist gerade selektiert, was an seiner dünnen gelben Umrandung zu erkennen ist. Alle Bereiche von Blender können per Maus vergrößert und verkleinert und in beliebig viele Unterbereiche aufgeteilt werden [Hes10]. Blender bietet mehrere Möglichkeiten mit den Objekten im dreidimensionalen Raum zu interagieren. Die drei wichtigsten Operationen sind dabei das Verschieben, das Rotieren und das Skalieren von Objekten. Eine Möglichkeit dazu bietet die linke Menüleiste mit den entsprechenden Schaltflächen Translate, Rotate und Scale. Wird ein Objekt selektiert, die Schaltfläche Translate angeklickt und die Maus bewegt, so bewegt sich im gleichen Maße das selektierte Objekt auf den beiden Koordinatenachsen, die ungefähr orthogonal zur Blickrichtung der virtuellen Kamera stehen. Ein Klick auf Rotate und eine Mausbewegung führen zu einer Rotation des Objekts um die Achse der Kamerablickrichtung und ein Klick auf Scale löst bei gleichen Aktionen eine Vergrößerung oder Verkleinerung des Objektes aus. Die Transformation des selektierten Objektes wird dabei so lange durchgeführt, bis ein erneuter Klick auf eine beliebige Stelle des Benutzungsinterface erfolgt. Eine weitere Methode dieser Art der Bearbeitung von Objekten ist das so genannte Manipulator Widget. Es handelt sich dabei um ein Benutzungsinterface, welches im dreidimensionalen Raum der Szene eingesetzt ist in Abbildung 4-8 bei dem selektierten Zylinder zu sehen. Das Widget wird in drei Modi betrieben. Im Modus Verschieben wird es als drei Pfeile dargestellt. Jeder Pfeil ist jeweils nach einer der drei Koordinatenachsen ausgerichtet und wird mit der Maus angeklickt und verschoben. Die Verschiebung des Pfeils entlang seiner Richtung führt zu einer äquivalenten Verschiebung des selektierten Objektes. Der Modus Rotieren zeigt das Widget als drei konzentrische Kreise an, welche jeweils auf der Ebene zweier Koordinatenachsen liegen. Klicken und Ziehen mit der Maus führt zu einer Rotation des Objektes um die zum Kreis orthogonal verlaufende Achse. Der Skalieren-Modus zeigt statt drei Pfeile drei Linien an. Das Anklicken und Ziehen dieser Linien erzeugt eine Skalierung des selektierten Objektes auf der entsprechenden Achse [Hes10]. Die Veränderung der Perspektive auf die Szene erfolgt mit der Tastatur und der Maus. Klickt der Benutzer die mittlere Maustaste und bewegt er die Maus, wird die virtuelle Kamera entsprechend der Mausrichtung verschoben und behält dabei den Fokus im Ursprung des Koordinatensystems. Die Bewegung mit der Maus kommt also einem Schwenk der Kamera um die Szene herum gleich. Die Betätigung des Scrollrades löst eine Bewegung der Kamera in Richtung des Blickwinkels oder in die entgegengesetzte Richtung aus. Auf diese Weise wird an Objekte herangefahren, so dass der Eindruck eines Zooms entsteht. Das

71 Stand der Technik Seite 65 gleichzeitige Drücken der Shift-Taste und der mittleren Maustaste bewegt die Kamera beim Ziehen der Maus in die entsprechende Richtung. Bei vertikalen Bewegungen der Maus wird die Kamera herauf- oder herabgesetzt. Bei horizontalen Bewegungen bewegt sich die Kamera auf einer horizontalen Achse, welche sich orthogonal zur Blickrichtung der Kamera befindet [Hes10]. 4.4 Bewertung In Kapitel 3 wurden die Anforderungen formuliert. Nachfolgend wird nun geprüft, welches Werkzeug welche Anforderungen erfüllt. Es werden Bewertungskriterien aufgestellt, die sich direkt aus den aufgestellten Anforderungen ergeben. Die vorgestellten Werkzeuge in diesem Kapitel werden anhand dieser Kriterien bewertet, indem jedem Werkzeug für jedes Kriterium ein Wert zwischen 0 und 4 zugewiesen oder das Kriterium mit einem Bindestrich als unbewertet gekennzeichnet wird. Unbewertet bleiben alle Kriterien, die sich nicht mit dem Einsatz des Werkzeugs in Verbindung bringen lassen. So werden die 3D-Modellierungswerkzeuge 3ds Max und Blender zum Beispiel nicht untersucht inwiefern sie die Modellierung von Geschäftsprozessmodellen unterstützen. Bei den Bewertungen bedeutet eine 0, dass die betreffende Anforderung nicht erfüllt ist, während eine 4 ausdrückt, dass die Anforderung bestmöglich umgesetzt ist. Die Kriterien werden im Folgenden Aufgelistet: Hilfestellung bei Modellierung (HM) Syntaxüberprüfung (SÜ) Semantische Verknüpfung (SV) Datenorganisation (DO) Personenorganisation (PO) Kommunikationsmöglichkeiten (KM) Förderung der Awareness (FA) Nutzung des dreidimensionalen Raumes (ND) Ausnutzung des Bildschirmplatzes (AB) Navigationsmöglichkeiten (NM) Tabelle 4-1 zeigt, wie die einzelnen Kriterien der vorgestellten Werkzeuge bewertet werden. In der linken Spalte ist die Kurzschreibweise der Kriterien aufgelistet, die übrigen Spalten enthalten die Bewertungen der Kriterien für das jeweilige Werkzeug. Die Namen der Werkzeuge werden wie folgt abgekürzt: Visio (VIS) OMEGA Process Modeller (OPM) Process Live (PL) BlueworksLive (BL) 3ds Max (3DS) Blender (BLE)

72 Seite 66 Kapitel 4 Aufgrund der sehr unterschiedlichen Einsatzgebiete und Zielgruppen der vorgestellten Werkzeuge und deren entsprechend sehr unterschiedlichen Ausprägungen in den Bereichen der einzelnen Kriterien wird auf eine Gesamtbewertung der Werkzeuge durch eine Aufsummierung aller Kriterienbewertungen verzichtet. Die hier durchgeführten Bewertungen dienen vielmehr als eine der Grundlagen für die Entwicklung des Konzepts indem verdeutlicht wird, welche Anforderung von welchem Werkzeug vorbildlich umgesetzt wurde und an welchen Stellen sich noch Verbesserungspotential befindet. KRITERIUM VIS OPM PL BL 3DS BLE HM SÜ SV DO PO KM FA ND AB NM Tabelle 4-1: Bewertung der Werkzeuge im Hinblick auf die gestellten Anforderungen aus Kapitel 3. Vorbildliche Umsetzungen sind Fett hervorgehoben. Hilfestellung bei Modellierung (HM) ist ein Kriterium zur Bewertung, inwiefern ein Werkzeug den Benutzer bei der Erstellung oder Ausrichtung von Modellelementen oder Objekten unterstützt. Ein automatisches System zur Anordnung o- der das gleichförmige Aneinanderreihen von Objekten ist beispielsweise so eine Hilfestellung. Visio besitzt dazu solch ein System und unterstützt den Anwender. Da Visio allerdings ein Werkzeug zur allgemeinen Modellierung ist, enthält es

73 Stand der Technik Seite 67 keine OMEGA-Spezifischen Hilfestellungen um z.b. Prozesse immer an der gleichen Stelle von Organisationseinheiten anzuzeigen. Dieses leistet jedoch der OMEGA Process Modeller und in einer ähnlichen Art Process Live. Mit der Maus muss jedoch nachjustiert werden. BlueworksLive erleichtert die Modellierung enorm durch eine automatische Ausrichtung von Prozessmodellen. Die Werkzeuge 3ds Max und Blender unterstützen diese Funktionalität aufgrund Ihres Einsatzgebietes nicht. Bei dem Kriterium Syntaxüberprüfung (SÜ) wird untersucht, ob ein Werkzeug dabei behilflich ist ein syntaktisch korrektes Modell des Geschäftsprozesses zu erzeugen. Visio bietet keinerlei Unterstützung dafür, genau so wenig wie 3ds Max und Blender. Der OMEGA Process Modeller, Process Live und BlueworksLive haben eine integrierte Syntaxüberprüfung, die schon bei der Erstellung fehlerhafte Modellierung unterbindet, indem zum Beispiel inkorrekte Verbindungen von Modellelementen nicht zugelassen werden. Das Kriterium semantische Verknüpfung (SV) dient dazu herauszufinden, ob ein mit dem jeweiligen Werkzeug modelliertes Geschäftsprozessmodell nach semantischen Aspekten analysiert werden kann. Das heißt zum Beispiel, ob Modellelemente mit Entitäten verknüpft werden können, um so herauszufinden wie oft und in welchem Kontext eine Entität genutzt wird. Visio, Process Live und BlueworksLive bieten keine solche Funktionalität. Der OMEGA Process Modeller dagegen enthält umfangreiche Funktionalitäten zur Verknüpfung. Eine automatisierte Hilfestellung zur Erzeugung neuer Elemente durch zum Beispiel eine Autovervollständigung bei der Benennung von Modellelementen fehlt jedoch. Datenorganisation (DO) ist ein Kriterium um festzustellen, ob eine Anwendung die Verwaltung der generierten Dateien unterstützt und zum Beispiel Kategorisierungen von Geschäftsprozessmodellen in Projekte bietet. Visio, 3ds Max und Blender bieten keine solche Funktionalität. Die hier erstellten Dateien müssen in einer separaten Umgebung verwaltet werden. Beim OMEGA Process Modeller ist durch die Integration von Microsoft SharePoint eine vereinfachte Form der Organisation gegeben. Process Live unterstützt dagegen selbst eine Kategorisierung von Geschäftsprozessmodellen in Projekte. BlueworksLive bietet daneben noch eine Einbindung von Modellen in Workflows an. Das Kriterium Personenorganisation (PO) gibt einen Hinweis darauf, ob beteiligte Personen an der Modellierung mit Hilfe des Werkzeugs organisiert werden können indem zum Beispiel Zugriffsrechte auf Benutzer vergeben oder Aufgaben zugeteilt werden. Visio und die Werkzeuge 3ds Max und Blender erfüllen dieses Kriterium nicht. Im OMEGA Process Modeller ist die Organisation von Personen teilweise gegeben, indem sie über die Integration von Microsoft SharePoint abgewickelt wird. Process Live erlaubt eine detaillierte Definition

74 Seite 68 Kapitel 4 von Benutzergruppen und Zugriffsrechten auf einzelne Projekte und Modelle. BlueworksLive bietet neben den Gruppendefinitionen noch komplexe Funktionalitäten zur Definition von Aufgaben und Workflows mit Modellierungs- Review- und Freigabephasen. Bei dem Kriterium Kommunikationsmöglichkeiten (KM) wird festgestellt welche Möglichkeiten mehreren Modellierern untereinander zur Kommunikation zur Verfügung stehen. Bei Vision und dem OMEGA Process Modeller sind diese Möglichkeiten sehr begrenzt gegeben, da lediglich Kommentare an Modellen erfasst werden können. Process Live bietet zusätzlich Kommunikationsplattformen für jede Benutzergruppe an. BlueworksLive erweitert dies noch um eine Chatfunktion, die aktuelle Bearbeiter eines Modells in Anspruch nehmen können. 3ds Max und Blender sind keine kollaborativen Anwendungen und bieten keine entsprechenden Funktionalitäten. Die Förderung der Awareness (FA) ist ein Kriterium um zu untersuchen wie Modellierer auf deren Aktionen untereinander aufmerksam gemacht werden und wie sie die Aktivitäten anderer Benutzer erfahren. Visio, der OMEGA Process Modeller und die beiden Werkzeuge 3ds Max und Blender bieten keine Förderung der Awareness. Process Live stellt den Modellierern eine Historie zur Nachverfolgung von Änderungen zu jedem Prozess und auf Projektebene zur Verfügung. BlueworksLive bietet daneben noch eine Anzeige, welche Benutzer im Moment an welchem Prozessmodell arbeiten und stellt deren Änderungen mit einer sehr kurzen zeitlichen Verzögerung dar. Das Kriterium Nutzung des dreidimensionalen Raumes (ND) wird zur Untersuchung der Fähigkeit der Werkzeuge zur dreidimensionalen Modellierung herangezogen. Keines der vier untersuchten Werkzeuge zur Bearbeitung von Geschäftsmodellen lieferte dafür eine Unterstützung. Bei den Werkzeugen 3ds Max und Blender ist dies jedoch ein integrierter Bestandteil. Ausnutzung des Bildschirmplatzes (AB) bezeichnet das Kriterium zur Feststellung wie effektiv ein Werkzeug den vorhandenen Bildschirmplatz nutzt. Bei Visio und dem OMEGA Process Modeller können gerade nicht benötigte Seitenleisten ausgeblendet und damit der verfügbare Platz zur Darstellung der Geschäftsprozessmodelle vergrößert werden. Die Leisten mit den verfügbaren Modellelementen sind in diesen Werkzeugen jedoch essentiell für die Modellierung und beschränken diese sehr stark im ausgeblendeten Zustand. Process Live erlaubt die Ausblendung von Seitenleisten und ist danach durch die Mini Toolbar immer noch voll funktionsfähig. In BlueworksLive werden sehr viele Metainformationen zusammen mit dem Geschäftsprozessmodell angezeigt. Der Bildschirmplatz für die Modellierung ist daher im Vergleich zu den anderen Werkzeugen klein. 3ds Max ermöglicht durch ein flexibles Fenstersystem und die Anordnung von Fenstern auf mehrere Bildschirme eine optimale Ausnutzung des

75 Stand der Technik Seite 69 Bildschirmplatzes. Blender erlaubt auch flexible Fenstergrößen, jedoch bleiben diese immer durch die Größe des Hauptfensters beschränkt und sind bei sehr starker Verkleinerung unbrauchbar. Bei dem Kriterium Navigationsmöglichkeiten (NM) handelt es sich um eine Bewertung der Möglichkeiten zur veränderbaren Sicht auf die Modelle und zum Wechsel zwischen zusammenhängenden Modellen durch beispielweise eine Traversierung der Modellhierarchien. Visio bietet hier die herkömmliche Navigation durch Scrollbalken und einer Zoom-Funktion. Der OMEGA Process Modeller enthält die Funktionalität des Explorers, einer baumartigen Navigationsstruktur. Die Ansicht kann auf das dort selektierte Element automatisiert angepasst werden. In Process Live und BlueworksLive findet die Navigation innerhalb eines Prozessmodells mit herkömmlichen Scrollbalken statt und außerhalb des Prozessmodells über eine Prozessliste. In 3ds Max und Blender ist eine freie Positionierung der virtuellen Kamera im dreidimensionalen Raum möglich und liefert so eine beliebige Ansicht auf die Modelle. Die Bewertungen zeigen, dass zu den gestellten Anforderungen bereits vereinzelte vielversprechende Ansätze aus bestehenden Werkzeugen existieren, obwohl es kein Werkzeug gibt, welches die Modellierung von Geschäftsprozessmodellen in OMEGA-Notation im dreidimensionalen Raum unterstützt. Zusammen mit den Forschungsergebnissen aus Kapitel 2 dienen diese Erkenntnisse dem Aufbau des Konzepts im nächsten Kapitel.

76 Seite 70 Kapitel 5 5 Entwicklung des Konzeptes In Kapitel 2 wurden relevante Forschungsergebnisse zusammengetragen, in Kapitel 3 die Anforderungen an das zu entwickelnde Konzept definiert und in Kapitel 4 bestehende Werkzeuge anhand der Anforderungen bewertet und untersucht. Dieses Kapitel beschreibt, wie das Konzept zur dreidimensionalen Mehrbenutzer-Interaktion mit Geschäftsprozessmodellen in OMEGA-Notation entwickelt wird und wie es sich darstellt. 5.1 Ansatz Der Prozess zur Entwicklung des Konzepts und der anschließenden Implementierung lehnt sich in den Grundzügen an den Rational Unified Process (RUP) an [KK03]. Dieser ist ein anwendungsfallorientierter Ansatz zur Softwareentwicklung, bei dem iterativ die Phasen Anwendungsdefinition, Analyse und Entwurf, Implementierung, Test und schließlich Evaluation durchlaufen werden [KK03]. In dieser Arbeit werden die Phasen folgendermaßen gehandhabt: die Phase Anwendungsdefinition wurde bereits teilweise in Kapitel 3 und 4 durch die Aufstellung der groben Anforderungen begonnen. Im nächsten Unterkapitel 5.2 wird diese Phase durch die Ermittlung der Anwendungsfälle für das zu entwickelnde Werkzeug abgeschlossen. Danach folgt die Phase Analyse und Entwurf, deren Inhalt in den weiteren Unterkapiteln von Kapitel 5 behandelt wird. In Kapitel 6 wird abschließend die Phase Implementierung beschrieben. Die Phase Test ist kein Bestandteil dieser Arbeit. Die letzte Phase Evaluation wird als Nachfolgearbeit vorgeschlagen, in welcher der Prototyp weiter verbessert wird. Die Phasen werden im Gegensatz zum gewöhnlichen Vorgehen im Rational Unified Process aufgrund des Umfangs dieser Arbeit hier nur jeweils einmal durchlaufen. Der konkrete Ablauf der Konzeptentwicklung wird in folgender Abbildung 5-1 als Phasendiagramm dargestellt. Zunächst wird in den ersten drei Phasen Literaturrecherche, Produktrecherche und Anforderungsanalyse ermittelt, welche Funktionalitäten das Werkzeug beinhalten muss. Dazu werden Anwendungsfälle [Oes12] aus der OMEGA-Definition und weiteren Literaturquellen zur OMEGA-Methode abgeleitet, bestehende Werkzeuge untersucht und Anwendungsfälle aus den in dieser Arbeit gestellten Anforderungen an das Werkzeug entwickelt. Das Resultat ist ein Katalog aus Anwendungsfällen, welcher in der Phase Strukturierung geordnet wird. Im Rahmen der Strukturierung werden zusammenhängende Anwendungsfälle zusammengefasst und übergeordneten Anwendungsfällen zugeordnet. Doppelte oder sehr ähnliche Anwendungsfälle werden durch einzelne Fälle ersetzt. Der strukturierte Katalog wird daraufhin in der Phase Priorisierung geordnet. Für jeden der priorisierten Anwendungsfälle wird in der Phase Einzelkonzeption ein Konzept für das Werkzeug entworfen und in

77 Entwicklung des Konzeptes Seite 71 der letzten Phase Zusammenführung zu einem Gesamtkonzept zusammengesetzt. Abbildung 5-1: Vorgehen bei der Konzeptentwicklung Das Gesamtkonzept wird anschließend teilweise als Prototyp umgesetzt, um dessen Machbarkeit zu zeigen. Dies wird in Kapitel 6 näher beschrieben und gehört nicht mehr zur Konzeptentwicklung.

78 Seite 72 Kapitel Ermittlung der Anwendungsfälle In diesem Unterkapitel wird vorgestellt, wie die Anwendungsfälle ermittelt werden. Ein Anwendungsfall wird in dieser Arbeit als reine prosaische Kurzbeschreibung einer möglichen Aktivität eines Benutzers mit dem Werkzeug genutzt. Die Beschreibung erfolgt abstrahiert von der technischen Umsetzung. Die Anwendungsfälle werden aus der Literatur, insbesondere der Definition der OMEGA-Methode in Fahrwinkels [Fah95] Arbeit und der Arbeit von Mayr [May10], den Werkzeugen Microsoft Visio [Mar13] und OMEGA Process Modeller von Unity [Uni12] und schließlich aus den in Kapitel 3 gestellten Anforderungen gewonnen Ermittlung aus der OMEGA-Methode Die OMEGA-Methode von Fahrwinkel [Fah95] beschreibt ein ganzheitliches Vorgehen zur Geschäftsprozessoptimierung auf der einen Seite und ein grobes Konzept für ein unterstützendes Werkzeug auf der anderen Seite. Das von Fahrwinkel beschriebene Werkzeug ist für diese Arbeit besonders interessant, denn aus dessen Grobkonzeption lassen sich grundlegende Anwendungsfälle für das hier zu entwickelnde Werkzeug ableiten. Fahrwinkel spezifiziert die Anforderungen an ein Modellierungswerkzeug in Form einer tabellarischen Liste und beschreibt mit Substantiven was das Werkzeug leisten muss. Ein Beispiel für einen Eintrag in dieser Liste ist graphische Modell-Entwicklung (graphische Notation) [Fah95]. Die Einträge wurden als Anwendungsfälle umgewandelt übernommen, indem je nach beteiligtem Subjekt in die Form [Subjekt] [Gewünschte Aktivität] umformuliert wurde. Obiges Beispiel lautet als Anwendungsfall somit Ein Benutzer soll die Modellentwicklung grafisch durchführen können. Einige Beispiele der so gewonnenen Anwendungsfälle sind in Tabelle 5-1 abgedruckt. Die linke Spalte enthält die Formulierungen aus Fahrwinkels Anforderungen. Die rechte Spalte ist mit den daraus gewonnenen Anwendungsfällen gefüllt. Eine vollständige Tabelle aller so gewonnenen Anwendungsfälle befindet sich im Anhang.

79 Entwicklung des Konzeptes Seite 73 ANFORDERUNG AUS FAHRWINKELS ARBEIT Abbildung der Geschäftsprozesse ERMITTELTER ANWENDUNGSFALL Der Benutzer soll Geschäftsprozesse abbilden können. Abbildung der Outputobjekte sowie der Inputobjekte der Geschäftsprozesse, differenziert nach Typ und Medium Definition von Prozesszuständen Sehr anschauliche, leicht erfassbare Visualisierung der Gesamtzusammenhänge Der Benutzer soll Input- und Outputobjekte nach Typ und Medium differenziert abbilden können. Der Benutzer soll Prozesszustände definieren können. Das Werkzeug soll Gesamtzusammenhänge sehr anschaulich und leicht erfassbar visualisieren. Tabelle 5-1: Beispielhafte Überführung von Anforderungen aus Fahrwinkels Arbeit [Fah95] in Anwendungsfälle Darüber hinaus beschreibt Fahrwinkel in einem eigenen Kapitel ihr Konzept eines Modellierungswerkzeugs. Darin werden die Aspekte der Darstellung von Modellen, der Interaktion des Benutzers mit dem Werkzeug und der Navigation in der Modellansicht erläutert. Die Texte wurden nach Anwendungsfällen untersucht und diese daraus extrahiert. Folgende Tabelle 5-2 zeigt einen Ausschnitt der gewonnenen Anwendungsfälle. Die vollständige Liste der so ermittelten Anwendungsfälle ist im Anhang abgedruckt. ERMITTELTER ANWENDUNGSFALL Das Werkzeug soll Modelle in einer ganzheitlichen 3D-Visualisierung darstellen. Der Benutzer soll unterschiedliche Ebenen des Detaillierungsgrades aktivieren können. Der Benutzer soll im dreidimensionalen Raum mit den Geschäftsprozessmodellen interagieren können. Der Benutzer soll sich im virtuellen dreidimensionalen Raum frei bewegen und die Kamera beliebig ausrichten können. Tabelle 5-2: Auszug der gewonnenen Anwendungsfälle aus Fahrwinkels [Fah95] Grobkonzept eines Modellierungswerkzeugs

80 Seite 74 Kapitel Ermittlung aus der Arbeit von Mayr Mayr [May10] entwickelt in seiner Arbeit einen Editor-Prototyp für Geschäftsprozesse in OMEGA-Notation. Vor der Umsetzung stellt er eine Liste von so genannten Lösungsansätzen auf. Dies ist eine Auflistung von Vorschlägen zu Funktionalitäten des zu entwickelnden Editors. Ein Listeneintrag ist durch ein deskriptives Substantiv übertitelt und enthält eine prosaische Beschreibung der Funktionalität [May10]. Die Listeneinträge wurden jeweils mit der gleichen Methodik wie bei der Überführung der Anwendungsfälle aus Fahrwinkels Arbeit übertragen. Die jeweiligen Beschreibungstexte dienten dabei der Konkretisierung von Anwendungsfällen, die allein durch ihre Betitelung unzureichend oder zu allgemein beschrieben waren. Tabelle 5-3 zeigt einen Ausschnitt des Resultats. Die linke Spalte enthält die Betitelungen aus Mayrs Liste. Die rechte Spalte enthält die aus den Listeneinträgen gewonnenen Anwendungsfälle. Die vollständige Liste befindet sich im Anhang dieser Arbeit. VORSCHLAG VON MAYR Löschen von Elementen ERMITTELTER ANWENDUNGSFALL Der Benutzer soll Modellelemente löschen können. Automatische Pfadführung von Kanten Automatische Anordnung der Elemente in einem Prozesskasten Animationen Das Werkzeug soll passende Modellelemente automatisch verbinden und Verbindungskanten entsprechend ausrichten. Das Werkzeug soll Hilfestellung bei der gleichförmigen Anordnung von Modellelementen leisten. Das Werkzeug soll das Verschieben, die Größenänderung von Modellelementen und den Übergang von einer Ansicht auf eine andere durch Animationen visualisieren. Tabelle 5-3: Auszug der ermittelten Anwendungsfälle aus Mayrs [May10] Vorschlägen zu Funktionalitäten eines OMEGA-Editors

81 Entwicklung des Konzeptes Seite Ermittlung aus Visio Microsoft Visio [Mar13] ist ein Werkzeug zur Erzeugung von Diagrammen in unterschiedlichsten Notationen. Die Anwendungsfälle wurden aus Visio in zwei Schritten gewonnen. Zunächst wurde das Programm systematisch nach Anwendungsfällen untersucht indem ein OMEGA-Diagramm mit allen Modelltypen erstellt und geändert wurde und dabei jede Aktion als Anwendungsfall formuliert aufgenommen wurde. Auf diese Weise sind grundlegende Anwendungsfälle identifiziert worden. Anschließend wurde die Benutzungsschnittstelle von Visio untersucht und die Ribbon-Bars und Kontextmenüs nach Funktionalitäten durchsucht, die mit der Modellierung von OMEGA-Diagrammen in Relation stehen. Passende Funktionalitäten wurden als Anwendungsfälle formuliert und ebenfalls aufgenommen. Die unten abgebildete Tabelle 5-4 zeigt einige Anwendungsfälle, die durch die Erstellung und Änderung eines OMEGA-Modells zustande gekommen sind. In der linken Spalte ist die jeweilige Aktion aufgeführt. In der rechten Spalte die jeweils daraus formulierten Anwendungsfälle. Die vollständige Tabelle aller Anwendungsfälle die auf diese Art erfasst wurden befindet sich im Anhang. AKTION Leere Zeichnung erstellen ERMITTELTER ANWENDUNGSFALL Der Benutzer soll einen neuen Geschäftsprozess erstellen können. Eine Organisationseinheit auf die Zeichenfläche ziehen Den Text der erstellten Organisationseinheit ändern Das externe Objekt, das Papierinformationsobjekt und den Prozess verbinden Der Benutzer soll Organisationseinheiten modellieren können. Der Benutzer soll Organisationseinheiten benennen können. Der Benutzer soll Modellelemente miteinander verbinden können. Tabelle 5-4: Beispiele der ermittelten Anwendungsfälle aus der Bedienung von Visio zur Erstellung und Bearbeitung eines Geschäftsprozesses Auf der nächsten Seite ist Tabelle 5-5 abgebildet, die beispielhaft einen Ausschnitt der Anwendungsfälle enthält, welche bei der Sichtung der Benutzungsschnittstelle erfasst wurden. Auf der linken Seite befindet sich das untersuchte Element der Benutzungsschnittstelle. In der rechten Spalte sind die gewonnenen Anwendungsfälle aufgelistet. Die gesamte Liste von Anwendungsfällen dieser Art ist im Anhang abgedruckt.

82 Seite 76 Kapitel 5 BENUTZUNGSSCHNITTSTELLE Ribbon-Bar: Kopieren ERMITTELTER ANWENDUNGSFALL Der Benutzer soll Modellelemente kopieren können. Ribbon-Bar: Verbinder Ribbon-Bar: Automatischer Abstand Kontextmenü: Text bearbeiten Der Benutzer soll Modellelemente miteinander verbinden können. Das Werkzeug soll die Positionen von Modellelementen automatisiert aneinander anpassen. Der Benutzer soll Modellelemente umbenennen können. Tabelle 5-5: Auswahl der ermittelten Anwendungsfälle aus der Benutzungsschnittstelle von Visio Ermittlung aus OMEGA Process Modeller Die Anwendungsfälle aus dem OMEGA Process Modeller [Uni12] wurden auf dieselbe Art und Weise ermittelt, wie es bei dem Programm Visio durchgeführt wurde. Zunächst wurde mit dem Werkzeug ein Geschäftsprozessmodell erstellt und dabei die einzelnen Aktionen in Anwendungsfälle umgewandelt. Zusätzlich dazu wurde die Benutzungsschnittstelle von dem Programm OMEGA Process Modeller systematisch nach Anwendungsfällen untersucht. Die folgende Tabelle 5-6 zeigt eine Auswahl der Anwendungsfälle, die bei der Erstellung und Bearbeitung eines Geschäftsprozessmodells ermittelt wurden. Die linke Spalte zeigt die jeweilige Aktion an. Die rechte Spalte enthält die aus den Aktionen abgewandelten Anwendungsfälle. Im Anhang ist eine vollständige Liste der so ermittelten Anwendungsfälle zu finden. AKTION Eine Organisationseinheit auf die Zeichenfläche ziehen ERMITTELTER ANWENDUNGSFALL Das Werkzeug soll zu neuen Organisationseinheiten automatisiert Prozesse erstellen. Der Organisationseinheit eine Klasse zuweisen Der Benutzer soll Modellelemente mit semantischen Objekten verbinden können.

83 Entwicklung des Konzeptes Seite 77 Das externe Objekt, das Papierinformationsobjekt und den Prozess verbinden Die Klasse des Papierinformationsobjekts umbenennen. Das Werkzeug soll ungültige Verbindungen verhindern. Der Benutzer soll semantische Objekte ändern und damit verbundene Modellelemente aktualisieren können. Tabelle 5-6: Beispiele der ermittelten Anwendungsfälle aus der Bedienung von OMEGA Process Modeller zur Erstellung und Bearbeitung eines Geschäftsprozesses In nachfolgender Tabelle 5-7 sind die Anwendungsfälle aufgelistet, welche aus der Benutzungsschnittstelle von OMEGA Process Modeller abgeleitet wurden. In der linken Spalte befinden sich die untersuchten Elemente der Benutzungsschnittstelle und auf der rechten Seite die jeweils daraus ermittelten Anwendungsfälle. Die Gesamtheit der so ermittelten Anwendungsfälle ist als Tabelle im Anhang abgedruckt. BENUTZUNGSSCHNITTSTELLE Ribbon-Bar: Löschen ERMITTELTER ANWENDUNGSFALL Der Benutzer soll Modellelemente löschen können. Ribbon-Bar: Explorer Ribbon-Bar: Verfeinern Ribbon-Bar: Gehe zu Der Benutzer soll in einer Baumansicht durch den Prozess navigieren können. Der Benutzer soll Prozesse in Unterprozesse zerlegen können. Der Benutzer soll selektierte Modellelemente in den Fokus rücken lassen können. Tabelle 5-7: Auswahl der ermittelten Anwendungsfälle aus der Benutzungsschnittstelle von OMEGA Process Modeller

84 Seite 78 Kapitel Ermittlung aus Anforderungen Der folgende Abschnitt beschreibt, wie und welche Anwendungsfälle aus den in Kapitel 3 aufgestellten Anforderungen ermittelt wurden. Die Anforderungen sind so formuliert, dass sie ausdrücken, was das zu entwickelnde Werkzeug leisten muss. Daraus lassen sich die Anwendungsfälle mit dem Werkzeug als Subjekt direkt ableiten. Anwendungsfälle mit dem Benutzer als Subjekt sind ermittelt worden, indem die Anforderungen nach Benutzeraktivitäten aufgeschlüsselt wurden. Tabelle 5-8 listet einige der so ermittelten Anwendungsfälle auf. In der linken Spalte sind die Anforderungen als Kurzbeschreibungen enthalten. Die rechte Spalte beinhaltet die daraus gewonnenen Anwendungsfälle. ANFORDERUNG Modellvisualisierung in 3D ERMITTELTER ANWENDUNGSFALL Der Benutzer soll Geschäftsprozessmodelle im dreidimensionalen Raum modellieren können. Baumstruktur zur Navigation Synchrone Arbeitsstände Hilfestellung bei der Modellierung Der Benutzer soll mittels einer baumartigen Darstellung des Modells zwischen Modellelementen navigieren können. Das Werkzeug soll die Arbeitsstände mehrerer gleichzeitiger Benutzer an einem Modell synchron halten. Das Werkzeug soll Hilfestellung bei der Modellierung von Modellelementen bieten. Tabelle 5-8: Beispiele der ermittelten Anwendungsfälle aus den Anforderungen an das zu entwickelnde Werkzeug 5.3 Strukturierung und Priorisierung Dieses Kapitel beschreibt, wie die Liste der ermittelten Anwendungsfälle strukturiert und priorisiert wurde. Die Strukturierung diente dem Ziel, doppelte und ähnliche Anwendungsfälle zu eliminieren und die Anwendungsfälle zu priorisieren, welche in einem Prototyp beispielhaft implementiert werden. Aufgrund des Arbeitsumfangs ist eine vollständige Implementierung aller ermittelten Anwendungsfälle nicht möglich.

85 Entwicklung des Konzeptes Seite Strukturierung der Anwendungsfälle Nach der Sammlung der Anwendungsfälle aus der Literatur, den Werkzeugen und den Anforderungen wurden diese strukturiert. Dazu wurde nach dem Vorbild der qualitativen Inhaltsanalyse nach Mayring [May10a] vorgegangen. Die Formulierungen der einzelnen Anwendungsfälle wurden im Zuge einer Zusammenfassung zunächst paraphrasiert und anschließend eine Reduktion auf der Gesamtliste der Anwendungsfälle angewandt. Einträge mit inhaltlich gleichen Paraphrasierungen wurden auf diese Weise entfernt. Danach erfolgte zur einfacheren Übersicht und Handhabung eine Einsortierung der übrig gebliebenen Anwendungsfälle in die drei Kategorien Visualisierung, Navigation und Interaktion und Modellierung. Die Sortierung erfolgte aufgrund des Vorgehens der deduktiven Kategorienanwendung [May10a] und fußte auf den folgenden Kategoriendefinitionen. Die Kategorie Visualisierung wurde bei allen Anwendungsfällen angewandt, bei denen die Darstellung von Modellelementen im Vordergrund steht. Navigation ist die Kategorie, der alle Anwendungsfälle zugeordnet wurden, welche sich mit der Navigation des Benutzers durch die Prozessmodelle in Relation bringen lassen. Alle Anwendungsfälle, die die Interaktion mit Modellelementen als Inhalt haben, wie zum Beispiel die Hilfestellung bei der Ausrichtung von Elementen, wurden der Kategorie Interaktion zugewiesen. Die Kategorie Modellierung wurde allen Anwendungsfällen zugewiesen, die eine allgemeine Modellierungstätigkeit wiederspiegeln, wie beispielweise die Abbildung eines Informationsobjektes und seinen Relationen zu Prozessen. Die folgende Tabelle 5-9 enthält beispielhaft einige Anwendungsfälle und deren Einsortierung in die jeweilige Kategorie. Die linke Spalte enthält die Anwendungsfälle. Die rechte Spalte beinhaltet die jeweils zugeordnete Kategorie. Der initiale Katalog von Anwendungsfällen mit 146 Einträgen wurde durch die Strukturierung auf eine Länge von 62 Einträgen gekürzt. ANWENDUNGSFALL Das Werkzeug soll Modelle in einer ganzheitlichen 3D-Visualisierung darstellen. KATEGORIE Visualisierung Der Benutzer soll in einer Baumansicht durch den Prozess navigieren können. Navigation

86 Seite 80 Kapitel 5 Der Benutzer soll Änderungen anderer Mitbenutzer mitverfolgen können. Der Benutzer soll Informationsobjekte modellieren können. Interaktion Modellierung Tabelle 5-9: Auszug der Einsortierung von Anwendungsfällen in Kategorien Priorisierung der Anwendungsfälle Der strukturierte Katalog von Anwendungsfällen ist im Sinne einer Sortierung nach Priorität verarbeitet worden. Aufgrund des Umfangs dieser Arbeit ist in diesem Schritt entschieden worden, welche Anwendungsfälle im Folgenden noch weiter bearbeitet werden können. Die Sortierung erfolgte nach einer Ordnungszahl, die sich aus den drei im Folgenden vorgestellten quantitativen Bewertungskriterien zusammensetzt. Voraussetzung für Modellierung ist das Kriterium, das bestimmt ob die Umsetzung des betrachteten Anwendungsfalls notwendig und als Aktion eine Voraussetzung ist, um Geschäftsprozessmodelle zu modellieren. Der Wert dieses Kriteriums ist entweder 0, was bedeutet, dass der jeweilig betrachtete Anwendungsfall keine Voraussetzung für die Modellierung ist oder 1, wenn der Fall eine Voraussetzung darstellt. Das Kriterium Relevanz für Forschungsthema wurde für die Bewertung des jeweiligen Anwendungsfalls herangezogen um zu bestimmen inwiefern der Anwendungsfall die Themen Mehrbenutzerinteraktion und Dreidimensionalität abdeckt. Das Kriterium nimmt die Werte 0 bis 2 an. 0 bedeutet, dass der Anwendungsfall keine Bedeutung für das Forschungsthema hat. 2 bedeutet, dass es mit dem Forschungsthema korreliert. Häufigkeit ist als das Kriterium genutzt worden, welches die Anzahl des Auftretens des jeweiligen Anforderungsfalls im initialen Katalog als Grundlage nimmt. Das Kriterium nimmt Werte zwischen 1 und 5 an. Jeder der Anwendungsfälle wurde gemäß der drei Kriterien bewertet und seine Priorität als Summe der Bewertungen berechnet. Daraus ergaben sich Bewertungen von 1 bis 8 Punkten. Aufgrund der Umfangsbeschränkung dieser Arbeit werden in den folgenden Kapiteln nur noch die Anwendungsfälle mit einer Bewertung mit mehr als 2 Punkten betrachtet. Die nebenstehende Tabelle 5-10 zeigt beispielhaft einige der bewerteten Anwendungsfälle. Eine Tabelle mit allen Anwendungsfällen, die hier weiter betrachtet wurden, findet sich im Anhang.

87 Entwicklung des Konzeptes Seite 81 ANWENDUNGSFALL Ein Benutzer soll die Modellentwicklung grafisch durchführen können. WERTUNG WERTUNG WERTUNG (=PRIORITÄT) VORAUSSETZUNG RELEVANZ HÄUFIGKEIT Der Benutzer soll in Unterprozesse navigieren können. Der Benutzer soll die Position und die Blickwinkel anderer gleichzeitiger Benutzer sehen können Tabelle 5-10: Auszug der Bewertung und Priorisierung der Anwendungsfälle 5.4 Analyse der Anwendungsfälle Das folgende Kapitel beschreibt, wie die priorisierten Anwendungsfälle hinsichtlich bestehender Konzepte und Ansätze aus der Literatur untersucht wurden. Da der Fokus dieser Arbeit auf Mehrbenutzerinteraktion im dreidimensionalen Raum liegt, werden Anwendungsfälle mit ausgeprägtem Bezug zum Forschungsthema bevorzugt behandelt und für diese Fälle Konzepte und Lösungen aus der Literatur und bestehenden Werkzeugen gesucht. Anwendungsfälle mit geringem Bezug zum Thema, wie die Fälle bei denen die Modellierung die Kategorie darstellt, werden dagegen nicht weiter analysiert. Die folgenden Unterkapitel stellen für die einzelnen Anwendungsfälle der jeweiligen Kategorie vor, ob und welche Ansätze in Literatur und bestehenden Werkzeugen gefunden wurden oder beschreiben ein neues Konzept zu deren Realisierung. Existieren für einen Anwendungsfall bereits Lösungen in bestehenden Werkzeugen, so wird gemäß der Bewertungstabelle aus Kapitel 4 untersucht, welches Werkzeug eine vorbildliche Umsetzung liefert und diese Umsetzung adaptiert oder erweitert. Die Konzipierungen der Umsetzungen für jeden Anwendungsfall erfolgten iterativ in jeweils mehreren Schritten. Nachdem für jeden Anwendungsfall ein grobes Konzept gefunden wurde, wurden miteinander in Verbindung stehende Konzepte identifiziert und aufeinander abgestimmt. So wird im Folgenden zum Beispiel das so genannte Snap-In-System beschrieben, welches gleich in mehreren Anwendungsfällen zum Zuge kommt.

88 Seite 82 Kapitel Visualisierung Dieses Unterkapitel beschäftigt sich mit den Anwendungsfällen, die der Kategorie Visualisierung zugeteilt wurden. Die Fälle beschäftigen sich vor allem mit der ganzheitlichen Modelldarstellung und dem visuellen Aufbau des Werkzeugs. Im Folgenden werden die Anwendungsfälle aufgelistet und deren zugehörige Ansätze und Konzepte erläutert. Anwendungsfall: Das Werkzeug soll Modelle in einer ganzheitlichen 3D-Visualisierung darstellen. Für diesen Anwendungsfall schlägt Fahrwinkel [Fah95] in der Definition der OMEGA-Methode einige Visualisierungskonzepte vor. Diese sehen eine Darstellung des Modells auf mehreren Ebenen vor, die sich horizontal in einem dreidimensionalen Raum befinden. In Kapitel 2 dieser Arbeit sind die Konzepte zusammengefasst. Abbildung 2-8 gibt dazu eine schematische Darstellung der Modellvisualisierung aus Fahrwinkels Werkzeug wieder. Im Vergleich zu existierenden Werkzeugen wie Visio [Mar13] und dem OMEGA Process Modeller [Uni12] unterscheidet sich diese Darstellung nicht nur dahingehend, dass Modelle im dreidimensionalen Raum dargestellt werden, sondern dass eine Ansicht von der Seite auf die Modelle erfolgt. Damit ist gemeint, dass die Ebenen, auf denen sich die Modelle befinden, orthogonal zum Betrachter ausgerichtet sind. Um eine geläufige Darstellungsart zu erzielen, wird das Konzept von Fahrwinkel adaptiert und so angepasst, dass Modelle von vorne, so wie bei gängigen Werkzeugen üblich, visualisiert werden. Abbildung 5-2: Ganzheitliche 3D-Visualisierung des Modells Die Abbildung 5-2 zeigt schematisch wie das neue Konzept zur Visualisierung aussieht. Es sind die vertikal ausgerichteten Ebenen zu sehen. Die gestrichelte Ebene vorne ist transparent geschaltet. Dahinter befindet sich die aktive Ebene

89 Entwicklung des Konzeptes Seite 83 mit drei Modellelemente. Weiter hinten befinden sich die Ebenen 1 bis n. Links unten ist zur Orientierung ein Koordinatenkreuz mit der horizontalen X-Achse, der vertikalen Y-Achse und der Z-Achse, die den virtuellen Raum hineinragt, abgebildet. Anwendungsfall: Das Werkzeug soll in der Lage sein, die Reihenfolgen (sequentiell / parallel) von Geschäftsprozessen darzustellen. Dieser Fall hängt mit der ganzheitlichen dreidimensionalen Modellvisualisierung zusammen. Die Platzierung von Geschäftsprozessen erfolgt auf den Ebenen. In herkömmlichen Werkzeugen wie Vision oder dem OMEGA Process Modeller ist die Platzierung auf den zweidimensionalen Raum begrenzt. Sequentielle Geschäftsprozesse werden horizontal hintereinander angeordnet mit der Reihenfolge von links nach rechts. Sowohl bei Verzweigungen als auch bei parallelen Prozessflüssen werden weitere horizontale Anordnungen unterhalb des Hauptflusses angelegt. Durch die neue Modellvisualisierung wird nun der dreidimensionale Raum genutzt, um sequentielle und parallele Prozessflüsse besser voneinander zu unterscheiden. Ein sequentieller Fluss und sequentielle Verzeigungen werden auf jeweils einer Ebene modelliert. Zur Modellierung paralleler Flüsse werden die Modellelemente auf mehrere Ebenen verteilt, so dass sich jeweils in der Sequenz zusammenhängende Geschäftsprozesse auf derselben Ebene befinden. Anwendungsfall: Das Werkzeug soll unterschiedliche Ebenen des Detaillierungsgrades darstellen. Dieser Anwendungsfall hängt mit der Navigation zwischen Ober- und Unterprozessen zusammen, welche im nächsten Kapitel genauer erläutert wird. Wie in den Werkzeugen Visio [Mar13] und OMEGA Process Modeller [Uni12] werden OMEGA-Diagramme verschachtelbar modelliert. Das bedeutet, dass ein Prozessschritt eines Geschäftsprozesses ein eigener Geschäftsprozess mit eigenen Prozessschritten sein kann. Das neue Werkzeug bietet die Möglichkeit, durch einen Rechtsklick auf einen Prozessschritt diesen mit Hilfe eines Kontextmenüs mit einem existierenden oder neuen Geschäftsprozess zu verknüpfen. Anwendungsfall: Das Werkzeug soll das Verschieben, die Größenänderung von Modellelementen und den Übergang von einer Ansicht auf eine andere durch Animationen visualisieren. Dieser Anwendungsfall wird zum Teil von dem Werkzeug OMEGA Process Modeller [Uni12] unterstützt. Der Wechsel einer Ansicht auf eine andere erfolgt in einem animierten fließenden Übergang. Auf diese Weise bleibt die Orientierung im Diagramm erhalten. Das neue Werkzeug soll dies ebenfalls unterstützen um den gleichen Effekt zu erzielen. Anwendungsfall: Der Benutzer soll die Positionen und die Blickwinkel anderer gleichzeitiger Benutzer sehen können. Dieser Fall ist für die Unterstützung der Awareness wichtig. Wie die Arbeiten von Bentley et al. [BHS95] und Klöckner et al. [Klö95] zeigen, fördern Benachrichtigungen über Aktionen anderer

90 Seite 84 Kapitel 5 Benutzer die Awareness des Anwenders. Im Sinne der Fragen von Gutwins Fragenkatalog zur Awareness [GG99] werden die Fragen Wo arbeiten sie? und Worauf schauen sie? durch die Visualisierung der Positionen und Blickwinkel beantwortet und die Awareness des Arbeitsraums gefördert. Das Werkzeug zeigt die Positionen anderer Benutzer als farbige Punkte und dem jeweiligen Namen des Benutzers im dreidimensionalen Raum an und visualisiert das Blickfeld des jeweiligen Benutzers durch die Projektion eines Vierecks auf die vom Benutzer gerade angesehene Ebene. Die folgende Abbildung 5-3 zeigt schematisch, wie Positionen und Blickwinkel anderer Benutzer visualisiert werden. Zu sehen sind mehrere Ebenen mit Modellelementen, wovon die aktive Ebene im Vordergrund drei Prozessmodelle enthält. Die Positionen von den beiden Benutzern Alfons und Gustav sind als grüner beziehungsweise blauer beschrifteter Punkt gekennzeichnet. Abbildung 5-3: Visualisierung der Positionen und Blickwinkel anderer Benutzer bei der Bearbeitung Ihre Blickwinkel sind die in der entsprechenden Farbe angezeigten Vierecke auf der aktiven Ebene. Es ist zu erkennen, dass Alfons das erste Modellelement in seinem Blickfeld hat und Gustav die beiden letzteren Modellelemente ansieht Navigation Dieses Unterkapitel enthält die Analysen der Anwendungsfälle, die die Navigation als Thema beinhalten und dieser Kategorie zugeordnet sind. Anwendungsfall: Der Benutzer soll in Unterprozesse navigieren können. Dieser Fall hängt mit der Darstellung unterschiedlicher Ebenen des Detaillierungsgrades zusammen und wird durch den OMEGA Process Modeller [Uni12] unterstützt. Dort wird ein Prozessschritt selektiert und mittels des Befehls Verfeinern aus dem Prozessschritt entweder ein neuer Geschäftsprozess erstellt und

91 Entwicklung des Konzeptes Seite 85 angezeigt oder in einen bestehenden Geschäftsprozess gewechselt. Das Werkzeug soll diese Funktionalität in gleicher Weise unterstützen. Zur visuellen Unterstützung soll der Wechsel in Unterprozesse durch eine Animation erfolgen bei der die Ansicht zunächst auf den betreffenden Prozess vergrößert und dieser ausgeblendet wird. Der Unterprozess wird während dessen eingeblendet. Anwendungsfall: Der Benutzer soll aus einem Prozess in einen übergeordneten Prozess navigieren können. Dieser Anwendungsfall hängt mit dem vorausgegangenen Fall zusammen. Analog zur Navigation in Unterprozesse soll die Möglichkeit gegeben werden in Oberprozesse zurück zu wechseln. Dies wird im OMEGA Process Modeller [Uni12] durch den Befehl Aufwärts unterstützt. Das neue Werkzeug unterstützt diesen Anwendungsfall auf gleiche Weise. Der Übergang zwischen Unter- und Oberprozessen wird dabei so gestaltet, dass er durch eine Animation erfolgt um die Orientierung des Benutzers zu verbessern. Der aktuell angesehene Geschäftsprozess wird verkleinert und gleichzeitig der übergeordnete Prozess eingeblendet. Die neue Position und Ausrichtung der virtuellen Kamera ist so ausgerichtet, dass sich der Prozessschritt, aus dem zum übergeordneten Prozess navigiert wurde, im Fokus befindet. Anwendungsfall: Der Benutzer soll unterschiedliche Ebenen des Detaillierungsgrades aktivieren können. Dieser Fall wird durch die beiden vorhergegangenen Fälle abgedeckt. Das Eintauchen in Unterprozesse entspricht der Aktivierung der Ebene eines feineren Detaillierungsgrades, während der Wechsel in Oberprozesse der Aktivierung eines gröberen Detaillierungsgrades entspricht. Anwendungsfall: Der Benutzer soll sich im virtuellen dreidimensionalen Raum frei bewegen und die Kamera beliebig ausrichten können. Dieser Anwendungsfall wird durch die Werkzeuge 3ds Max [DD13] und Blender [Hes10] vollständig und durch die Werkzeuge Visio [Mar13] und OMEGA Process Modeller [Uni12] teilweise unterstützt. Mittels Scrollrad wird der Zoom bedient und über die mittlere Maustaste entweder die Ansicht orthogonal zur Blickrichtung bewegt oder um einen fokussierten Punkt gedreht. Das neue Werkzeug setzt die Unterstützung des Anwendungsfalls folgendermaßen um. Der Zoom wird auf die gleiche Weise umgesetzt. Die Bewegung der virtuellen Kamera parallel zu den Ebenen erfolgt mittels dem Klick der mittleren Maustaste und der Verschiebung der Maus in die gewünschte Richtung. Die Drehung der Kamera wird durch Klicken der mittleren Maustaste, dem Drücken der Alt-Taste und der Bewegung in die gewünschte Richtung realisiert. Die Kamera dreht sich stets um den Fokuspunkt, welcher der Schnittpunkt der Blickrichtung der virtuellen Kamera und der aktiven Ebene ist. Ein Wechsel zwischen verschiedenen Ebenen wird durch das Drücken der linken Umschalt-Taste und der Betätigung des Scrollrades durchgeführt.

92 Seite 86 Kapitel Interaktion Anwendungsfall: Der Benutzer soll Modellelemente mit semantischen Objekten verbinden können. Dieser Anwendungsfall wird durch das Werkzeug OMEGA Process Modeller [Uni12] unterstützt. Dort werden für Modellelemente sogenannte Klassen definiert und den Modellelementen zugewiesen. Die Klassen repräsentieren semantische Objekte in dem Sinne, dass Modellelemente und Klassen klar unterschieden werden. Modellelemente sind reine Repräsentationsobjekte und verweisen lediglich auf die ihnen zugewiesene Klasse. So ist eine Analyse über die semantischen Klassen möglich und syntaktische oder semantische Fehler durch versehentlich falsches Benennen von Modellelementen werden ausgeschlossen. Das neue Werkzeug unterstützt den Anwendungsfall, indem zu jedem Modellelement ein semantisches Objekt definiert und jedem Element ein semantisches Objekt zugewiesen wird. Die Aufforderung zur Zuweisung erfolgt direkt bei der Erstellung neuer Modellelemente und kann nicht abgebrochen werden. Zur einfachen Auswahl aus vielen semantischen Objekten wird ein Autovervollständigungsfeld geboten. Der Benutzer gibt entweder den Namen eines bereits vorhandenen Objekts an und verknüpft das Modellelement somit mit diesem Objekt oder er gibt einen neuen Namen an und veranlasst so die Erzeugung eines neuen semantischen Objekts und eine Verknüpfung mit dem neuen Modellelement. Anwendungsfall: Der Benutzer soll im dreidimensionalen Raum mit den Geschäftsprozessmodellen interagieren können. Dieser Fall wird durch die Werkzeuge 3ds Max [DD13] und Blender [Hes10] unterstützt. Sie bieten beide sowohl eine herkömmliche 2D- als auch eine 3D-Benutzungsschnittstelle. Modelle im dreidimensionalen Raum werden in den Werkzeugen direkt angeklickt und verschoben, rotiert oder skaliert. Das neue Werkzeug leistet dies, indem Modellelemente im dreidimensionalen Raum angeklickt und mit ihnen interagiert werden kann. Zur Erzeugung neuer Elemente kommt eine Lösung zum Einsatz, die in ähnlicher Weise aus den Werkzeugen Visio [Mar13] und OMEGA Process Modeller [Uni12] bekannt ist. Dort werden Elemente aus einer zweidimensionalen Toolbar auf eine zweidimensionale Zeichenfläche gezogen. Das neue Werkzeug bietet ebenfalls eine zweidimensionale Toolbar an. Die von dort gezogenen Elemente werden jedoch in dreidimensionale Objekte umgewandelt, sobald sich die Maus über der aktiven Ebene im dreidimensionalen Raum befindet. Die folgende Abbildung 5-4 zeigt, wie der Übergang von 2D-Toolbar-Elementen zu 3D-Modellelementen aussieht. An Position (1) beginnt der Benutzer ein externes Objekt von der Toolbar zu ziehen. Bei Position (2) befindet sich der Mauszeiger über der aktiven Ebene im Raum. Das Objekt wird dreidimensional dargestellt.

93 Entwicklung des Konzeptes Seite 87 Abbildung 5-4: Einsatz von 2D- und 3D-Benutzungsschnittstellen Anwendungsfall: Das Werkzeug soll Hilfestellung bei der gleichförmigen Anordnung von Modellelementen leisten. Dieser Fall wird von den Werkzeugen Visio [Mar13] und OMEGA Process Modeller [Uni12] bereits ansatzweise durch das sogenannte dynamische Gitter und von dem Werkzeug BlueworksLive durch eine automatische Ausrichtung und Anordnung von Modellelementen unterstützt. Dieses System, welches Modellelemente an bestimmten Stellen einschnappen lässt, wird im neuen Werkzeug weiter ausgebaut. Dazu wird sich die Tatsache über den immer gleichen Aufbau von OMEGA-Diagrammen zunutze gemacht und ein allgemeines Muster der Struktur von Diagrammen erstellt. Um dieses allgemeine Muster zu erhalten, wurden 11 modellierte Geschäftsprozesse mit insgesamt über 500 Modellelementen aus der Praxis untersucht. Die Prozessdiagramme sind von links nach rechts und von oben nach unten durchlaufen worden, wobei zu jedem Modellelement seine relative Position zu seinen Nachbarelementen notiert wurde. Aufgrund des Umfangs der Diagramme werden diese nicht im Anhang abgedruckt, sondern befinden sich anonymisiert als PDF-Dateien beiliegend auf dem Datenträger dieser Arbeit. Die nachfolgende Abbildung 5-5 auf der nächsten Seite zeigt, wie das gewonnene Muster der Struktur von OMEGA-Diagrammen aussieht. Abgebildet ist jeweils eine horizontale und vertikale Wiederholung. Diese können beliebig oft hintereinandergeschaltet werden. Jeder Typ eines Modellelements ist mit einem Buchstaben und einer Farbe versehen. Blau umrandete Kästen (A) sind Organisationseinheiten. Dunkelblaue ausgefüllte Pfeile sind Prozesse (B). Die grünen Kästen (C) stehen für Speicherobjekte, die roten (D) für Informationsobjekte. Violette Kästen repräsentieren externe Objekte und gelbe (F) sind Entscheidungsknoten.

94 Seite 88 Kapitel 5 Abbildung 5-5: Muster der Positionen und Ausrichtungen der Snap-In-Punkte Auf der Basis dieses allgemeinen Musters baut ein Snap-In-System des neuen Werkzeugs auf. Es lässt Modellelemente in die für sie passenden Felder einschnappen. Wird ein neues Modellelement über die aktive Ebene gezogen, zeigt das Snap-In-System die passenden Einfüge-Stellen (Snap-In-Punkte) an und verhindert, dass Modellelemente nicht syntaxgemäß platziert werden. Die Anzeige der Snap-In-Punkte ist dynamisch und hängt von den bereits platzierten Modellelementen ab. Sind beispielsweise bereits zwei Organisationseinheiten vorhanden, wird erst für die Erstellung einer dritten Organisationseinheit der entsprechende Snap-In-Punkt angezeigt. Anwendungsfall: Das Werkzeug soll nur Änderungen zulassen, die die syntaktische Korrektheit des Modells nicht beeinträchtigen und Änderungen eines oft verwendeten Elements im gesamten Modell automatisiert übernehmen. Dieser Anwendungsfall ist in zwei Teilfälle zu zerlegen. Der erste Teil behandelt die syntaktische Korrektheit des Modells, welche bereits durch das Snap-In-System sichergestellt wird. Zur Unterstützung dieses Anwendungsfalls ist es an dieser Stelle nicht nötig, ein weiteres Konzept zu entwerfen. Der zweite Fall wird von dem Werkzeug OMEGA Process Modeller [Uni12] unterstützt. Dort werden semantische Objekte verwaltet und ihre Eigenschaften geändert. Das neue Werkzeug bietet zu diesem Zweck ebenfalls Verwaltungsfunktionalitäten. Per Kontextmenü auf einem Modellelement öffnet der Benutzer ein Fenster zur Bearbeitung der zum Modellelement passenden semantischen Objekte. Ist beispielsweise ein Modellelement ausgewählt, das eine Organisationseinheit repräsentiert, enthält das Fenster eine Benutzungsschnittstelle zur Verwaltung von semantischen Objekten des Typs Organisationseinheit. Das Fenster ist im Master-Details-Entwurfsmuster gehalten bei dem links alle verfügbaren semantischen Objekte aufgelistet und rechts die Details zum jeweiligen selektierten Objekt dargestellt und geändert werden.

95 Entwicklung des Konzeptes Seite 89 Anwendungsfall: Das Werkzeug soll passende Modellelemente automatisch verbinden und Verbindungskanten entsprechend ausrichten. Dieser Fall wird bereits durch das Snap-In-System unterstützt. In Abbildung 5-5 sind das Muster der Positionen und Ausrichtungen der Snap-In-Punkte und deren Verbindungen dargestellt. Platziert der Benutzer ein neues Modellelement auf einem Snap-In-Punkt, so wird es automatisch mit denjenigen benachbarten Snap-In- Punkten verbunden, die ebenfalls Modellelemente enthalten. Anwendungsfall: Der Benutzer soll Modellelemente verschieben können. Dieser Anwendungsfall wird bereits durch die Werkzeuge Visio [Mar13], OMEGA Process Modeller [Uni12], 3ds Max [DD12] und Blender [Hes10] unterstützt und hängt mit den Anwendungsfällen zur automatischen Ausrichtung von Modellelementen und der Interaktion mit Modellelementen im dreidimensionalen Raum zusammen. Das neue Werkzeug erlaubt das Verschieben von Modellelementen im Modellierungsraum und wendet dabei die Regeln des Snap-In- Systems an. Das heißt, dass Modellelemente nur von einem Snap-In-Punk in einen anderen verschoben werden können, so dass die syntaktische Korrektheit des Diagramms stets erhalten bleibt. Anwendungsfall: Der Benutzer soll Modellelemente löschen können. Dieser Fall wird bereits durch die Werkzeuge Visio [Mar13], OMEGA Process Modeller [Uni12], 3ds Max [DD12] und Blender [Hes10] unterstützt. Per Kontextmenü erlaubt das neue Werkzeug das Löschen von Modellelementen. Anwendungsfall: Das Werkzeug soll zu neuen Organisationseinheiten automatisiert Prozesse erstellen. Dieser Anwendungsfall wird von dem Werkzeug OMEGA Process Modeller [Uni12] unterstützt. Dort wird beim Ziehen einer Organisationseinheit auf die Zeichenfläche automatisch ein zugehöriger Prozess erstellt und ausgerichtet. Das neue Werkzeug implementiert diese Funktionalität unter zu Hilfename des Snap-In-Systems. Aus der Toolbar zieht der Benutzer eine Organisationseinheit auf einen passenden Snap-In-Punkt und erwirkt damit eine automatische Erstellung eines zugehörigen Prozesses. Anwendungsfall: Das Werkzeug soll die Arbeitsstände mehrerer gleichzeitiger Benutzer an einem Modell synchron halten. Dieser Anwendungsfall wird bereits von den Werkzeugen Google Docs [Goo14a] und BlueworksLive [Ibm14] unterstützt. Die Webanwendungen übernehmen alle Änderungen am Modell direkt in das System, ohne dass explizit gespeichert werden muss. Alle so automatisch gespeicherten Änderungen werden nach einer kurzen Zeit in die aktuelle Ansicht der jeweiligen gleichzeitigen Benutzer des Modells übernommen. Das neue Werkzeug implementiert diese Funktionalität ebenfalls, jedoch werden Änderungen sofort an alle anderen Benutzer verteilt. Anwendungsfall: Der Benutzer soll Änderungen anderer Mitbenutzer mitverfolgen können. Dieser Fall wird von Process Live [Sof14], Google Docs

96 Seite 90 Kapitel 5 [Goo14a] und BlueworksLive [Imb14] unterstützt. Die Webanwendungen bieten jeweils Ansichten um Änderungen am Modell zurückverfolgen zu können. Diese werden mit Hilfe von Auflistungen dargestellt. Das neue Werkzeug unterstützt den Anwendungsfall ebenfalls und bietet dazu folgende Funktionalitäten. Wie in den bestehenden Werkzeugen ist es möglich, sich eine Liste über Änderungen am aktuellen Modell darstellen zu lassen. Darüber hinaus ist der Benutzer in der Lage, den Stand eines Modells zu einem beliebigen Zeitpunkt darzustellen. Über eine Chatfunktion können sich Benutzer in Echtzeit abstimmen. Während der Bearbeitung eines Modells ist für einen Benutzer außerdem sichtbar wo in den letzten Minuten Mitarbeiter am Modell gearbeitet haben, indem deren Mauspositionen durch farbige Flächen visualisiert werden. Diese sind in der Farbintensität wie folgt variiert. Je kürzer der Zeitpunkt einer Mausposition zurückliegt, desto kräftiger ist die Farbe. Abbildung 5-6: Ansicht der Mausposition eines Mitbearbeiters Abbildung 5-6 zeigt schematisch, wie Mauspositionen anderer Benutzer dargestellt werden. Auf der rechten Seite ist der Mauszeiger des aktuellen Benutzers zu sehen. Auf der linken Seite befindet sich der blaue Mauszeiger von einem der Mitbearbeiter. Es ist zu erkennen, dass sich sein Mauszeiger zunächst bei dem externen Objekt befand und dann in einem Bogen herunter wanderte auf das IT- System. Dies wird durch die blaue Fläche sichtbar, die der Mauszeiger wie einen Schweif hinter sich her zieht. 5.5 Zusammenführung und Ergebnis Nach der Analyse und Konzipierung der einzelnen Umsetzungen für jeden Anwendungsfall wurden die Einzelkonzepte zu einem Gesamtkonzept zusammen-

97 Entwicklung des Konzeptes Seite 91 gesetzt. Tatsächlich beeinflussten sich die Einzelkonzipierungen durch ein iteratives Vorgehen gegenseitig, so dass bereits einige Zusammenhänge existieren, wie sie das anwendungsfallübergreifende Snap-In-System knüpft. Im Folgenden wird das Ergebnis des Konzepts zusammengefasst. Details der einzelnen Konzepte sind bereits in Kapitel 5.4 beschrieben. Das Werkzeug läuft als Webanwendung und speichert alle Daten auf einem Server, so wie es in den Anforderungen in Kapitel 3 beschrieben ist. Es wird über ein Webinterface bedient und bietet die Darstellung und Bearbeitung von OMEGA-Prozessmodellen im dreidimensionalen Raum. Mittels einer virtuellen Kamera ist der Benutzer in der Lage, verschiedene Blickwinkel auf die Modelle zu erhalten. Es wird die Modellierung von parallelen, sequentiellen und verschachtelten Geschäftsprozessen unterstützt. Der Benutzer navigiert in fließenden Animationen zwischen Ober- und Unterprozesse. Bei der Modellierung wird der Benutzer durch ein Snap-In-System unterstützt. Dieses liefert Hilfestellung bei der gleichförmigen Ausrichtung von Modellelementen und stellt die syntaktische Korrektheit von Modellelementen sicher. Zur einfacheren Verwaltung erlaubt das Werkzeug neben der Erstellung von Modellelementen eine zusätzliche Verknüpfung derselben mit semantischen Objekten. Das Werkzeug unterstützt für die Arbeit in Teams die Awareness der Bearbeiter, indem deren Aktionen, Positionen, Sichtbereiche und Mauspositionen direkt an alle anderen Mitarbeiter weitergegeben werden. Eine Chatfunktion unterstützt textuelle Echtzeitkommunikation zwischen Bearbeitern eines Prozesses. Abbildung 5-7: Schematische Ansicht der Benutzungsschnittstelle Abbildung 5-7 zeigt eine schematische Sicht der Benutzungsschnittstelle. Am oberen Rand ist die Toolbar abgebildet, welche zur Erstellung neuer Geschäftsprozessmodelle dient. Auf der rechten Seite ist die Chatbox zur Kommunikation dargestellt. Anhand der Nachrichten ist zu erkennen, dass die beiden Benutzer

98 Seite 92 Kapitel 5 Alfons und Gustav am aktuellen Prozess arbeiten. Den mittleren Bereich bildet der Modellierungsraum, in dem mehrere Ebenen und Modellelemente zu sehen sind. Die Ebenen sind als transparente Gitternetzlinien dargestellt und erleichtern die Orientierung im 3D-Raum. Die Abbildung zeigt hier, wie der aktuelle Benutzer eine neue Organisationseinheit erstellt und das Snap-In-System die dazu passenden Stellen anzeigt. Außerdem werden die Position, der Sichtbereich und der Mauszeiger des Mitarbeiters Gustav angezeigt, welcher momentan das externe Objekt Kunde betrachtet.

99 Prototypische Umsetzung und Bewertung Seite 93 6 Prototypische Umsetzung und Bewertung Diese Kapitel beschreibt, wie das aufgestellte Konzept des Werkzeugs als prototypische Anwendung umgesetzt und die Implementierung getestet wurde. Zunächst werden die Entwicklungsumgebung und das Vorgehen erläutert, dann folgen die Beschreibungen der Implementierung und des Tests und schließlich die abschließende Bewertung. 6.1 Umgebung Der Prototyp wurde als Webanwendung vollständig in der Entwicklungsumgebung Visual Studio 2013 Ultimate [Mic14a] unter Windows 8.1 [Häh13] umgesetzt. Für die Speicherung von Datenbankdaten kam der Microsoft SQL Server 2008 [Mic14b] und das SQL Server Management [Mic14c] und zum Hosting der lokalen Webanwendung der IIS 8 [Mic14d] zum Einsatz. Das Entwicklungssystem bestand unter anderem aus einem 3 GHz Prozessor, 8 GB RAM und einer AMD Radeon HD 6800 Grafikkarte. 6.2 Vorgehen Der Prototyp wurde in mehreren Phasen entwickelt, die in der folgenden Abbildung 6-1 dargestellt werden. Zunächst wurden Technologien gesucht und ausgewählt, mit deren Hilfe das Konzept umgesetzt werden konnte. Das Ergebnis war eine Menge von Software-Paketen, so genannte Bundles und Packages, die in die Entwicklungsumgebung Visual Studio integriert wurden und in Form eines neuen Projekts zur Verfügung standen. Danach erfolge die Konzipierung der Softwarearchitektur und der Datenstrukturen. Anschließend wurde ein kleines Framework erstellt auf dessen Basis der Editor implementiert werden konnte. Das Framework bildet die Basis zur Generierung der Seiten der Webanwendung und leistet eine Abstraktion der Datenbank in Form von so genannten API-Controllern. Der Editor ist eine Seite der Webanwendung und übernimmt die Visualisierung der dreidimensionalen OMEGA-Modelle und die Entgegennahme von Benutzereingaben und interaktionen. Nachdem die Grundstrukturen des Werkzeugs bestanden, wurden die einzelnen Funktionalitäten aus der Konzeptbeschreibung aus Kapitel 5 implementiert. Zuletzt erfolgte ein Funktionstest des Werkzeugs, indem mit mehreren Personen im dreidimensionalen Raum ein beispielhafter Geschäftsprozess modelliert wurde.

100 Seite 94 Kapitel 6 Abbildung 6-1: Vorgehen bei der prototypischen Implementierung des Konzepts 6.3 Implementierung Das folgende Unterkapitel beschreibt im Detail, wie die einzelnen Phasen der Entwicklung durchgeführt wurden Technologieauswahl Die Basis des Prototyps setzt auf der Technologie ASP.NET MVC4 [CSP12] auf, einem Framework für die Sprache C# zur Entwicklung von Webanwendungen in der.net-umgebung und wurde als Vorgabe von der progresso group GbR festgesetzt. Die Benutzungsschnittstelle des Werkzeugs sind also HTML-

101 Prototypische Umsetzung und Bewertung Seite 95 Webseiten. Passend dazu und zu dem entwickelten Konzept wurden weitere Technologien gesucht und ausgewählt, mit deren Hilfe das Werkzeug umgesetzt werden konnte. Dazu bildete ein Anforderungskatalog, in dem die zu leistenden Funktionalitäten aufgelistet wurden, die Grundlage. Dieser Katalog wurde erstellt, indem jeweils jedes Konzept aus Kapitel 5.4 betrachtet und die daraus resultierenden Anforderungen notiert wurden. So wurde zum Beispiel aus dem Konzept zu dem Anforderungsfall Das Werkzeug soll Modelle in einer ganzheitlichen 3D-Visualisierung darstellen ermittelt, dass das Werkzeug mit Hilfe der Sprachen HTML und Javascript in der Lage sein muss, 3D-Grafik im Browserfenster anzuzeigen. Mithilfe des Anforderungskatalogs sind passende Javascript- Bibliotheken und Plug-Ins für ASP.NET-Anwendungen recherchiert worden und wurden nach deren Abdeckung der geforderten Funktionalität und der Aktivität der Weiterentwicklung ausgewählt. Die folgenden Technologien wurden ausgewählt. Bootstrap for MVC: Framework zur vereinfachten Gestaltung von Webseiten Entity Framework: Bibliothek zur Abstraktion der Datenhaltung jquery: Javascript-Bibliothek zur vereinfachten Modifizierung des DOM SignalR: MVC- und jquery-plug-in für Socket-ähnliche Verbindungen zwischen Webseiten-Besuchern THREE.js: Javascript-Bibliothek zur Verwendung von WebGL Architektur Der Aufbau des Prototyps ist teilweise durch den Einsatz von ASP.NET MVC vorgegeben, welcher sich sehr stark am klassischen Model-View-Controller-Pattern orientiert. Diese Architektur wurde verfeinert und ausgebaut, indem die Datenhaltung durch ein eigenes Framework abstrahiert und die Kommunikation mit dem Client um die SignalR-Technologie [CSP12] erweitert wurde. SignalR ist eine Bibliothek für ASP.NET MVC Anwendungen, die es erlaubt verbundenen Clients auf direktem Wege Daten zu schicken. Im Gegensatz zu herkömmlichen Webanwendungen, wo der Datenaustausch nur im Halbduplex erfolgt und nur nach jeder Clientanfrage eine Antwort vom Server gesendet wird, ermöglicht SignalR eine Datenkommunikation im Vollduplex. So benachrichtigt eine SignalR-Chat-Anwendung beispielsweise die verbundenen Clients automatisch über neue Nachrichten, ohne dass diese in zeitlichen Intervallen nachfragen müssen. Folgende Abbildung 6-2 zeigt, wie die Architektur der Webanwendung aussieht. Sie besteht aus vier großen Komponenten. Auf der linken Seite ist die SignalR- Erweiterung zu sehen. Mittig befindet sich die ASP.NET MVC Komponente

102 Seite 96 Kapitel 6 und am unteren Rand das Framework und die Datenbank. Die ASP.NET MVC Komponente ist der zentrale und wichtigste Teil. Sie ist in die drei Teile Model, View und Controller aufgeteilt. Die Controller nehmen Anfragen von Clients entgegen, verarbeiten sie und veranlassen Datenbankoperationen, die Auslieferung von Views oder Nachrichtenübermittlungen über SignalR. Es gibt jeweils zwei Typen von Controllern und Views. Die mit Application bezeichneten Komponenten enthalten die Funktionalität einer Rahmenanwendung, die aus einem Login-System und einer einfachen Prozessverwaltung besteht. Dieser Teil des Prototyps ist zwar nicht zwingend für die Evaluierung des Konzeptes notwendig, erleichtert aber das Aufsetzen der Testumgebung. Die anderen Controller und Views gehören zum Teil der Prozessbearbeitung, dem Editor. Dieser besteht nur aus einer einzigen HTML-Seite und interagiert per Ajax mit den Web-API-Controllern. Das Framework bietet einige Hilfsmethoden zum Laden und Speichern von Daten und bildet die Schnittstelle zur Datenbank. Abbildung 6-2: Architektur der Webanwendung

103 Prototypische Umsetzung und Bewertung Seite 97 Neben dem Aufbau der Webanwendung wurde auch die Architektur des Editors, dem zentralen Element zur Bearbeitung der Geschäftsprozesse, entworfen. Es handelt sich dabei um den Teil der Webanwendung, der als eine einzelne HTML- Seite und einigen Javascript-Objekten umgesetzt ist. Die folgende Abbildung 6-3 zeigt, aus welchen Javascript-Objekten der Editor besteht und wie sie zusammenhängen. Die Hauptkomponente bildet das Modeller-Objekt. Es verwaltet den Renderer, der für die 3D-Darstellung der Geschäftsprozessmodelle zuständig ist, den SceneManager, der zur Verwaltung der Objekte in der Scene genutzt wird, das Mousenavigation-Objekt, welches Mauseingaben entgegennimmt und verarbeitet und den ShapeCreator, der die Erzeugung von 3D-Modellen durchführt. Das Canvas-Objekt ist ein Teil der HTML-Seite und beinhaltet die gerenderte Szene. Die Hubs sind Javascript-Objekte, die für die Vollduplex-Kommunikation mit dem Server vorgesehen sind. Sie werden vom Modeller angesprochen, um Daten an den Server zu senden und greifen selbst auf den Modeller zu, wenn sie Daten vom Server erhalten. Abbildung 6-3: Architektur der Editor-Seite Frameworkentwicklung Zur besseren Ausführbarkeit und Testbarkeit des Prototyps wurde ein kleines Framework entwickelt, welches zum einen Hilfsmethoden zum einfachen Speichern und Laden bereitstellt und zum anderen Basisfunktionalitäten wie ein Login-System und eine rudimentäre Benutzer- und Prozessverwaltung bietet. Das Framework bietet die Möglichkeit, Benutzerkonten und Geschäftsprozesse anzulegen und die Konten den Prozessen zuzuweisen. Diese Möglichkeit der Zuweisung ist eine Voraussetzung für die Ausführbarkeit des Editors, weil dieser Informationen darüber braucht, welche Änderungen an welche Bearbeiter mitgeteilt werden müssen.

104 Seite 98 Kapitel Editorentwicklung Der Editor ist eine einzelne HTML-Seite über die die Geschäftsprozesse angezeigt und bearbeitet werden. Alle Benutzereingaben werden per Javascript abgearbeitet und per Ajax an den Server weitergegeben. Seine Entwicklung erfolgte iterativ. Zu Beginn wurden nur die grundlegenden Objekte ohne oder mit nur wenigen Funktionalitäten implementiert. Dann folgen die Umsetzungen der einzelnen Konzepte und eine kontinuierliche Weiterentwicklung des Modellers. Zunächst wurden die im Architekturentwurf beschrieben Javascript-Objekte erstellt und nach und nach implementiert. Der Renderer wurde so weit umgesetzt, dass dieser THREE.js nutzte, um eine leere Szene zu rendern und auf dem Canvas anzuzeigen. Der SceneManager erhielt Basisfunktionalitäten zur Verwaltung der Szene. Die Mousenavigation wurde dahingehend implementiert, dass sie Mauseingaben entgegennehmen und konnte und bereit war um weitere Funktionen aufzurufen um diese Eingaben zu verarbeiten. Der ShapeCreator wurde erstellt und testhalber eine Funktion implementiert, die einfache Würfel erstellen konnte. Zuletzt wurden die Hub-Objekte angelegt und die einzelnen Komponenten so weiterentwickelt, dass der Editor in der Lage war einige Würfel auf der Szene darzustellen und sie von mehreren Benutzern gleichzeitig verschiebbar zu machen Umsetzungen Nachdem die Rahmenanwendung entwickelt war, wurden die einzelnen Konzepte umgesetzt. Diese wurden dazu nacheinander betrachtet und die zu implementierenden Funktionalitäten ermittelt und umgesetzt. Zunächst wurde der ShapeCreator entwickelt und Funktionen implementiert, die 3D-Modellelemente erzeugen. Danach folgen die Umsetzung der Toolbar und einer einfachen Drag-And-Drop-Funktionalität um Elemente aus der Toolbar in den Raum zu ziehen. Der Dialog zur Auswahl und Erstellung von semantischen Objekten wurde erstellt und so eingebaut, dass er nach der Erstellung von Modellelementen erscheint. Als nächster Schritt wurde das Snap-In-System entwickelt und somit die Drag-And-Drop-Funktionalität weiter ausgebaut. Die Positionierung der Snap-In-Punkte und das automatische Anzeigen von Verbindungspfeilen wurden anschließend umgesetzt. Daraufhin folgte die Entwicklung des Navigationssystems und der Prototyp erhielt Funktionalitäten zur Positionierung und Ausrichtung der virtuellen Kamera. Nachdem der Prototyp in der Lage war die Modellierung von Geschäftsprozessen zu ermöglichen, wurden die Funktionalitäten zur Mehrbenutzerinteraktion implementiert. Die bestehenden Funktionen wurden so erweitert, dass Benutzerinteraktionen automatisch an alle anderen Benutzer verteilt werden und sich deren Ansichten aktualisieren. Die Visualisierung

105 Prototypische Umsetzung und Bewertung Seite 99 der Positionen und Ausrichtungen aller Bearbeiter wurde umgesetzt und schließlich die Chatfunktion eingebaut. 6.4 Test Mithilfe des Prototyps konnte nach seiner Implementierung das aufgestellte Konzept hinsichtlich seiner Realisierbarkeit und Praxistauglichkeit getestet werden. Dazu wurde dieser genutzt um ein Geschäftsprozess mit sequentiellen und parallelen Prozessflüssen und mit zwei Unterprozessen zu modellieren. Die Modellierung wurde von zwei Personen gleichzeitig durchgeführt um zu prüfen ob diese Art der Zusammenarbeit gut von dem Werkzeug unterstützt wird. Der zu modellierende Prozess beschreibt einen realitätsnahen Vorgang einer Angebotserstellung für eine Softwareentwicklung. Ein Kunde tritt mit einer Anfrage an das Unternehmen an und wünscht die Entwicklung einer Individualsoftware. Die Vertriebsabteilung des Unternehmens nimmt die Anfrage an und hinterlegt sie als elektronisches Element im SharePoint-System, während die Verwaltung die Kundendaten in das System einpflegt. Danach erfolgt die Angebotserstellung, indem die Entwicklungsabteilung den Umsetzungsaufwand schätzt und diesen dem Vertrieb mitteilt. Dieser erstellt daraufhin das Angebot in Briefform. Abbildung 6-4: Ausschnitt des modellierten Testprozesses

106 Seite 100 Kapitel 6 Abbildung 6-4 auf der vorherigen Seite zeigt einen Ausschnitt des modellierten Prozesses. Auf der linken Seite ist der Kunde als externes Objekt modelliert. Dieser tritt mit einer Anfrage in Papierform an das Unternehmen heran. Die Anfrage wird von den Abteilungen Verwaltung und Vertrieb parallel verarbeitet, was durch deren Darstellung auf unterschiedlichen Ebenen zu erkennen ist. Im Prozess Anfrage annehmen ist zu sehen, wie die Anfrage in ein IT-Informationsobjekt umgewandelt und sowohl im SharePoint gespeichert, als auch an den nächsten Prozess Angebot erstellen weitergereicht wird. Dort wird schließlich das Angebot in Papierform erzeugt und als Kopie zu den Akten gelegt. Die Prozessschritte der Aufwandsschätzung und der Brieferstellung sind Unterprozesse von Angebot erstellen und in dieser Abbildung nicht dargestellt. Die folgende Abbildung 6-5 zeigt eine Momentaufnahme aus der Modellierung mit den beiden Bearbeitern Michael Hilus und Hessam Omumi. Die abgebildete Ansicht zeigt, wie das Werkzeug von Michael Hilus im Browserfenster bedient wird. Im oberen Bereich befindet sich die Toolbar, rechts unten das Chatfenster und in der Mitter der Modellierungsbereich. Darin sind zwei Organisationseinheiten, ein externes Objekt und ein Papierspeicher platziert. Der Sichtbereich und die Mausposition des anderen Modellierers Hessam Omumi werden durch farbliche Markierungen visualisiert. Abbildung 6-5: Benutzungsschnittstelle des Prototyps

EINFÜHRUNG 06.06.2013 IOZ AG 1

EINFÜHRUNG 06.06.2013 IOZ AG 1 BPMN BPMN2.0 EINFÜHRUNG 06.06.2013 IOZ AG 1 EINFÜHRUNG GESCHÄFTSPROZESSMODELLIERUNG Was ist Geschäftsprozessmodellierung? Darstellung von geschäftlichen Abläufen und deren Interaktion Was wird inhaltlich

Mehr

Integration mit. Wie AristaFlow Sie in Ihrem Unternehmen unterstützen kann, zeigen wir Ihnen am nachfolgenden Beispiel einer Support-Anfrage.

Integration mit. Wie AristaFlow Sie in Ihrem Unternehmen unterstützen kann, zeigen wir Ihnen am nachfolgenden Beispiel einer Support-Anfrage. Integration mit Die Integration der AristaFlow Business Process Management Suite (BPM) mit dem Enterprise Information Management System FILERO (EIMS) bildet die optimale Basis für flexible Optimierung

Mehr

BPMN. Suzana Milovanovic

BPMN. Suzana Milovanovic BPMN Suzana Milovanovic 2 Übersicht Klärung von Begriffen, Abkürzungen Was ist BPMN? Business Process Diagram (BPD) Beispielprozess Entwicklung von BPMN BPMN in der Literatur 3 Grundlegende Begriffe Business

Mehr

Geschäftsprozessanalyse

Geschäftsprozessanalyse Geschäftsprozessanalyse Prozessmodellierung weitere Begriffe: workflow business process modelling business process (re-)engineering 2 Was ist ein Prozess? Prozesse bestehen aus Aktionen / Ereignissen /

Mehr

Geschäftsprozesse modellieren mit BPMN. Nürnberg, 10.11.2009

Geschäftsprozesse modellieren mit BPMN. Nürnberg, 10.11.2009 Geschäftsprozesse modellieren mit BPMN Nürnberg, 10.11.2009 I N H A L T 1. Warum noch ein Notation? 2. Grundlegende BPMN-Elemente 3. Prozess versus Interaktion 4. Services 5. Fazit Warum noch eine Notation?

Mehr

Use Cases. Use Cases

Use Cases. Use Cases Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben

Mehr

EPK Ereignisgesteuerte Prozesskette

EPK Ereignisgesteuerte Prozesskette Ausarbeitung zum Fachseminar Wintersemester 2008/09 EPK Ereignisgesteuerte Prozesskette Referent: Prof. Dr. Linn Ausarbeitung: Zlatko Tadic e-mail: ztadic@hotmail.com Fachhochschule Wiesbaden Fachbereich

Mehr

Aufgaben und Lösungshinweise zum Lehrbuch

Aufgaben und Lösungshinweise zum Lehrbuch Aufgaben und Lösungshinweise zum Lehrbuch UVK Verlagsgesellschaft mbh 204 Aufgaben zu Kapitel 4 Aufgabe : (Grundlagen von IT-Services) Nennen Sie vier Kriterien, die für die Gebrauchstauglichkeit eines

Mehr

UpToNet Workflow Workflow-Designer und WebClient Anwendung

UpToNet Workflow Workflow-Designer und WebClient Anwendung UpToNet Workflow Workflow-Designer und WebClient Anwendung Grafische Erstellung im Workflow-Designer 1 Grafische Erstellung im Workflow-Designer Bilden Sie Ihre Arbeitsvorgänge im Workflow-Designer von

Mehr

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel. EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.de/~mtr FRAGEN / ANMERKUNGEN Vorlesung Neue Übungsaufgaben MODELLIERUNG

Mehr

Fachdidaktik der Informatik 18.12.08 Jörg Depner, Kathrin Gaißer

Fachdidaktik der Informatik 18.12.08 Jörg Depner, Kathrin Gaißer Fachdidaktik der Informatik 18.12.08 Jörg Depner, Kathrin Gaißer Klassendiagramme Ein Klassendiagramm dient in der objektorientierten Softwareentwicklung zur Darstellung von Klassen und den Beziehungen,

Mehr

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Dateiname: ecdl5_01_00_documentation_standard.doc Speicherdatum: 14.02.2005 ECDL 2003 Basic Modul 5 Datenbank - Grundlagen

Mehr

Prozessorganisation Mitschriften aus den Vorlesung bzw. Auszüge aus Prozessorganisation von Prof. Dr. Rudolf Wilhelm Feininger

Prozessorganisation Mitschriften aus den Vorlesung bzw. Auszüge aus Prozessorganisation von Prof. Dr. Rudolf Wilhelm Feininger Darstellungsmittel für Prozesse graphische Darstellung Bild davon machen wie Prozesse gegenwärtig verlaufen Durchführung der Prozesse festlegen zwei Darstellungsmittel: Prozesslandkarten und Flussdiagramme

Mehr

2. Übung zur Vorlesung Service-orientierte Architekturen

2. Übung zur Vorlesung Service-orientierte Architekturen 2. Übung zur orlesung Service-orientierte Architekturen Geschäftsprozessmodellierung mit Ereignisgesteuerten Prozessketten (EPK) Wiederholung Grundlagen Was ist ein Prozess? Was ist ein Geschäftsprozess?

Mehr

Übung 4. Musterlösungen

Übung 4. Musterlösungen Informatik für Ökonomen II HS 2010 Übung 4 Ausgabe: 18.11.2010 Abgabe: 25.11.2010 Musterlösungen Schreiben Sie Ihre Namen und Ihre Matrikelnummern in die vorgesehenen Felder auf dem Deckblatt. Formen Sie

Mehr

Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements. von Stephanie Wilke am 14.08.08

Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements. von Stephanie Wilke am 14.08.08 Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements von Stephanie Wilke am 14.08.08 Überblick Einleitung Was ist ITIL? Gegenüberstellung der Prozesse Neuer

Mehr

Universität Trier. FB IV Wirtschafts- und Sozialwissenschaften. SS 2008 Veranstalterin: Dipl.-Wirt.-Inf. Ariane Gramm

Universität Trier. FB IV Wirtschafts- und Sozialwissenschaften. SS 2008 Veranstalterin: Dipl.-Wirt.-Inf. Ariane Gramm Universität Trier FB IV Wirtschafts- und Sozialwissenschaften SS 2008 Veranstalterin: Dipl.-Wirt.-Inf. Ariane Gramm Übung Wirtschaftsinformatik I Teil 2 Thema: Erläuterung der eepk Eingereicht am 12.06.2008

Mehr

1 topologisches Sortieren

1 topologisches Sortieren Wolfgang Hönig / Andreas Ecke WS 09/0 topologisches Sortieren. Überblick. Solange noch Knoten vorhanden: a) Suche Knoten v, zu dem keine Kante führt (Falls nicht vorhanden keine topologische Sortierung

Mehr

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem Fachbericht zum Thema: Anforderungen an ein Datenbanksystem von André Franken 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis 1 2 Einführung 2 2.1 Gründe für den Einsatz von DB-Systemen 2 2.2 Definition: Datenbank

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

Mehr

Modellierung von Arbeitsprozessen

Modellierung von Arbeitsprozessen Informatik II: Modellierung Prof. Dr. Martin Glinz Kapitel 9 Modellierung von Arbeitsprozessen Universität Zürich Institut für Informatik Inhalt 9.1 Grundlagen 9.2 Ereignisgesteuerte Prozessketten (EPK)

Mehr

SEQUENZDIAGRAMM. Christoph Süsens

SEQUENZDIAGRAMM. Christoph Süsens SEQUENZDIAGRAMM Christoph Süsens DEFINITION Das Sequenzdiagramm gibt Auskunft darüber: Welche Methoden für die Kommunikation zwischen ausgewählten Objekten zuständig sind. Wie der zeitliche Ablauf von

Mehr

Task: Nmap Skripte ausführen

Task: Nmap Skripte ausführen Task: Nmap Skripte ausführen Inhalt Einfache Netzwerkscans mit NSE Ausführen des Scans Anpassung der Parameter Einleitung Copyright 2009-2015 Greenbone Networks GmbH Herkunft und aktuellste Version dieses

Mehr

Fragenkatalog Geschäftsmodellierung Grundlagen

Fragenkatalog Geschäftsmodellierung Grundlagen Fragenkatalog Geschäftsmodellierung Grundlagen 1. Erläutern Sie den Begriff der Geschäftsmodellierung - Erfassung und Spezifikation von Geschäftsprozessen für die Analyse und Gestaltung betrieblicher Systeme

Mehr

1 Mathematische Grundlagen

1 Mathematische Grundlagen Mathematische Grundlagen - 1-1 Mathematische Grundlagen Der Begriff der Menge ist einer der grundlegenden Begriffe in der Mathematik. Mengen dienen dazu, Dinge oder Objekte zu einer Einheit zusammenzufassen.

Mehr

Schnittstelle DIGI-Zeiterfassung

Schnittstelle DIGI-Zeiterfassung P.A.P.A. die kaufmännische Softwarelösung Schnittstelle DIGI-Zeiterfassung Inhalt Einleitung... 2 Eingeben der Daten... 2 Datenabgleich... 3 Zusammenfassung... 5 Es gelten ausschließlich unsere Allgemeinen

Mehr

Unified Modeling Language (UML)

Unified Modeling Language (UML) Kirsten Berkenkötter Was ist ein Modell? Warum Modellieren? Warum UML? Viele, viele Diagramme UML am Beispiel Was ist ein Modell? Ein Modell: ist eine abstrakte Repräsentation eines Systems, bzw. ist eine

Mehr

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche

etutor Benutzerhandbuch XQuery Benutzerhandbuch Georg Nitsche etutor Benutzerhandbuch Benutzerhandbuch XQuery Georg Nitsche Version 1.0 Stand März 2006 Versionsverlauf: Version Autor Datum Änderungen 1.0 gn 06.03.2006 Fertigstellung der ersten Version Inhaltsverzeichnis:

Mehr

Das große ElterngeldPlus 1x1. Alles über das ElterngeldPlus. Wer kann ElterngeldPlus beantragen? ElterngeldPlus verstehen ein paar einleitende Fakten

Das große ElterngeldPlus 1x1. Alles über das ElterngeldPlus. Wer kann ElterngeldPlus beantragen? ElterngeldPlus verstehen ein paar einleitende Fakten Das große x -4 Alles über das Wer kann beantragen? Generell kann jeder beantragen! Eltern (Mütter UND Väter), die schon während ihrer Elternzeit wieder in Teilzeit arbeiten möchten. Eltern, die während

Mehr

Praxishandbuch BPMN 2.0

Praxishandbuch BPMN 2.0 Jakob Freund Bernd Rücker Praxishandbuch BPMN 2.0 2., aktualisierte Auflage HANSER Inhaltsverzeichnis 1 Einführung 1 1.1 Business Process Management 1 1.1.1 Definition 1 1.1.2 BPM in der Praxis 2 1.1.3

Mehr

Suche schlecht beschriftete Bilder mit Eigenen Abfragen

Suche schlecht beschriftete Bilder mit Eigenen Abfragen Suche schlecht beschriftete Bilder mit Eigenen Abfragen Ist die Bilderdatenbank über einen längeren Zeitraum in Benutzung, so steigt die Wahrscheinlichkeit für schlecht beschriftete Bilder 1. Insbesondere

Mehr

Wirtschaftsinformatik

Wirtschaftsinformatik Fakultät für Betriebswirtschaft Munich School of Management Wirtschaftsinformatik Tutorium 1: Ereignisgesteuerte Prozessketten Dipl.-Kfm. Julian Propstmeier Institut für Information, Organisation und Management

Mehr

Prozessdokumentation und -darstellung

Prozessdokumentation und -darstellung Prozessdokumentation und -darstellung Methoden und Ansätze zur praxisorientierten Dokumentation Unsere Leistungen Interims- und Projektmanagement Test- und Dokumentationsmanagement Prozess- und Organisations-Consulting

Mehr

Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität

Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität Warum sich das Management nicht für agile Softwareentwicklung interessieren sollte - aber für Agilität Marcus Winteroll oose GmbH Agenda I. Ziele und Zusammenarbeit II. Was wir vom agilen Vorgehen lernen

Mehr

Business Process Model and Notation

Business Process Model and Notation BPMN 2.0 Crashkurs Business Process Model and Notation entwickelt von der Object Management Group, einem Konsortium von vielen Firmen (u.a. HP, IBM, Microsoft, Oracle, SAP) >60 verschiedene Produkte implementieren

Mehr

Grundlagen für den erfolgreichen Einstieg in das Business Process Management SHD Professional Service

Grundlagen für den erfolgreichen Einstieg in das Business Process Management SHD Professional Service Grundlagen für den erfolgreichen Einstieg in das Business Process Management SHD Professional Service Der BPM-Regelkreis Im Mittelpunkt dieser Übersicht steht die konkrete Vorgehensweise bei der Einführung

Mehr

Robot Karol für Delphi

Robot Karol für Delphi Robot Karol für Delphi Reinhard Nitzsche, OSZ Handel I Version 0.1 vom 24. Januar 2003 Zusammenfassung Nach der Einführung in die (variablenfreie) Programmierung mit Robot Karol von Freiberger und Krško

Mehr

Arbeiten mit UMLed und Delphi

Arbeiten mit UMLed und Delphi Arbeiten mit UMLed und Delphi Diese Anleitung soll zeigen, wie man Klassen mit dem UML ( Unified Modeling Language ) Editor UMLed erstellt, in Delphi exportiert und dort so einbindet, dass diese (bis auf

Mehr

Geschäftsprozesse - EPK

Geschäftsprozesse - EPK Geschäftsprozesse - EPK Prof. Dr. W. Riggert Darstellung von Geschäftsprozessen EPK Grundelemente Die grundlegenden Elemente einer eepk sind Funktionen, Ereignisse und Verknüpfungsoperatoren (Konnektoren).

Mehr

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML)

09.01.14. Vorlesung Programmieren. Unified Modeling Language (UML) Unified Modeling Language (UML) Unified Modeling Language (UML) Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)

Mehr

Vorlesung Programmieren

Vorlesung Programmieren Vorlesung Programmieren Unified Modeling Language (UML) Prof. Dr. Stefan Fischer Institut für Telematik, Universität zu Lübeck http://www.itm.uni-luebeck.de/people/fischer Unified Modeling Language (UML)

Mehr

Fragebogen zur Anforderungsanalyse

Fragebogen zur Anforderungsanalyse Fragebogen zur Anforderungsanalyse Geschäftsprozess Datum Mitarbeiter www.seikumu.de Fragebogen zur Anforderungsanalyse Seite 6 Hinweise zur Durchführung der Anforderungsanalyse Bevor Sie beginnen, hier

Mehr

Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.

Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch. Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.pdf 2 Nach derbefragung aller Stakeholder und der Dokumentation

Mehr

4. Jeder Knoten hat höchstens zwei Kinder, ein linkes und ein rechtes.

4. Jeder Knoten hat höchstens zwei Kinder, ein linkes und ein rechtes. Binäre Bäume Definition: Ein binärer Baum T besteht aus einer Menge von Knoten, die durch eine Vater-Kind-Beziehung wie folgt strukturiert ist: 1. Es gibt genau einen hervorgehobenen Knoten r T, die Wurzel

Mehr

Inhaltsverzeichnis. Jakob Freund, Bernd Rücker. Praxisbuch BPMN 2.0 ISBN: 978-3-446-42455-5. Weitere Informationen oder Bestellungen unter

Inhaltsverzeichnis. Jakob Freund, Bernd Rücker. Praxisbuch BPMN 2.0 ISBN: 978-3-446-42455-5. Weitere Informationen oder Bestellungen unter Jakob Freund, Bernd Rücker Praxisbuch BPMN 2.0 ISBN: 978-3-446-42455-5 Weitere Informationen oder Bestellungen unter http://www.hanser.de/978-3-446-42455-5 sowie im Buchhandel. Carl Hanser Verlag, München

Mehr

Projektmanagement in der Spieleentwicklung

Projektmanagement in der Spieleentwicklung Projektmanagement in der Spieleentwicklung Inhalt 1. Warum brauche ich ein Projekt-Management? 2. Die Charaktere des Projektmanagement - Mastermind - Producer - Projektleiter 3. Schnittstellen definieren

Mehr

Vgl. Oestereich Kap 2.7 Seiten 134-147

Vgl. Oestereich Kap 2.7 Seiten 134-147 Vgl. Oestereich Kap 2.7 Seiten 134-147 1 Sequenzdiagramme beschreiben die Kommunikation/Interaktion zwischen den Objekten (bzw. verschiedenen Rollen) eines Szenarios. Es wird beschrieben, welche Objekte

Mehr

Die Dateiablage Der Weg zur Dateiablage

Die Dateiablage Der Weg zur Dateiablage Die Dateiablage In Ihrem Privatbereich haben Sie die Möglichkeit, Dateien verschiedener Formate abzulegen, zu sortieren, zu archivieren und in andere Dateiablagen der Plattform zu kopieren. In den Gruppen

Mehr

Software-Engineering SS03. Zustandsautomat

Software-Engineering SS03. Zustandsautomat Zustandsautomat Definition: Ein endlicher Automat oder Zustandsautomat besteht aus einer endlichen Zahl von internen Konfigurationen - Zustände genannt. Der Zustand eines Systems beinhaltet implizit die

Mehr

Die Formatierungsregeln (die so genannte Wiki-Syntax) für Texte in DokuWiki sind zu großen Teilen die selben, wie in anderen Wiki-Systemen.

Die Formatierungsregeln (die so genannte Wiki-Syntax) für Texte in DokuWiki sind zu großen Teilen die selben, wie in anderen Wiki-Systemen. DokuWiki Kurzanleitung DokuWiki ein sehr einfach zu installierendes und anzuwendendes Wiki und bietet einige Funktionen, welche das Erstellen von Hypertexten, Dokumentationen und Präsentation von Projekten

Mehr

Lineargleichungssysteme: Additions-/ Subtraktionsverfahren

Lineargleichungssysteme: Additions-/ Subtraktionsverfahren Lineargleichungssysteme: Additions-/ Subtraktionsverfahren W. Kippels 22. Februar 2014 Inhaltsverzeichnis 1 Einleitung 2 2 Lineargleichungssysteme zweiten Grades 2 3 Lineargleichungssysteme höheren als

Mehr

Datenübernahme von HKO 5.9 zur. Advolux Kanzleisoftware

Datenübernahme von HKO 5.9 zur. Advolux Kanzleisoftware Datenübernahme von HKO 5.9 zur Advolux Kanzleisoftware Die Datenübernahme (DÜ) von HKO 5.9 zu Advolux Kanzleisoftware ist aufgrund der von Update zu Update veränderten Datenbank (DB)-Strukturen in HKO

Mehr

Ishikawa-Diagramm. 1 Fallbeispiel 2. 2 Was ist ein Ishikawa-Diagramm 2. 3 Vorgehen bei der Erstellung eines Ishikawa-Diagramms 2.

Ishikawa-Diagramm. 1 Fallbeispiel 2. 2 Was ist ein Ishikawa-Diagramm 2. 3 Vorgehen bei der Erstellung eines Ishikawa-Diagramms 2. Ishikawa-Diagramm 1 Fallbeispiel 2 2 Was ist ein Ishikawa-Diagramm 2 3 Vorgehen bei der Erstellung eines Ishikawa-Diagramms 2 4 Vorteile 5 5 Nachteile 5 6 Fazit 5 7 Literaturverzeichnis 6 1 Fallbeispiel

Mehr

Data Mining: Einige Grundlagen aus der Stochastik

Data Mining: Einige Grundlagen aus der Stochastik Data Mining: Einige Grundlagen aus der Stochastik Hagen Knaf Studiengang Angewandte Mathematik Hochschule RheinMain 21. Oktober 2015 Vorwort Das vorliegende Skript enthält eine Zusammenfassung verschiedener

Mehr

Der vorliegende Konverter unterstützt Sie bei der Konvertierung der Datensätze zu IBAN und BIC.

Der vorliegende Konverter unterstützt Sie bei der Konvertierung der Datensätze zu IBAN und BIC. Anleitung Konverter Letzte Aktualisierung dieses Dokumentes: 14.11.2013 Der vorliegende Konverter unterstützt Sie bei der Konvertierung der Datensätze zu IBAN und BIC. Wichtiger Hinweis: Der Konverter

Mehr

Barrierefreie Webseiten erstellen mit TYPO3

Barrierefreie Webseiten erstellen mit TYPO3 Barrierefreie Webseiten erstellen mit TYPO3 Alternativtexte Für jedes Nicht-Text-Element ist ein äquivalenter Text bereitzustellen. Dies gilt insbesondere für Bilder. In der Liste der HTML 4-Attribute

Mehr

Geschäftsprozessunterstützung mit Microsoft SharePoint Foundation 2010 Microsoft InfoPath 2010 und Microsoft BizTalk Server 2013

Geschäftsprozessunterstützung mit Microsoft SharePoint Foundation 2010 Microsoft InfoPath 2010 und Microsoft BizTalk Server 2013 mit Microsoft SharePoint Foundation 2010 Microsoft InfoPath 2010 und Microsoft BizTalk Server 2013 Exemplarische Darstellung Bearbeitung einer März 2013 - Motivation Stetiger Wandel innerhalb einer Organisation

Mehr

Best Practice. Prozessmodellierung für behördenübergreifende. pm-bpmn 1.0.0. Bundesverwaltung: Ergebnis der AG BEST PRACTICE BPMN.

Best Practice. Prozessmodellierung für behördenübergreifende. pm-bpmn 1.0.0. Bundesverwaltung: Ergebnis der AG BEST PRACTICE BPMN. Prozessmodellierung für behördenübergreifende Verfahren der mittelbaren Bundesverwaltung: BEST PRACTICE BPMN Best Practice pm-bpmn 1.0.0 Ergebnis der AG Kurzbeschreibung In diesem Dokument werden die Best-Practice-

Mehr

Proseminar: Website-Managment-System. NetObjects Fusion. von Christoph Feller

Proseminar: Website-Managment-System. NetObjects Fusion. von Christoph Feller Proseminar: Website-Managment-System NetObjects Fusion von Christoph Feller Netobjects Fusion - Übersicht Übersicht Einleitung Die Komponenten Übersicht über die Komponenten Beschreibung der einzelnen

Mehr

Online Schulung Anmerkungen zur Durchführung

Online Schulung Anmerkungen zur Durchführung Online Schulung Anmerkungen zur Durchführung 1.0 Einleitung Vielen Dank, dass Sie sich für die Online Schulung von SoloProtect entschieden haben. Nachfolgend finden Sie Informationen für Identicomnutzer

Mehr

Hilfedatei der Oden$-Börse Stand Juni 2014

Hilfedatei der Oden$-Börse Stand Juni 2014 Hilfedatei der Oden$-Börse Stand Juni 2014 Inhalt 1. Einleitung... 2 2. Die Anmeldung... 2 2.1 Die Erstregistrierung... 3 2.2 Die Mitgliedsnummer anfordern... 4 3. Die Funktionen für Nutzer... 5 3.1 Arbeiten

Mehr

Anleitung IQXPERT-Demo-Version Ideenmanagement

Anleitung IQXPERT-Demo-Version Ideenmanagement Anleitung IQXPERT-Demo-Version Ideenmanagement Im Folgenden wird Ihnen eine kurze Einführung für das IQXpert-Demo-System gegeben. Zugang zum System finden Sie unter http://vplanweb.de/iqx_demo/login.php

Mehr

Anleitung zum Login. über die Mediteam- Homepage und zur Pflege von Praxisnachrichten

Anleitung zum Login. über die Mediteam- Homepage und zur Pflege von Praxisnachrichten Anleitung zum Login über die Mediteam- Homepage und zur Pflege von Praxisnachrichten Stand: 18.Dezember 2013 1. Was ist der Mediteam-Login? Alle Mediteam-Mitglieder können kostenfrei einen Login beantragen.

Mehr

Wintersemester Maschinenbau und Kunststofftechnik. Informatik. Tobias Wolf http://informatik.swoke.de. Seite 1 von 22

Wintersemester Maschinenbau und Kunststofftechnik. Informatik. Tobias Wolf http://informatik.swoke.de. Seite 1 von 22 Kapitel 19 Vererbung, UML Seite 1 von 22 Vererbung - Neben der Datenabstraktion und der Datenkapselung ist die Vererbung ein weiteres Merkmal der OOP. - Durch Vererbung werden die Methoden und die Eigenschaften

Mehr

Anleitung für den Euroweb-Newsletter

Anleitung für den Euroweb-Newsletter 1. Die Anmeldung Begeben Sie sich auf der Euroweb Homepage (www.euroweb.de) in den Support-Bereich und wählen dort den Punkt Newsletter aus. Im Folgenden öffnet sich in dem Browserfenster die Seite, auf

Mehr

Visio 2013. Grundlagen. Linda York. 1. Ausgabe, Oktober 2013

Visio 2013. Grundlagen. Linda York. 1. Ausgabe, Oktober 2013 Visio 2013 Linda York 1. Ausgabe, Oktober 2013 Grundlagen V2013 2 Visio 2013 - Grundlagen 2 Einfache Zeichnungen erstellen In diesem Kapitel erfahren Sie wie Sie Shapes einfügen, kopieren und löschen was

Mehr

Benutzerverwaltung Business- & Company-Paket

Benutzerverwaltung Business- & Company-Paket Benutzerverwaltung Business- & Company-Paket Gemeinsames Arbeiten mit der easyfeedback Umfragesoftware. Inhaltsübersicht Freischaltung des Business- oder Company-Paketes... 3 Benutzerverwaltung Business-Paket...

Mehr

Einführung in. Logische Schaltungen

Einführung in. Logische Schaltungen Einführung in Logische Schaltungen 1/7 Inhaltsverzeichnis 1. Einführung 1. Was sind logische Schaltungen 2. Grundlegende Elemente 3. Weitere Elemente 4. Beispiel einer logischen Schaltung 2. Notation von

Mehr

Binäre Bäume. 1. Allgemeines. 2. Funktionsweise. 2.1 Eintragen

Binäre Bäume. 1. Allgemeines. 2. Funktionsweise. 2.1 Eintragen Binäre Bäume 1. Allgemeines Binäre Bäume werden grundsätzlich verwendet, um Zahlen der Größe nach, oder Wörter dem Alphabet nach zu sortieren. Dem einfacheren Verständnis zu Liebe werde ich mich hier besonders

Mehr

Hilfe zur Urlaubsplanung und Zeiterfassung

Hilfe zur Urlaubsplanung und Zeiterfassung Hilfe zur Urlaubsplanung und Zeiterfassung Urlaubs- und Arbeitsplanung: Mit der Urlaubs- und Arbeitsplanung kann jeder Mitarbeiter in Coffee seine Zeiten eintragen. Die Eintragung kann mit dem Status anfragen,

Mehr

carekundenforum 2012 In Prozessen denken, mit IT Systemen lenken

carekundenforum 2012 In Prozessen denken, mit IT Systemen lenken carekundenforum 2012 In Prozessen denken, mit IT Systemen lenken Seite 1 13./14.11.2012 carekundenforum 2012 Prozessmanagement ist relevant und Teil unseres Alltags. Seite 2 13./14.11.2012 carekundenforum

Mehr

BPMN verdrängt die EPK? Warum BPMN alleine nicht reicht

BPMN verdrängt die EPK? Warum BPMN alleine nicht reicht BPMN verdrängt die EPK? Warum BPMN alleine nicht reicht Einführung in BPMN - Defini>on & Historie Mit BPMN 2.0 haben mehrere Erweiterungen stahgefunden. Erweiterungen der BPMN 2.0: Formale Beschreibung

Mehr

Erstellung von Prozessbeschreibungen. PB 4.2-1: Erstellung von Prozessbeschreibungen

Erstellung von Prozessbeschreibungen. PB 4.2-1: Erstellung von Prozessbeschreibungen Seite 1 von 9 PB 4.2-1: Erstellung von Prozessbeschreibungen 1 Ziel und Zweck Durch Prozessbeschreibungen werden die einzelnen Prozesse des Qualitätshandbuchs detaillierter beschrieben. Sie werden für

Mehr

Das Modellieren von Geschäftsprozessen (ereignisgesteuerte Prozessketten) Fortbildung Nr. 67/309 15.11.2004. Manuel Friedrich

Das Modellieren von Geschäftsprozessen (ereignisgesteuerte Prozessketten) Fortbildung Nr. 67/309 15.11.2004. Manuel Friedrich Fortbildung Nr. 67/309 15.11.2004 Manuel Friedrich Das Modellieren von Geschäftsprozessen (ereignisgesteuerte Prozessketten) 2004 Manuel Friedrich email: info@manuel-friedrich.de - Seite 1 von 6 1. Geschäftsprozesse

Mehr

R&I-Fließbilder in PLANEDS

R&I-Fließbilder in PLANEDS in PLANEDS Planetenfeldstr. 97 D - 44379 Dortmund Fon: +49 (0) 231 555 783 0 Fax: +49 (0) 231 555 783 111 Mail: info@planets-software.de Web: www.planets-software.de Inhalt: 1 Motivation...3 2 Symbolbearbeitung...4

Mehr

Datensicherung. Beschreibung der Datensicherung

Datensicherung. Beschreibung der Datensicherung Datensicherung Mit dem Datensicherungsprogramm können Sie Ihre persönlichen Daten problemlos Sichern. Es ist möglich eine komplette Datensicherung durchzuführen, aber auch nur die neuen und geänderten

Mehr

PowerPoint 2010 Mit Folienmastern arbeiten

PowerPoint 2010 Mit Folienmastern arbeiten PP.002, Version 1.1 07.04.2015 Kurzanleitung PowerPoint 2010 Mit Folienmastern arbeiten Der Folienmaster ist die Vorlage für sämtliche Folien einer Präsentation. Er bestimmt das Design, die Farben, die

Mehr

syntax.tex Eine Übersicht

syntax.tex Eine Übersicht syntax.tex Eine Übersicht Bernd Worsch 7. Juli 1997 Inhaltsverzeichnis 1 Einleitung 1 2 Bevor es funktioniert... 1 3 Grundelemente von syntax.tex 1 4 Strukturelemente von syntax.tex 3 5 Setzen von Syntaxdiagrammen

Mehr

Konzepte der Informatik

Konzepte der Informatik Konzepte der Informatik Vorkurs Informatik zum WS 2011/2012 26.09. - 30.09.2011 17.10. - 21.10.2011 Dr. Werner Struckmann / Christoph Peltz Stark angelehnt an Kapitel 1 aus "Abenteuer Informatik" von Jens

Mehr

Handbuch Schulungsdatenbank

Handbuch Schulungsdatenbank Handbuch Schulungsdatenbank Inhaltsverzeichnis Hinweise... 3 Überblick... 4 Themen... 5 Schulungsprogramm Verwalten... 6 Details... 7 Schulungsprogramm bearbeiten... 9 Anstehende Termine... 10 Schulungen

Mehr

Abamsoft Finos im Zusammenspiel mit shop to date von DATA BECKER

Abamsoft Finos im Zusammenspiel mit shop to date von DATA BECKER Abamsoft Finos im Zusammenspiel mit shop to date von DATA BECKER Abamsoft Finos in Verbindung mit der Webshopanbindung wurde speziell auf die Shop-Software shop to date von DATA BECKER abgestimmt. Mit

Mehr

Tipp III: Leiten Sie eine immer direkt anwendbare Formel her zur Berechnung der sogenannten "bedingten Wahrscheinlichkeit".

Tipp III: Leiten Sie eine immer direkt anwendbare Formel her zur Berechnung der sogenannten bedingten Wahrscheinlichkeit. Mathematik- Unterrichts- Einheiten- Datei e. V. Klasse 9 12 04/2015 Diabetes-Test Infos: www.mued.de Blutspenden werden auf Diabetes untersucht, das mit 8 % in der Bevölkerung verbreitet ist. Dabei werden

Mehr

Projektmanagement. Einleitung. Beginn. Was ist Projektmanagement? In dieser Dokumentation erfahren Sie Folgendes:

Projektmanagement. Einleitung. Beginn. Was ist Projektmanagement? In dieser Dokumentation erfahren Sie Folgendes: Projektmanagement Link http://promana.edulearning.at/projektleitung.html Einleitung Was ist Projektmanagement? In dieser Dokumentation erfahren Sie Folgendes: Definition des Begriffs Projekt" Kriterien

Mehr

1. Software installieren 2. Software starten. Hilfe zum Arbeiten mit der DÖHNERT FOTOBUCH Software

1. Software installieren 2. Software starten. Hilfe zum Arbeiten mit der DÖHNERT FOTOBUCH Software 1. Software installieren 2. Software starten Hilfe zum Arbeiten mit der DÖHNERT FOTOBUCH Software 3. Auswahl 1. Neues Fotobuch erstellen oder 2. ein erstelltes, gespeichertes Fotobuch laden und bearbeiten.

Mehr

Übungen Workflow Management. Blatt 2

Übungen Workflow Management. Blatt 2 Übungen Workflow Management Blatt 2 Aufgabe 1: Erstellen Sie ein Petrinetz inklusive Anfangsmarkierung für den im Folgenden beschriebenen Prozess zur Bearbeitung einer Münzbestellung. Zuerst geht eine

Mehr

Grundlagen der Theoretischen Informatik, SoSe 2008

Grundlagen der Theoretischen Informatik, SoSe 2008 1. Aufgabenblatt zur Vorlesung Grundlagen der Theoretischen Informatik, SoSe 2008 (Dr. Frank Hoffmann) Lösung von Manuel Jain und Benjamin Bortfeldt Aufgabe 2 Zustandsdiagramme (6 Punkte, wird korrigiert)

Mehr

4. BEZIEHUNGEN ZWISCHEN TABELLEN

4. BEZIEHUNGEN ZWISCHEN TABELLEN 4. BEZIEHUNGEN ZWISCHEN TABELLEN Zwischen Tabellen können in MS Access Beziehungen bestehen. Durch das Verwenden von Tabellen, die zueinander in Beziehung stehen, können Sie Folgendes erreichen: Die Größe

Mehr

Herstellen von Symbolen mit Corel Draw ab Version 9

Herstellen von Symbolen mit Corel Draw ab Version 9 Herstellen von Symbolen mit Corel Draw ab Version 9 Einleitung : Icon Design-Überblick: 1) Gestalten in Corel Draw 10.0 3) Vorlage für Photopaint für Import von Corel 4) Einfügen in die PSD-Datei und Bearbeiten

Mehr

Kapitel 4 Die Datenbank Kuchenbestellung Seite 1

Kapitel 4 Die Datenbank Kuchenbestellung Seite 1 Kapitel 4 Die Datenbank Kuchenbestellung Seite 1 4 Die Datenbank Kuchenbestellung In diesem Kapitel werde ich die Theorie aus Kapitel 2 Die Datenbank Buchausleihe an Hand einer weiteren Datenbank Kuchenbestellung

Mehr

Auswahl alter Klausuraufgaben aus einer ähnlichen Vorlesung Maßgeblich für die Prüfung sind die Vorlesungsinhalte!

Auswahl alter Klausuraufgaben aus einer ähnlichen Vorlesung Maßgeblich für die Prüfung sind die Vorlesungsinhalte! Auswahl alter Klausuraufgaben aus einer ähnlichen Vorlesung Maßgeblich für die Prüfung sind die Vorlesungsinhalte! Aufgabe 1: Grundlagen (5 Punkte) a) Definieren Sie kurz Usability und User Experience.

Mehr

Ordner Berechtigung vergeben Zugriffsrechte unter Windows einrichten

Ordner Berechtigung vergeben Zugriffsrechte unter Windows einrichten Ordner Berechtigung vergeben Zugriffsrechte unter Windows einrichten Was sind Berechtigungen? Unter Berechtigungen werden ganz allgemein die Zugriffsrechte auf Dateien und Verzeichnisse (Ordner) verstanden.

Mehr

Systemen im Wandel. Autor: Dr. Gerd Frenzen Coromell GmbH Seite 1 von 5

Systemen im Wandel. Autor: Dr. Gerd Frenzen Coromell GmbH Seite 1 von 5 Das Management von Informations- Systemen im Wandel Die Informations-Technologie (IT) war lange Zeit ausschließlich ein Hilfsmittel, um Arbeitsabläufe zu vereinfachen und Personal einzusparen. Sie hat

Mehr

Zahlen auf einen Blick

Zahlen auf einen Blick Zahlen auf einen Blick Nicht ohne Grund heißt es: Ein Bild sagt mehr als 1000 Worte. Die meisten Menschen nehmen Informationen schneller auf und behalten diese eher, wenn sie als Schaubild dargeboten werden.

Mehr

Einführung und Motivation

Einführung und Motivation Einführung und Motivation iks-thementag: Requirements Engineering 16.11.2010 Autor Carsten Schädel Motto Definiere oder Du wirst definiert. Seite 3 / 51 These Im Privatleben definiert jeder (seine) Anforderungen.

Mehr

SICHERN DER FAVORITEN

SICHERN DER FAVORITEN Seite 1 von 7 SICHERN DER FAVORITEN Eine Anleitung zum Sichern der eigenen Favoriten zur Verfügung gestellt durch: ZID Dezentrale Systeme März 2010 Seite 2 von 7 Für die Datensicherheit ist bekanntlich

Mehr

Prozessmodellierung mit Objektorientierten Ereignisgesteuerten. und der bflow* Toolbox

Prozessmodellierung mit Objektorientierten Ereignisgesteuerten. und der bflow* Toolbox Prozessmodellierung mit Objektorientierten Ereignisgesteuerten Prozessketten (oepk) und der bflow* Toolbox Prof. Dr. Frank Hogrebe Wiesbaden im Juli 2013 1 Agenda Einleitung oepk-grundansatz oepk-symbolik

Mehr

Handbuch zum Excel Formular Editor

Handbuch zum Excel Formular Editor Handbuch zum Excel Formular Editor Mit diesem Programm können Sie die Zellen von ihrer Excel Datei automatisch befüllen lassen. Die Daten können aus der Coffee Datenbank, oder einer weiteren Excel Datendatei

Mehr

Softwaretechnologie -Wintersemester 2013/2014 - Dr. Günter Kniesel

Softwaretechnologie -Wintersemester 2013/2014 - Dr. Günter Kniesel Übungen zur Vorlesung Softwaretechnologie -Wintersemester 2013/2014 - Dr. Günter Kniesel Übungsblatt 3 - Lösungshilfe Aufgabe 1. Klassendiagramme (9 Punkte) Sie haben den Auftrag, eine Online-Videothek

Mehr

Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.

Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch. Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.pdf Nachdem die Projekt-Vision und die Stakeholder bekannt sind,

Mehr