UNIVERSITÄT DUISBURG-ESSEN FAKULTÄT FÜR INGENIEURWISSENSCHAFTEN

Transkript

1 UNIVERSITÄT DUISBURG-ESSEN FAKULTÄT FÜR INGENIEURWISSENSCHAFTEN ABTEILUNG INFORMATIK UND ANGEWANDTE KOGNITIONSWISSENSCHAFT Masterarbeit Entwicklung einer Web-Applikation zur Netzwerkanalysebasierten Entscheidungsunterstützung Per Philippe Verheyen Matrikelnummer: Abteilung Informatik und angewandte Kognitionswissenschaft Fakultät für Ingenieurwissenschaften Universität Duisburg-Essen 25. April 2013 Themensteller: Prof. Dr. H. U. Hoppe

2

3 Inhaltsverzeichnis 1. Einleitung Motivation Aufgabenstellung Aufbau der Arbeit Grundlagen Entscheidungsfindung Decision Making und Decision Maker Der Prozess der Entscheidungsfindung Berichtswesen Die Begriffe Bericht und Berichtswesen Berichtsarten Berichtsgestaltung Planungs- und Kontrollsysteme & Management Support Systeme Planungs- und Kontrollsysteme Der Begriff der Management Support Systeme Management Information Systeme Decision Support Systeme Executive Information Systeme Executive Support Systeme Business Intelligence Der Begriff der Business Intelligence BI-Architekturschichten Nutzergruppen von BI-Anwendungen Anwendungen zur Entscheidungsunterstützung Anwendungsformen: Reporting, Dashboards und Portale Business Intelligence Produkte: Pentaho Weiterer Kontext der Arbeit Social Network Analysis SISOB Project Analytics Workbench Eingesetzte Technologien SQLSpaces Node.js Websockets und Socket.IO Ansatz Szenario Problemstellung Beteiligte Akteure und deren Rollen Datenaufbereitung, Analyse, Entscheidungsfindung iii

4 Inhaltsverzeichnis Einsatz der Analytics Workbench Bewertung der sich ergebenen Möglichkeiten zur Entscheidungsunterstützung Anforderungen an die Web-Applikation Orientierung Anforderungen bezüglich der Rechteverwaltung Anforderungen bezüglich der Nutzertypen Anforderungen bezüglich der Templates Konzeption des Berichts bzw. Dashboards Bericht und Dashboard im Kontext der Web-Applikation Inhalte und Aufbau eines Berichts Mockup eines Berichts Prozess der Entscheidungsunterstützung Konzept des User Interface Grundgerüst Administration-View Workbench-View AnalysisExplorer-View ReportComposer-View ReportViewer-View ReportViewer-View mobile Systementwurf Orientierung Clientkomponente Serverkomponente User / Rollen / Gruppen Genutzte Datenstrukturen der Analytics Workbench Workflows / Runs / Results Templates Reports und Reportelemente Berechtigungen auf Gruppenebene Statusinformationen zu Systemnutzern Konzept für die Gesamtarchitektur Implementierung Übersicht der realisierten Architektur Clientkomponente Serverkomponente Grundlegende Kommunikationsabläufe Initiale Authentifikation des Nutzers Autorisierung von HTTP- und Socket.IO-basierten Anfragen Realisierung der einzelnen Views Grundaufbau und Administration-View Workbench-View AnalysisExplorer-View ReportComposer-View ReportViewer-View iv

5 Inhaltsverzeichnis 6. Anwendungsbeispiel Rahmenbediungungen Durchführung des Anwendungsbeispiels Zusammenfassung und Ausblick Zusammenfassung Ausblick A. Eidesstattliche Erklärung 93 B. Verwendete Netzwerkdaten und Templates 95 B.1. Netzwerk B.2. Template I B.3. Template II C. Beigefügter Datenträger 103 Literaturverzeichnis 105 v

6

7 Abbildungsverzeichnis 2.1. Phasen der Entscheidungsfindung (angelehnt an [TSD11, S. 46]) Merkmale zur Einordnung von Berichten (angelehnt an [GGD08, S. 208]) SISOB Workbench Prototype SISOB Workbench - Ergebnis als Downloadlink SISOB Workbench - Ergebnis als Graphvisualisierung SISOB Workbench - Systemarchitektur Szenario-Workflow Mockup eines Reports Prozess der Entscheidungsunterstützung mit Hilfe der Web-Applikation Mockup des grundlegenden User Interfaces Mockup der Administration-View Mockup der Workbench-View Mockup der AnalysisExplorer-View Mockup der ReportComposer-View Mockup der ReportViewer-View Mockup der mobilen ReportViewer-View Erstes Konzept für eine Gesamtarchitektur des NetAnaReporters Konzept der Gesamtarchitektur Übersicht der verwendeten Module Initiale Nutzerauthentifikation Autorisierung von Anfragen Realisierte Administration-View Realisierte Workbench-View Realisierte AnalysisExplorer-View Realisierte ReportComposer-View Realisierte ReportViewer-View Realisierte ReportViewer-View (mobile Version) Initiales Anlegen und Benennen eines Reports Kontaktaufnahme mit dem Reporter Ausführen des Templates Visualisierung des zu dem Report hinzugefügten Netzwerkes Bearbeitung der Berichtsinhalte Erzeugen des statischen Reports und Verfassen einer Nachricht Der erzeugte statische Bericht Betrachten des erzeugten Reports in der ReportViewer-View vii

8

9 1. Einleitung 1.1. Motivation In einer modernen Unternehmung treffen Angehörige unterschiedlichster Hierachieebenen wichtige Entscheidungen und können somit maßgeblich zum Erfolg oder Misserfolg dieser beitragen. Um sinnvolle Entscheidungen treffen zu können, benötigt dieser Personenkreis fundierte Informationen. Ein häufig zur Informationsvermittlung genutztes Mittel ist der Bericht. Dieser kann, beispielsweise im Rahmen eines betrieblichen Berichtswesens, das Management regelmäßig über relevante Vorgänge unterrichten, aber auch, etwa im Rahmen eines Projektes gezielt angefordert, als Grundlage für eine anstehende Entscheidungsfindung dienen. Die einem Bericht zugrundeliegenden Daten können dabei aus verschiedenen Quellen stammen. Zum Zwecke der Berichterzeugung müssen relevante Daten ausgewählt, aufbereitet und entsprechend präsentiert werden. Eine mögliche Bezugsart stellt dabei die Analyse von Daten dar, die soziale Netzwerke abbilden. Die als Ergebnis solcher Analysen anfallenden Informationen können Zusammenhänge aufzeigen, die für die Unterstützung verschiedenartiger Entscheidungssituationen, etwa im Rahmen des Personalmanagements, von Wert sein können. Zenk und Behrend führen in [ZB10] (unter Verweis auf [CPPB01][CP04]) an, dass informelle Netzwerke innerhalb von Organisationen neben den formalen Hierarchien existieren und diese unter anderem zeigen, in welcher Form das Personal einer Organisation zusammenarbeitet. Weiter wird argumentiert, dass diese informellen Netzwerke mittels der sozialen Netzwerkanalyse aufgedeckt und analysiert werden können, was den entsprechenden Managern bei der Entscheidungsfindung, etwa im Hinblick auf die Personalentwicklung, helfen könnte. Die Unterstützung von Entscheidungsträgern kann mit Hilfe computergestützer Systeme erfolgen. So wurde im Rahmen des SISOB Projektes [SISb] eine Analytics Workbench zur Durchführung sozialer Netzwerkanalysen entwickelt. Die jeweiligen Ergebnisse können bisher nur getrennt voneinander, also ohne die direkte Möglichkeit, diese in Berichtsform aufbereiten zu können, dargestellt werden. Heute gebräuchliche Systeme zur Entscheidungsunterstützung bieten je nach zugrundeliegendem Konzept und der jeweiligen Zielsetzung unter anderem Funktionalitäten, um Berichte anhand von Daten und Analysen zu erzeugen und die enthaltenen Informationen so interessierten Empfängern zur Verfügung zu stellen. Solche Systeme können an dieser Stelle grob unter den Begriffen Management Support Systeme sowie Business Intelligence zusammengefasst werden. Die Nutzung von Methoden der sozialen Netzwerkanalyse, im Rahmen solcher Systeme, beispielsweise durch Einsatz der zuvor angesprochenen Analytics Workbench, erscheint sinnvoll, nicht nur für den oben angegebenen Einsatzzweck innerhalb von Organisationen. 1

10 1. Einleitung 1.2. Aufgabenstellung Diese Masterarbeit hat die Zielsetzung der Entwicklung einer Web-Applikation zur Netzwerkanalyse-basierten Enscheidungsunterstützung. Das zu entwickelnde Tool soll webbasierte Technologien nutzen, um bequem über einen Browser und verschiedene, auch mobile Geräteklassen ausgeführt werden zu können. Als primäre Nutzer- bzw. Zielgruppe sind Entscheidungsträger (Decision Makers), die Berichte zu Informationszwecken im Rahmen einer Entscheidungsfindung nutzen, aber nicht erstellen wollen, sowie Spezialisten, die die Aufgabe der Berichterstellung übernehmen, vorgesehen. Diese Analysten sollen mit Hilfe der vorhandenen Analytics Workbench Analysen durchführen können, um anschließend deren Ergebnisse aufzugreifen und unter Zuhilfenahme der entsprechenden Funktionalitäten des zu entwickelnden Reporting Werkzeuges Berichte zu erstellen. Somit muss zunächst ein Konzept für den Anschluss der Analytics Workbench an das zu entwickelnde Tool erarbeitet werden. Die zu erstellenden Berichte sollen die Möglichkeit bieten, Ergebnisse der Analytics Workbench in den jeweils vorgesehen Formatierungen und Visualisierungsformen in den Bericht einzuschließen, sowie darüber hinaus diesen mit zusätzlichen Inhalten, wie beispielsweise Text, auch aus weiteren (externen) Quellen, anzureichern. So würden die grundlegenden Voraussetzungen für die Durchführung einer Metaanalyse gegeben. Die mit Hilfe des Reporting Tools erzeugten Berichte sollen anschließend in statischer Form ausgegeben werden können, um sie gegebenfalls mit Hilfe externer Tools weiterzubearbeiten. Die Funktionalität setzt die Wahl entsprechender Dateiformate, wie beispielsweise das PDF- Format, voraus. Auch sollen Analyseergebnisse im Sinne einer Dashboard-Funktionalität interaktiv navigierbar sein. Darüber hinaus ist die Unterstützung von Templates in der Form vorgesehen, als dass diese vorgefertigte Workflows abbilden können, die dann direkt, gegebenenfalls in parametrisierter Form, aus dem Werkzeug heraus ausführbar sein sollen Aufbau der Arbeit Das erste Kapitel dieser Arbeit dient der einführenden Absteckung des zugrundeliegenden thematischen Rahmens und zeigt die Motivation sowie die Aufgabenstellung auf. Anhand des zweiten Kapitels sollen die theoretischen Grundlagen geschaffen werden, die für die Konzeption sowie Implementierung des zu entwickelnden Werkzeuges benötigt werden. Das dritte Kapitel beschreibt den Ansatz, in dem, basierend auf einem Szenario, die Anforderungen an das zu entwickelnde System formuliert werden. Zusätzlich wird hier ein Prozess entwickelt, der die anhand der Anwendung zu unterstützenden Nutzertypen und deren Aufgabenausführung im Zusammenhang beschreibt. Daraus werden erste Entwürfe für die Benutzeroberfläche abgeleitet. Im vierten Kapitel werden die für die technische Realisierung notwendigen Konzepte entwickelt sowie ein Entwurf der Gesamtarchitektur vorgestellt. Anhand des fünften Kapitels wird aufgezeigt, auf welche Weise das System implementiert wurde. Hierzu wird eine Übersicht über einzelne Komponenten sowie grundsätzliche 2

11 1.3. Aufbau der Arbeit Kommunikationsabläufe aufgezeigt. Darüber hinaus wird anhand der einzelnen Bestandteile des Frontends auf client- wie auch serverseitige Implementierungsdetails eingegangen. Die im sechsten Kapitel vorgestellte Beschreibung eines durchgeführten Anwendungsbeispiels soll den praktischen Einsatz des Systems und dessen Einsatzfähigkeit demonstrieren. Abschließend bietet das siebte Kapitel eine Zusammenfassung zu den in dieser Masterarbeit durchgeführten Arbeiten, sowie einen Ausblick auf mögliche Erweiterungen der implementierten Web-Applikation. 3

12

13 2. Grundlagen In diesem Kapitel soll zunächst der Begriff des Decision Makers erklärt, sowie der damit verknüpfte Prozess der Entscheidungsfindung aufgezeigt werden(abb. 2.1). Im Anschluss daran wird in Abschnitt 2.2 näher auf die Begrifflichkeit des Berichts eingegangen, wobei verschiedene Berichtsarten sowie Möglichkeiten zur Klassifikation von Berichten und Regeln für die Gestaltung dieser vorgestellt werden. Gefolgt wird der Abschnitt von Ausführungen zu IT-basierten Konzepten der Managementunterstützung. Hierzu werden in Abschnitt 2.3 zunächst die verschiedenen Ausprägungen der klassischen, aber auch heute noch relevanten Management Support Systeme vorgestellt, die in Teilen in den letzten Jahren immer häufiger auch unter der Begrifflichkeit der in Abschnitt 2.4 dargestellten Business Intelligence geklammert werden. In diesem Zusammenhang wird ein Framework zur Klassifikation von Business Intelligence Systemen bzw. Anwendungen vorgestellt. In Abschnitt 2.5 werden einige im Kontext dieser Arbeit relevante Anwendungstypen bzw. Konzepte präsentiert, die im Rahmen von Business Intelligence Anwendungen zum Einsatz kommen, sowie ein konkretes Produkt vorgestellt. Abschnitt 2.6 stellt weitere dieser Arbeit zugrundeliegende Thematiken vor. Dazu wird in Grundzügen auf den Begriff der Netzwerkanalyse eingegangen sowie die Analyse Workbench und das SISOB Projekt näher vorgestellt. Abschließend wird in Abschnitt 2.7 eine Auswahl an eingesetzten Technologien betrachtet Entscheidungsfindung Das Treffen von Entscheidungen gehört zu den wichtigen Aufgaben des Managements einer jeden Unternehmung. Die getroffenen Entscheidungen können unterschiedlicher Natur sein. So können diese etwa zur Lösung eines spezifischen Problems beitragen, aber beispielsweise auch Anstoß für längerfristige Investitionen sein. Im Folgenden wir der Begriff Decision Making sowie einige damit verbundenen Konzepte näher betrachtet Decision Making und Decision Maker Turban, Ramesh und Dursun beschreiben den Prozess der Entscheidungsfindung in [TSD11, Seite 41] relativ allgemein zunächst folgendermaßen: Decision making is a process of choosing among two or more alternative courses of action for the purpose of attaining one or more goals. Das Treffen von Entscheidungen durch Manager wird unter Verweis auf [Sim77] dabei als wichtiger Bestandteil aller Managementaufgaben, wie etwa der Planung oder des Controllings, angesehen. Es existieren viele Faktoren, die sich auf das Treffen von Entscheidungen auswirken bzw. die Art mitbestimmen, wie Entscheidungen bewertet werden.[tsd11] 5

14 2. Grundlagen Entscheidungen werden, evtl. durch situativen Kontext beinflusst, von unterschiedlichen Menschen auf jeweils individuelle Art und Weise getroffen. Dabei lassen sich laut [TSD11] verschiedene Decision Styles identifizieren, die charakterisieren, auf welche Art unterschiedliche Personen Entscheidungen treffen. Persönlichkeitstests geben Auskunft über individuelle Persönlichkeitseigenschaften und können zur Identifizierung eines oder mehrerer Decision Styles genutzt werden. Als Beispiele für Decision Styles werden heuristische oder analytische Vorgehensweisen genannt, aber auch die Unterscheidung zwischen autokratischen und demokratischen Stilen aufgezählt. Darüber hinaus wird darauf hingewiesen, dass auch Mischformen, bestehend aus mehreren Decision Styles, auftreten können. Entsprechend müssten sich Computersysteme, die eine Entscheidungsfindung unterstützen sollen, durch hohe Anpassbarkeit und Flexibilität unter Einbeziehung der Eigenschaften des Nutzers und des situativen Kontextes auszeichnen. Zum Begriff des Decision Makers stellen Turban et al. weiter heraus, dass es sich dabei um Einzelpersonen, auch des unteren Managements in kleineren Unternehmen handeln kann, aber auch um eine Gruppe von Personen aus evtl. verschiedenen Bereichen, die gemeinsam zu einem Konsens kommen müssen. Weiter stellen sie fest, dass entsprechende Computersysteme den mitunter schwierigen und teilweise mit (unternehmungs-) politischen Problemen behafteten Prozess der Entscheidungsfindung durch Gruppen verbessern können.[tsd11] Der Prozess der Entscheidungsfindung Laut Turban et al. in [TSD11] ist es von Vorteil, den Prozess der Entscheidungsfindung systematisch anzugehen und es wird in diesem Kontext auf die von Simon in [Sim77] dargestellten Phasen verwiesen. In Abbildung 2.1 sind diese im Gesamtzusammenhang des Prozesses der Entscheidungsfindung dargestellt. Im Folgenden wird auf einige Aspekte der einzelnen Phasen eingegangen. Die Problemanalysephase (Intelligence Phase) steht am Beginn des Entscheidungsfindungsprozesses. In dieser Phase wird ein bestimmter Aspekt einer Unternehmung, unter Betrachtung der Ziele und Aufgaben dieser, kritisch betrachtet. Ist ein zu entscheidendes Problem eindeutig identifiziert, so wird versucht, es einer bestimmten Kategorie zuzuordnen, was den Vorteil haben kann, dass evtl. schon Ansätze einer möglichen Problemlösung bekannt sind. Da ein zu behandelndes Problem einen hohen Komplexitätsgrad aufweisen kann, wird versucht, es in kleinere Unterprobleme einzuteilen, die dann einzeln, evtl. durch Einbeziehung verschiedener Instanzen, angegangen werden können. Wichtig ist auch festzustellen, wem das Problem und dessen Lösung zugeordnet werden kann. Liegt die Ursache im Einflussbereich der jeweiligen Unternehmung, so kann die zuständige Instanz zugeordnet werden und evtl. nachträglich die Verantwortung zur Problemlösung an diese übertragen werden oder diese selbst übernommen werden. Das Ergebnis der Intelligence Phase ist die formal definierte Problemstellung.[TSD11] Die Modellbildungsphase (Design Phase) hat das Ziel, ein Modell für das vorliegende Problem, zu dem eine Entscheidung gefunden werden soll, zu entwickeln. Ein Modell ist dabei als eine vereinfachte Darstellung der Realität zu betrachten, die trotz Simplifizierung dieser, alle für das abzubildende System relevanten Variablen beinhaltet. Modelle können anhand des Grades, mit dem sie ein System abbilden, klassifiziert werden. Turban et al. unterscheiden zwischen ikonischen, analogen und mathematischen Modellen. Das erstellte Modell wird in der Design-Phase verifiziert und Auswahlkriterien für mögliche 6

15 2.2. Berichtswesen Abbildung 2.1.: Phasen der Entscheidungsfindung (angelehnt an [TSD11, S. 46]) Lösungsansätze, die für das Modell identifiziert wurden, werden festgelegt.[tsd11] In der Entscheidungsphase (Choice Phase) wird die Entscheidung getroffen, welche der in der vorhergehenden Phase gefundene(n) Lösungsalternative(n) gewählt werden soll. Dazu werden die Alternativen evaluiert und im Rahmen dessen wird möglicherweise nochmal in die Design Phase zurückgekehrt, etwa um neue Alternativen zu generieren. Nach Auswahl einer oder mehrerer Lösungsansätze wird mit der nächsten Phase fortgefahren.[tsd11] In der Umsetzungsphase (Implementation Phase) schließlich wird die gefundene Lösung in geeigneter Form umgesetzt, was im Idealfall zur Lösung des identifizierten Problems führt. In dieser wie auch jeder anderen dargestellten Phase des Entscheidungsprozesses ist es möglich in frühere Phasen zurückzukehren.[tsd11] Der hier dargestellte Prozess der Entscheidungsfindung kann wie bereits angedeutet in seinen einzelnen Phasen durch computergestützte Systeme unterstützt werden. Entsprechende Konzepte und Ausprägungen werden in den folgenden Abschnitten 2.3 und 2.4 vorgestellt Berichtswesen Die Erzeugung, Aufbereitung und Bereitstellung von Informationen für Entscheidungsträger stellt eine wichtige Grundvoraussetzung für die erfolgreiche Durchführung einer Unternehmung dar. Dem Begriff Bericht (Report), sowie dem darauf basierenden betrieb- 7

16 2. Grundlagen lichen Bereich des Berichtswesens (Reporting) kommt dabei eine besondere Rolle zu. Im folgenden Abschnitt soll dieser Themenkomplex näher beleuchtet werden. Es werden hier jedoch noch keine Konzepte für softwaregestützte Berichtswerkzeuge vorgestellt. Das erfolgt, nach Vorstellung weiterer Basiskonzepte, zusammenfassend in Abschnitt dieses Kapitels Die Begriffe Bericht und Berichtswesen Angehörige verschiedener Fach- und Führungsebenenen einer Unternehmung können jeweils in geeigneter Abstraktion präsentierte Informationen in Enscheidungsfindungsprozesse einfließen lassen. Zu diesem Zweck müssen Informationen einerseits gesammelt und aufbereitet werden, andererseits den jeweiligen Adressaten zugänglich gemacht werden. Da je nach Form und Größe einer Unternehmung diese Vorgänge durch verschiedene, zeitlich und räumlich getrennte Prozesse abgebildet sein können, müssen Vorgänge stattfinden, die einen ordentlichen Transfer von Informationen zwischen den einzelnen Stellen ermöglichen. Diese werden durch den Begriff des (betrieblichen) Berichtswesens abgebildet.[hor11] Ein Bericht ist nach [Zie12, S. 587] [...] die geordnete Zusammenstellung ausgewählter Informationen wie (Kenn-)Zahlen und aussagekräftiger Grafiken zu jeweils einem Sachverhalt oder Ereignis. In [GGD08, S. 206] werden in diesem Zusammenhang auch Berichte explizit als Dokumente, [...] die unterschiedliche Informationen für einen bestimmten Untersuchungszweck miteinander kombinieren und in aufbereiteter Form vorhalten. dargestellt. Zum Begriff des Berichtswesens wird in [BS11, S ] u.a. folgendes festgestellt: Das Berichtswesen umfasst alle Personen, Einrichtungen, Regelungen, Daten und Prozesse der Erstellung und Weitergabe von Berichten im Sinne von zweckorientiert zusammengestellten Informationen zur Befriedigung eines spezifizierten Informationsbedarfs. Berichte und somit das Berichtswesen können einerseits den zuvor angesprochenen internen Zwecken dienen, andererseits auch an externe Adressaten gerichtet sein. Ein Beispiel für letzteres wäre etwa (im Unternehmenskontext) die Erstellung und Bereitstellung des gesetzlich vorgesehenen Jahresabschlussberichts. In dieser Arbeit soll jedoch nicht näher auf das externe Berichtswesen eingegangen werden. Entsprechend beziehen sich alle weiteren Ausführungen auf das interne Berichtswesen, auch wenn Überschneidungen mit Teilen des externen Berichtswesen nicht auszuschließen sind Berichtsarten Berichte können sich hinsichtlich vieler verschiedener Merkmale stark voneinander unterscheiden. Zu diesen Eigenschaften zählen der Zweck, der mit Hilfe eines Berichts zu erreichen ist, der Berichtsgegenstand, also der Rahmen, der durch einen Report abgedeckt wird, wie auch die Art der Information, die vermittelt werden soll, sowie deren Verdichtungsgrad. Auch die Unterscheidung, ob ein Bericht regelmäßig oder unregelmäßig, etwa ausgelöst durch Eintreten eines bestimmten Ereignisses, erstellt werden soll, spielt eine wichtige Rolle für die Kategorisierbarkeit von Berichten. Auch die Art des Mediums (Datenträger), mit dessen Hilfe ein Bericht weitergeben werden kann, hat Einfluss auf 8

17 2.2. Berichtswesen die Charakteristik eines Reports.[K 08] Auch bestimmt die Tatsache, dass Berichte an Empfänger der unterschiedlichsten Hierarchieebenen sowie Abteilungen einer Unternehmung, wie beispielsweise an das Top- Management, aber auch an Fachkräfte gerichtet sein können, die Ausprägung verschiedener Berichtsmerkmale im Hinblick auf die Zielgruppe[GGD08]. Besonders hervorzuheben sind im Zusammenhang der Unterscheidung von Berichtstypen bzw. -arten Standardberichte, Abweichungsberichte und Bedarfsberichte[K 08]. Von Zentraler Bedeutung für das Berichtswesen ist der Standardbericht. Hierbei handelt es sich um periodisch erstellte Berichte, die einen zu einem früheren Zeitpunkt mittels einer Informationsbedarfsanalyse festgestellten Wissensbedarf befriedigen sollen. Dieser Berichtstyp wird allgemein, unter anderem aus wirtschaftlichen Gründen, von vielen verschiedenen Arten von Empfängern genutzt. So müssen im Vorfeld für die Erstellung eines solchen Berichts verschiedene Standards festgelegt werden. Dazu zählen neben Inhalt, Form und Erscheinungszeitpunkt auch eine festgelegte Menge an enthaltenen Daten. Aus diesen können sich die jeweiligen Empfänger die für den eigenen Zweck relevanten Daten auswählen. Dieser Berichtstyp eignet sich aber, unter anderem auf Grund des relativ hohen Standardisierungsgrades, wenig für die Befriedigung spontaner bzw. spezieller Informationsbedürfnisse.[K 08] Regelmäßig erstellte (Standard-)Berichte können unter Umständen zu einer Informationsüberversorgung führen, sodass in bestimmten Fällen die Nutzung von Abweichungsberichten sinnvoll sein kann. Zielsetzung dieses Berichtstyps ist es, die potentiellen Empfänger ausschließlich nach Eintreten bestimmter Umstände mit den Informationen zu versorgen, die benötigt werden, um auf die neu eingetretene Situation angemessen reagieren zu können. Ein Beispiel für einen Auslöser zur Erzeugung eines Abweichungsberichts ist etwa das Überschreiten eines zuvor definierten Schwellwertes einer beobachteten Größe. Abweichungsberichte werden somit in unregelmäßigen Abständen generiert, wobei deren Häufigkeit von festgelegten Regeln bestimmt ist. Dieser Berichtstyp eignet sich für die Kontrolle von Vorgängen, nicht jedoch zur Planung neuer Prozesse.[K 08] Standard- und Abweichungsberichte sind oft an eine relativ große Zielgruppe gerichtet. Dabei hat der Adressat keine Möglichkeit, speziell auf seine aktuellen Bedürfnisse zugeschnittene Informationen anzufordern. Dieser Fall kann mit Hilfe von Bedarfsberichten abgedeckt werden. Dabei ist der Empfänger der Auslöser für die Berichtserstellung, da er gezielt Informationen anfordert. Der resultierende Report ist speziell auf den Nutzer oder eine bestimmte Nutzergruppe sowie die jeweilige Anfrage zugeschnitten und bleibt damit einer größeren Zielgruppe vorenthalten, da der jeweilige Nutzen für Dritte gering oder nicht vorhanden wäre. Eine individuelle Informationsanfrage kann die Erstellung von Bedarfsberichten aufwendig gestalten und auch die Tatsache, dass häufig vergleichsweise wenige Empfänger von dieser Berichtsart profitieren können, kann evtl. als problematisch angesehen werden. Andererseits wird der konkrete Informationsbedarf durch diesen Berichtstyp möglichst genau befriedigt.[k 08] Berichtsgestaltung Wie zuvor bereits angesprochen, können Berichte anhand verschiedener Kriterien eingeordnet bzw. kategorisiert werden. Diejenigen Berichtsmerkmale, die auch zur sinnvollen Gestaltung von Berichten herangezogen werden können, sind in Abbildung 2.2 dargestellt und werden im Folgenden näher betrachtet. 9

18 2. Grundlagen Zentraler Bestandteil der Beschreibung von Berichten ist der Berichtszweck, an diesem orientieren sich alle weiteren Merkmale [Hor11]. In [K 08] werden unter Verweis auf [Ass71] drei Berichtszwecke herausgestellt und weiter ausgeführt: Der erste angesprochene Zweck ergibt sich aus den Aufbewahrungs- und Dokumentationspflichten eines Unternehmens. Die Dokumentation von Daten ist allerdings nicht nur im Zusammenhang mit der Einhaltung gesetzlicher Vorschriften sinnvoll, auch im Rahmen der Kontrolle von Abläufen sowie Planung dieser, etwa durch Erstellung von Prognosen auf Basis der gesammelten Informationen, kann sie eine wichtige Funktion erfüllen. Ein weiterer wesentlicher Berichtszweck ist die Auslösung von (Arbeits-)vorgängen aufgrund von aus Berichten entnommenen Informationen. Beispielsweise kann ein berichteter Absatzrückgang eines bestimmten Produktes ein Unternehmen dazu veranlassen, die Produktion entsprechend zu drosseln. Somit können Berichte unmittelbar zur Entscheidungsvorbereitung beitragen, womit der letztgenannte Berichtszweck angesprochen ist. Diesem kommt aber darüber hinaus noch eine Kontrollfunktion zu, da es sinnvoll erscheint, auch die durch vorausgegangene Berichte ausgelösten Vorgänge und Entscheidungen auf Erfolg zu prüfen.[k 08] Der Berichtsinhalt beschreibt die darzustellenden Sachverhalte. Hierbei ist auf einen dem Zweck angemessenen Detaillierungsgrad sowie entsprechende Verdichtung der dargebotenen Informationen zu achten. Ebenso sollten, zur Ermöglichung einer einfach vorzunehmenden Einordnung der Informationen, Anhaltspunkte durch Vergleichsinformationen geschaffen werden sowie das Spektrum zur Auswahl der Informationen dem Zweck entsprechend ausreichend breit gewählt werden.[ggd08] Der oder die Berichtsempfänger (Berichtsinstanzen) bestimmen in großem Ausmaß den Aufbau und Inhalt des Berichts. Hierbei ist die Wichtigkeit der exakten Bestimmung des Informationsbedarfs der jeweiligen Zielgruppe sowie die genaue Ausrichtung auf deren Bedürfnisse hervorzuheben.[ggd08] Der zeitliche Aspekt (Berichtszeit) bestimmt den durch den entsprechenden Bericht abzudeckenden Zeitraum, die Frequenz mit denen Berichte auf regelmäßiger oder unregelmäßiger Basis erstellt werden sowie die im Bericht betrachteten Zeitspannen[GGD08]. Als letztes Merkmal ist die Berichtsform zu nennen. Zur Darstellung von Berichtsinhalten werden unterschiedliche Darstellungsformen genutzt, die sich grob in graphische und textuelle Verfahren untergliedern lassen. Häufige grafische Darstellungsformen sind etwa Kreis- oder Balkendiagramme. Textuelle Darstellungsformen werden oft in Tabellenform zur Angabe quantitativer Daten genutzt, aber auch Volltext zur Vermittlung qualitativer Informationen ist eine gängige Darstellungsform. Zentral für die Verständlichkeit der durch den Bericht zu vermittelnden Informationen und Aussagen auf Seiten der Adressaten, ist die strukturelle Anordnung der einzelnen Berichtsbestandteile. Generell kann zwischen konventionellen Präsentationsmedien (meist papiergestützt) und elektronischen Präsentationsmedien unterschieden werden.[ggd08] Die in Abbildung 2.2 dargestellten Pfeile zwischen den einzelnen Berichtsmerkmalen lassen auf Beziehungen untereinander schließen, die über die bereits angesprochene zentrale Rolle des Berichtszweckes hinausgeht. Laut Küpper [K 08] (mit Verweis auf[koc94]) handelt es sich dabei um teilweise komplementäre wie auch konkurrierende Beziehungen zwischen den Merkmalen, die im Rahmen der Berichtsgestaltung zu berücksichtigen sind. 10

19 2.3. Planungs- und Kontrollsysteme & Management Support Systeme Abbildung 2.2.: Merkmale zur Einordnung von Berichten (angelehnt an [GGD08, S. 208]) 2.3. Planungs- und Kontrollsysteme & Management Support Systeme In Unternehmungen kommen verschiedenartige computergestützte Informations- und Kontrollsysteme zum Einsatz, die alle Hierarchieebenen und Abteilungen durchdringen und in ihrer jeweiligen Ausprägung dabei einen spezifischen Nutzen darstellen. Auch die Management-Etagen setzen heutzutage auf unterschiedliche Arten von Softwaresystemen, die nicht nur die Kommunikation erleichtern können, sondern auch als Informationsquelle, wie etwa zur Entscheidungsunterstützung, dienen. Im Folgenden sollen anlehnend an [GGD08] allgemein einige der in Unternehmen eingesetzten Anwendungssysteme klassifiziert werden. Insbesondere wird auf die Planungs- und Kontrollsysteme als wichtiger Baustein dieser Systeme eingegangen. Anschließend werden die unter dem Sammelbegriff Management Support Systeme zusammengefassten Konzepte aufgezeigt Planungs- und Kontrollsysteme Die im betrieblichen Kontext eingesetzten Anwendungssoftwaresysteme sollen die Ausführung von betrieblichen Prozessen unterstützen und gleichzeitig zur Problemlösung beitragen. Diese Anwendungssysteme lassen sich laut Mertens und Griese in die folgenden zwei Kategorien unterteilen. Die erste Kategorie bilden die Administrations- und Dispositionssysteme. Diese bilden die Basisabläufe der operativen Unternehmensabläufe sowie die diesen zugeordneten Abrechnungssysteme ab. Die zweite Kategorie bilden die Planungsund Kontrollsysteme.[MG02][Mer05] Aufgrund der Ausrichtung dieser Arbeit auf entscheidungsunterstützende Prozesse und Systeme wird im Weiteren lediglich auf diese zweite Kategorie vertiefend eingegangen. Die unter dem Begriff Planungs- und Kontrollsysteme geklammerten Systemtypen lassen sich anhand ihres entweder aktiven oder passiven Charakters klassifizieren. Aktiv 11

20 2. Grundlagen bedeutet im Falle der dieser Kategorie zuzuordnenden Berichtssysteme, dass sie zu einem selbstbestimmten Zeitpunkt aktiv (im Sinne einer Berichtsgenerierung) werden. Diese aktiven Berichtssysteme können entweder periodisch, also in fest vorgegebenen Zeitabständen als reine Berichtssysteme oder aperiodisch, beispielsweise nur bei Eintreten bestimmter Ereignisse, vom System ausgelöst werden. Die passiven System, zu denen die Abfrage- und Auskunftsysteme sowie die Dialogsysteme gehören, ermöglichen dem Anwender das gezielte Anstoßen der jeweiligen Aktivität.[GGD08] Aufgrund der Ausrichtung dieser Masterarbeit auf die Unterstützung von Entscheidungen mit Hilfe gezielter Analysen, soll hier lediglich weiter auf die Systeme mit passivem Charakter eingegangen werden. Die den Abfrage- und Auskunftsystemen zuzuordnenden Systemtypen stellen grundlegende Funktionalitäten zur Abfrage von Daten aus vorhandenen Beständen, beispielsweise einer Datenbank, zur Verfügung. Zu diesen zählen die standardisierten Systeme sowie die frei formulierten Systeme. Die zuerst genannten Systeme ermöglichen meist die Abfrage anhand von fest vorformulierten Anfragen, deren Ergebnisse in Berichten mit starrer oder veränderbarer Strukturierung mündet. Die frei formulierten Systeme bieten dem Anwender größere Freiheiten. Diese bedingen aber möglicherweise Expertenwissen, wie die im Falle von individuell gestellten Datenbankabfragen benötigten Kenntnisse in entsprechenden Datenbanksprachen.[GGD08] Dialogsysteme ermöglichen dem Nutzer bereits ohne Einsatz eines Entscheidungsmodells, über die einmalige Anfrage bestimmter Daten hinaus, das erneute Aufgreifen von Ergebnissen aus vorhergehenden Anfragen und Arbeitsschritten. Liegen dem System Entscheidungsmodelle zugrunde, so wird dem Anwender eine problemorientierte Nutzung der Systemfunktionalitäten ermöglicht. Die Dialogsysteme können zu den im nächsten Abschnitt dargestellten Decision Support Systemen gezählt werden.[ggd08] Der Begriff der Management Support Systeme Der Begriff Management Support Systeme (MSS) fasst alle Softwaresysteme zusammen, die durch Fach- und Führungskräfte einer Unternehmung genutzt werden und dabei für diese Zielgruppe unterstützenden Charakter aufweisen. Insbesondere sollen Planung, Organisation, Kontrolle und Steuerung von Unternehmungsprozessen unterstützt werden. Da Fach- und Führungskräfte allgemein einen hohen Bedarf an speziell aufbereiteten Informationen haben, die zur Problemlösung wie auch zur Entscheidungsfindung beitragen können, müssen entsprechende Softwaresysteme hohen Anforderungen im Bereich der Belastbarkeit, des Integrationsgrades und der Prozessorientierung genügen.[ggd08] Im Folgenden werden die klassischen Unterformen der Management Support Systeme anlehnend an [GGD08] vorgestellt Management Information Systeme Die ersten Ausprägungen der Administrations- und Dispositionssysteme zur Unterstützung von operativen Abläufen von Unternehmungen bestanden oft aus verschiedenen, häufig unabhängigen Einzelkomponenten. Aus Managersicht boten diese neuen Technologien vielfältige Möglichkeiten in Hinblick auf die Nutzung der den Systemen zugrunde 12

21 2.3. Planungs- und Kontrollsysteme & Management Support Systeme liegenden Datenbestände. Der häufig geäußerte Wunsch des Managements nach hoher Verfügbarkeit von aktuellen, evtl. zuvor verdichteten und verschiedene Geschäftsaktivitäten abbildenden Daten führte zur Entwicklung entsprechender Softwarelösungen. Diese Anforderungen prägten den Begriff der Management Information Systeme.[GGD08] Diese Systeme können wie folgt definiert werden: Management Information Systeme (MIS) sind EDV-gestützte Systeme, die Managern verschiedener Hierarchieebenen erlauben, detaillierte und verdichtete Informationen aus der operativen Datenbasis zu extrahieren. Die Informationsverarbeitung erfolgt ohne (aufwändige) Modellbildung und ohne Anwendung von anspruchsvollen Methoden (logisch-algorithmische Bearbeitung). [GGD08, S. 56] Somit zielen Management Information Systeme lediglich auf die Zusammenstellung von operativen Daten ab, ohne dabei Modelle oder Methoden zu nutzen. Management Information Systeme waren in ihren frühen Formen oft an unterschiedliche Systeme der operativen Unternehmensbasis angeschlossen, die verschiedene Formen der Datenhaltung und voneinander abweichende Datenformate nutzten. Dieser Umstand führte dazu, dass wenig standardisierte Datenbestände verarbeitet werden mussten und die Empfänger mit kaum relevanten Informationen überladen wurden, sowie ein die Unternehmung umspannendes Informationsbedürfnis meist nicht befriedigt werden konnte. Diesem Problem kann in heutigen MIS-Systemen oft dadurch begegnet werden, dass Anfragen an standardisierte Datenbanken gerichtet werden können und Möglichkeiten zur Verfügung gestellt werden, um Daten schrittweise zu aggregieren und den unterschiedlichen Adressaten entsprechend zu präsentieren. Management Information Systeme stellen heutzutage häufig eine wichtige Ausprägung der in Unternehmungen eingesetzten Management Support Systeme dar.[ggd08] Decision Support Systeme Dem Ansatz der MIS folgten historisch betrachtet die Decision Support Systeme. Diese sehen eine starke Orientierung an Modellen und Methoden vor, die dem jeweiligen Anwender bei der Problemstrukturierung helfen und mögliche Lösungsalternativen aufzeigen sollen.[ggd08] Die Begrifflichkeit der Decision Support Systeme lässt sich wie folgt definieren: Decision Support Systeme (DSS) oder Entscheidungsunterstützungssysteme (EUS) sind interaktive EDV-gestützte Systeme, die Manager (Ent- scheidungsträger) mit Modellen, Methoden und problembezogenen Daten in ihren Entscheidungsprozessen unterstützen. [GGD08, S. 63] Decision Support Systeme orientieren sich am Problemlösungsverhalten des Nutzers und versuchen dieses abzubilden. Somit gehen herkömmliche Enscheidungsunterstützungssysteme davon aus, dass das Ausgangsproblem mit Hilfe eines Modells abgebildet werden kann. Anhand spezifischer Methoden kann dieses im Anschluss bearbeitet werden. Diese abstrahierende und methodengestützte Vorgehensweise zur Problemlösung hat verschiedene Vorteile, wie etwa die einfacheren, da gut beschreibbaren Vorschriften, 13

22 2. Grundlagen für die softwareseitige Implementierung von Methoden. Die im von Sprague und Carlson in [SC82] im ROMC 1 -Konzept beschriebenen Kriterien zur Beschreibung von DSS ermöglichen die Herleitung der im Folgenden beschriebenen Bestandteile von Entscheidungsunterstützungssystemen.[GGD08] Es lassen sich bis zu sechs unterschiedliche Komponenten von DSS identifizieren, die ebenfalls in [SC82] genannt werden. Zentral ist dabei das Verwaltungssystem, an das die anderen Systembestandteile angebunden sind, und von dem diese kontrolliert und gesteuert werden. Die Dialogsystem-Komponente ermöglicht es dem Nutzer mit dem System zu interagieren. Über ein (grafisches) Benutzerinterface kann der Nutzer das System steuern, indem er beispielsweise Anfragen an dieses richtet oder in laufende Vorgänge eingreift. Diese Kommandos werden von den übrigen Systembestandteilen verarbeitet und in der jeweils vom Benutzer gewünschten Repräsentation über die Dialogkomponente ausgegeben. Die Modellbank-Komponente ermöglicht die Erzeugung und Speicherung neuer Modelle wie auch Möglichkeiten zum Suchen bereits vorhandener Modelle. Dabei sollen enthaltene Daten, Variablen und funktionale Abhängigkeiten zwischen diesen editierbar sein. Die Verarbeitung der durch ein Modell abgebildeten Fragestellung soll mit Hilfe der in der Methodenbank-Komponente enthaltenen Verfahren ermöglicht werden. Die hier vorgehaltenen Methoden bilden algorithmische Vorgehensweisen ab. Bei diesen kann es sich um einfache Verfahren zur Aggregation von Informationen aber auch um komplexere Kalkulationen oder Simulationen handeln. Die Datenbank-Komponente bildet einen wichtigen und die anderen Komponenten unterstützenden Bestandteil von Decision Support Systemen. Sie ermöglicht unter anderem das Anlegen, Ablegen, Editieren, Löschen und Abrufen von Datenbeständen systeminterner wie auch -externer Quellen. Durch die Datenbankeinheit werden die Voraussetzungen für den benötigten gegenseitigen Datenaustausch zwischen den einzelnen Systemkomponenten geschaffen. Als letzte Komponente ist die Reportdatenbank anzuführen. Hier können Ergebnisse von in der Vergangenheit durchgeführten Problemlösungsanfragen an das DSS dauerhaft gelagert und für ein eventuelles Wiederaufgreifen für spätere Fragestellungen vorgehalten werden. Andererseits können auch erweiterbare Reportvorlagen, die zur vereinfachten Berichterstellung beispielsweise auch von Reportgeneratoren (vgl ), die über das vom Anwender bediente Frontend genutzt werden können, in der Reportbank gelagert sein. Decision Support Systeme existieren in vielen verschiedenen Ausprägungen. Die hier vorgestellten Komponenten sind als Teile eines jeden DSS, mal in stärkerer, mal in weniger prägnanter Form, vorhanden.[ggd08] Zur Erzeugung problemorientierter Decision Support Systeme werden häufig Tabellenkalkulationsprogramme eingesetzt, anhand derer beispielsweise Arbeitsblätter, die sich der Lösung eines spezifischen Problems widmen, erstellt werden können und diese auch nutzbar machen. Decision Support Systeme werden häufig in Fachabteilungen zur Behandlung eng definierter Problemstellungen eingesetzt, da sie, ähnlich wie die Management Information Systeme, keine unternehmungsweit gültigen Problemlösungsstrategien bieten können.[ggd08] Executive Information Systeme Executive Information Systeme (EIS) können als Weiterentwicklung der zuvor vorgestellten Management Information Systeme angesehen werden. Definieren lässt sich dieser 1 Representations, Operations, Memory Aids, Control Mechanisms 14

23 2.3. Planungs- und Kontrollsysteme & Management Support Systeme Systemtyp wie folgt: Executive Information Systeme (EIS) sind dialog- und datenorientierte Informationssysteme für das Management mit ausgeprägten Kommu- nikationselementen, die Fach- und Führungskräften aktuelle entscheidungsrelevante interne und externe Informationen über intuitiv und individuell anpassbare Benutzungsoberflächen anbieten. [GGD08, S. 75] Executive Information Systeme sollen dem Anwender frühzeitige Unterstützung im Rahmen des Planungs- wie auch Entscheidungsprozesses bieten. In diesem Zusammenhang benötigt der betreffende Nutzer Möglichkeiten, um explorativ Daten betrachten und auf Basis dieser eventuell weitergehende Analysen in Auftrag geben zu können.[ggd08](unter Verweis auf [Jah93]) Aber auch zur (kritischen) Betrachtung zuvor durchgeführter Aktivitäten eignen sich EIS grundsätzlich. Executive Information Systeme sollten individuell an den jeweiligen Anwender anpassbar sein und dabei unterschiedliche Arten von Informationen aus verschiedenen Quellen in geeignet aufbereiteter Form präsentieren, um einen Überblick über den Status einer Unternehmung bieten zu können.[ggd08] Voraussetzung für die individuelle Ausrichtung eines EIS ist das Vorhandensein eines Modells für die betreffende Unternehmung. Dessen definierte Strukturen, die Beschränkung auf die vorgegebenen Datenstrukturen, sowie die begrenzte Anzahl der anwendbaren Methoden, machen eine aufwändige Methoden- und Modellverwaltung überflüssig. Daten können in EIS beliebig exploriert und mittels verschiedener Techniken präsentiert werden. Häufig werden Möglichkeiten der Berichtsgenerierung innerhalb der Benutzeroberfläche angeboten. Executive Information Systeme weisen zusätzlich unterschiedliche und meist integrierte Komponenten zur Kommunikation auf. Per können beispielsweise Informationen direkt, aus der Beuntzeroberfläche heraus, unternehmungsintern wie auch -extern ausgetauscht werden. Die durch EIS genutzten Daten können aus verschiedenen Quellen stammen und sollten zum Zwecke der guten Verfügbarkeit in einer entsprechend gut geplanten Form vorgehalten werden. Dabei können die Daten in einer systemeigenen Datenbank gehalten werden, die die Daten in, je nach geplanten Verwendungszwecken, unterschiedlichen Formen bereitstellt (siehe hier auch Data Warehouses 2.4.2) bzw. auch direkt aus der evtl. abgreifbaren operativen Datenbasis stammen.[ggd08] Executive Support Systeme Excecutive Support Systeme stellen einen Ansatz dar, der Eigenschaften von Executive Information Systemen mit denen der Decision Support Systeme in geeigneter Form verbindet. Dieser Bestandteil der Management Support Systeme kann folgendermaßen definiert werden: Executive Support Systeme (ESS) sind arbeitsplatzbezogene Kombinationen aus problemlösungsorientierten DSS- und präsentations- und kommu- nikationsorientierten EIS-Funktionalitäten, die an Anwendertypen und Problemspektren ausgerichtet sind. Unter Umständen werden neben konventionellen DSS auch wissensbasierte DSS einbezogen. [GGD08, S. 82] Durch die vielfältigen Verfahren der Informationsvisualisierung und -präsentation, sowie nutzerfreundliche Bedienkonzepte von Executive Information Systemen und der gleich- 15

24 2. Grundlagen zeitigen Möglichkeit, vielfältige Modelle und Methoden zur weiteren Verarbeitung dieser Informationen, die durch Decision Support Systeme bereitgestellt werden, nutzen zu können, können ESS einen vielfältigeren Management-Support bieten, als die einzelnen Komponenten für sich betrachtet. Für die Entwicklung eines Executive Support Systems können einzelne Komponenten aus den EIS- und DSS-Ansätzen kombiniert und so auf die jeweiligen Einsatzzwecke abgestimmt werden. Somit handelt es sich bei dem Begriff der ESS eher um ein Konzept zur Erstellung eines Management Support System als um ein vorgefertigtes Komplettsystem.[GGD08] 2.4. Business Intelligence Auch wenn der, die im Abschnitt 2.3 vorgestellten Konzepte klammernde Begriff der Management Support Systeme weiterhin, insbesondere in der Wissenschaft, genutzt wird, so wird gerade im betrieblichen Umfeld, also der Praxis, seit den 1990er Jahren vermehrt der Begriff Business Intelligence verwendet[kbm10] Der Begriff der Business Intelligence Der Begriff Business Intelligence (BI) lässt sich schwer fassen. Es kann allgemein festgehalten werden, dass die dieser Begrifflichkeit zuordenbare Anwendungen gemeinsam einen Charakterzug aufweisen. So dienen sie, durch Bereitstellung entsprechender Nutzungsmöglichkeiten, der Unterstützung von Entscheidungen und sollen einen besseren Überblick über die eigene Unternehmung bieten.[ggd08] Kemper, Baars und Mehanna stellen in [KBM10] unter Bezugnahme auf den von Gluchowski in [Glu01] aufgezeigten Ordnungsrahmen verschiedene Sichtweisen auf den Begriff Business Intelligence vor. Demnach lassen sich drei unterschiedliche Typen von Definitionen abgrenzen. Unter dem engen Verständnis von Business Intelligence werden Anwendungen wie das Online Analytical Processing (OLAP) oder auch die im Abschnitt 2.3 angesprochenen Management Information Systeme und Executive Information Systeme verstanden. Dabei handelt es sich um Konzepte, die zur direkten Unterstützung von Entscheidungsfindungen beitragen sollen. Weiter kann Business Intelligence aus analyseorientierter Sicht beschrieben werden. Dazu zählen Systeme, die direkt durch den jeweiligen Anwender (interaktiv) bedient werden können. In diesem Zusammenhang sind Personen, die Informationen für Entscheidungsträger vorbereiten, wie auch diese selbst, zu nennen. Beispiele, die in diese Kategorie fallen, sind unter anderen etwa die im Rahmen des engen BI-Verständnisses angesprochenen Konzepte aber auch das Ad-hoc-Reporting, was im Abschnitt kurz angesprochen wird. Das weite Verständnis von Business Intelligence fasst allgemein alle Anwendungen bzw. Konzepte zusammen, die auf direkte oder indirekte Weise Entscheidungen unterstützen sollen. Dazu zählen Komponenten, anhand derer Daten gesammelt, aufbereitet und gespeichert werden können, sowie solche, die diese zu Auswertungszwecken weiterverarbeiten und dem Nutzer in geeigneter Form verfügbar machen.[kbm10] Kemper et al. stellen in [KBM10] fest, dass Business Intelligence als integrierter Gesamtansatz gesehen werden muss, soll er denn den heutigen Anforderungen der Managementunterstützung genügen. Eine Eigenschaft von klassischen Einzellösungen zur Unterstützung von Managementaufgaben sei etwa, dass durch sie nur einzelne Gebiete 16

25 2.4. Business Intelligence einer Unternehmung berücksichtigt werden können. Konkret wird die folgende Definition für den Begriff Business Intelligence gegeben: Business Intelligence (BI) bezeichnet einen integrierten, unternehmensspezifischen, IT-basierten Gesamtansatz zur betrieblichen Entschei- dungsunterstützung. BI-Werkzeuge dienen ausschließlich der Entwicklung von BI-Anwendungen. BI-Anwendungssysteme bilden Teilaspekte des BI-Gesamtansatzes ab. [KBM10, S. 9] BI-Architekturschichten Als Orientierungsmöglichkeit für die Ausgestaltung sowie Einordenbarkeit der einzelnen Bestandteile eines Business Intelligence Konzeptes soll im Folgenden ein in [KBM10] vorgestellter Ordnungsrahmen, der den Begriff Business Intelligence anhand von drei Schichten strukturiert, vorgestellt werden. Die Komponenten der Datenbereitstellungsschicht sind dafür zuständig, dass Daten, die aus verschiedenen Beständen der operativen Unternehmenssysteme wie auch aus externen Quellen stammen, in einer konsistenten Form abzulegen und für Komponenten der nächsten Schicht verfügbar zu machen. Dabei kann es sich um strukturierte, numerische Daten, aber auch um unstrukturierte Daten, die beispielsweise in Form von (eingescannten) Textdokumenten oder Bildern vorliegen, handeln. Im Rahmen der Integration von strukturierten Daten werden häufig Data Warehouses eingesetzt.[kbm10] Data Warehouses bieten laut Bauer und Günzel in [BG09] gegenüber den Datenhaltungssystemen einzelner Informationssysteme, die die sie selbst betreffenden Daten häufig getrennt von anderen Systemen bzw. Anwendungen einer Unternehmung halten, den Vorteil, die Datenbestände dieser Einzelsysteme vereinen zu können. So können sie in geeigneter, standardisierter Form zur weiteren Verwendung, z.b. zu Analysezwecken, vorgehalten werden. Bauer und Günzel führen an, dass die von Inmon in [Inm96] angegebene Definition, nach der ein Data Warehouse vier verschiedene der Entscheidungsunterstützung dienende Eigenschaften besitzt, nicht optimal ist. So schließe die gegebene Definition zu viele Ansätze aus und sei auch nicht aussagestark genug für eine breite Verwendung. Sie geben daher eine neue Definition wie folgt: Ein Data Warehouse ist eine physische Datenbank, die eine integrierte Sicht auf beliebige Daten zu Analysezwecken ermöglicht. [BG09, S. 8] Die über der Datenbereitstellungsschicht angeordnete Schicht des Ordnungsrahmens behandelt die Informationsgenerierung und Informationsdistribution. Es lassen sich Systeme nennen, die sich, mit dem gemeinsamen Zweck des Erzeugens von Informationen, anhand verschiedener Merkmale unterscheiden lassen. Dazu zählt beispielsweise der Grad, zu dem ein System auf eine Anwendung ausgerichtet ist, die Häufigkeit, mit der es genutzt wird oder die vom Nutzer zur Bedienung dieses Systems verlangten Kompetenzen. Zur Generierung von Informationen kommen Analysesysteme zum Einsatz, mit der Zielsetzung, Daten zu untersuchen, entsprechend des Nutzungskontextes aufzubereiten und anschließend zu präsentieren, um wiederum von ihren Adressaten interpretiert werden zu können. Es erscheint sinnvoll, Anaylsesysteme, die diesen Zweck erfüllen sollen, anhand ihrer funktionalen Ausrichtug zu charakterisieren. Dabei kann eine Unterteilung in 17

26 2. Grundlagen konzeptorientierte Systeme und generische Basissysteme vorgenommen werden. Unter die generischen Basissysteme fallen alle Systeme, die sich als Bestandteil im Sinne einer Einzelanwendung in ein integriertes BI-System einbauen lassen.[kbm10] Einen in diesem Zusammenhang häufig genannten Ansatz stellen die Berichtssysteme dar. Diese tragen den in Abschnitt 2.2 vorgestellten Konzepten und Anforderungen Rechnung. In Abschnitt wird auf einige, das Berichtswesen betreffende, Systeme eingegangen. Die zweite Katgorie der Analysesysteme zeichnet sich durch die Orientierung entsprechender Systeme an betriebswirtschaftlichen Konzepten, etwa den von Managern durchgeführten Planungsprozessen, aus. Systeme dieser Ausprägung können somit Anwendungen der generischen Basissysteme enthalten und bilden, jeweils auf die Unternehmung ausgerichtet, umfangreiche Verfahren in Form von Standardlösungen ab.[kbm10] Kemper et al. führen als Beispiel eines solchen Systems das von Kaplan und Norton in [KN92] vorgestellte Konzept der Balanced Scorecard (BSC) auf. Ein weiterer Bestandteil der zweiten Schicht des BI-Frameworks umfasst diejenigen Systeme, die sicherstellen sollen, dass erzeugte Informationen einerseits weiteren Empfängergruppen zur Verfügung gestellt werden können, aber auch Analyseergebnisse an anderer Stelle für weitere Verarbeitungsschritte wieder aufgegriffen werden können [KBM10]. Die oberste Architekturschicht beschreibt Systeme, die für den Informationszugriff verantwortlich sind. Mit Hilfe grafischer Benutzeroberflächen soll es dem Nutzer eines Business Intelligence Systems ermöglicht werden, die einzelnen Systemwerkzeuge in evtl. personalisierter Form zu nutzen, was oft über Portale realisiert wird.[kbm10] Im Abschnitt wird auf das Konzept eingegangen Nutzergruppen von BI-Anwendungen Wie bereits zuvor an verschiedenen Stellen angesprochen, gibt es unterschiedliche Personengruppen, die entscheidungsunterstützende Systeme einsetzen. Im Folgenden wird näher auf diese eingegangen. Die potentiellen Nutzer von BI-Anwendungen setzen sich aus dem kompletten Führungssystem zusammen. Dabei unterscheiden Kemper et. al. in [KBM10] anhand der jeweiligen Hierarchieebene der betreffenden Gruppe. Zunächst wird das Top Management benannt, dessen Angehörige strategische Entscheidungen treffen, welche ausschließlich auf der hohen Hierarchieebene getroffen werden können, der sie angehören. Weiter zählen Mitglieder des Middle Management zum Nutzerkreis. Diese setzen Entscheidungen der übergeordneten Hierarchieebene um und führen entscheidungsvorbereitende Aufgaben durch. Angehörige des Lower Management sind unmittelbar über dem ausführenden Bereich eines Unternehmens, den sie beeinflussen, angesiedelt. Zusätzlich können noch weitere Gruppen von Mitarbeitern, etwa Angehörige des Controllings, an entscheidungsvorbereitenden Maßnahmen beteiligt sein und auf BI-Anwendungen zurückgreifen.[kbm10] Gluchowski, Gabriel und Dittmar identifizieren in [GGD08] (aufbauend auf Ausführungen von Chamoni, Gluchowski und Hahne in [CGH05]) typische Nutzerrollen, die anhand der jeweiligen Nutzungsart von BI-Systemen unterschieden werden können: Angehörige der Gruppe der Informationskonsumenten nutzen an anderer Stelle vorbereitete Informationen. Häufig werden dazu Standardberichte genutzt, die, in entsprechender Frequenz, einem oder mehreren Adressaten zur Verfügung gestellt werden. Die 18

27 2.5. Anwendungen zur Entscheidungsunterstützung Empfänger nutzen die dargestellten Informationen ohne weitergehende Änderungen an ihnen, oder Analysen anhand dieser durchzuführen. Die Informationen sollten sich durch Einsatz unterschiedlicher Medien darstellen lassen, was verschiedene Arten von Endgeräten einschließt. Dabei soll die Verteilung der Informationen auf einem Berechtigungsund Rollenkonzept basieren. Eine weitere Nutzergruppe, die der Analytiker, bedient sich der in der Anwendung verfügbaren Mittel zur tiefergehenden Untersuchung der zur Verfügung stehenden Daten. Diese können Funktionalitäten zur Navigation durch die Datenbasis beinhalten, aber auch in Form von Modellen und Methoden vorliegen, die jeweils die Möglichkeiten zur weiteren Untersuchung vorgeben. Analytiker wenden die vorgegebenen Methoden, die beispielsweise mathematische Standardverfahren enthalten, an, entwickeln aber keine gänzlich neuen Methoden oder Modelle. Durch die Nutzung der bereitgestellten Präsentationsformen bereiten Angehörige dieser Nutzergruppe Informationen auf, um sie anschließend verschiedenen Empfängern in jeweils interpretierbarer Form zur Verfügung stellen zu können. Die letzte vorgestellte Nutzergruppe besteht aus Spezialisten, die sowohl Methoden als auch die die entsprechenden Funktionalitäten zur Verfügung stellenden (Software-)Anwendungen nutzen. Sie führen oft anspruchsvolle Analysen anhand entsprechender Modelle unter Nutzung von geeigneten Methoden durch, entwickeln aber bei Bedarf auch neue Verfahren. Diese können im Anschluss anderen Nutzern zur Verfügung gestellt werden. Auch diese Nutzergruppe hat das Ziel, entscheidungsrelevante Informationen, die sich aus den durchgeführten Analysen ergeben, in verwertbarer Form an die jeweiligen Empfänger weiterzugeben.[ggd08] 2.5. Anwendungen zur Entscheidungsunterstützung Im Folgenden sollen Anwendungsformen, die in Teilen auf den in den Abschnitten 2.1 bis 2.4 vorgestellten Konzepten beruhen, vorgestellt werden. Im Hinblick auf die Aufgabenstellung dieser Arbeit wird dabei zunächst näher auf Anwendungsformen, die das (betriebliche) Berichtswesen unterstützen, eingegangen. Im Anschluss wird das im Rahmen der Business Intelligence häufig erwähnte Konzept des Dashboards vorgestellt. Die Präsentation des Begriffs des Business Intelligence Portals, was beispielsweise auch die Integration einzelner Funktionalitäten der im Folgenden vorgestellten Konzepte zulässt, bildet den Abschluss. Im zweiten Teil dieses Abschnittes wird ein sich auf dem Markt befindliches Produkt aus dem Bereich Business Intelligence angesprochen Anwendungsformen: Reporting, Dashboards und Portale Gluchowski stellt in [Glu10] einzelne Kategorien von (betrieblichen) Berichtswerkzeugen vor, die im Kontext der heute häufig eingesetzten Data Warehouses genannt werden. Dabei werden zunächst die beiden klassischen Konzepte der Abfragegeneratoren und Berichtsgeneratoren angesprochen. Erstere repräsentieren einfache Werkzeuge, anhand derer Abfragen auf vorhandenen, relationalen Datenbanken durchgeführt werden können. Dabei muss der Anwender nicht notwendigerweise eine Datenbanksprache beherrschen, sondern wird in die Lage versetzt, auch komplexe Abfragen, anhand speziell 19

28 2. Grundlagen zugeschnittener Elemente einer grafischen Benutzeroberfläche, zu generieren. Abfragegeneratoren eignen sich somit beispielsweise zur Erzeugung von Berichten, oft mit Hilfe zusätzlicher Tools, im Rahmen des Ad-hoc-Reporting.[Glu10] Das Konzept des Ad-hoc-Reporting wird in [Ban09] vorgestellt und kann als Erweiterung des Standardberichtswesens gesehen werden. Dem Anwender, der nicht notwendigerweise über ein ausgeprägtes (technisches) Fachwissen zur Bedienung der entsprechenden Reportingkomponente verfügen muss, da er durch entsprechende Funktionalitäten dieser Unterstützung erfährt, können zwei verschiedene Rollen zukommen. Es kann sich dabei um einen Reportersteller, der den Bericht für einen bestimmten Adressaten generiert aber auch um den Reportnutzer selbst handeln, der den jeweiligen Bericht selbstständig erstellt und diesen dann evtl. interaktiv nutzt.[ban09] Als weitere Form des Berichtswerkzeuges wird in [Glu10] die Klasse der Berichtsgeneratoren angeführt. Diese können ähnliche Funktionalitäten bieten wie die reinen Abfragegeneratoren. Zusätzlich verfügen Anwender von Werkzeugen dieser Kategorie noch über Möglichkeiten, Berichte inhaltlich, beispielsweise über die Einbindung von Metadaten, sowie optisch, durch Nutzung grafischer Formatierungen, anzureichern. Als Hilfestellung bei der Auswahl der Daten und jeweiligen Darstellungsformen, sowie der Gestaltung des Berichts in Hinsicht auf dessen Aufbau, werden dem Nutzer häufig Assistenten innerhalb des jeweiligen Berichtsgenerators zur Seite gestellt. Zusätzlich besteht häufig die Möglichkeit, über die reine Datenabfrage hinaus, weitere Verarbeitungsschritte, wie beispielsweise statistische Verfahren, auf Daten der Datenbasis bzw. auf zuvor, auf diesem Weg erzeugte, Informationen anzuwenden. Berichtsgeneratoren kommen häufig in Form von lokal ausgeführten Anwendungsprogrammen zum Einsatz, was in der klassisch dezentralen Ausrichtung des Berichtswesens begründet liegt, und für den Aufbau eines unternehmensweiten, einheitlichen Berichtswesens erhebliche Nachteile aufweisen kann.[glu10] Der neuere Ansatz des Enterprise Reportings ist laut Gluchowski in [Glu10] stärker auf die unternehmensumspannende Befriedigung des Informationsbedarfs unterschiedlicher Empfänger ausgerichtet. So wird in diesem Fall nicht der gesamte Funktionsumfang für die Berichtserstellung von der jeweiligen Einzelplatzanwendung bereitgestellt. Im Gegensatz zu den zuvor vorgestellten Generatorenkonzepten sieht dieser Ansatz eine zusätzliche (serverseitige) Reportingkomponente vor, die Aufgaben, wie beispielsweise die Vorformatierung von zu erstellenden Berichten vorsieht. Auch besteht so die Möglichkeit, Reports an zentraler Stelle abzulegen und für die Betrachtung oder das Editieren durch verschiedene Personen vorzuhalten. Der Anwender nutzt dabei zur Erstellung wie auch zur Anzeige von Berichten häufig einen Webbrowser. Dabei kommen Internettechnologien wie beispielsweise HTML 2 zur Darstellung entsprechender Berichte zum Einsatz. Dies kann theoretisch die Nutzung von Reports über verschiedene Geräteklassen hinweg und die Überführung in andere, teilweise statische und evtl. mit anderen Tools weiterverarbeitbare Formate erleichtern. Zugang zu den mit Hilfe des Systems erzeugten und von diesem vorgehaltenen Berichten kann durch ein Abonemmentmodell, das auf der Zuordnung verschiedener Nutzertypen zu definierten Rollen und damit verbundenen Zugriffsberechtigungen beruht, die auch auf Datenbank- bzw. Betriebssystemebene realisiert, oder diese Systembereiche umfassen können, eingeschränkt werden. Vorgänge, die besonders viel Last erzeugen, lassen sich über Komponenten, die diese Rechenprozesse auf Zeiten verteilen, in denen das System weniger stark frequentiert wird, bewältigen. Auch bieten heutige Berichtsanwendungen häufig die Möglichkeit der Versionierung von 2 Hypertext Markup Language 20

29 2.5. Anwendungen zur Entscheidungsunterstützung Berichten. Damit können unterschiedliche Ausprägungen eines Berichtes zu unterschiedlichen Zeitpunkten dauerhaft vorgehalten werden.[glu10] Weiter zählt Gluchowski die sogenannten Performance Dashboards zu den im Rahmen des betrieblichen Reportings genutzten Anwendungen. Demnach grenzen sich diese, genau wie die nachfolgend vorgestellten Business Intelligence Portale, schon hinsichtlich der gewählen Form, in der Informationen dargestellt werden, von den zuvor vogestellten Ansätzen ab. So ist die Zielsetzung hier nicht die Gestaltung eines Berichtes, der besonders gut anhand klassischer Papierformate dargestellt werden kann.[glu10] In [Few06, S. 34] wird die folgende Definition gegeben: A Dashboard is a visual display of the most important information needed to achieve one or more objectives; consolidated and arranged on a single screen so the information can be monitored at a glance. Weiter stellt Few einige wichtige Eigenschaften von Dashboards heraus. So sollen relevante Informationen, wenn möglich auf einer einzigen Bildschirmseite und in möglichst auf die wesentlichen Fakten beschränkter, kompakter Form, dargestellt werden. Hinsichtlich der Art der Informationsdarstellung sind die Performance Dashboards auf eine problemlose und hohe Verständlichkeit ausgelegt. Dazu liegt der Fokus auf grafischen Datenvisualisierungsformen, wie beispielsweise Diagrammen oder Tabellen. Aber auch bekannten (analogen) Messinstrumenten entliehene Konzepte, wie Tachometerdarstellungen, können zum Einsatz kommen. Wichtig ist auch die spezifische Ausrichtung, der mit dem Dashboard darzustellenden Informationen. So kann eine Orientierung an der jeweiligen Zielgruppe oder Funktion sinnvoll sein. Es sollen diejenigen Informationen dargestellt werden, die zur Durchführung einer bestimmten Aufgabe benötigt werden. Die Detaillierung dieser Informationen muss dabei nicht notwendigerweise soweit gehen, dass durch ihre Betrachtung in der Dashboarddarstellung das jeweilige Problem direkt lösbar wäre. Der Nutzer sollte auf einfache Weise in der Lage sein, wichtige Informationen erkennen zu können, um dann möglichst einfach weitere Informationen zu einem Thema, etwa durch Wechsel in eine andere Sicht, beziehen zu können.[few06] Das letzte von Gluchowski in [Glu10] im Kontext der Berichtswerkzeuge angesprochene Konzept ist das des Business Intelligence Portals. Ein entscheidendes Merkmal eines Portals ist dabei die Tatsache, dass verschiedene Inhalte und Funktionalitäten, also beispielsweise auch spezifische Anwendungen, unter einem gemeinsamen Dach vereint werden[glu10]. Kemper führt in [KBM10] weiter aus, das das Portal im Rahmen des Informationszugriffs eines BI-Systems als Schnittstelle zum Manager fungiert. Dieses hat die Aufgabe, die Komplexität einzelner Systembestandteile durch geschickte Integration zu verdecken und zusätzlich Möglichkeiten anzubieten, um auf die verschiedenen Ansprüche der einzelnen Nutzer eingehen zu können. Als Voraussetzung für eine Ausrichtung der bereitgestellten Systembestandteile und Informationen an dem jeweiligen Nutzer wird die Unterstützung eines zentralen Logins hervorgehoben. Durch einmalige Anmeldung am System ist der Nutzer in der Lage auf alle, seinem Profil entsprechenden, Bereiche zuzugreifen, ohne sich jeweils neu anmelden zu müssen.[kbm10] Weiter nimmt Kemper eine Einordnung des Portalbegriffs vor. Mit Verweis auf [Dav01] werden verschiedene Portalklassen aufgeführt. Neben den öffentlichen Portalen und den persönlichen Portalen sowie den Unternehmensportalen werden die Enterprise Information Portale (EIP) dargestellt. Unter Bezugnahme auf [ST98] und [Fir03] wird 21

30 2. Grundlagen herausgestellt, dass Enterprise Information Portale auf die Entscheidungsunterstützung abzielen.[kbm10] Heine und Wende zitieren in [HW04] die Definition des Begriffs Enterprise Information Portal aus [ST98] wie folgt: Enterprise Information Portals sind Anwendungen, die es dem Unternehmen ermöglichen, intern und extern gespeicherte Information über eine einzige personalisierbare Schnittstelle den Nutzern zur Unterstützung informierter Entscheidungen zur Verfügung zu stellen. Sie sind eine Zusammenstellung von Software-Anwendungen für Konsolidierung, Management, Analyse und Verteilung von Information innerhalb und außerhalb eines Unternehmens. (Technologien: Business Intelligence, Content Management und Data Warehouse & Mart).([HW04] S. 357 mit Verweis auf [ST98]) Als Unterformen des Enterprise Information Portals existieren Collaboration Portals, die auf die Unterstützung von Teamarbeit zugeschnitten sind, Content Management Portale die Informationen in un- oder semistrukturierter Form vorhalten und Business Intelligence Portale. Oft werden Portale eingesetzt, die Eigenschaften der drei aufgezählten Typen vereinen.[kbm10] Business Intelligence Produkte: Pentaho Es existieren zahllose Anbieter, die sich auf die Entwicklung von fertigen Business Intelligence Softwarelösungen oder Tools zur Erstellung solcher Lösungen spezialisiert haben. Für einen ersten Überblick verweise ich an dieser Stelle auf [Ban10]. Bange gibt dort eine Übersicht über Produkte sowie Anbieter entsprechender Systeme und orientiert sich dabei an den einzelnen in Abschnitt vorgestellten Architekturschichten von BI-Systemen. An dieser Stelle soll stellvertretend für verschiedene Ansätze das Produkt Pentaho 3 vorgestellt werden. Bei Pentaho handelt es sich um eine Softwaresammlung, anhand der spezifische Business Intelligence Anwendungen entwickelt werden können. Es stehen zu diesem Zweck verschiedene Komponenten zur Verfügung. Bei den durch diese angebotenen Funktionalitäten handelt es sich unter anderen um die folgenden 4 ): Möglichkeiten zum (interaktiven) Reporting. Durchführung interaktiver Analysen sowie Visualisierung der Ergebnisse. Erstellung von Dashboards. Datenintegration und Möglichkeiten, der Anbindung von (externen) Datenquellen. Features, die die mobile Nutzung verschiedener Funktionalitäten ermöglichen. Möglichkeiten zu Erstellung von BI-Portalen, die über typische Features wie beispielsweise die Möglichkeit eines zentralen Login verfügen. 3 Siehe hierzu [Pena] 4 Siehe hierzu bspw.: [Pena] 22

31 2.6. Weiterer Kontext der Arbeit Die einzelnen Funktionalitäten lassen sich teils als Standalone-Anwendungen nutzen, es bestehen aber auch Möglichkeiten, einzelne Funktionen in eigene Anwendungen zu integrieren. Ein Beispiel hierfür ist der Pentaho Report Designer. Dabei handelt es sich um eine Desktopanwendung, die die Erzeugung von (statischen) Berichten ermöglicht. Die auf diesem Weg erzeugten Berichte können auf dem Pentaho BI Server bzw. der Pentaho BI-Plattform abgelegt werden. Diese Serverkomponente bietet dabei die Infrastruktur zur Anbindung und Intergration einzelner Anwendungen und Funktionalitäten im Sinne eines BI-Plattform-Ansatzes und somit auch ein Web-Frontend, was die komfortable Bedienung der jeweils umgesetzten Business Intelligence Lösung ermöglicht.[pena][penb] Pentaho basiert auf einem Open-Source-Projekt [Penb]. Neben der frei nutzbaren Open- Source Variante existieren drei unterschiedliche kommerzielle Versionen, wobei letzere sich unter anderem durch einen erweiterten Funktionsumfang und inkludierten Support 5 auszeichnen Weiterer Kontext der Arbeit In diesem Abschnitt sollen weitere, für die Aufgabenstellung dieser Masterarbeit zentrale Konzepte, vorgestellt werden Social Network Analysis Wasserman und Faust definieren die Begrifflichkeit des Sozialen Netzwerkes wie folgt: A social network consists of a finite set or sets of actors and the relation or relashions defined on them. The presence of relational information is a critical and defining feature of a social network. [WF97, S. 20] Ein soziales Netzwerk besteht also im Wesentlichen zunächst aus einer bestimmten Menge von Actors (Akteuren) und der Menge der jeweils definierten Relations (Relationen). Diese beiden Begriffe sollen im Folgenden betrachtet werden. Darüber hinaus werden weitere Konzepte, die im Rahmen der sozialen Netzwerkanalyse eine wichtige Rolle einnehmen, angesprochen. Bei einem Akteur handelt es sich allgemein um eine soziale Entität, die in unterschiedlichen Formen auftreten kann. So kann diese eine einzelne Person aber auch Gruppen von Personen, beispielsweise in Form einer Abteilung eines Unternehmens, oder ein ganzes Land, abbilden.[wf97] Zwischen Akteuren, gleichen wie auch unterschiedlichen Typs, können direkte soziale Verbindungen bestehen. So können durch Akteure eines sozialen Netzwerkes abgebildete Personen beispielsweise miteinander befreundet sein, an gemeinsamen Aktivitäten teilnehmen oder direkt miteinander interagieren. Diese Verknüpfungen von Akteuren werden auch als Relational Ties bezeichnet.[wf97] Wie bereits angesprochen, kann ein einzelner Akteur auch unterschiedlichste Arten von Gruppierungen (von Personen) darstellen. Gruppenstrukturen lassen sich aber auch anhand verschiedener Akteure identifizieren. Bei einer Group (Gruppe) handelt es sich 5 Einen Überblick über die unterschiedlichen Pakete bietet die folgende Resource: assets/pdf/pentaho-ce-vs-ee-com.pdf. 23

32 2. Grundlagen allgemein um eine definierte Menge von Aktueren, die über direkte soziale Verbindungen miteinander verknüpft sind.[wf97] Eine Relation schließlich ist die Menge der direkten sozialen Verknüpungen des gleichen Typs zwischen Akteuren, die einer Gruppe angehören. Relationen beschreiben also Arten von Beziehungen zwischen Mitgliedern von Gruppen.[WF97] So kann beispielsweise festgehalten werden, dass in Organisationen im Allgemeinen eine Kommunikation zwischen Gruppen oder Gruppenmitgliedern stattfindet oder dass hierarchisch bestimmte Abhängigkeitsverhältnisse bestehen. Bei der Betrachtung von konkreter Kommunikation zwischen zwei Akteuren handelt es sich in dem Fall dann um die Relational Ties, also direkten sozialen Verbindungen zwischen diesen beiden. Verschiedene Arten von sozialen Netzwerken können anhand der Art der Akteure und den Beziehungen zwischen diesen beschrieben werden. Anhand des Begriffs Mode wird von Wasserman und Faust in [WF97] (unter Verweis auf [Tuc63], [Kro83] und [ACD87]) eine eindeutige Menge von Akteuren bezeichnet. Demnach handelt es sich bei One-Mode- Netzwerken um Netzwerke, die nur eine Art von Akteuren, wie beispielsweise Personen, beinhalten. Two-Mode-Netzwerke enthalten demnach verschiedene Arten von Akteuren. Ein Beispiel für diesen Netzwerktyp ist etwa ein Netzwerk aus Wissenschaftlern und Arbeitsgruppen, wobei die direkten sozialen Verbindungen zwischen den einzelnen Entitäten dieses Netzwerkes in Form einer ist Mitglied von - und bzw. oder war Mitglied von -Beziehung vorliegen könnte. Eine Sonderform der Two-Mode-Netzwerke ist das sogenannte Affiliation-Netzwerk. Hierbei ist einer der beiden Modes eine Menge von Akteuren, der andere eine Menge von Events (Ereignissen), wobei es sich bei diesen beispielsweise auch um Vereinsmitgliedschaften handeln kann. Vorausgesetzt wird bei diesem Netzwerktyp, dass jeder Akteur mindestens mit einem Ereignis oder einer Mitgliedschaft in Beziehung steht. Ein Beispiel wäre an dieser Stelle eine Menge von Personen, die an verschiedenen Festivitäten teilnehmen. Über die One- und Two-Mode- Netzwerke hinaus existieren auch Netzwerke mit einer höheren Anzahl an Modes.[WF97] Soziale Netzwerke bzw. Daten, auf denen diese beruhen, können anhand verschiedener mathematischer Notationen beschrieben werden. Eine davon ist die Graphentheorie. Ohne an dieser Stelle detailliert auf entsprechende mathematische Definitionen der einzelnen Konzepte des sozialen Netzwerkes einzugehen, kann vereinfachend festgehalten werden, dass in diesem Fall die Knoten eines Graphen die Akteure eines Netzwerkes repräsentieren und die Beziehungen zwischen diesen über Kanten abgebildet werden. Auf den verschiedenen Arten von sozialen Netzwerken können Berechnungen zur Bestimmung unterschiedlicher Maße durchgeführt werden. So können Maße, die das gesamte Netzwerk oder Teile davon, wie etwa Gruppen, betreffen, bestimmt werden, aber auch solche, anhand derer Aussagen über spezifische Eigenschaften einzelner Akteure eines Netzwerkes getroffen werden können. So kann beispielsweise festgestellt werden, wie viele direkte Beziehungen ein Akteur zu anderen Akteuren eines Netzwerkes unterhält. Diese Maßzahl wird als Degree des jeweiligen Knotens des das Netzwerk repräsentierenden Graphen bezeichnet. Dieses Maß beschreibt die Anzahl von Kanten, die mit dem betrachteten Knoten verbunden sind. Ein wichtiges Maß im Rahmen der sozialen Netzwerkanalyse ist die Centrality (Zentralität), das beispielsweise die Wichtigkeit eines bestimmten Akteurs für das betrachtete Netzwerk herausstellen kann. Es existieren verschiedene Arten von Zentralität, wovon eine einfache Variante die Degree Centrality ist. Diese beschreibt den Grad der Aktivität eines Akteurs, wobei es sich hierbei um eine Netzwerkanalysebasierte Interpretation des Begriffs des Degree handelt. Der Akteur mit der höchsten Degree Centrality ist derjenige Knoten, der die meisten Kanten zu anderen Knoten des 24

33 2.6. Weiterer Kontext der Arbeit jeweils betrachteten Graphen hat.[wf97] SISOB Project Das SISOB 6 -Projekt ist ein europäisches Gemeinschaftsforschungsprojekt im Rahmen des Seventh Framework Programme (FP7) 7 der Europäischen Union [SISb]. Zielsetzung des SISOB-Projekts ist es, Möglichkeiten zu finden, um den sozialen Einfluss von Forschung messen und vorhersagen zu können. Dabei soll insbesondere untersucht werden, auf welche Weise bzw. auf welchen Wegen sich Forschungsergebnisse verbreiten bzw. diese von unterschiedlichen Institutionen und Akteuren aufgenommen und genutzt werden. Die Grundannahme im Rahmen des SISOB-Projekts ist dabei, dass zwischen den Akteuren und Institutionen, die Wissen in Form von Forschungsergebnissen schaffen und denjenigen, die dieses Wissen aufgreifen, also beispielsweise Journalisten, Entscheidungsträger aus Industrie und Politik oder Konsumenten, vielfältige soziale Verbindungen existieren.[sisb] Konkret sollen hierzu anhand von Fallstudien drei unterschiedliche Aspekte des Teilens von Wissen untersucht werden, nämlich Researcher Mobility, Knowledge Sharing und Peer Reviewing. Researcher Mobility beschäftigt sich mit der Tatsache, dass zwischen einzelnen Forschungseinrichtungen ein Austausch von und unter Wissenschaftlern stattfindet. Dieser Austausch kann in Form von kurzen Austauschprogrammen oder Besuchen stattfinden, aber auch durch Jobwechsel hervorgerufen werden. Allgemein kann festgehalten werden, dass eine hohe Mobilität zwischen Forschern und jeweiligem Wissen besteht und sich somit entsprechende Netzwerke identifizieren lassen. Weiter kann Wissen auf vielen unterschiedlichen Wegen weitergetragen werden (Knowledge Sharing). Dies kann in Form von wissenschaftlichen Veröffentlichungen, die von anderen Forschern aufgegriffen werden, aber auch über klassische Medien, wie beispielsweise (Fach-)Zeitschriften oder das Fernsehen, welche sich an eine breitere Zielgruppe richten, geschehen. Somit lassen sich Netzwerke herausstellen, deren Akteure aus Forschern und anderen Mitgliedern der Gesellschaft bestehen können. Darüber hinaus sollen die aus dem Prozess des Peer-Reviewing entstehenden Netzwerken zwischen Reviewern und Autoren betrachtet werden.[sisb] Im Rahmen des SISOB-Projektes sollen wichtige Indikatoren und Methoden gefunden und entsprechende Werkzeuge zur Erfassung und Untersuchung dieser sozialen Netzwerke entwickelt werden.[sisb] Analytics Workbench Im Zuge des SISOB Projekts wurde eine sogenannte Analytics Workbench entwickelt. Diese richtet sich an Analysten, die unterschiedliche Methoden im Rahmen von sozialen Netzwerkanalysen durchführen wollen. Der Aufbau sowie die Funktionsweise der Workbench richtet sich dabei nach dem Pipeline Architekturmuster [Sha96]. Gemäß diesem Ansatz der Pipes und Filters werden, mit Hilfe von sogenannten Filtern und den diese 6 SISOB: An Observatorium for Science in Society based of Social Models 7 Siehe hierzu 25

34 2. Grundlagen verbindenden Pipes, Datenströme verarbeitet. Die Filter bilden in diesem Fall einzelne Datenverarbeitungsschritte ab, während die Pipes diese einzelnen Funktionseinheiten miteinander verbinden. Ein Filter verarbeitet die jeweils an einem oder mehreren Dateneingängen ankommenden Daten und gibt das Ergebnis an einem oder mehreren Ausgängen aus. Eine Pipe stellt die Verbindung dieses Ausgangs zum Dateneingang des nächsten Filters, also dem jeweils nachgelagerten Datenverarbeitungsschritt, her.[sha96] Mit Hilfe der über die einzelnen Filter der Workbench abgebildeten Funktionalitäten können dabei zusammenhängende Arbeitsabläufe (Workflows) konstruiert werden. Die Abbildung 2.3 zeigt den, zum Beginn dieser Arbeit in der Version 2.1 vorliegenden, Prototypen der SISOB Workbench. Die Oberfläche lässt sich in vier Bereiche unterteilen. Über die Buttons der im oberen Bereich angesiedelten Funktionsleiste werden die unterschiedlichen Grundfunktionalitäten der Analytics Workbench zur Verfügung gestellt. So können neue Workflows erstellt, geladen oder gespeichert, aber auch exportiert werden. Im Rahmen des Speicherns eines Workflows kann für diesen ein Name sowie eine Beschreibung angegeben werden. Auch können neue Datensätze, zum Zwecke der Verfügbarkeit durch die entsprechenden Filter, hochgeladen werden. Schließlich können Workflows ausgeführt werden. Die unterschiedlichen Filter der Analytics Workbench sind auf der linken Seite des Abbildung 2.3.: SISOB Workbench Prototype 2.1 Benutzerinterfaces untergebracht. Die durch sie abgebildeten Methoden sind in acht Kategorien unterteilt. Im Einzelnen handelt es sich dabei um die folgenden Kategorien: Input Filter: Stellen Daten aus der Datenbasis dem jeweils nachfolgenden Filter des Workflows zur Verfügung. Tools: Stellen verschiedene Funktionalitäten, wie beispielsweise den Duplicator zur Aufspaltung einer Pipe in zwei identische Datenströme, zur Verfügung. Data Extractor: Enthalten Methoden, die zum Extrahieren von Daten aus bestimmten Arten von Quellen genutzt werden können. 26

35 2.6. Weiterer Kontext der Arbeit Data Converter: Ermöglichen die Konvertierung der jeweils genutzten Ausgangsdaten bzw. Zwischenergebnisse in das von der jeweils genutzten Komponente benötigte Format. Analysis Filter: Bilden einige Methoden der sozialen Netzwerkanalyse, wie beispielsweise Möglichkeiten, Zentralitätsmaße zu bestimmen, ab. Graph Visualizations: Ermöglichen die Visualisierung von Graphdaten in diversen Formen. Statistical Visualization Enthalten Methoden zur Visualisierung statistischer Daten. Modeling Filter: Ermöglichen die Generierung von Netzwerkstrukturen, beispielsweise aus unstrukturierten Daten. Per Drag & Drop können einzelne Filter in den, im mittleren Bereich der Benutzeroberfläche der Analytics Workbench angesiedelten und einen großen Teil dieser ausfüllenden, Workflow-Bereich gezogen werden. Zwischen den jeweils in den Arbeitsbereich gezogenen Filtern, können anschließend Pipes gezogen werden. So entsteht ein gerichteter Graph aus Knoten (Filter) und diese verbindenden Kanten (Pipes). Die einzelnen Filter lassen sich, je nach Ausprägung, parametrisieren. Im rechten Bereich des Benutzerinterfaces befindet sich ein Bereich, in dem Statusmeldungen angezeigt werden können. So wird, nach Start eines oder mehrerer Workflows, angezeigt, ob ein oder mehrere Workflows zu diesem Zeitpunkt ausgeführt werden. Nach Abarbeitung der in den jeweiligen Workflows abgebildeten einzelnen Arbeitsschritte wird das Ergebnis dieser ebenfalls im Statusbereich der Benutzeroberfläche angezeigt. Einzelne Ergebnisse lassen sich anschließend über den jeweils angezeigten Link erreichen. Hierbei wird ein neues Browserfenster geöffnet, welches den weiteren Umgang mit den Ergebnisinformationen, in Abhängigkeit des Ergebnisstyps und der jeweils genutzten Visualisierungsform, bestimmt durch den jeweils verwendeten Filter, ermöglicht. Abbildung 2.4 zeigt exemplarisch das in textueller, strukturierter Form und als Download-Link vorliegende Ergebnis einer durchgeführten Analyse. In Abbildung 2.5 wird auf eine Graphvisualisierung zur Präsentation eines Analyseergebnisses zurückgegriffen. Dabei werden zusätzliche Informationen angezeigt und Funktionalitäten angeboten, die das weitere Explorieren des Graphen ermöglichen. So ist es in dem hier dargestellten Fall beispielsweise unter anderem möglich, den Graph näher heran oder weiter heraus zu zoomen sowie einzelne Knoten anhand der jeweiligen Beschriftung mit Hilfe der Suchfunktionalität zu suchen. Es existieren weitere Arten um Informationen aus unterschiedlichen Workflows zu visualisieren. Abbildung 2.4.: SISOB Workbench - Ergebnis als Downloadlink 27

36 2. Grundlagen Abbildung 2.5.: SISOB Workbench - Ergebnis als Graphvisualisierung Die Analytics Workbench wurde mit Hilfe der auf dem YUI 2 Framework8 basierenden Javascript Bibliothek WireIt 9 entwickelt und la sst sich somit als Webapplikation im Browser ausfu hren. Sie bildet das Frontend des Analysesystems. Die u ber Filter abstrahierten Funktionalita ten bilden einzelne Software-Agenten des der Workbench zugrundeliegenden Multi-Agenten-Systems ab. Dieses nutzt die im Abschnitt vorgestellten SQLSpaces zu Zwecken des Datenaustausches sowie unterschiedliche Programmiersprachen und Tools fu r die Implementierung der einzelnen Agenten. Die einzelnen Filter sind mit Hilfe einer JSON10 -Notation beschrieben. Eine Filterbeschreibung entha lt jeweils Informationen zu den einzelnen Ein- und Ausga ngen, den enthaltenen Filterfeldern sowie deren Typ und evtl. auswa hlbare Parameter. Zusa tzlich werden die Beschriftungen der einzelnen Filterteile in der Filterbeschreibung festgehalten. Zusammen mit der Pipes & Filters Darstellung der Workflows bilden die Filterbeschreibungen eine visuelle Sprache. Die Abbildung 2.6 zeigt die Systemarchitektur der Analytics Workbench. Als Clientkomponente u bernimmt das Frontend die Funktion der Darstellung der Benutzeroberfla che. Auf Serverseite befinden sich die Komponenten SQLSpaces, die einzelnen Agenten, das Ergebnis-Repository sowie der hier aus Gru nden der U bersichtlichkeit nicht dargestellte Webserver, der das Frontend zur Verfu gung stellt. Das Frontend steht in direkter Verbindung zu den SQLSpaces und hat dabei lesenden und schreibenden Zugriff. Zusa tzlich ko nnen Events direkt auf den SQLSpaces registriert werden, wobei im Falle der Auslo sung dieser u ber die direkte Verbindung das Frontend benachrichtigt werden kann. Die einzelnen Agenten kommunizieren ebenfalls direkt mit den SQLSpaces. Das Ergebnis-Repository stellt den auf dem Server zur Verfu gung stehenden Bereich dar, in dem einzelne Ergebnisse von durchgefu hrten Analysen, gespeichert werden. Diese Ergebnisse werden dabei vom jeweils zusta ndigen Agenten im Rahmen einer Analyse in einer Weise abgelegt, die eine eindeutige Zuordnung zwischen Analyse und Ergebnis 8 Siehe hierzu Siehe hierzu 10 JavaScript Object Notation 9 28

37 2.7. Eingesetzte Technologien ermöglicht. Über das Frontend können die Ergebnisse (unter Einbeziehung des Webservers) dem Nutzer zur Verfügung gestellt werden. Abbildung 2.6.: SISOB Workbench - Systemarchitektur 2.7. Eingesetzte Technologien Im Folgenden sollen einige wichtige Technologien vorgestellt werden, die eine zentrale Rolle bei der Konzeption und Implementierung der im Rahmen dieser Masterarbeit zu entwickelnden Webapplikation einnehmen SQLSpaces SQLSpaces sind eine an der Universität Duisburg-Essen entwickelte Implementierung des Tuple Spaces Konzepts [CA][GWEH07]. Dieses wurde 1985 von Gelernter in [Gel85] vorgestellt und orientiert sich an der in [EHLR80] vorgestellten Blackboard-Architektur. Zielsetzung des Tuple Space Konzeptes ist es, mehreren Prozessen zur gleichen Zeit, unabhängig voneinander Zugriff auf einen gemeinsamen Tuple Space zu gewähren. Dieser gemeinsame Ort des Nachrichtenaustausches wird durch einen Server bereitgestellt, auf den alle beteiligten Prozesse Zugriff haben. Der Tuple Space kann dabei unterschiedliche Arten von Daten-Tuples aufnehmen und somit allen beteiligten Prozessen zur Verfügung stellen. Zum Zwecke des Nachrichtenaustausches stehen den Prozessen verschiedene Operationen zu Verfügung. Die Operation out() ermöglicht es einem Prozess, Tuples in den Tuple Space zu schreiben. Ein oder mehrere anderere Prozesse können diese anschließend entweder per read() lesen, wobei die entsprechenden Tuples nach dem Auslesen im Tuple Space verbleiben und somit anderen Prozessen weiterhin zum Abruf bereit stehen, oder per out() aus dem Tuple Space entfernen, wobei gleichzeitig lesender Zugriff auf diese Tuples besteht. Zur Ausführung der einzelnen, unterschiedliche Tuples im Tuple Space adressierenden Operationen wird jeweils die den Tupletyp identifizierende Tuplestruktur genutzt. Diese setzt sich aus Parametern, die mit tatsächlichen Werten belegt sind und / oder formellen Parametern zusammen.[gel85] 29

38 2. Grundlagen Eine neuere Implementierung des Tuple Spaces Ansatzes sind beispielsweise die JavaSpaces. Diese bieten neben konzeptuellen Änderungen, neue Funktionen, wie ewta die Möglichkeit für Clients, sich beim Server für bestimmte Events registrieren zu können um beim Eintreten eines Ereignisses über dieses informiert zu werden. Auch bieten die JavaSpaces die Möglichkeit, mehrere unabhängig von einander nutzbare Tuple Spaces auf einem Server zu verwalten.[ora] Die SQLSpaces bieten viele der Funktionalitäten, die in anderen Implementierungen des Tuple Spaces Ansatzes verfügbar sind, stellen gleichzeitig aber weitere Features zur Verfügung. Dazu gehören Möglichkeiten, Versionierung einzusetzen, Wildcards für die Definition von Tuple-Templates zu nutzen, aber auch eine verschlüsselte Verbindung für den Datenaustausch aufzubauen. Die SQLSpaces basieren dabei auf einer relationalen Datenbank. Es stehen Clients für verschiedene Programmiersprachen, darunter Java, JavaScript und Prolog, zur Verfügung, was reichhaltige Einsatzszenarien, unter Einbeziehung der unterschiedlichsten Clienttypen, ermöglicht.[ca] Node.js Im Gegensatz zu klassischen Ansätzen zur Entwicklung von Web-Anwendungen, bei denen häufig unterschiedliche Programmiersprachen wie beispielsweise clientseitig JavaScript und auf Seiten des Servers PHP oder Java zum Einsatz kommen, bietet Node.js 11 einen neuen Ansatz. Bei Node.js handelt es sich um ein auf der Google V8 JavaScript Runtime 12 basierendes Framework, das eine möglichst einfache Entwicklung von Webanwendungen ermöglichen soll, indem nicht nur clientseitig, sondern auch serverseitig mit JavaScript gearbeitet werden kann.[joy] Der Node.js Ansatz legt den Fokus unter anderem auf eine hohe Performance und einfache Skalierbarkeit. Heutige Webanwendungen müssen mit einer eventuell hohen Anzahl von Nutzern gleichzeitig zurecht kommen, dabei aber möglichst schnell auf die jeweiligen Nutzeranfragen reagieren können. Um diesen Ansprüchen gerecht werden zu können, wird neben der Tatsache, dass es sich bei V8 um eine hochperformante JavaScript Engine handelt, auf das Konzept des Asynchronous non-blocking-i/o 13 gesetzt. Dabei werden die oft zeitaufwendigen I/O-Operationen, wie beispielsweise das Lesen aus einer Datenbank oder das Schreiben auf das Dateisystem, zwar gestartet, aber bis zur Beendigung der Ausführung nicht auf diese gewartet. Stattdessen können in der Zwischenzeit weitere Anfragen bearbeitet werden. Ist eine zuvor gestartete I/O-Operation beendet, so wird per Callback über diesen Umstand informiert und es kann entsprechend darauf reagiert werden. Node.js wird dabei in einem einzelnen Thread ausgeführt, was gegenüber klassischen Ansätzen, in denen für jede Anfrage ein neuer Thread genutzt wird und was wiederum viel Overhead u.a. auf Seiten der Speicher- Prozessorverwaltung bedeuten kann, den Vorteil hat, dass ein mit Node.js implementierter Server sehr viele gleichzeitige Anfragen bewältigen kann.[rod12] Node.js bietet die Möglichkeit, den Umfang der zur Verfügung stehenden Funktionalitäten durch die Verwendung sogenannter Module zu erweitern. Einige Module, die beispielsweise für die Bereitstellung grundlegender Serveraufgaben benötigte Funktionalitäten bereitstellen, wie die Module http oder url, werden bereits mit der Standard- 11 Siehe hierzu [Joy]. 12 Siehe hierzu 13 Siehe hierzu bspw. dgr-lnxw02ausingpoisixaioapi. 30

39 2.7. Eingesetzte Technologien installation von Node.js mitgeliefert. Darüber hinaus steht eine große Zahl an extern bereitgestellten Modulen zur Auswahl bereit, was einen flexiblen Einsatz von Node.js in unterschiedlichen Szenarien ermöglicht. Diese Module können, neben der Möglichkeit zur manuellen Installation, bequem über den Node.js Package Manager (npm) 14 bezogen werden.[rod12] Einen wichtigen Beitrag im Rahmen der Entwicklung von echtzeitfähigen [Rod12, S. VII] Webanwendungen leistet Node.js durch die Tatsache, dass die Nutzung von Websockets ermöglicht wird.[rod12] Im folgenden Abschnitt wird auf diesen Umstand eingegangen Websockets und Socket.IO Einfache Webseiten, die dem Besucher lediglich (statische) Informationen zur Verfügung stellen, tun dies in einer vom Nutzer initiierten Weise. In diesem Fall fragt der Besucher gezielt eine bestimmte Information vom Server an. Dabei kann es sich beispielsweise um das Aufrufen einer kompletten Webseite handeln. Der Server nutzt die vom Browser des Nutzers aufgebaute Verbindung um die jeweilige Antwort zu senden und baut diese im Anschluss ab. Eine weitere Einflussnahme auf die jeweils angezeigte HTML-Seite von Seiten des Servers ist in diesem Szenario nicht vorgesehen. Dieser Umstand ist unter anderem für Webseiten, die dynamischen Inhalt darstellen sollen, von Nachteil. Eine Web-Applikation, die auch das Nachladen von zusätzlichen Informationen in bereits geladene Seiten vorsieht, ließe sich mit Hilfe des zuvor angesprochenen Ansatzes nicht realisieren. Die durch den Nutzer, unter Verwendung entsprechender Auswahlmöglichkeiten auf der jeweiligen Website angefragten Inhalte, könnten nicht ohne ein vollständiges Neuladen der Webseite innerhalb dieser dargestellt werden. Ein weiterer Nachteil ergibt sich aus der Tatsache, dass der Server, beispielsweise nach Durchführung einer evtl. zeitaufwändigen Analyse, den Nutzer, der mittlerweile zu einem anderen Punkt der Webanwendung navigiert sein kann, nicht über diesen Umstand informieren könnte. Der häufig eingesetzte AJAX 15 Ansatz entschärft diese Problematik nur in Teilen. Es wird das dynamische Nachladen von Inhalten in Webseiten ermöglicht, ohne diese komplett neu laden zu müssen. Über neue, serverseitige Entwicklungen kann der jeweilige Client nicht ohne weiteres informiert werden, da keine persistente, bidirektionale Verbindung zwischen Server und Client gehalten wird. In diesem Fall muss der Client aktiv auf ein Ergebnis warten, d.h. er muss in regelmäßigen Abständen durch sogenanntes Polling Anfragen an den jeweiligen Server stellen. Mit Hilfe des WebSocket-Protokolls 16 können die zuvor beschriebenen Problematiken umgangen werden, indem eine beständige, bidirektionale Verbindung zwischen Client und Server ermöglicht wird. Beim Websockets Ansatz handelt es sich allerdings um einen relativ neuen Standard, der im Rahmen von HTML5 vorgesehen ist. Insbesondere viele ältere Browser bieten keine Unterstützung von Websockets. Laut [Moz] unterstützt der Browser Chrome ab Version 16, Firefox ab Version 11.0, Internet Explorer ab Version 10 und Safari ab Version 6.0 den Websocket Standard nach RFC Somit muss unter Umständen auf andere Technologien oder Methoden zurückgegriffen werden. 14 Eine Übersicht über npm und verfügbare Module bietet die Webseite 15 Asynchronous JavaScript and XML 16 Siehe hierzu und 31

40 2. Grundlagen An diesem Punkt setzt das für Node.js erhältliche Modul Socket.IO 17 an. Es ist auf eine größtmögliche Browserkompatibilität ausgelegt. Dabei werden, wenn verfügbar, Web- Sockets genutzt und im Falle, dass der genutzte Browser diesen Standard nicht unterstützt, auf alternative Methoden oder Technologien, wie beispielsweise AJAX long polling oder Adobe Flash Socket 18, zurückgegriffen. In beiden Fällen kann die gleiche, durch Socket.IO bereitgestellte API 19 verwendet werden.[soc] 17 Siehe hierzu [Soc]. 18 Siehe hierzu bspw. flash/net/socket.html. 19 Application Programming Interface 32

41 3. Ansatz In diesem Kapitel soll zunächst ein Szenario beschrieben werden, das einen fiktiven Fall der Entscheidungsfindung im Rahmen des in Kapitel vorgestellten SISOB Projektes aufzeigt. Dabei soll gleichzeitig auf die in der Aufgabenstellung dieser Masterarbeit angegebenen Anforderungen eingegangen werden. Es werden somit verschiedene Akteure und deren Rollen vor dem Hintergrund einer Problemstellung, die mit Hilfe geeigneter Methoden der sozialen Netzwerkanalyse betrachtet werden und deren Ergebnisse zur Problemlösung beitragen sollen, vorgestellt. In einem ersten Schritt soll dabei nicht im Detail auf die einzelnen zur Verfügung stehenden computergestützten Hilfsmittel eingegangen werden, sondern das Szenario rein methoden- und ergebnisorientiert beschrieben werden. Im Anschluss daran wird aufgezeigt, wie die in Kapitel vorgestellte Analytics Workbench im Rahmen des beschriebenen Szenarios eingesetzt werden kann. Aufbauend darauf wird eine Orientierung an den in Kapiel 2 vorgestellten Konzepten für entscheidungsunterstützende Systeme mit dem Ziel vorgenommen, eine Grundlage für die weitere Ausgestaltung des zu entwickelnden Konzeptes zu erhalten. So können dann Anforderungen an die einzelnen Komponenten sowie das Gesamtsystem formuliert werden. Im Anschluss daran soll eine Einordnung der Begrifflichkeiten des Berichts und Dashboards im Kontext der Aufgabenstellung vorgenommen werden. Danach wird zusammenfassend der Prozess der Entscheidungsunterstützung, wie er mit Hilfe des zu entwickelnden Systems durchgeführt werden können soll, aufgezeigt. Abschließend werden erste Konzepte der Benutzeroberfläche vorgestellt Szenario Wie in Kapitel angesprochen, können zwischen ganz verschiedenen gesellschaftlichen Akteuren Netzwerke identifiziert werden, die beschreiben, wie und von wem Wissen, beispielsweise als Resultat von Forschung, verbreitet, aufgegriffen und genutzt wird. Das im Folgenden vorgestellte Szenario beschreibt einen möglichen Prozess der Entscheidung über die Zuteilung von Fördergeldern an wissenschaftliche Projekte bzw. Einrichtungen. Bei der für die Zuteilung zuständigen Institution soll es sich um ein für Wissenschaft und Wirtschaft zuständiges Landesministerium handeln, das insbesondere regionale Projekte fördern möchte. Ein aus dem SISOB-Kontext stammendes Beispiel hierzu ist etwa das Ministerium für Wirtschaft, Innovation, Wissenschaft und Arbeit (CICE) 1 der Regionalregierung von Andalusien. Das CICE ist unter anderem für die Zuteilung von Fördergeldern an lokale Projekte mit wissenschaftlichem Hintergrund zuständig und analysiert zu diesem Zweck Aktivitäten von (lokalen) Wissenschaftlern. Darüber hinaus ist das CICE als Projektpartner in das SISOB-Projekt involviert.[sisa] Die im Folgenden beschriebenen Akteure, Vorgänge und Überlegungen sollen einen möglichen Anwen- 1 Consejería de Economía, Innovación, Ciencia y Empleo [Jun] 33

42 3. Ansatz dungsfall darstellen, lassen sich aber nicht notwendigerweise in die Realität übertragen Problemstellung Eine Institution wie die zuvor beschriebene kann unter anderem die Aufgabe haben, Fördergelder für lokale Forschungsprojekte zu verteilen. Hierbei kann grundsätzlich auf unterschiedliche Art vorgegangen werden. So können die verfügbaren Mittel beispielsweise in einem einfach zu entscheidenen Fall gleichmäßig auf die von unterschiedlichen Arbeitsgruppen der regionalen Universitäten initiierten oder mitgetragenen Projekte verteilt werden. Ein Faktor zur Bestimmung der Förderhöhe könnte hier etwa die Anzahl der an einem Projekt beteiligten Institutionen sein. Diese Zuteilungspolitik macht auf den ersten Blick den Anschein, insbesondere in Hinblick auf die Gleichbehandlung unterschiedlicher Institutionen wie auch Fachrichtungen, ein faires Mittel darzustellen. Betrachtet man allerdings im Rahmen der Zuteilung von Fördergeldern ein breiteres Feld an Einflussfaktoren, so können alternative Strategien ebenfalls sinnvoll erscheinen. Eine Möglichkeit bestünde beispielsweise darin, gezielt solche Projekte zu fördern, die nicht nur den alleinigen Forschungsinteressen bestimmter, lokaler Forschungsgruppen dienen, sondern auch unmittelbar Einfluss auf die regionale Wirtschaft haben. In diesem Rahmen könnten in der Region tätige Industrieunternehmen direkt in einzelne Projekte involviert oder alternativ an Themen geforscht werden, die für die lokale Wirtschaft besonders relevant erscheinen. Mit möglichen Lösungsansätzen für diese Problematik befasst sich das in diesem Teil des Kapitels beschriebene Szenario. Für das Lösen der Probemstellung ergibt sich somit eine Reihe von durchzuführenden Schritten. Zunächst muss eine Bestimmung derjenigen Wirtschaftszweige durchgeführt werden, die eine große Relevanz, beispielsweise im Hinblick auf die zukünftige Arbeitsmarktentwicklung der Region zu haben scheinen. In diesem Zuge werden die für diese Branchen besonders interessanten Forschungsthemen identifiziert, um in der Lage zu sein, gezielt Projektausschreibungen auf den einzelnen Gebieten machen zu können. Die daraufhin von Verbünden von Forschungsgruppen, evtl. unter Einbeziehung von Wirtschaftsunternehmen, gestellten Projektanträge sowie die Antragsteller selbst, werden im Anschluss näher analysiert. Die gesammelten Informationen können dann in den Entscheidungsprozess im Rahmen der Bewilligung einzelner Anträge einfließen Beteiligte Akteure und deren Rollen Es kann davon ausgegangen werden, dass die unterschiedlichen Schritte, die nötig sind, um anhand solcher Informationen Entscheidungen treffen zu können, in der Regel nicht von einer einzelnen Person ausgeführt werden. Eine Orientierung für die Identifizierung einzelner Personengruppen liefern dabei die in Kapitel angesprochenen Nutzertypen. Auch wenn an der genannten Stelle Nutzertypen im Kontext von Entscheidungsunterstützungssystemen betrachtet werden, so lassen sich die genannten Personengruppen dennoch anhand ihrer Funktionen auf die in dem hier vorgestellten Szenario genannten Akteure abbilden. Es wird im Folgenden der Einfachheit halber von einzelnen, bestimmte Rollen repräsentierenden Personen gesprochen, auch wenn grundsätzlich mehrere Personen an einzelnen Prozessen beteiligt sein sowie Mischformen der einzelnen Rollen existieren können. 34

43 3.1. Szenario Der in Kapitel angesprochene Informationskonsument stellt die hier Entscheidungsträger genannte Personengruppe dar. Ein für diesen arbeitender Reporter hat die Aufgabe, die für die jeweilige Entscheidung relevanten Informationen in einer geeigneten Form aufzubereiten. So soll dem Entscheidungsträger ermöglicht werden, diese zu verstehen und in die jeweilige Entscheidung einfließen zu lassen. Gemäß der dieser Personengruppe weitestgehend entsprechenden Rolle des Analytikers (vgl. Kapitel 2.4.3) ist der Reporter selbst unter Umständen kein Spezialist auf dem Gebiet der sozialen Netzwerkanalyse sondern stellt lediglich Informationen zusammen oder wendet vorgegebene, problemlösungsorientierte Modelle und Methoden an, um Informationen zu navigieren bzw. zu analysieren. Somit ist der Reporter eventuell zwar in der Lage relevante Daten zu identifizieren, technisch aber nicht versiert genug, um diese aus unterschiedlichen Datenquellen extrahieren zu können bzw. neue Analysemethoden zu entwickeln. Diese Funktion kommt in einem solchen Szenario einer weiteren Personengruppe zu, die an dieser Stelle relativ allgemein als Analyst bezeichnet wird. Sie entspricht in ihrem Aufgabenspektrum weitestgehend dem in Kapitel beschriebenen Spezialisten. Die Umbenennung der einzelnen Rollen im Rahmen dieser Masterarbeit soll der besseren Identifizierung der einzelnen Aufgabenbereiche im Kontext der Netzwerkanalyse, des Reportings und der Entscheidungsfindung dienen. Neben den hier vorgestellten Personengruppen, die Analysen durchführen und anhand der aufbereiteten Ergebnisse Entscheidungen treffen sollen, sind noch diejenigen Akteure zu nennen, die Bestandteil der Untersuchung sein sollen. Die im Rahmen der Problemstellung zu betrachtenden Daten beschreiben einzelne Forscher, die unter anderem an regionalen Einrichtungen tätig sind, sowie deren Aktivitäten. Der in Abschnitt angesprochene Teil der Datenerhebung und Analyse zur Ermittlung von relevanten Branchen und Forschungsgebieten soll im Weiteren der Einfachheit halber nicht näher betrachtet werden Datenaufbereitung, Analyse, Entscheidungsfindung Im Folgenden wird ein möglicher Ablauf zur Lösung der dem Szenario zugrundeliegenden Problemstellung aufgezeigt. Beginnend mit dem Eingang eines Antrages wird dieser zunächst hinsichtlich seiner Relevanz für die der Ausschreibung zugrundeliegenden Themenstellung geprüft. In dem Fall, dass der Antrag den inhaltlichen Voraussetzungen genügt, sollen die beteiligten Akteure näher betrachtet werden. Hierbei lassen sich viele interessante Fragestellungen identifizieren. Das Hauptaugenmerk liegt dabei auf der Frage, inwiefern sich die an dem Antrag beteiligten Wissenschaftler bzw. Forschungsgruppen sowie Wirtschaftsunternehmen für die Durchführung des Projektes eignen. Weiterhin soll untersucht werden, ob bei der Zusammenstellung der Beteiligten eventuell Optimierungspotential besteht. Der für die Zusammenstellung der für den Entscheidungsträger relevanten Informationen verantwortliche Reporter stellt in Ermangelung von verfügbaren Problemlösungsmodellen bzw. -methoden dem zuständigen Analysten eine detaillierte Anfrage bezüglich der zu untersuchenden Daten. Dieser stellt daraufhin Daten zu zuvor identifizierten, das Thema der Ausschreibung betreffenden Stichworten mit Hilfe einer Datenbank für wissenschaftliche Publikationen zusammen. Die zusammengestellten Daten bestehen aus einzelnen wissenschaftlichen Veröffentlichungen und den Namen der an diesen Publikationen beteiligten Wissenschaftler. Nun liegen Daten vor, die sich als two-mode-netzwerk darstel- 35

44 3. Ansatz len lassen und auf denen somit Untersuchungen mit Hilfe von Methoden der sozialen Netzwerkanalyse durchgeführt werden können. Zunächst werden die einzelnen Wissenschaftler näher betrachtet. Es soll die Frage beantwortet werden, ob sich einige der den Antrag stellenden Wissenschaftler in dem Netzwerk wiederfinden. Ist das der Fall, so wird für jeden einzelnen Akteur bestimmt, an wievielen der dargestellten Publikationen er oder sie beteiligt war. Das gibt einen ersten Hinweis darauf, inwiefern Erfahrungen auf dem jeweiligen, durch eine Veröffentlichung repräsentierten Forschungsgebiet existieren. Nach Betrachten der einzelnen Wissenschaftler kann nun auch für die verschiedenen Forschungsgruppen abgeschätzt werden, ob und in welcher Ausprägung Erfahrung auf einzelnen Forschungsgebieten besteht. Nachdem das grundsätzliche Vorhandensein von Kompetenzen abgeprüft wurde, wird versucht Informationen zu Kollaborationsstrukturen innerhalb des Netzwerkes aufzudecken. So werden die einzelnen Wissenschaftler hinsichtlich ihrer gemeinsamen Arbeit an wissenschaftlichen Publikationen betrachtet. Dabei sollen besonders wichtige Akteure herausgestellt werden. So können einerseits diejenigen Wissenschaftler identifiziert werden, die mit besonders vielen anderen Forschern des Netzwerkes zusammengearbeitet haben, andererseits soll betrachtet werden, welchen dieser Akteure dabei eine Vermittlerrolle zukommt. So können Rückschlüsse darauf gezogen werden, inwiefern die einzelnen Forschergruppen schon untereinander vernetzt sind sowie Personen oder Gruppen identifiziert werden, die unter Umständen für die Projektleitung in Frage kommen. Darüber hinaus sind viele weitere Fragestellungen zu dem betrachteten Netzwerk denkbar, diese sollen hier aber nicht weiter verfolgt werden. Um dem jeweiligen Entscheidungsträger ein möglichst umfassendes, aber trotzdem verständliches Gesamtbild von den einzelnen aus der Analyse gewonnenen Erkenntnissen bieten zu können, fasst der Reporter die Ergebnisse anhand eines schriftlichen Reports zusammen. Bei der Erstellung dieses Berichtes orientiert er sich an den in Kapitel vorgestellten Kriterien zur Gestaltung von Reports. In diesem Rahmen visualisiert er relevante Ausschnitte des Netztwerkes und hält die Ergebnisse und Interpretationen in textueller Form fest. Für die graphische Aufbereitung der Netzwerkdaten, sowie Anfragen nach weiteren Informationen, greift er erneut auf die Hilfe des Analysten zurück. Die Modelle, die der Analyst für bereits durchgeführte Datenerfassungs- und Analyseschritte entwickelt hat, wurden von diesem für den Reporter aufbereitet und stehen dem Berichtsersteller an dieser Stelle, evtl. in eingeschränkter Form hinsichtlich der Parametrisierbarkeit der enthaltenen Methoden, zur freien Verfügung. Somit können, beispielsweise nach Veränderung der Basisdaten, neue Analysen ad hoc, ohne die Hilfe des Analysten durchgeführt werden. Das Ergebnis, in diesem Fall der fertige Bericht, wird dem Entscheidungsträger im Anschluss zur Verfügung gestellt. Dieser ist dabei in der Lage, die zusammengestellten Informationen in unterschiedlicher Form zu betrachten. Neben der Möglichkeit, einen statischen Bericht, beispielsweise ausgedruckt auf Papier beziehen zu können, ist der Entscheidungsträger grundsätzlich in der Lage, die Inhalte interaktiv zu navigieren. Die im Report enthaltenden Informationen können nun in die Entscheidungsfindung einfließen und der jeweilige Antrag in der eingereichten oder einer optimierten Form angenommen bzw. abgelehnt werden. Im Fall, dass über weitere, parallel eingereichte Anträge entschieden werden soll, kann ein Entscheidungsträger jederzeit auf die von evtl. verschiedenen Reportern und Analysten erstellten Reports zugreifen und anhand dieser Entscheidungen treffen. 36

45 3.1. Szenario Einsatz der Analytics Workbench Das Sammeln und Analysieren von Daten nimmt einen wichtigen Teil des zuvor dargestellten Szenarios ein. Die Analytics Workbench soll in dieser Masterarbeit das Mittel der Wahl für die Durchführung dieser Arbeiten sein. Somit stellt sie einen wichtigen Bestandteil der zu entwickelnden Web-Applikation zur Enscheidungsunterstützung dar. Im Folgenden werden erneut die im letzten Abschnitt angesprochenen Arbeitsschritte aufgegriffen und dargelegt, wie diese für den Fall eines einzelnen Antrages mit Hilfe der Analytics Workbench durchgeführt werden können. Die Abbildung 3.1 zeigt einen Workflow, der sowohl den am Anfang stehenden Datenzugriff als auch einzelne Analyseschritte und die für die jeweilige Präsentation gewählten Datenvisualisierungen abbildet. Zunächst werden Daten, die ein Autoren-Publikations- Netzwerk darstellen, aufgegriffen. Diese wurden bereits in einem vorgelagerten Schritt aus einer entsprechenden Datenbank extrahiert und in die Datenbasis der Analytics Workbench übernommen. Da unterschiedliche Analysen auf dem gleichen Datensatz durchgeführt werden sollen, kommt im Anschluss an die Formatumwandlung ein Filter zum Einsatz, der den Datenstrom dupliziert. So stehen zwei identische Datenquellen zur Verfügung, die von den sich diesem Filter anschließenden Analysekomponenten genutzt werden können. Die darauf folgenden Schritte teilen sich entsprechend in zwei unterschiedliche Zielsetzungen auf. Im ersten Fall sollen, wie im Abschnitt beschrieben, die einzelnen Wissenschaftler hinsichtlich ihrer Erfahrung auf den durch das Netzwerk repräsentierten Forschungsgebieten, untersucht werden. Hierzu wird für jeden Wissenschaftler der Degree, also die Anzahl der Beteiligungen an verschiedenen, im Netzwerk abgebildeten wissenschaftlichen Veröffentlichungen, ermittelt. Anschließend werden die Ergebnisse einerseits als Graph mit Hilfe eines zirkulären Layouts visualisiert, andererseits als Downloadlink für textuell dargestellte Daten angeboten. Im zweiten dargestellten Hauptzweig des Workflows soll die jeweilige Zusammenarbeit der einzelnen Wissenschaftler im Hinblick auf gemeinsame Publikationen untersucht werden. Dazu wird das Netzwerk zunächst in ein One-Mode-Netzwerk überführt, das ausschließlich Wissenschaftler enthält, die miteinander in Beziehung stehen. Einzelne Wissenschaftler stehen in diesem Netzwerk dann in Beziehung zueinander, wenn sie gemeinsam an einer oder mehreren Veröffentlichungen gearbeitet haben. Anschließend wird wie in dem zuvor dargestellten Fall, der jeweilige Degree eines Wissenschaftlers untersucht, anhand dessen bestimmt wird, mit wievielen anderen Wissenschaftlern zusammengearbeitet wurde. Die Ergebnisse werden wieder als Graphvisualisierung und Downloadlink zur Verfügung gestellt. Auf die im Szenario dargestellte Untersuchung der einzelnen Analysten hinsichtlich ihrer Rolle als Vermittler zwischen den einzelnen Forschern wird hier aus Gründen einer übersichtlichen Darstellung des in Abbildung 3.1 dargestellten Workflows nicht weiter eingegangen Bewertung der sich ergebenen Möglichkeiten zur Entscheidungsunterstützung Grundsätzlich können die einzelnen, an der Analyse, Zusammenstellung und Entscheidungsfindung beteiligten Akteure, auf verschiedene softwaregestütze Systeme zurückgreifen. So können die beteiligten Rollentypen durch eine Zusammenstellung unterschied- 37

46 3. Ansatz Abbildung 3.1.: Szenario-Workflow licher Werkzeuge, unter Einbeziehung der Analytics Workbench, die zuvor dargestellte Problemstellung behandeln. Zentral ist unter Berücksichtigung der Aufgabenstellung dieser Masterarbeit dabei die Fragestellung, in welcher Weise die Entscheidungsträger, Reporter und Analysten mit Hilfe der zu entwickelnden Web-Applikation zur Entscheidungsunterstützung zusammenarbeiten können. Der Abschnitt zeigt, dass die Analytics Workbench ein komfortables Mittel darstellt, um zumindest die Aufgaben des Analysten im Rahmen der im Szenario vorgestellten Problemstellung zu erfüllen. Die Analytics Workbench kann dabei im weitesten Sinne als eine Möglichkeit zur Erstellung und Nutzung von den in Kapitel vorgestellten Descision Support Systemen betrachtet werden. Die einzelnen an der genannten Stelle aufgeführten Komponenten eines DSS sind dabei weitestgehend auch in der Analytics Workbench wiederzufinden. Bei Betrachtung dieser fällt auf, dass die in Kapitel vorgestellte Komponente der Reportbank, wenn überhaupt, nur in einer sehr eingeschränkten Ausprägung identifizierbar ist. Ergebnisse der Analytics Workbench lassen sich nur solange über das Web-Frontend darstellen, bis das Browserfenster geschlossen wird. Auch besteht keine Möglichkeit, die Ergebnisse weiter aufzubereiten bzw. um Inhalte zu ergänzen und verschiedenen Nutzern oder Nutzergruppen für unterschiedliche Arten der Weiterverwendung auf direktem Wege zur Verfügung zu stellen. Für die vollständige Unterstützung der im Szenario dargestellten Aufgaben der Reporter und Entscheidungsträger werden somit zusätzliche Mittel benötigt. So müssen die Ergebnisse in geeigneter Form als Bericht aufbereit und dem jeweiligen Entscheidungsträger im Anschluss zur Verfügung gestellt werden können. Im Folgenden soll ein Konzept für die Web-Applikation entwickelt werden, welche das vorgestellte Szenario vollständig abdecken soll. 38

47 3.2. Anforderungen an die Web-Applikation 3.2. Anforderungen an die Web-Applikation Orientierung Im Kapitel 2 werden verschiedene Ansätze von Management Support Systemen und Business Intelligence Systemen aufgezeigt. Management Information Systeme zielen hauptsächlich auf die Informationsbereitstellung ab, ohne dabei problemorientierte Modelle und Methoden zu verwenden, wie es beispielsweise die Decision Support Systeme vorsehen. Beide Ansätze eignen sich für relativ eng eingrenzbare Aufgabenbereiche. Dabei können sie aber nicht alle, insbesondere nicht die die einzelnen Aufgabenbereiche der Nutzerrollen betreffenden Ansprüche des in diesem Kapitel vorgestellten Szenarios abdecken. Die Executive Information Systeme bieten zwar konzeptionell bedingt Möglichkeiten der Kommunikation sind aber ähnlich wie die MIS eher auf die Präsentation bestimmter Informationen für verschiedene Personengruppen ausgerichtet, ohne dabei, wenn überhaupt vorhanden, eine große Anzahl an problemlösungsorientierten Methoden für das zugrundeliegende Modell mit einzubeziehen. Somit stellen die einzelnen angesprochenen Konzepte höchstens in Kombination eine Möglichkeit dar, die einzelnen Aufgabenbereiche der vorgestellten Nutzertypen ansatzweise abzudecken. Das Konzept der Executive Support Systeme bietet einen ersten Anhaltspunkt für eine mögliche Einordnung der zu erstellenden Webapplikation. Es vereinigt Eigenschaften der EIS sowie der DSS und ist somit sowohl Daten- und Präsentationsorientiert, bezieht aber auch Modelle und Methoden mit ein. Leichter fällt die Orientierung an einzelnen im Rahmen der Business Intelligence Systeme dargestellten Konzepten und Ansätzen. So können die unterschiedlichen von Analysten, Reportern und Entscheidungsträgern durchzuführenden Aufgaben konzeptionell durch einzelne, generische Basissysteme, die in Kapitel vorgestellt wurden, abgebildet werden. Diese sind den in der Informationsgenerierungsschicht des vorgestellten BI-Ordnungsrahmens angesiedelten Analysesystemen zugeordnet. Mit Hilfe des der Informationsschicht zugehörigen und in Kapitel erläuterten Portalansatzes kann auf diese von zentraler Stelle durch unterschiedliche Nutzertypen zugegriffen werden. Der Fakt, dass die Aufgabenstellung die Konzeption und Implementierung einer Web- Applikation zur Entscheidungsunterstützung vorsieht und unterschiedliche Rollen und Aufgaben identifiziert wurden, legt eine Orientierung des zu entwerfenden Konzepts am Portalansatz, insbesondere des BI-Portals als Unterform der Enterprise Information Portale, nahe. Somit soll sich die im Folgenden durchgeführte Sammlung von Anforderungen sowie die Konzeption der Web-Applikation an diesem Ansatz orientieren Anforderungen bezüglich der Rechteverwaltung Um grundlegende Features des Portalansatzes, wie beispielsweise ein rollenbasiertes Zugriffskonzept, realisieren zu können, muss das zu entwickelnde System einige Voraussetzungen hinsichtlich der Rechteverwaltung erfüllen. Im Einzelnen sind in diesem Rahmen die folgenden Eigenschaften zu nennen: Unterstützung der Rolle des Administrators. Dieser hat zusätzlich die Rollen des Analysten, Reporters sowie des Entscheidungsträgers inne. 39

48 3. Ansatz Unterstützung von Rollen, die die Nutzertypen Analyst, Reporter und Entscheidungsträger abbilden. Hierbei soll anhand der Nutzerrolle Zugriff auf die einzelnen, dieser Rolle zuzuordnenden Funktionalitäten gewährt werden. Aufgrund der zuvor angesprochenen Möglichkeit, dass auch Mischformen der einzelnen Rollen denkbar sind, sollen Analysten auch die Funktionalitäten der Reporter sowie Entscheidungsträger nutzen können. Der Reporter hingegen hat über die seiner Rolle entsprechenden Funktionalitäten hinaus das Recht, auf die Funktionalitäten der Rolle des Entscheidungsträgers zuzugreifen. Der Entscheidungsträger kann ausschließlich die seiner Rolle unmittelbar zugeordneten Funktionalitäten nutzen. Somit ist eine von der Rolle des Administrators ausgehende, mit abnehmenden Befugnissen gestufte Zuteilung von Rechten möglich. Dabei muss die jeweils einem Nutzer zugeordnete Rolle nicht zwingend dessen Status bzw. Hierarchieebene in der Realität entsprechen. Ein mit entsprechenden Modellen und Methoden vertrauter Entscheidungsträger kann also beispielsweise mit dem Ziel des Ad-Hoc-Reportings die Rolle des Reporters ausfüllen und somit entsprechende Funktionalitäten zum Erstellen und Betrachten von Reports nutzen. Auf diesem Weg können andererseits direkte Zugriffe auf die komplette Datenbasis, die über die Analytics Workbench zugreifbar wäre, anhand der Nutzerrolle eingeschränkt werden. Unterstützung von unterschiedlichen Gruppen, denen Nutzer verschiedener Rollen angehören können. Die jeweiligen Gruppenzugehörigkeiten sollen sowohl die Nutzung von Reports als auch den Zugriff auf durchgeführte Analysen sowie deren Ergebnisse einschränken. Auch die Verfügbarkeit der im Abschnitt angesprochenen Templates soll in Abhängigkeit der jeweiligen Gruppenzugehörigkeit eines Nutzers stehen Anforderungen bezüglich der Nutzertypen Bedingt durch die Anforderungen aus der Aufgabenstellung (siehe Kapitel 1.2) und ergänzt durch das in diesem Kapitel vorgestellte Szenario kommen den einzelnen Nutzergruppen unterschiedliche Aufgaben zu, die durch die zu entwickelnde Web-Applikation unterstützt werden müssen. Im Folgenden sollen die Anforderungen an das System in Hinblick auf die einzelnen Nutzergruppen aufgestellt werden. Dem Administrator sollen die folgenden Nutzungsmöglichkeiten zur Verfügung stehen: Möglichkeiten, dem System neue Nutzerkonten hinzuzufügen sowie diese zu löschen. Möglichkeiten, dem System neue Gruppen hinzuzufügen sowie diese zu löschen. Möglichkeiten Nutzern jeweils eine bestimmte Rolle zuzuteilen, darüber hinaus sollen Nutzer verschiedenen Gruppen zuteilbar sein. Dem Analysten sollen die folgenden Nutzungsmöglichkeiten zur Verfügung stehen: Erstellung von Workflows mit Hilfe des vollen Funktionsumfanges der Analytics Workbench. Dies soll sowohl hinsichtlich der verfügbaren Filter als auch der Bedienfunktionalitäten gelten. 40

49 3.2. Anforderungen an die Web-Applikation Erstellung von Templates, die Reportern das Durchführen von vorkonfigurierten Workflows ermöglicht. Die in den von den Templates dargestellten Workflows enthaltenen Filter sollen zu diesem Zweck in unterschiedlicher Weise parametrisierbar sein. Einzelheiten dazu werden im Abschnitt vorgestellt. Dem Reporter sollen die folgenden Nutzungsmöglichkeiten zur Verfügung stehen: Möglichkeit, bereits durchgeführte Analysen und deren Ergebnisse aufgreifen zu können, mit dem Ziel diese unterschiedlichen Berichten zuzuordnen. Möglichkeit, Templates zu konfigurieren und anhand dieser Analysen durchzuführen sowie im Anschluss auf die resultierenden Ergebnisse zuzugreifen. Möglichkeit, mit einem Analysten zu kommunizieren. So sollen neue Templates bei einem Analysten angefordert oder diesem direkt der Auftrag zur Erfassung bzw. Analyse von Daten gegeben werden können. Möglichkeiten, Berichte um Inhalte, die nicht unmittelbar Ergebnisse von durchgeführten Analysen sind, erweitern zu können. Insbesondere sind an dieser Stelle Möglichkeiten zur Freitexteingabe vorzusehen. Möglichkeiten, die jeweils einem Bericht zugeordneten Elemente dynamisch anordnen sowie entfernen zu können. Möglichkeiten, statische Berichte in unterschiedlichen Dateiformaten erstellen zu können. Die so erstellten Reports sollen Entscheidungsträgern zur Verfügung gestellt werden können. Dem Entscheidungsträger sollen die folgenden Nutzungsmöglichkeiten zur Verfügung stehen: Möglichkeit, mit Reportern Kontakt aufzunehmen. So sollen grundsätzlich neue Reports angefordert wie auch Anfragen bezüglich bestehender Reports gestellt werden können. Betrachtung von durch Reporter zur Verfügung gestellten Berichten mit Hilfe des Web-Interfaces. Visualisierungen sollen in diesem Fall, falls von der jeweiligen Darstellungsform vorgesehen, interaktiv navigierbar sein. Auch sollen zur Betrachtung von Reports im Web-Browser grundsätzlich mobile Endgeräte nutzbar sein. Möglichkeit zum Abrufen von durch Reportern erstellten, statischen Berichten. Einige grundlegende Funktionalitäten müssen allen hier aufgezählten Nutzertypen zur Verfügung stehen: Nutzer müssen die Möglichkeit haben, sich entsprechend dem Portalansatz an zentraler Stelle des Systems An- bzw. Abzumelden. Allen Nutzertypen müssen die Möglichkeit haben, Reports anzulegen sowie zu laden. Im Rahmen des Erstellungsprozesses soll ermöglicht werden, einen Report entweder mit anderen Mitgliedern der Gruppen, denen der erstellende Nutzer zu diesem Zeitpunkt angehört, zu teilen oder den jeweiligen Bericht als privat zu definieren. 41

50 3. Ansatz Anforderungen bezüglich der Templates Die hier zu konzipierende Web-Applikation zur Entscheidungsunterstützung soll Nutzern in der Rolle des Reporters ermöglichen, auf Templates zur Durchführung von Analysen zurückgreifen zu können. Wie zuvor bereits angesprochen, stellen Templates vorgefertigte Workflows dar, deren Filter unter Umständen nur eingeschränkt parametrisierbar ein sollen. So soll bestimmten Reportern die Möglichkeit gegeben werden, anhand von vorgegebenen Standardmodellen bestimmte Analysen durchführen zu können, ohne dabei besondere Kenntnisse von den zugrundeliegenden Überlegungen und Methoden haben zu müssen. Templates können somit beispielsweise dazu genutzt werden, um methodisch identische Analysen auf sich häufig verändernden Datenbeständen durchzuführen, ohne jeweils erneut einen Analysten mit der Aufgabe betreuen zu müssen. Gleichzeitig bietet dieser Ansatz die Möglichkeit der Analyse von Daten, ohne gleichzeitig Zugriff auf unterschiedliche Datensätze zu haben, wie es im Fall des Analysten durch Nutzung der Analytics Workbench möglich wäre. Um hinsichtlich der Beschränkung der Parametrisierbarkeit eine möglichst hohe Flexibilität zu erreichen, sollen Templates bei Erstellung auf drei unterschiedliche Arten konfigurierbar sein: Ein Feld kann vollständig parametrisierbar sein. Ein Feld kann eingeschränkt parametrisierbar sein, in dem Sinne, als dass ein Bereich definiert wird, der die Grenzen vorgibt, innerhalb derer die Werte eines Filters liegen dürfen. Im Falle von vorgegebenen Werten handelt es sich dabei um eine Liste von für den Nutzer auswählbaren Werten. Im Falle, dass der betreffende Filter eine freie Parametereingabe vorsieht, handelt es sich dabei um einen jeweils nicht zu überschreitenden oberen und nicht zu unterschreitenden unteren Grenzwert. Ein Feld kann nicht konfigurierbar sein. Einzelne Felder eines jeden im Workflow enthaltenen Filters sollen dabei unabhängig voneinander mit Beschränkungen der Parametrisierbarkeit belegt werden können. Zusätzlich sollen einzelne Felder mit einem bestimmten Wert vorkonfiguriert werden können. Die Erstellung von Templates soll mit Hilfe der parallel zu dieser Masterarbeit weiterentwickelten Analytics Workbench ermöglicht werden. Die Zurverfügungstellung dieses Features fällt nicht in den Aufgabenbereich dieser Arbeit. In Abschnitt 4.3 werden allerdings unter anderem Ansätze formuliert, die die Nutzung von Templates in der hier zu entwickelnden Web-Applikation ermöglichen sollen Konzeption des Berichts bzw. Dashboards Wie in Kapitel 2.2 dargelegt, stellt der Bericht ein wichtiges Mittel dar, um Informationen in geordneter Weise weiterzugeben. Die Aufgabenstellung dieser Masterarbeit sieht die Entwicklung eines Web-basierten Reporting Tools bzw. Dashboards vor. Somit kommt den Begrifflichkeiten des Berichts sowie des Dashboards als zentralen Bestandteilen dieser Arbeit große Bedeutung zu. Im Folgenden sollen zunächst die Eigenschaften der zwei Konzepte Dashboard (s. Kap ) und Bericht (s. Kap ) im Kontext der zu entwickelnden Web-Applikation betrachtet werden. So sollen Eigenschaften beider 42

51 3.3. Konzeption des Berichts bzw. Dashboards Konzepte in sinnvoller Weise in die Konzeption der benötigten Berichts- bzw. Dashboardfunktionalitäten einfließen und eine einheitliche Begrifflichkeit zur weiteren Verwendung festgelegt werden. Im Anschluss daran wird ein Konzept für den Aufbau sowie die Inhalts- und Präsentationsformen des mit Hilfe der Web-Applikation zu erstellenden Reports bzw. Dashboards entwickelt. Zuletzt kann dann ein Prozess, der die einzelnen Phasen der Berichts- bzw. Dashboarderstellung abbildet, beschrieben werden Bericht und Dashboard im Kontext der Web-Applikation Die mit Hilfe der zu entwickelnden Web-Applikation zu erstellenden Berichte sollen sowohl in statischer Form ausgegeben und verwendet, als auch möglicherweise interaktiv von dem jeweiligen Empfänger betrachtet werden können. Diese Unterteilung anhand der Art der geplanten Nutzung lässt in einem ersten Ansatz den Schluss zu, dass eine getrennte Betrachtung der Konzepte Bericht sowie Dashboard im Rahmen der Konzeption der Web-Applikation sinnvoll sein könnte. Eine Zuordnung von statischem Bericht zu der Begrifflichkeit des Berichts sowie interaktiver Bericht zu der des Dashboards kann jedoch nicht in sinnvoller Weise vorgenommen werden, da beide Konzepte an wichtigen Punkten Überschneidungen aufweisen und das Konzept des Dashboards, wie es in Kapitel vorgestellt wird, möglicherweise einige Einschränkungen hinsichtlich der Aussagekraft der in der Web-Applikation darzustellenden Informationen bedeuten würde. Bei näherer Betrachtung der beiden Konzepte lassen sich einige Ähnlichkeiten bezüglich ihrer jeweiligen Eigenschaften identifizieren: Grundsätzlich kann festgestellt werden, dass sowohl der Bericht als auch das Dashboard jeweils Mittel der Informationsvermittlung darstellen. Der Aufbau sowie die Inhalte eines Berichts als auch eines Dashboards richtet sich in hohem Maße nach den Bedürfnissen des jeweiligen Nutzers und den von diesem zu einem bestimmten Thema bzw. einer spezifischen Problemstellung angefragten Informationen. Die jeweils enthaltenen Inhalte sollten dabei möglichst sinnvoll verdichtet und ansprechend bzw. intuitiv verständlich präsentiert werden, wobei auch eine klare strukturelle Anordnung der einzelnen Elemente zu einer besseren Rezeption der wesentlichen Inhalte durch den jeweiligen Empfänger beitragen kann. Zur Zusammenstellung von Dashboards werden häufig grafische Präsentationsformen eingesetzt, die Informationen wie beispielsweise relativ leicht zu überblickende Kennzahlen auf eine intuitive Weise darstellen. Deren Interpretation bedarf auf Seiten des Nutzers unter Umständen keiner weiteren Erklärungen. Auch sollten Dashboards Informationen möglichst auf einer Bildschirmseite darstellen können. In dieser Arbeit liegt hinsichtlich der darzustellenden Informationen ein besonderer Fokus auf der Analyse von sozialen Netzwerken. In diesem Zusammenhang sind unter Umständen sowohl deren Ergebnisse als auch die jeweilige Genese, beispielsweise dargestellt durch einen Workflow der Analytics Workbench, Gegenstand der Betrachtung und Interpretation. Der Entscheidungsträger selbst ist, wie zuvor dargelegt, nicht in jedem Fall in der Lage diese Schritte durchzuführen. Somit kommt dem Reporter die in Abschnitt beschriebene Rolle zu, die Informationen in einer verständlichen Form aufzubereiten, was unter Umständen auch in Form einer Metaanalyse geschehen kann. So kann es sinnvoll sein, neben den eigentlichen Ergebnissen in graphischer wie auch textueller Form und Workflows auch zusätzliche Inhalte, insbesondere Text, an unterschiedlichen Stellen in die Struktur des Berichts bzw. Dashboards einzufügen. So können wichtige Kontextinfor- 43

52 3. Ansatz mationen vermittelt werden, die bei bloßer Betrachtung eines Dashboards, das lediglich auf die Darstellung von unkommentierten Ergebnissen aus einzelnen Analysen ausgelegt ist, keinen Raum hätten. Dashboards und Berichte lassen sich zur Überwachung und Interpretation einer sich unter Umständen häufig ändernden Datenbasis mit Hilfe von festgelegten, standardisierten Analyse- sowie Datenvisualisierungsmethoden nutzen. In diesem Fall erfüllen Berichte die Funktion der in Kapitel vorgestellten Standard- oder Abweichungsberichte. Im Falle von individuellen, problemspezifischen Fragestellungen, die einer tiefergehenden Analyse und Interpretation durch Spezialisten bedürfen, bilden jeweils unmittelbar zu diesem Zweck zusammengestellte Reports die Funktion von den ebenfalls in Kapitel vorgestellten Bedarfsberichten ab. Beide Fälle können in einem gewissen Umfang auch von Dashboards abgedeckt werden. Die zuletzt genannte Form des individuell angefertigten und evtl. mit weiteren Informationen versehenen Bedarfsberichts soll in der weiteren Konzeption als Orientierung genutzt werden. Aufgrund der hier aufgezeigten Ähnlichkeiten und Argumente gegen eine Trennung von Bericht und Dashboard soll in der weiteren Konzeption der Dashboard- bzw. Reportfunktionalitäten eine Mischform, die Eigenschaften aus Dashboards und Berichten aufweist, entworfen werden, wobei dabei im Weitern der Begriff Report (bzw. Bericht) verwendet werden soll. Ein solcher Report kann dann sowohl in statischer Form aber auch interaktiv navigierbar, als eigens für den Zweck des Reportings zusammengestelltes Dashboard mit Kontextinformationen, vorliegen Inhalte und Aufbau eines Berichts Unter Einbeziehung der im vorherigen Abschnitt durchgeführten Argumentation und den sich aus den aufgezählten Eigenschaften ergebenen Anforderungen, können zu den zu erstellenden Berichten konkrete Aussagen getroffen werden. Hinsichtlich der Inhalte muss ein Bericht die folgenden Möglichkeiten bieten: Möglichkeit, Ergebnisse aus Analysen von sozialen Netzwerken in einen Bericht zu integrieren. Dabei müssen sowohl statische als auch dynamische Visualisierungsformen unterstützt werden. Dazu zählen Graph- und Datenvisualisierungen sowie die textuelle Darstellung von Analyseergebnissen, die in Form von strukturierten wie auch unstrukturierten Daten vorliegen können. Möglichkeit, einzelne, mit Hilfe der Analytics Workbench erstellte Workflows in graphischer Form in einen Bericht integrieren zu können. So können Informationen bereitgestellt werden, die aufzeigen, auf welche Weise Ergebnisse ermittelt wurden. Möglichkeit, Abbildungen in einen Bericht zu integrieren. So soll insbesondere die Einbindung von externen Informationen unterschiedlicher Art ermöglicht werden. Möglichkeit, frei definierten Text in einen Bericht zu integrieren. Dabei soll der Text in geeigneter Weise formatiert werden können. Möglichkeit, Hyperlinks in einen Bericht integrieren zu können. So können Verweise auf externe Informationen erstellt werden, ohne diese in den eigentlichen Bericht direkt einbinden zu müssen. 44

53 3.3. Konzeption des Berichts bzw. Dashboards Abbildung 3.2.: Mockup eines Reports Bezüglich des Aufbaus eines Berichts können die folgenden Aussagen getroffen werden: Ein Report soll grundsätzlich ein Portraitformat haben und sich dabei grob an für Papierformate gängigen Seitenverhältnissen orientieren. Auf diese Weise soll eine Überführung von am Bildschirm zusammen- und dargestellten Reports in eine statische und druckbare Form erleichtert werden. Die einzelnen Berichtselemente sollen unter Berücksichtigung des letzten Punktes vertikal untereinander in dem Bericht angeordnet sein. So können Berichte zusammenhängend über mehrere Seiten gedruckt werden. 45

54 3. Ansatz Mit dem Ziel einer möglichst kompakten Darstellung sollen sich die einzelnen Elemente eines Reports im Rahmen der web-basierten Darstellung jeweils in normaler oder minimierter Form anzeigen lassen Mockup eines Berichts Die Abbildung 3.2 zeigt den grundsätzlichen Aufbau sowie die einzelnen Elemente eines Reports unter Berücksichtigung der in Abschnitt formulierten Anforderungen Prozess der Entscheidungsunterstützung Auf Basis der einzelnen in diesem Kapitel formulierten Anforderungen sowie Konzepte kann nun der Prozess für die Unterstützung von Entscheidungsträgern mit Hilfe der Web-Applikation zusammenfassend dargestellt werden. Dieser soll als Grundlage für das Design der Benutzeroberfläche der Web-Applikation dienen und gleichzeitig die Interaktion des Nutzers mit dieser sowie anderen beteiligten Nutzern im Rahmen der Reporterstellung sowie der Betrachtung der so zusammengestellten Informationen beschreiben. Abbildung 3.3 zeigt die einzelnen aufeinander aufbauenden Phasen des Prozesses und die diesen jeweils zugeordneten Bereiche der Web-Applikation. Auch die beteiligten Rollen, sowie deren Kommunikationswege und die rollenbedingten Rechte in Bezug auf die einzelnen Prozessphasen bzw. den Zugriff auf den jeweiligen Bereich der Web-Applikation sind zusammenfassend dargestellt. Vor Beginn der eigentlichen Reporterstellung und -nutzung meldet der Entscheidungsträger einen bestimmten Informationsbedarf mit Hilfe der Web-Applikation an den Reporter. Dieser fragt nach Sichtung der bereits über die Web-Applikation abrufbaren Templates und Ergebnisse aus vorherigen Analysen, neue Templates oder komplette Analysen bei einem Analysten an. An dieser Stelle beginnt der eigentliche Prozess der Reportzusammenstellung und -nutzung. Die einzelnen Phasen dieses Prozesses sollen jeweils anhand von individuellen Views, also Bereichen, die die unterschiedlichen, zur Durchführung der jeweiligen Phase benötigten Funktionalitäten in der Web-Applikation zur Verfügung stellen, abgebildet werden. Im Einzelnen handelt es sich dabei um die folgenden, in Reihenfolge des Prozessablaufs vorgestellten Views: Die Workbench-View erfüllt die in Abschnitt angesprochenen Anforderungen des Analysten an die Web-Applikation und bildet somit die mit Analysieren / Modellieren betitelte Phase des Prozesses ab. Somit können Analysen mit Hilfe der Analytics Workbench durchgeführt sowie Templates erstellt und anderen Nutzern zur Verfügung gestellt werden. Mit Hilfe der AnalysisExplorer-View, die die Phase Selektieren / Analysieren abbildet, sollen Teile der in Abschnitt formulierten Anforderungen des Reporters bedient werden. So können mit Hilfe dieser View vorhandene Analyseergebnisse exploriert sowie zur Verfügung gestellte Templates bei Bedarf parametrisiert und ausgeführt werden. Auch hat der Reporter über diese View die Möglichkeit, Kontakt zu einem Analysten, etwa zur Anforderung neuer Analysen oder Templates, aufzunehmen. Einzelne Ergebnisse lassen sich betrachten und bei Verfügbarkeit 46

55 3.4. Prozess der Entscheidungsunterstützung entsprechender Visualisierungstechniken interaktiv navigieren sowie einem zuvor angelegten bzw. geöffneten Bericht hinzufügen. Die dritte Phase des Prozesses (Ergänzen / Arrangieren / Erzeugen) wird durch die ReportComposer-View abgebildet, dieser Teil der Web-Applikation bedient die verbleibenden Anforderungen des Reporters. So können einzelne Elemente des zu erstellenden Reports umarrangiert werden aber auch zusätzliche Inhalte hinzugefügt werden. Zudem können Reports in statischer Form für bestimmte Entscheidungsträger erzeugt werden. Bei Bedarf kann der Reporter in Phase zwei des Prozesses zurückkehren und mit Hilfe des AnalysisExplorers dem Bericht weitere, analysebezogene Inhalte hinzufügen. Die ReportViewer-View bildet die letzte Phase des Prozesses (Betrachten / Entscheiden) ab und befriedigt die durch den Entscheidungsträger an die Web-Applikation gestellten Anforderungen (s. Kap ). Ein in den vorausgehenden Phasen erstellter Report kann interaktiv bertrachtet werden, sowie, falls durch den Reporter erzeugt, in statischer Form abgerufen und im Rahmen einer Entscheidungsfindung genutzt werden. Auch kann der Entscheidungsträger an dieser Stelle Kontakt zu einem Reporter aufnehmen, um beispielsweise weitere Informationen anzufordern. Der Begriff View für die einzelnen Bereiche der Web-Applikation wurde aus dem Grund gewählt, als dass diese unterschiedliche Sichten auf einen bestimmten Report darstellen. So können in der Workbench-View einzelne, potentielle Reportelemente unabhängig von Abbildung 3.3.: Prozess der Entscheidungsunterstützung mit Hilfe der Web-Applikation 47

56 3. Ansatz einer konkreten Reportdarstellung betrachtet werden. Die AnalysisExplorer-, Report- Composer- und ReportViewer-View zeigen einzelne Reportelemente direkt im Kontext eines solchen Reports, wobei die letzten beiden diese Elemente innerhalb eines konkreten Reportlayouts darstellen. Somit finden alle Phasen im Kontext eines bestimmten Reports statt. Die im Abschnitt 3.5 zusätzlich vorgestellte Administrationsoberfläche wird aus Gründen der Konsistenz ebenfalls als View bezeichnet. Diese Administration-View bietet unabhängig von dem hier beschriebenen Prozess der Entscheidungsunterstützung eine Sicht auf die jeweiligen Daten der einzelnen Nutzer der Web-Applikation. Aufgrund der Tatsache, dass in dem hier dargestellten Prozess der Entscheidungsunterstützung die Konzepte des Reports sowie der sozialen Netzwerkanalyse eine zentrale Rolle spielen, wird der Web-Applikation der Name NetAnaReporter 2 gegeben Konzept des User Interface Im Folgenden sollen Konzepte für die einzelnen Teile der Benutzeroberfläche der Web- Applikation vorgestellt werden. Für die Konzeption dieser wurden die in diesem Kapitel entwickelten Anforderungen und Konzepte und insbesondere der in Abschnitt 3.4 vorgestellte Prozess der Entscheidungsunterstützung berücksichtigt Grundgerüst Abbildung 3.4.: Mockup des grundlegenden User Interfaces Die Abbildung 3.4 zeigt ein Mockup des grundlegenden Aufbaus der Benutzeroberfläche. Diese lässt sich an dieser Stelle grob in zwei Bereiche unterteilen. Im oberen Bereich des User Interface befindet sich die Navigations- und Optionsleiste. Über diese kann durch Auswählen frei zwischen den einzelnen, je nach Nutzerrolle verfügbaren Views navigiert werden. Rechts neben den Viewauswahlelementen werden der Name des aktuell geladenen Reports sowie der Nutzername angezeigt. Über den in der rechten Ecke der Navigations- und Optionsleiste befindlichen Option-Button kann das Optionsmenü aufgerufen werden. Hierüber hat der Nutzer die Möglichkeit, sich anbzw. abzumelden sowie Reports zu erstellen oder zu öffnen. Entsprechende Funktionalitäten sollen über dynamisch einzublendende Dialogfenster durchgeführt werden. Unterhalb der zuvor beschriebenen Navigations- und Optionsleiste befindet sich der Bereich, der zur Darstellung der einzelnen Views, die wie zuvor beschrieben angewählt werden können, genutzt wird. Auf diese Weise kann die Darstellung der Benutzeroberfläche über die verschiedenen Views hinweg konsistent gehalten werden. 2 NetworkAnalysisReporter 48

57 3.5. Konzept des User Interface Administration-View Die Abbildung 3.5 zeigt ein Mockup der Administration-View. Das Interface lässt sich in zwei Bereiche einteilen. Auf der linken Seite befindet sich ein Bereich anhand dessen vorhandene Nutzer und Gruppen zur Selektion dargestellt sind. So können über entsprechende Buttons einzelne Nutzer oder Gruppen hinzugefügt oder entfernt werden, sowie Nutzer zu Gruppen hinzugefügt werden. Im rechten Bereich der Administration-View werden Details zu dem aktuell ausgewählten Nutzer dargestellt. So können neben Nutzername und - adresse auch die aktuell zugewiesene Rolle und die Gruppen, denen der Nutzer angehört, abgelesen werden. Über eine Schaltfläche können einem Nutzer zugewiesene Gruppen entfernt werden. Die Nutzerrolle kann durch Auswahl einer alternativen Rolle geändert werden. Alle durchgeführten Änderungen am hier dargestellten Nutzerprofil können durch Drücken des Speichern- Buttons übernommen werden. Abbildung 3.5.: Mockup der Administration-View Workbench-View Die Abbildung 3.6 zeigt in Form eines Mockups die vollständig in die Workbench-View integrierte Analytics Workbench. Die Funktionalitäten können wie von der Stand-Alone- Version gewohnt genutzt werden AnalysisExplorer-View Die Abbildung 3.7 zeigt einen Entwurf für die AnalysisExplorer-View. Auch diese View unterteilt sich in zwei Bereiche. 49

58 3. Ansatz Abbildung 3.6.: Mockup der Workbench-View Auf der linken Seite befinden sich Möglichkeiten zu Auswahl von Analysen und deren einzelnen Durchläufen sowie Templates. Bei Auswahl einer Analyse sowie durchgeführtem Run (Durchlauf) oder Auswahl eines Templates werden unterhalb der Auswahlwerkzeuge Metainformationen zu diesem angezeigt. Diese enthalten den Namen, die Beschreibung, den Namen des Erstellers sowie den genauen Zeitpunkt des Speicherns oder Durchführens eines Workflows bzw. Templates. Über im unteren Bereich angesiedelte Buttons kann einerseits ein evtl. parametrisiertes Template ausgeführt werden, andererseits Kontakt zu einem Analysten aufgenommen werden. Nach Ausführen eines Templates soll der Nutzer durch ein entsprechendes Popup über die erfolgreich durchgeführte Analyse und vorliegende Ergebnisse informiert werden. Die Kontaktaufnahme mit einem Analysten soll mit Hilfe eines dynamisch einzublendenen Dialogfensters geschehen. Im rechten Bereich der View werden die einzelnen Inhalte, die zur jeweiligen Analyse oder einem Template gehören, untereinander angeordnet angezeigt. So werden zunächst erneut die Metainformationen, einmal in Kurzform, und einem in Form eines automatisch erzeugten, ausformulierten Textes dargestellt. Unterhalb dieser obligatorischen Informationsfelder wird der jeweils zu einer Analyse gehörende bzw. ein Template darstellender Workflow angezeigt. Im Falle einer Templatedarstellung können, falls vorgesehen, direkt in der Darstellung die einzelnen, enthaltenen Filter parametrisiert werden. Unterhalb der Workflowdarstellung werden im Fall einer Analyse die einzelnen Ergebnisse des ausgewählten Durchlaufs dargestellt. Diese können, falls durch die jeweilige Visualisierungstechnik vorgesehen, interaktiv exploriert werden. Neben jedem der hier vorgestellten Felder befinden sich Schaltflächen, die sowohl das Mini- bzw. Maximieren der jeweiligen Darstellung ermöglichen, als auch die Zuweisung eines Elements zu dem aktuell geladenen Report, aber auch das Entfernen eines Elements aus diesem ermöglichen. Der aktuelle Status eines Elements hinsichtlich der Zuweisung zu einem Report ist dabei jederzeit ersichtlich. 50

59 3.5. Konzept des User Interface Abbildung 3.7.: Mockup der AnalysisExplorer-View ReportComposer-View Abbildung 3.8 zeigt ein Mockup der ReportComposer-View. Diese View lässt sich ebenfalls in zwei Bereiche einteilen. Auf der linken Seite befindet sich erneut ein Bereich, der eine Optionsleiste darstellt. An dieser Stelle werden zunächst Informationen zum aktuell geladenen Report angezeigt. Dazu gehören an erster Stelle die einzelnen Analysen wie auch Templates, aus denen Inhalte diesem Report zugewiesen wurden. Diese einzelnen Elemente können selektiert werden. Darunter werden Metainformationen zu dem aktuellen ausgewählten Reportelement angezeigt. Dazu gehören der Name und die Beschreibung der Analyse bzw. des Templates, sowie der Name des Erstellers und der genaue Zeitpunkt der Durchführung der Analyse oder der Erstellung des Templates. Unter diesem Infobereich befinden sich Möglichkeiten, weitere Reportelemente hinzuzufügen, wie auch Konfigurationsmöglichkeiten für die Erstellung von statischen Berichten. Dabei können die einzelnen Zielformate und Nutzer, denen der jeweilige statische Bericht nach Erzeugung zugestellt werden soll, ausgewählt werden. Darunter ist die Schaltfläche angeordnet, die die Erzeugung des hier konfigurierten statischen Berichts anstößt. Im rechten Bereich wird der geladene Report in dem Layout angezeigt, das sowohl zur Darstellung in der ReportViewer-View als auch zur Erzeugung des statischen Berichts verwendet wird. Je nach Auswahl einer Analyse oder eines Templates im linken Viewbereich werden die zugehörigen Elemente gehighlighted (hier in gelber Farbe dargestellt). Umgekehrt können einzelne Reportelemente im rechten Viewbereich angewählt werden, was zur Folge hat, dass im linken Viewbereich die entsprechende Analyse bzw. das Tem- 51

60 3. Ansatz plate als ausgewählt markiert wird. Jedes in diesem Bereich dargestellte Reportelement, welches, falls durch die jeweilige Visualisierungstechnik vorgesehen, interaktiv exploriert werden kann, verfügt über drei Schaltflächen. Dabei ermöglichen die zwei Pfeilbuttons, die einzelnen Elemente vertikal zu verschieben. Bei Betätigung des dritten Buttons wird das betreffende Element aus dem Bericht entfernt. Abbildung 3.8.: Mockup der ReportComposer-View ReportViewer-View Die Abbildung 3.9 zeigt den Entwurf der ReportViewer-View. Auch diese View unterteilt sich in zwei Bereiche. In dem auf der linken Seite befindlichen Bereich werden Informationen zu dem aktuell geladenen Report angezeigt. Dazu gehören der Name sowie die Beschreibung des Reports, der Name des Reporters, der diesen Bericht erstellt hat, sowie der Zeitpunkt der Erzeugung. Über die sich unter diesem Informationsbereich befindlichen Buttons können, soweit verfügbar, die statischen Versionen des aktuell betrachteten Berichts abgerufen werden (in Form eines Download-Links). Die Schaltfläche unterhalb dieses Bereiches 52

61 3.5. Konzept des User Interface ermöglicht die Kontaktaufnahme des Entscheidungsträgers mit einem Reporter. Diese Funktionalität soll mit Hilfe eines dynamisch einzublendenden Dialogfensters realisiert werden. Im rechten Bereich dieser View wird schließlich der Bericht in seinem über die Report- Composer-View erstellten Layout dargestellt. Einzelne Elemente können auch hier, falls durch die jeweilige Visualisierungstechnik vorgesehen, interaktiv exploriert werden. Die jeweils einem Element zugeordnete Schaltfläche ermöglicht erneut das Mini- bzw. Maximieren des jeweiligen Reportelements. Abbildung 3.9.: Mockup der ReportViewer-View ReportViewer-View mobile Die Abbildung 3.10 zeigt die für die Darstellung auf mobilen Endgeräten optimierte Variante der ReportViewer-View. Diese bietet die gleichen Funktionen, wobei die beiden Hauptbereiche im Gegensatz zu der Standardvariante der View nicht nebeneinander, sonder übereinander angeordnet sind. Bei ausreichend hoher Auflösung des Gerätedisplays kann, beispielsweise im Falle der Verwendung auf einem entsprechenden Tablet, auch die Standardvariante der ReportViewer-View genutzt werden. 53

62 3. Ansatz Abbildung 3.10.: Mockup der mobilen ReportViewer-View 54

63 4. Systementwurf In diesem Kapitel sollen mit dem Ziel der Konzeption einer Gesamtarchitektur für das System des NetAnaReporters einzelne, für die Implementierung benötigte Konzepte auf einer technischen Ebene betrachtet, überarbeitet, wie auch neue formuliert werden Orientierung Die Tatsache, dass es sich bei dem zu entwickelnden System um eine Web-Applikation handelt, die sich zusätzlich am Portalansatz orientiert, bedingt die Konzeption sowohl einer Client- wie auch einer Serverkomponente. Die im Kapitel 3 entwickelten Anforderungen und Konzepte wurden größtenteils nutzerzentriert, also im Hinblick auf die Interaktion des Nutzers mit dem Frontend des NetAnaReporters beschrieben. Dieses Web-basierte Benutzerinterface erfüllt eine wichtige Rolle im Gesamtkonzept des NetAnaReporters, da es die einzige Möglichkeit des Nutzers darstellt, mit dem System zu interagieren. Trotzdem kommt dieser Komponente lediglich die Aufgabe zu, einerseits Informationen, die serverseitig generiert wurden, in geeigneter Weise darzustellen und andererseits Nutzereingaben zu Verarbeitungszwecken an die Serverkomponente weiterzuleiten. Der Hauptteil der Applikationslogik soll sich, wie in Abschnitt 4.3 argumentiert, im Falle des NetAnaReporters auf Seiten des Servers befinden. Im Folgenden sollen zunächst einige Angaben zu der Clientkomponente gemacht werden, um anschließend die Serverkomponente sowie die grundlegenden zur Realisierung des NetAnaReporters benötigten Datenstrukturen zu konzipieren Clientkomponente Die einzelnen Bestandteile der Clientkomponente wurden bereits hinlänglich in Bezug auf die jeweils zur Verfügung zu stellenden Funktionalitäten und Interaktionmöglichkeiten vorgestellt. Technische Aspekte für die Umsetzung dieser Komponente wurden bisher kaum angesprochen. Das Frontend des NetAnaReporters soll in möglichst vielen unterschiedlichen Browsern darstellbar sowie bedienbar sein. Dazu zählen auch Browser auf mobilen Geräten, die oft aufgrund der verbauten Hardware, nur geringe Bildschirmauflösungen bieten. Um eine möglichst große Zahl an Browsern abdecken zu können, soll zusätzlich zu den obligatorischen Technologien HTML, CSS 1 und JavaScript auf den Einsatz von jquery 2 gesetzt 1 Cascading Style Sheets 2 Siehe hierzu 55

64 4. Systementwurf werden. Der gemeinsame Einsatz dieser Technologien soll einen browserübergreifend konsistenten Umgang mit der Darstellung von Inhalten und dem Abgreifen von Nutzereingaben im Browser sowie der Kommunikation mit der Serverkomponente ermöglichen. Zusätzlich soll die Gestaltung des Frontends mit Hilfe des Frameworks Bootstrap 3 vorgenommen werden. So kann unter Zuhilfenahme der darüber verfügbaren CSS- und JavaScript-basierten Komponenten eine einheitliche Benutzeroberfläche erstellt werden, wobei die Darstellung auf verschiedenen Endgeräten dynamisch angepasst wird. So soll die Darstellung der in Kapitel 3.5 als Entwurf dargestellten Report-Viewer-View sowie der mobilen Variante dieser automatisch durch die von Bootstrap zur Verfügung gestellten Features ermöglicht werden. Um auch der Serverkomponente zu ermöglichen, jederzeit selbst initiiert Informationen an das Frontend zu schicken, soll die in Kapitel vorgestellte Websocket Technologie verwendet werden. Da wie bereits beschrieben, nicht alle unterschiedlichen, am Markt befindlichen Browser in ihren verschiedenen Versionen die Nutzung von Websockets ermöglichen, soll für die Anbindung der Clientkomponente an die Serverkomponente das ebenfalls in Kapitel vorgestellte für Node.js verfügbare Modul Socket.IO eingesetzt werden Serverkomponente Da zu Kommunikationszwecken zwischen Server- und Clientkomponente unter anderem auf Socket.IO zurückgegriffen werden soll, fällt die Wahl der für die Implementierung der Serverkomponente zu verwendenen Technologie auf Node.js (s. Kap ). Dieser Ansatz ermöglicht das Umsetzen der getroffenen Entscheidung, die Applikationslogik hauptsächlich auf Seiten des Servers abzubilden und die Logik auf Seiten der Clientkomponente auf das Nötigste zu beschränken. So sollen Unterschiede in Hinblick auf die Leistungsfähigkeit der verwendeten Endgeräte relativiert werden. Auch kann so sichergestellt werden, dass alle Arten von Operationen auf Daten auf die gleiche Art bzw. überhaupt durchgeführt werden können. Aufgrund der häufig unterschiedlichen Verfügbarkeit bestimmter Funktionalitäten in verschiedenen Browsern könnte das sonst nicht garantiert werden. Da sich auf Node.js basierende Serverkomponenten grundsätzlich gut skalieren lassen, können auch größere Nutzerzahlen und somit viele Anfragen gleichzeitig bewältigt werden. Für die Umsetzung des NetAnaReporter im Rahmen dieser Masterarbeit soll allerdings eine einzelne Serverkomponente konzipiert werden, die alle serverseitig zu erfüllenden Aufgaben bearbeiten kann. An dieser Stelle können nun in einem ersten Ansatz diejenigen Komponenten identifiziert werden, die zur Realisierung der in diesem Kapitel aufgestellten Anforderungen benötigt werden. Die Analytics Workbench soll nicht nur in Form der zuvor beschriebenen Workbench-View in das System des NetAnaReporters integriert werden, sondern einzelne Bestandteile wie Workflows, Templates und Analyseergebnisse sowie Visualisierungstechnologien sollen im gesamten Prozess der Entscheidungsunterstützung verwendet werden. So macht es bereits an dieser Stelle Sinn, dieses System in die Konzeption mit einfließen zu lassen, um so bereits vorhandene Systembestandteile gemeinsam nutzen zu können. Betrachtet man die in Kapitel vorgestellte Architektur der Analytics Workbench, 3 Siehe hierzu 56

65 4.3. Serverkomponente so fällt auf, dass auch diese sowohl über eine Client- wie auch eine Serverkomponente verfügt. Die Serverkomponente erfüllt in diesem Fall nur die Aufgabe eines Webservers. Sie stellt also lediglich die für die Bereitstellung der über das Frontend der Analytics Workbench realisierten Funktionalitäten benötigten Dateien zur Verfügung. Das Frontend selbst kommuniziert mit den SQLSpaces, indem es die zur Durchführung von Analysen benötigten Tuples (siehe hierzu auch Abschnitt 4.3.2) erzeugt sowie Callbacks direkt auf den SQLSpaces registriert. Im Rahmen der Integration in das System des NetAnaReporters soll die hierfür genutzte Anwendungslogik in die Serverkomponente verlagert werden. So kann den zuvor beschriebenen, evtl. auftretenden Problemen, entgegengewirkt werden. Auch bietet dieser Ansatz die Möglichkeit, die aufgestellten Anforderungen bezüglich des Nutzer- und Rollenkonzeptes an das System auch für die integrierte Analytics Workbench umzusetzen. Die Abbildung 4.1 zeigt eine erste, grundlegende Architekturübersicht mit der integrierten Analytics Workbench. Das Frontend kommuniziert in diesem Fall ausschließlich mit der auf Node.js basierenden, zuvor beschriebenen Serverkomponente. Diese übernimmt ihrerseits die Kommunikation mit den SQLSpaces und erfüllt gleichzeitig die Funktion des Webservers über den die vom Frontend angeforderten Dateien abgerufen werden können. Abbildung 4.1.: Erstes Konzept für eine Gesamtarchitektur des NetAnaReporters Der hier entwickelte Ansatz bietet bereits alle unmittelbar benötigten server- wie auch clientseitigen Komponenten, um die in diesem Kapitel entwickelten Anforderungen an das System des NetAnaReporters grundsätzlich umsetzen zu können. Neben der zur Darstellung der verschiedenen Views benötigten Clientkomponente ist eine Serverkom- 57

66 4. Systementwurf ponente, anhand derer der vorgesehene Portalansatz realisierbar ist, vorhanden. Auch eine Möglichkeit zur Persistierung von Daten, etwa zum Vorhalten von Nutzerprofilen, Templates, Rollen- und Gruppeninformationen sowie Reports, ist mit den SQLSpaces gegeben. Das Ergebnis-Repository, realisiert durch einen eigens hierfür reservierten Bereich im Dateisystem, bietet der Serverkomponente die Möglichkeit, Ergebnisse aus Analysen jederzeit abzurufen, sowie andere Inhalte, wie beispielsweise statische Reports auf diese Weise abzulegen. Es konnten keine unmittelbaren Nachteile identifiziert werden, die gegen die gemeinsame Nutzung der hier beschriebenen serverseitigen Komponenten sprechen. Somit sollen die hier vorgestellten Komponenten zur Implementierung des Systems des NetAnaReporters genutzt werden. Im Folgenden sollen die für die technische Umsetzung der einzelnen Funktionalitäten und Konzepte des NetAnaReporters benötigten Vorraussetzungen entwickelt werden. Da der hier beschriebene Ansatz die Nutzung der SQLSpaces als zentrale Datenbankkomponente vorsieht, müssen somit Tupletypen entwickelt bzw. im Falle von der Analytics Workbench zuzuordnenden Tuples Tupletypen angepasst werden. Dabei soll sich hinsichtlich des Grundaufbaus der einzelnen Tupletypen an den bereits vorhandenen und in Abschnitt vorgestellten Tupletypen der Analytics Workbench orientiert werden. Hier besteht mit Ausnahme der noch zu beschreibenden Workflow-Save-Tuples jeweils das erste Feld aus einer systemweit eindeutigen ID, und das zweite Feld aus einem Zahlenwert, der den Typ des jeweiligen Tuples beschreibt. Im Anschluss an die Konzeption der einzelnen Tupletypen soll ein Ansatz entwickelt werden, der aktuelle Statusinformationen zu am System angemeldeten Nutzern verfügbar macht User / Rollen / Gruppen Um Nutzerprofile, die einen Anwender des NetAnaReporters beschreiben, sowie die in Kapitel bezüglich der Rollen- und Gruppenkonzepte aufgestellten Anforderungen realisieren zu können, sollen sowohl User- als auch Role- und Group-Tuples definiert werden. Zuordnungen zwischen Nutzern und Rollen sowie Gruppen sollen über User- Group-Link- sowie User-Role-Link-Tuples realisiert werden. Ein User-Tuple soll wie folgt aufgebaut sein. {User-ID, 21, User-Name, User-Password, User- } Das Feld User-Name enthält den vom Nutzer gewählten Anwendernamen, der zu Zwecken der Anzeige im Frontend sowie in Kombination mit dem im Feld User- Password gespeicherten Nutzerkennwort zur Anmeldung am NetAnaReporter genutzt wird. Die im Feld User- enthaltene -Adresse des Nutzers soll zu Kommunikationssowie Benachrichtigungszwecken genutzt werden. Ein Role-Tuple soll wie folgt aufgebaut sein. {Role-ID, 24, Role-Name} 58

67 4.3. Serverkomponente Im Feld Role-Name wird der Name der jeweils anhand dieses Tuples abgebildeten Nutzerrolle vorgehalten. Da für die Nutzung des NetAnaReporters die Rollen Administrator, Analyst, Reporter sowie Entscheidungsträger vorgesehen sind, gibt es systemweit also insgesamt lediglich vier diesen Rollen entsprechende Tuples. Ein Group-Tuple soll wie folgt aufgebaut sein: {Group-ID, 22, Group-Name} Im Feld Group-Name wird der Name der jeweils anhand dieses Tuples abgebildeten Gruppe vorgehalten. Ein User-Role-Link-Tuple soll wie folgt aufgebaut sein: {Role-Link-ID, 25, User-ID, Role-ID} Anhand der Kombination der beiden in den Feldern User-ID und Role-ID vorgehaltenen Ids kann so einem Nutzer eine Rolle zugeordnet werden. Pro Nutzer soll nur eine Rollenzuordnung ermöglicht werden, somit existiert pro Nutzer genau ein einziges Tuple diesen Typs. Ein User-Group-Link-Tuple soll wie folgt aufgebaut sein: {Group-Link-ID, 23, User-ID, Group-ID} Anhand der Kombination der beiden in den Feldern User-ID und Group-ID vorgehaltenen Ids kann so ein Nutzer einer bestimmten Gruppe zugeordnet werden. Da ein jeder Nutzer theoretisch einer unbegrenzten Anzahl von Gruppen angehören dürfen soll, kann für einen jeden Nutzer somit entweder kein Tuple diesen Typs, eins oder auch mehrere existieren Genutzte Datenstrukturen der Analytics Workbench Die Analytics Workbench setzt in ihrer zu Beginn dieser Masterarbeit vorliegenden Form vier verschiedene Tupletypen ein. Dabei handelt es sich zunächst um Command- sowie Data-Tuples, die zur Steuerung und zum Betrieb des der Analytics Workbench zugrundeliegenden Multi-Agenten-Systems eingesetzt werden. Darüber hinaus existieren Error- Tuples, die Informationen zu aufgetretenen Fehlern im Rahmen einer durchgeführten Analyse beschreiben sowie Workflow-Save-Tuples, die es ermöglichen, Workflows zu speichern und anschließend zu laden. Ein Command-Tuple bildet einen Filter aus einem durchzuführenden Workflow ab und ist wie folgt aufgebaut : {Run-ID, 2, Status, Agent-Instance-ID, Agent-Type, Wiring, Parameters} 59

68 4. Systementwurf Die im Feld Run-ID vorgehaltene ID ist für alle zu einem Durchlauf eines Workflows gehörenden Command-, Data sowie Error-Tuples gleich und wird bei dessen Ausführung automatisch erzeugt. Somit können alle zu einem Durchlauf eines Workflows gehörenden Elemente identifiziert werden. Das Feld Status kann die Werte 1 (waiting), 2 (running) oder 3 (finished) enthalten und gibt somit den aktuellen Status des Filters im Rahmen des betreffenden Durchlaufs an. Das Feld Agent-Instance-ID enthält eine eindeutige, automatisch erzeugte und den jeweiligen Filter repräsentierende ID. Im Feld Agent-Type wird die Information darüber gespeichert, welche Art von Agent dieser Filter repräsentiert. Das Feld Wiring enthält Informationen über den oder die auf diesen Filter im Workflow nachfolgenden Filter. Die im Feld Parameters enthaltenen Informationen beschreiben schließlich die Parametrisierung des betroffenen Filters. Ein Workflow besteht somit aus mehreren Command-Tuples. Ein Data-Tuple repräsentiert eine Pipe und somit den Datenfluss zwischen zwei verschiedenen Tuples. Dieser Tupletyp ist wie folgt aufgebaut: {Run-ID, 1, Agent-Instance-ID, Data*} Über das Feld Agent-Instance-ID wird der zugehörige Filter bestimmt. Auf diese Weise können die in diesem Tuple enthaltenen Daten dem durch den Filter dargestellten Verarbeitungsschritt zugeordnet und von dem entsprechenden Agenten genutzt werden. Über das Feld Data* bzw. beliebige weitere Felder können Daten in einem Tuple vorgehalten werden. Ein Workflow besteht also aus mehrenen Data-Tuples, die zum Datenaustausch zwischen den einzelnen Agenten genutzt werden. Ein Error-Tuple gibt im Fehlerfall Auskunft und ist wie folgt aufgebaut: {Run-ID, 5, Agent-Instance-ID, Error-Message} Über das Feld Agent-Instance-ID wird derjenige Filter bestimmt, bei dessen Durchführung ein Fehler aufgetreten ist, wobei das Feld Error-Message die jeweilige Fehlerbeschreibung in Textform enthält. Dem Workflow-Save-Tuple kommt im Rahmen dieser Arbeit eine besondere Rolle zu. Es bildet komplette Workflows ab, indem es Informationen zu den einzelnen enthaltenen Filtern, deren Parametrisierung sowie Informationen zu den diese jeweils verbindenen Pipes enthält. Ein solches Tuple wird bei Nutzung der Speicherfunktionlität der Analytics Workbench erzeugt. Es ist wie folgt aufgebaut: 60

69 4.3. Serverkomponente { any, 3, WF-Name, WF-Description, WF-Configuration} Das erste Feld des Tuples enthält in jedem Fall den Wert any. Somit ist klar, dass nur ein Workflow im Allgemeinen, ohne Zuordnung zu einem bestimmten Run durch ein solches Tuple beschrieben wird. Das Feld WF-Name enthält den Namen des Workflows, der beim Speichern dieses vergeben werden kann. Im Feld WF-Description wird die Beschreibung des Workflows, die ebenfalls beim Speichern dieses eingetragen werden kann, vorgehalten. Das Feld Wiring schließlich enthält die Beschreibung des gesamten Workflows in Form eines JSON-Strings. Dieser hat die folgende Form: { modules :[...], wires :[...], properties :{ name :, description :}}. Das Array modules enthält dabei die Beschreibungen der einzelnen Filtertypen sowie die jeweilige Parametrisierung dieser. Zusätzlich ist hier die absolute Positionierung des Filters auf der Workflowoberfläche anhand von Koordinaten abgelegt. Das Array wires beschreibt die Pipes zwischen den Filtern des Workflows. Das Feld name enthält, falls vergeben, den Namen des gespeicherten Workflows, das Feld description entsprechend die Beschreibung. Nach Beschreibung der einzelnen, durch die Analytics Workbench bereits eingesetzten Tupletypen wird deutlich, dass sich durch den alleinigen Einsatz dieser Tuples nicht alle Anforderungen, die bezüglich Workflows, Runs, Analyseergebnissen und insbesondere Templates an das System des NetAnaReporters erfüllen lassen. Im folgenden Abschnitt werden aus diesem Grund bestehende Tupletypen modifiziert sowie weitere hinzugefügt Workflows / Runs / Results Eine Anforderung an das System ist es, Workflows im Kontext einer konkreten Analyse, also einem Durchlauf des vollständig parametrisierten Workflows, darstellen zu können. So soll anhand dieses Workflows in der AnalysisExplorer-View aufgezeigt werden können, wie einzelne Ergebnisse aus einer Analyse entstanden sind. Somit müssen zu einzelnen Workflows unter Umständen mehrere Runs existieren können. Darüber hinaus soll nachvollziehbar sein, welcher Nutzer zu welchem Zeitpunkt einen Workflow gespeichert sowie eine darauf basierende Analyse durchgeführt hat. Die bereits vorhandenen, durch die Analytics Workbench genutzten Tupletypen erfüllen diese Anforderungen nicht. Aus diesem Grund soll sowohl das Workflow-Save-Tuple modifiziert werden als auch ein neuer Tupletyp, das Workflow-Run-Tuple, definiert werden. Das Workflow-Save-Tuple soll in der optimierten Form wie folgt aufgebaut sein: {Workflow-ID, 3, Short-Name, Description, Wiring, User-ID, Save-Date} In Abweichung zu dem ursprünglichen Workflow-Save-Tuple wird im ersten Feld des Tuples eine eindeutige Workflow-ID gespeichert. 61

70 4. Systementwurf In dem neu hinzugekommenen Feld User-ID wird die einen User eindeutig identifizierende und über das entsprechende User-Tuple beschreibende ID vorgehalten. So kann jederzeit der Ersteller eines Workflows festgestellt werden. Das Feld Save-Date enthält das Datum sowie die Uhrzeit zum Speichervorgang. Das Workflow-Run-Tuple soll sich wie folgt zusammensetzen: {Run-ID, 7, Workflow-ID, User-ID, Exec-Date, Status} Das Feld Run-ID enthält die diesen Durchlauf einer Analyse eindeutig identifizierende ID. Anhand der im Feld Workflow-ID gespeicherten ID kann das Workflow-Save-Tuple, das den durchgeführten Workflow beschreibt, eindeutig zugeordnet werden. Über die im Feld User-ID gespeicherte ID kann über das entsprechende User-Tuple derjenige Nutzer identifiziert werden, der diesen Run durchgeführt hat. Das Feld Exec-Date hält den genauen Zeitpunkt, zu dem der Run gestartet wurde, fest. Im Feld Status wird der aktuelle Zustand eines Runs festgehalten. So kann dieses Feld die Werte 1 (waiting), 2 (executing), 3 (done) oder 5 (error) enthalten. Die Struktur der im Feld Wiring enthaltenen Workflowbeschreibung wird soweit angepasst, dass auch Templates durch diese beschrieben werden können. Im Abschnitt wird näher auf die Struktur der Daten dieses Feldes eingegangen. Um die Kombination aus Workflow-Save- und Workflow-Run-Tuples nutzen zu können, muss sichergestellt werden, dass bei Durchführung eines Runs der zugrundeliegende Workflow bereits gespeichert wurde. Andernfalls kann im Workflow-Run-Tuple das entsprechende, auf den Workflow verweisende Feld nicht belegt werden. So soll ein noch nicht existierendes Workflow-Save-Tuple automatisch angelegt werden, wenn der Workflow gestartet wird. Eine weitere Anforderung an das System ist die Möglichkeit, Ergebnisse aus bestimmten Analysen anzeigen zu können. Zu diesem Zweck wird ein neuer Tupletyp, das Result- Tuple, definiert. Dieses soll den folgenden Aufbau haben: {Run-ID, 8, Result-Info, Agent-Instance-ID} Über die im Feld Run-ID vorgehaltene ID, die ein Workflow-Run-Tuple identifiziert, kann ein Result eindeutig einem Run, also einer durchgeführten Analyse, zugeordnet werden. Das Feld Result-Info enthält den Pfad zu den im Dateisystem gespeicherten, einem Ergebnis zugehörigen Dateien. Dabei sind diese in Verzeichnissen, die nach dem Muster../Workflow-Run-ID/Agent-Instance-ID/... benannt sind, abgelegt. Anhand der im Feld Agent-Instance-ID gespeicherten ID, die einen Filter eines bestimmten Typs identifiziert, soll der Result-Typ leichter bestimmbar sein. So muss nicht erst die Agent-Instance-ID aus den im Feld Result-Info enthaltenen Daten extrahiert werden. 62

71 4.3. Serverkomponente Anhand der hier vorgestellten Tupletypen lassen sich nun fast alle an Workflows, Runs sowie Analyseergebnisse gestellten Anforderungen erfüllen. Die Möglichkeit, den Zugriff auf diese Elemente anhand der jeweiligen Gruppenzugehörigkeit eines Nutzers abhängig machen zu können, soll mit Hilfe der in Abschnitt einzuführenden Tupletypen realisiert werden. Die hier vorgestellten Tupletypen sollen sowohl in der Analytics Workbench genutzt werden, als auch im Rahmen der Reporterstellung. Die Durchführung von Anpassungen, die dazu an Teilen der Analytics Workbench nötig sind, sollen nicht Teil dieser Masterarbeit sein aber parallel dazu vorgenommen werden Templates Analog zu den Workflow-Save-Tuples soll ein neuer Tupletyp, das Template-Tuple, definiert werden. Anhand dieses Tuples sollen Templates gespeichert und unterschiedlichen Nutzergruppen über den entsprechenden, in Abschnitt einzuführenden Tupletyp zur Verfügung gestellt werden können. Ein Template-Tuple soll wie folgt aufgebaut sein: {Template-ID, 9, Template-Name, Template-Description, Template-Configuration, User-ID, SaveDate} Die einzelnen Felder entsprechen in ihrer jeweiligen Funktion bis auf die Benennung den Feldern eines Workflow-Save-Tuples. An dieser Stelle soll auf die notwendigen Veränderungen an der JSON-Struktur der im Feld Wiring gespeicherten Informationen zu einem Template eingegangen werden. In Abschnitt wurde die JSON-Struktur der im Wiring Feld enthaltenen Daten des Workflow-Save-Tuples beschrieben. Zu jedem Filter kann dabei für jedes enthaltene parametrisierbare Feld ein Wert im Array modules angegeben werden. Diese Wertzuweisung ist folgendermaßen strukturiert: { value : <Wert> } Somit können zwar die einzelnen Felder eines Filters parametrisiert werden, die für Templates in Kapitel geforderte Möglichkeit zur Beschränkung der Parametrisierbarkeit kann mit diesem Mittel jedoch nicht realisiert werden. Deshalb sollen die Zuweisungen anhand einer modifizierten Datenstruktur vorgenommen werden können. Diese ist im Folgenden für die einzelnen geforderten Fälle dargestellt: Ein vollständig parametrisierbares Feld, ohne vorausgewählten Parameter: { value :{ configurable : free }} Ein vollständig parametrisierbares Feld, mit vorausgewähltem Parameter: { value :{ configurable : free, value : <Wert> }} Ein eingeschränkt parametrisierbares Feld, mit vorausgewähltem Parameter: { value :{ configurable : range, range : [ <Wert a>, <Wert b>,...], value : <Wert a> }} Ein nicht parametrisierbares Feld, ohne vorausgewählten Parameter: { value :{ configurable : false }} 63

72 4. Systementwurf Reports und Reportelemente Um den Anforderungen bezüglich der Möglichkeit Reports anlegen und anhand verschiedener Elemente zusammenstellen zu können gerecht zu werden, sollen zwei weitere Tupletypen eingeführt werden. Das Report-Element-Tuple bildet dabei einzelne zu einem Report gehörende Elemente ab, das Report-Tuple stellt den eigentlichen Report dar, dem solche Elemente zugeordnet sein können. Das Report-Element-Tuple soll wie folgt aufgebaut sein: {Report-Element-ID, 27, Report-ID, Element-Type, Workflow-ID, Run-ID, (Agent-Instance-ID)} Das Feld Report-Element-ID enthält die dieses Element eindeutig identifizierende ID. Die im Feld Report-ID gespeicherte ID verweist auf den Report, dem dieses Reportelement zugewiesen ist. Ein Reportelement kann somit nur im Kontext genau eines Reports existieren. Für den hier nicht vorgesehenen Fall, dass Reportelemente unterschiedlichen Reports zugewiesen sein können, müsste an stelle dieses Feldes ein neuer Link-Tupletyp definiert werden. Das kann beispielsweise in Orientierung an den in Abschnitt eingeführten Link-Tuples geschehen. Der in Feld Element-Type enthaltene Wert gibt Auskunft über die Art des durch ein Tuple dieses Typs repräsentierte Reportelement. Hier kann unter Berücksichtigung der in Kapitel gemachten Anforderungen und zusätlichen in Kapitel 3.5.5gezeigten Reportelemente zwischen fünf verschiedenen Arten unterschieden werden. Anhand der ersten beiden Arten von Reportelementen können Metainformationen zu einer Analyse bzw. einem Template in Kurz- oder Langform dargestellt werden. Weiter kann ein zu einer Analyse und/oder Template gehörender Workflow anhand eines Reportelements dargestellt werden. Auch Ergebnisse aus Analysen in ihren unterschiedlichen Ausprägungen bilden eine weitere Art von Reportelement. Die letzte Form von Reportelement eignet sich zur Einbringung von frei definierbaren und formatierbaren Inhalten wie Text, Bilder oder Hyperlinks. Über die im Feld Workflow-ID vorgehaltene ID kann ein Element einem bestimmten Workflow in eindeutiger Weise zugeordnet werden. Über die Run-ID kann ein Reportelement darüber hinaus eindeutig einem Workflow wie auch Run zugeordnet werden, was die im vorhergehenden Feld vorgehaltene Workflow-ID in dem Fall, dass ein betreffender Workflow bereits ausgeführt wurde, überflüssig macht. Das Feld Agent-Instance-ID wird genau dann mit einem Wert belegt, wenn über ein Tuple diesen Typs ein Ergebnis eines durchgeführten Workflows abgebildet wird. So kann über die im Feld vorgehaltene Agent-Instance-ID eins von mehreren möglichen Analyseergebnissen eindeutig identifiziert werden. 64

73 4.3. Serverkomponente Berechtigungen auf Gruppenebene Um die in Kapitel aufgestellten Anforderungen bezüglich der Zugriffsbeschränkungen auf Reports, Analyseergebnisse sowie Workflows und Templates in Abhängigkeit der Zugehörigkeit eines Nutzers zu bestimmten Gruppen realisieren zu können, sollen drei neue Tupletypen eingeführt werden. Das Report-Group-Link-Tuple soll dabei einen Report, das Result-Group-Link-Tuple ein Analyseergebnis und das Workflow-/Template-Group- Link-Tuple einen Workflow bzw. ein Template einer Gruppe zuordnen. Die einzelnen Tupletypen sollen dabei wie folgt aufgebaut sein: {Report-Group-Link-ID, 28, Report-ID, Group-ID} {Result-Group-Link-ID, 29, Result-ID, Group-ID} {WfT-Group-Link-ID, 30, Workflow-/Template-ID, Group-ID} Da alle drei Tupletypen grundsätzlich den gleichen Aufbau haben und sich nur in der Art der Daten, die in den einzelnen Feldern vorgehalten werden sollen, unterscheiden, können die einzelnen Felder dieser Tupletypen gemeinsam beschrieben werden: Das erste Feld enthält eine ID, die ein Tuple diesen Typs eindeutig identifizierbar macht. Das dritte Feld enthält jeweils die ID, die das Element, welches einer Gruppe zugeordnet werden soll, identifiziert. Die im vierten Feld enthaltene ID identifiziert die Gruppe, der ein Report, Analyseergebnis oder Workflow bzw. Template zugeordnet werden soll Statusinformationen zu Systemnutzern Um serverseitig ständig den aktuellen Nutzungskontext eines jeden angemeldeten Nutzers sowie weitere aktuelle Daten abrufen zu können, sollen entsprechende Informationen in geeigneter Weise persistiert und jederzeit durch die Serverkomponente zugreifbar sein. Da es sich bei diesen Daten im Gegensatz zu den zuvor konzipierten Datenstrukturen um Informationen handelt, die in direktem Zusammenhang mit der Nutzung des Systems stehen, sollen diese in einer separaten Komponente gehalten werden. Hierzu fällt die Wahl auf die Open-Source Datenbank Redis 4. Einerseits verspricht der Einsatz einen schnellen Zugriff auf die in Form von Key-Value-Paaren abgelegten Daten. Andererseits eignet sich diese Datenbank für die Persistierung von Sessions, die im Rahmen der Authentifizierung (siehe hierzu Kap ) und somit für die Kommunikation zwischen Client- und Serverkomponente des NetAnaReporter Systems genutzt werden sollen, da ein entsprechendes Modul 5 für Node.js verfügbar ist. Die zu einem Nutzer vorzuhaltenen Daten (Values) sollen die folgenden Informationen enthalten und über ein im Rahmen der Nutzerauthentifikation erstelltes, eindeutiges User-Token (Key) zugegriffen werden können: 4 Siehe hierzu 5 Das Modul connect-redis bietet diese Funktionalität. Siehe hierzu connect-redis. 65

74 4. Systementwurf Die jeweils systemweit eindeutige User-ID. Die aktuelle Socket-ID. Die ID des jeweils geladenen Reports. Die aktuell angezeigte View. Die ID des aktuell angezeigten Templates. Die ID der aktuell angezeigten Analyse (Workflow, der bereits ausgeführt wurde). Der Zeitunkt der letzten Nutzerinteraktion. Anhand dieser Informationen soll jederzeit festgestellt werden können, welcher Report aktuell geladen ist und welche View der Anwender nutzt. Darüber hinaus soll serverseitig erkennbar sein, welches Template bzw. welcher Workflow einer durchgeführten Analyse betrachtet wird. Diese Informationen sollen dann im Rahmen der Durchführung unterschiedlicher Aufgaben, wie beispielsweise dem Ausführen eines Templates, genutzt werden können. Zu Autorisierungszwecken soll die Information zum Zeitpunkt der letzten Nutzerinteraktion eingesetzt werden können. So soll ein Nutzer, der über einen längeren Zeitraum keine Interaktion (der Wert soll hier auf 30 Minuten festgesetzt werden) mit der Serverkomponente durchgeführt hat, automatisch vom System abgemeldet werden. Die Information zur Socket-ID soll genutzt werden, um serverseitig initiiert mit dem jeweiligen Client in Kontakt treten zu können Konzept für die Gesamtarchitektur Zuvor wurden bereits Client- wie auch Serverkomponente in einem ersten Konzept für die Gesamtarchitektur vorgestellt. Im Anschluss wurden die für die Realisierung des NetAnaReporters sowie der damit verbundenen Integration der Analytics Workbench in den NetAnaReporter benötigten Datenstrukturen konzipiert. Auch eine zusätzliche Datenbankkomponente, die aktuelle Nutzerinformationen sowie Session-Daten vorhalten soll, wurde konzipiert. Die Abbildung 4.2 zeigt zusammenfassend die einzelnen, erarbeiteten Konzepte. Anhand der Einfärbung der verschiedenen Elemente wird verdeutlicht, welche Komponenten einerseits im Rahmen dieser Masterarbeit implementiert werden sollen (blau) und andererseits zur Analytics Workbench zu zählen sind (grau), die in Teilen parallel dazu weiterentwickelt werden sollen. Die einzelnen Tupletypen sind zu Zwecken der einfacheren Zuordnenbarkeit auf drei verschiedene Spaces verteilt. 66

75 4.4. Konzept für die Gesamtarchitektur Abbildung 4.2.: Konzept der Gesamtarchitektur 67

76

77 5. Implementierung In diesem Kapitel werden die Ergebnisse der Umsetzung der in den Kapiteln 3 und 4 beschrieben Anforderungen und Konzepte aufgezeigt. Dazu wird zunächst eine grundlegende Übersicht über wichtige Teile und Abläufe des implementierten Systems des NetAna- Reporters gegeben. Im Anschluss daran werden die einzelnen in Kapitel 3 konzipierten Views des Benutzerinterface in ihrer realisierten Form vorgestellt und die Umsetzung einzelner Funktionalitäten, unter Einbeziehung der Server- wie auch der Clientkomponente, näher betrachtet Übersicht der realisierten Architektur In Kapitel 4.4 wurde ein Konzept für die Gesamtarchitektur des Systems des NetAna- Reporters vorgestellt. Im Folgenden sollen insbesondere die als Serverkomponente und Frontend bezeichneten Elemente in ihrer realisierten Form in ihrem grundlegenden Aufbau vorgestellt werden. Anschließend wird aufgezeigt, wie die Kommunikation zwischen den einzelnen beteiligten Komponenten abläuft und in welcher Weise die Anforderungen an die Rechteverwaltung im Rahmen der Implementierung berücksichtigt wurden Clientkomponente Die Clientkomponente hat, wie bereits in Kapitel 4.2 beschrieben, die Aufgabe, dem Nutzer die Interaktion mit dem System zu ermöglichen. Hierzu werden anhand einer grafischen Benutzeroberfläche auf Seiten des Servers erzeugte Informationen angezeigt, wie auch Benutzereingaben entgegengenommen und serverseitig verarbeitet. Die einzelnen Views bestehen zu diesem Zweck jeweils aus den folgenden Komponenten: Eine View-spezifische HTML-Datei. Diese stellt das grundlegende Layout und einzelne Elemente der Benutzeroberfläche zur Verfügung. Dazu gehören das in Kapitel konzipierte Grundgerüst der Benutzeroberfläche, wie auch die Viewspezifischen Inhalte des UI. Eine JavaScript-Datei. Das enthaltene Script stellt die Anwendungslogik, die benötigt wird, um Inhalte der jeweiligen View darstellen und manipulieren zu können sowie mit der Serverkomponente in View-spezifischer Weise kommunizieren zu können, bereit. Eine oder mehrere, unter Umständen gemeinsam genutzte CSS-Dateien. Hierüber werden Layout- und Designinformationen bereitgestellt. Zusätzlich werden von den Views einzelne Elemente gemeinsam genutzt: 69

78 5. Implementierung Ein von allen Views gemeinsam genutztes Script stellt grundlegende Funktionalitäten bereit. Dazu zählen Überprüfung des Login-Status des jeweiligen Nutzers, Navigationsfunktionalitäten und Verbindungsaufbau der jeweiligen Socket.IO- Verbindung. Alle Views nutzen zu Darstellungs-, Manipulations- und Kommunikationszwecken unterschiedliche Bibliotheken bzw. Frameworks. Die wichtigsten sind hierbei, wie in Kapitel 4.2 angesprochen, Bootstrap, JQuery und Socket.IO. Zusätzlich kommen weitere (teilweise) gemeinsam genutzte Ressourcen wie beispielsweise Bilddateien zum Einsatz. Einige andere zur Abbildung View-spezifischer Funktionalitäten eingesetzte Technologien werden im weiteren Verlauf dieses Kapitels vorgestellt Serverkomponente Neben der Funktion eines einfachen Web-Servers, der die in Abschnitt aufgezählten clientseitig benötigten Dateien zum Abruf bereit hält, stellt die Serverkomponente, wie in Kapitel 4 angesprochen, den Hauptteil der Applikationslogik. Diese Komponente ist mit Hilfe von Node.js realisiert. Dabei kommen unterschiedliche Module, die der Serverkomponente weitere Funktionalitäten hinzufügen, zum Einsatz. In einer Unterteilung kann zwischen im Standardumfang von Node.js enthaltenen Modulen, Third-Party-Modulen und solchen, die im Rahmen der Implementierung des NetAnaReporters entstanden sind, unterschieden werden. Das in Abbildung 5.1 dargestellte Diagramm zeigt die einzelnen verwendeten Node.js- / Fremdmodule und NetAnaReporter-Module. Auf die Darstellung der einzelnen Abhängigkeiten in Form von genutzten Funktionalitäten der unterschiedlichen Module zueinander soll aufgrund der großen Anzahl an Modulen wie auch Abhängigkeiten an dieser Stelle verzichtet werden. Die einzelnen verwendeten Node.js- / Fremdmodule sollen an dieser Stelle nicht näher betrachtet werden. Einige dieser Module werden allerdings im weiteren Verlauf dieses Kapitels angesprochen. Die verschiedenen NetAnaReporter-Module nutzen diese in unterschiedlicher Ausprägung, um ihre jeweiligen Funktionalitäten zur Verfügung stellen zu können. Diese sollen im Folgenden kurz aufgezeigt werden: Das Modul sqlspacesservices bietet alle für die Realisierung der einzelnen Funktionen des NetAnaReporters benötigten lesenden und schreibenden Zugriffe auf die SQLSpaces in Funktionsform an. Das Modul tupleutils stellt Funktionen zur Verfügung, um die in Kapitel 4.3 aufgezählten Tupletypen auf einfache Art erzeugen zu können. Das Modul socketservices stellt die Schnittstelle zur Nutzung der Socket.IO- Kommunikation zwischen Client- und Serverkomponente dar. Im Modul routes sind die einzelnen Routen 1, die im Rahmen der HTTP-basierten Kommunikation genutzt werden, definiert. 1 Siehe hierzu auch [Rau12] S

79 5.2. Grundlegende Kommunikationsabläufe Das Modul authorizationservices stellt Funktionen zur Verfügung, die im Rahmen der Authentifikation der von Clientseite gestellten Anfragen an die Serverkomponente in Form von HTTP- oder Socket.IO-basierter Kommunikation genutzt werden. Das Modul managementservices stellt Funktionalitäten bereit, die verschiedene Informationen über aktuell am System angemeldete Nutzer zugreifbar machen. Somit dienen die im Modul vorgehaltenen Funktionen als Schnittstelle zu der in Kapitel angesprochenen Redis-Datenbankkomponente. Das Modul viewservices bietet Funktionaliäten, die zur dynamischen Erzeugung von HTML-Elementen eingesetzt werden. Das Modul resultservices stellt Funktionen zur Verfügung, anhand derer Ergebnisse von mit Hilfe der Analytics Workbench durchgeführten Analysen für die Darstellung vorbereitet werden können. Das Modul reportservices bietet die benötigten Funktionalitäten, um Reports zusammenstellen zu können. Anhand der Funktionen im Modul explorerutils können Templates dargestellt und zu Zwecken der Ausführung analysiert werden. Das Modul communicationservices bietet die Funktionalitäten, die benötigt werden, um Nachrichten zwischen Nutzern versenden zu können. Anhand der Funktionen im Modul notificationservices können Benachrichtigungen von Nutzern zu bestimmten Ereignissen, wie beispielsweise der Information über neu verfügbare Analyseergebnisse, realisiert werden. Das Modul apputils stellt allgemein nutzbare Funktionalitäten, wie beispielsweise das Erzeugen eindeutiger IDs, zur Verfügung. Abbildung 5.1.: Übersicht der verwendeten Module Grundlegende Kommunikationsabläufe In diesem Abschnitt sollen exemplarisch die grundlegenden Kommunikationsabläufe zwischen den einzelnen Komponenten des Systems unter Berücksichtigung der beteiligten NetAnaReporter-Module dargestellt werden. Somit kann im weiteren Verlauf des Kapitels auf die erneute, explizite Darstellung dieser Abläufe im Rahmen der im einzelnen vorgestellten Systemkomponenten und Funktionalitäten verzichtet werden. 71

80 5. Implementierung Um einerseits die einzelnen Views der Anwendung im Browser darstellen wie auch die enthaltenen Funktionalitäten in Abhängigkeit der aktuellen Nutzerrolle wie auch Gruppenmitgliedschaft nutzen zu können, muss der jeweilige Nutzer am System angemeldet sein. Die jeweiligen Zugriffsberechtigungen betreffen auf technischer Ebene sowohl Teile der durch die Serverkomponente zur Verfügung gestellten Dateien unterschiedlichster Art wie auch Funktionsaufrufe basierend auf HTTP- oder Socket.IO-Kommunikation. Im Folgenden soll somit zunächst der grundlegende Ablauf der Kommunikation zwischen den beteiligten Komponenten im Rahmen der auf Basis von HTTP-Kommunikation durchgeführten initialen Nutzerauthentifikation betrachtet werden. Im Anschluss daran werden kurz die Abläufe im Rahmen der Autorisierung von HTTP- und Socket.IObasierter Kommunikation beschrieben Initiale Authentifikation des Nutzers (a) Initiale Anfrage (b) Authentifizierung Abbildung 5.2.: Initiale Nutzerauthentifikation Die Abbildung 5.2 zeigt in übersichtlicher Form die Architektur des NetAnaReporters, reduziert auf die an der Nutzerauthentifikation direkt beteiligten Komponenten auf Server- wie auch Clientseite. Anhand gestrichelter Linien sind nicht-dauerhafte HTTP- Verbindungen dargestellt. Bei der als durchgängige Line dargestellten Verbindung zwischen Server-Komponente und SQLSpaces sowie der Socket.IO-basierten Verbindung zwischen Client- und Serverkomponente handelt es sich jeweils um dauerhafte Verbindungen. Letztere existiert für die Zeit, in der ein Client am System angemeldet ist sowie eine View im Browser angezeigt wird. Zunächst soll der initiale Aufruf der Web-Applikation durch den Client anhand von Abbildung 5.2(a) aufgezeigt werden. Zu Beginn stellt der Nutzer eine initiale Anfrage an die Serverkomponente (Schritt 1). Wird dabei eine unverschlüsselte Verbindung genutzt, so wird automatisch auf eine SSL-verschlüsselte HTTP-Kommunikation umgeleitet. Anhand einer für diesen intitialen Fall allgemein im Modul routes definierten Route und der in diesem Zusammenhang genutzten Funktionalität des Modules AuthorizationServices wird geprüft, ob die in diesem Fall existierende Session ein bestimmtes User-Token 72

81 5.2. Grundlegende Kommunikationsabläufe enthält (Schritt 2 und 3). Da der Client zuvor nicht am System angemeldet war, ist das nicht der Fall, und es wird direkt eine HTML-Seite, die ein Login-Formular bereitstellt, an den Client ausgeliefert (Schritt 4). Anhand der Abbildung 5.2(b) soll der darauf folgende Anmelde-Vorgang am System beschrieben werden. Nach Absenden der über das Login-Formular eingegebenen Nutzerdaten (Schritt 1) wird eine Anfrage an die Serverkomponente gestellt. Auch für diesen Fall existiert eine spezielle Route. Da es sich um eine Login-Anfrage handelt, werden die übermittelten Daten direkt validiert. Dazu werden die Daten mit den in den SQLSpaces liegenden User-Tuples verglichen (Schritt 2 und 3). Die Anfrage an die SqlSpaces wird anhand des Modules sqlspacesservices vorgenommen. Stimmen die Daten überein, so wird ein User-Token erstellt, anhand dessen aktuelle Nutzerinformationen in der Redis- Datenbank (Schritt 4) gespeichert werden. Dazu zählen Informationen über die dem Nutzer entsprechende Standard-View, sowie über den aktuelle Zeitpunkt dieser Nutzerinteraktion. Diese Schritte werden mit Hilfe des Moduls managementservices durchgeführt. Zusätzlich wird das User-Token in die aktuelle Session geschrieben (Schritt 5). Nun ist der Nutzer am System angemeldet. Nach Feststellung der jeweiligen Nutzerrolle über die entsprechenden Role-Tuples sowie User-Role-Link-Tuples (zusammenfassend Schritt 6 und 7) wird die der jeweiligen Nutzerrolle entsprechende Standard-Startseite an den Client ausgeliefert (Schritt 8). Im Anschluss daran wird eine ebenfalls verschlüsselte Socket.IO-Verbindung hergestellt (Schritt 9). Dieser Verbindungsaufbau wird von Clientseite initiiert und serverseitig mit Hilfe entsprechender Funktionalitäten im Modul socketservices akzeptiert. Hierzu wird erneut geprüft, ob die Session ein User-Token enthält und der Zeitpunkt der letzten Nutzerinteraktion nicht zu weit zurückliegt (Schritt 10 bis 12). In diesem Rahmen wird auch der aktuelle Zeitpunkt sowie die Socket-ID festgehalten. Von diesem Zeitpunkt an werden Navigationsschritte zwischen den Views sowie das Abmelden und erneute Anmelden am System per HTTP-basierter Kommunikation durchgeführt. Jegliche Art von Funktionsaufrufen von Client- oder Serverseite werden über Socket.IO-basierte Kommunikation realisiert. Im Folgenden werden Beispiele für beide Fälle aufgezeigt Autorisierung von HTTP- und Socket.IO-basierten Anfragen Im Folgenden soll dargestellt werden, welche Schritte im Rahmen der Autorisation von clientseitig initiierten HTTP- sowie Socket.IO-basierten Anfragen von am System angemeldeten Nutzern durchlaufen werden. Als Beispiel für eine HTTP-basierte Anfrage sollen Vorgänge aufgezeigt werden, die im Rahmen eines Viewwechsels stattfinden. Als Beispiel für eine Socket.IO-basierte Interaktion sollen entsprechende Vorgänge beschrieben werden, die bei Aufruf einer beliebigen serverseitigen Funktionalität auftreten. Abbildung 5.3(a) stellt die einzelnen, im Falle einer HTTP-basierten Anfrage durchlaufenen Schritte dar. Im Rahmen der HTTP-basierten, clientseitig initiierten Anfrage an die Serverkomponente (Schritt 1) wird zunächst geprüft, ob ein User-Token in den Sessiondaten vorhanden ist (Schritt 2 und 3). Da dies zutrifft, wird anschließend überprüft, ob die letzte Interaktion mit dem System nicht zu weit zurückliegt (Schritt 4 und 5). Da dem nicht so ist, wird der aktuelle Zeitpunkt eingetragen. Anschließend wird überprüft, ob dem Nutzer die für die Darstellung der angefragten View benötigte Rolle zugewiesen 73

82 5. Implementierung (a) Initiale Anfrage (b) Authentifizierung Abbildung 5.3.: Autorisierung von Anfragen ist (Schritte 6 und 7). Ist der Nutzer autorisiert, so kann die gewünschte View an den Client ausgeliefert werden (Schritt 8). Nach Laden der neuen View wird erneut geprüft, ob der Client am System angemeldet ist sowie der Zeitpunkt der letzten Interaktion nicht zu lange zurück liegt (Schritte 9 bis 13). In diesem Rahmen werden erneut Informationen zum Interaktionszeitpunkt sowie der aktuell angezeigte View festgehalten. Die bedingt durch das Neuladen der HTML-Seite abgebrochene Socket.IO-Verbindung wird anschließend neu aufgebaut (Schritt 15) und die in der geladenen View initial anzuzeigenden Informationen über diesen Weg angefragt. Ein Beispiel für einen solchen Fall wird im Folgenden dargestellt. Die Abbildung 5.3(b) zeigt die einzelnen Schritte, die im Rahmen einer Socket.IObasierten Anfrage durchgeführt werden. So wird nach Initiierung der Anfrage (Schritt 1) zunächst geprüft, ob ein User-Token in den Daten der Nutzersession vorhanden ist (Schritt 2 und 3) und die aktuelle Nutzerinteraktion nicht zu lange zurück liegt (Schritt 4 und 5). Dabei wird erneut der Zeitpunkt der Nutzerinteraktion festgehalten. Anschließend werden die im Modul authorizationservices definierten Regeln abgeprüft. Dabei wird erneut anhand der jeweiligen Rolle bestimmt, ob der Nutzer eine bestimmte, angefragte Funktionalität nutzen darf (Schritt 6 und 7). Ist das der Fall, so werden die im Rahmen der angefragten Funktionalität definierten Schritte unter Inanspruchnahme der Funktionen der einzelnen Module durchgeführt (diese Schritte und eventuell beteiligte sind hier nicht dargestellt). In diesem Rahmen kann unter anderem sowohl auf die in Kapitel 4.3 definierten Datenstrukturen aber auch auf die jeweils für den Nutzer vorgehaltenen aktuellen Informationen zurückgegriffen werden. In letzterem Fall kann so beispielsweise serverseitig der aktuell geladene Report festgestellt werden, dessen Report-ID im Rahmen eines anderen Socket.IO-basierten Aufrufs zum Laden dieses Reports festgehalten wurde. Ergebnisse, die den hier beschriebenen Aufruf betreffen, werden abschließend über die bestehende Socket.IO-Verbindung an den Client gesendet (Schritt 8). 74

83 5.3. Realisierung der einzelnen Views 5.3. Realisierung der einzelnen Views Im Folgenden sollen die einzelnen Bestandteile der Clientkomponente, insbesondere die einzelnen Views der Benutzeroberfläche, vorgestellt werden. In diesem Zusammenhang wird auch zu einigen wichtigen Funktionalitäten, in teilweise vereinfachter Form, aufgezeigt, wie diese realisiert wurden. Generell ist festzuhalten, dass für die Anzeige einer bestimmten View im Browser, der Nutzer am System angemeldet sein muss. Die in diesem Rahmen durchlaufenen Schritte wurden in Abschnitt 5.2 detailliert aufgezeigt. Auch wurde in Abschnitt gezeigt, dass nach dem Laden einer View, die initial in dieser darzustellenden Informationen per Socket.IO-Kommunikation über die Serverkomponente abgerufen werden. Dieser Schritt kann, je nach View und serverseitig verfügbarer Datenlage unter Umständen aus mehreren, parallel ablaufenden oder aufeinander aufbauenden Anfragen bestehen. Da die dabei und im Rahmen der Bereitstellung weiterer Funktionalitäten durchlaufenen Einzelschritte bereits exemplarisch aufgezeigt wurden, soll in den folgenden Abschnitten nicht mehr detailliert auf diese eingegangen und vereinfachend von Anfragen gesprochen werden. Die Umsetzung der in den folgenden Abschnitten jeweils dargestellten Frontendkomponenten sowie der serverseitig bereitzustellenden Funktionalitäten wurde in starker Orientierung an den in den Kapiteln 3.2 und 3.5 beschriebenen Anforderungen und Konzepten und Entwürfen durchgeführt Grundaufbau und Administration-View Abbildung 5.4.: Realisierte Administration-View Die Abbildung 5.4 zeigt die realisierte Administration-View. Es ist zu erkennen, dass der Grundaufbau der Benutzerfläche in enger Orientierung an dem in Abbildung 3.4 dargestellten Mockup realisiert wurde. Die Navigations- und Optionsleiste bildet den oberen Rand der Benutzeroberfläche. Hier dargestellte Information werden direkt nach Laden der View auf Serverseite angefragt und anschließend dargestellt. Funktionen wie das Anlegen oder Laden neuer Berichte sind über das Optionsmenü erreichbar und per 75

84 5. Implementierung entsprechendem, dynamisch eingeblendeten Dialogfenster durchzuführen. Notifikationen zu neu verfügbaren Analyseergebnissen sowie Templates werden, unabhängig von der dargestellten View als dynamische Popups eingeblendet. Zu diesem Zweck sind serverseitig entsprechnende Callbacks auf den SQLSpaces registriert, um im Ereignissfall die einzelnen Clients informieren zu können. Darunter befindet sich der View-spezifische Teil. Dieser entspricht in seiner implementierten Form ebenfalls größtenteils der konzeptionellen Vorlage, die in Abbildung dargestellt ist. Nach Laden dieser View werden minimale Informationen zu allen auf der Plattform verfügbaren Nutzerkonten zusammengestellt. Bei Auswahl eines Nutzers werden detailliertere Informationen zu diesem angefragt und anschließend im Benutzerinterface angezeigt. Anhand dieser können die in den Anforderungen 3.2 definierten Aufgaben durchgeführt werden. Neue Gruppen und Nutzer können per dynamisch eingeblendetem Dialogfenster erstellt werden. Die durchgeführten Änderungen werden anschließend an die Plattform gesendet, wo sie anhand der entsprechenden Tupletypen persistiert werden Workbench-View Abbildung 5.5.: Realisierte Workbench-View Die Abbildung 5.5 zeigt die in die Benutzeroberfläche des NetAnaReporters vollständig integrierte Analytics Workbench. Wie bereits in Kapitel 4.3 konzipiert, findet die Kommunikation zwischen dem Frontend der Analytics Workbench und den SQLSpaces in dieser Implementierung nicht auf direktem Wege statt. Der dafür zuständige Connector wurde durch eine neu implementierte Variante ersetzt. Somit kommuniziert das Frontend der Analytics Workbench hier direkt mit der Serverkomponente des NetAnaReporters. Nach Laden der View wird die Logik der Analytics Workbench ausgeführt und dabei die ID des jeweils am NetAnaReporter System angemeldeten Nutzers übergeben. Dies geschieht bei Einsatz der eigenständigen, nicht im System des NetAnaReporters integrierten Analytics Workbench normalerweise durch manuelle Eingabe des Nutzernamens. Auf diese Weise kann die Analytics Workbench ohne weitere Eingriffe und mit Hilfe des neu implementierten Connectors im System des NetAnaReporters eingesetzt werden. 76

85 5.3. Realisierung der einzelnen Views Werden aus der Workbench heraus Workflows gestartet oder gespeichert, so werden Informationen zu dem entsprechenden Workflow mit Hilfe des Connectors an die Serverkomponente übermittelt. Dort werden die entsprechenden Tuples generiert und in die SQLSpaces geschrieben. Auch Callbacks werden durch die Serverkomponente auf den TupleSpaces registriert, um neue Ereignisse an das Frontend der in der Clientkomponente ausgeführten Analytics Workbench melden zu können. Auch das Laden von Workflows findet über den Umweg der Serverkomponente des NetAnaReporters statt AnalysisExplorer-View Abbildung 5.6.: Realisierte AnalysisExplorer-View Die Abbildung 5.6 zeigt die realisierte AnalysisExplorer-View. Nach Laden der View werden grundlegende Informationen zu verfügbaren Analysen sowie Templates von der Serverkomponente angefordert. Bei Auswahl einer Analyse oder eines Templates werden diese im linken Navigationsbereich sowie eingeschränkt im rechten Bereich der View in Form von zwei zu dem jeweiligen Report hinzufügbaren Elementen dargestellt. Zusätzlich werden weitere Informationen, die für die Darstellung des zugehörigen Workflows benötigt werden, angefragt. Dabei wird serverseitig im Falle einer Analyse das jeweilige Workflow-Save-Tuple analysiert und eine HTML-Repräsentation des Workflows generiert. Um einen Workflow in der AnalysisExplorer-View darstellen zu können, wird zuvor ein ebenfalls HTML-basierter Container generiert und in das clientseitig dargestellte Dokument an entsprechender Stelle eingefügt. Zur Container-Erstellung wird ein Jade 2 Template verwendet. Der entsprechende Container enthält unter anderem ein Canvas Element, das von der clientseitig zur Darstellung von Workflows verwendeten JavaScript Bibliothek js-graph.it 3 verwendet wird. Anschließend können die zuvor generierten und den Workflow repräsentierenden HTML-Elemente in den in das Dokument integrierten Container eingefügt werden. Die Abbildung 5.6 zeigt eine solche Workflowdarstellung. Für den Fall, dass ein Workflow dargestellt werden soll, der ein Template repräsentiert, 2 Bei Jade handelt es sich um eine Template Engine für Node.js. Siehe hierzu 3 Js-graph.it ist eine JavaScript Bibliothek zur Darstellung von Graphen. Siehe hierzu js-graph-it.sourceforge.net/index.html. 77

86 5. Implementierung werden zuvor die in Kapitel erwähnten und den darzustellenden Filtern entsprechenden Filterbeschreibungen der Analytics Workbench serverseitig betrachtet. So können mögliche Parameter für die einzelnen Felder der im darzustellenden Template-Workflow enthaltenen Filter identifiziert werden. Anhand der in dem Template-Tuple des Workflows abgelegten Informationen zur Beschränkung der Parametrisierbarkeit (s. Kap ) können anschließend nicht zur Wahl zu stellende Parameter ausgeschlossen werden sowie Felder parametrisierbar oder statisch dargestellt werden. Anhand dieser Informationen wird zunächst, wie im Fall der Analyse-Workflows, erneut ein Container in das Dokument eingefügt, in dem anschließend die erzeugten HTML-Elemente des Template- Workflows dargestellt werden können. Die beiden eingangs erwähnten und in Abbildung 5.6 an erster und zweiter Stelle dargestellten Elemente werden jeweils ebenfalls mit Hilfe eines serverseitig per Jade Template generierten Containers im Frontend dargestellt. Eine anhand eines in der AnalysisExplorer-View dargestellten und evtl. parametrisierten Template-Workflows repräsentierte Analyse kann auf Wunsch ausgeführt werden. Dazu werden die HTML-Elemente, die den Workflow repräsentieren, an die Serverkomponente übermittelt. Anhand dieser werden die entsprechenden Tuples generiert und anschließende in die SQLSpaces geschrieben. Dieser Vorgang ähnelt der Vorgehensweise beim Ausführen von Workflows aus der Workbench-View. Bei Darstellung einer Analyse und Auswahl eines Durchlaufs im Optionsmenü werden zusätzlich die zugehörigen Analyseergebnisse angefordert. Diese können dann zusätzlich zu den zuvor erwähnten Elementen im rechten Bereich der View dargestellt werden. Die Abbildung 5.6 zeigt in Teilen eine Visualisierung von Ergebnissen aus einer mit Hilfe der Analytics Workbench durgeführten sozialen Netzwerkanalyse. Zum Zweck der Darstellung dieser wird auf die Visualisierungstechniken der Analytics Workbench zurückgegriffen. Zunächst wird serverseitig der Visualisierungstyp durch Analyse der im jeweiligen Ergebnisverzeichnis des Dateisystems liegenden Dateien festgestellt. Anschließend wird vorbereitend anhand eines Jade Templates serverseitig ein HTML-basierter Container erzeugt und in das Dokument der im Frontend dargestellten AnalysisExplorer-View eingefügt. Anhand des zu dem jeweiligen Visualisierungstyp gehörenden und für die Nutzung im NetAnaReporter stellenweise angepassten Scripts, können dann die im Zielverzeichnis auf Serverseite liegenden Daten angefordert werden und im Frontend visualisiert werden. Nachdem alle darzustellenden Elemente vollständig geladen sind, wird per Anfrage an die Serverseite für jedes Element geprüft, ob dieses bereits einem Report zugewiesen ist. Der diesbezüglich aktuelle Status wird neben dem jeweiligen Element angezeigt. Soll ein Element zu einem Report hinzugefügt werden, so wird serverseitig ein Report- Element-Tuple erzeugt und die jeweilige ID in das den geladenen Report repräsentierende Report-Tuple eingetragen. Im umgekehrten Fall wird der Eintrag und das entsprechende Report-Element-Tuple gelöscht. Der Erfolg einer solchen Operation wird anhand der sich geänderten Statusanzeige neben dem jeweiligen Element ersichtlich. Die Abbildung 5.6 zeigt drei dem aktuellen Report zugewiesene Elemente. Die AnalysisExplorer-View bietet zusätzlich die Möglichkeit, mit einem Analysten Kontakt aufzunehmen. Dazu wird ein Dialogfenster eingeblendet. Die potentiell zur Auswahl stehenden Empfänger einer Nachricht werden im Rahmen der Anzeige des Dialogfensters nach Anfrage serverseitig ermittelt. Dabei wird nach Nutzern mit der Rolle des Analysten, die den gleichen Gruppen angehören wie der Verfasser, gefiltert. So soll sichergestellt werden, dass die daraufhin evtl. erstellten Templates auch vom Nachrichtenverfasser genutzt werden dürfen. Anschließend werden die möglichen Empfänger clientseitig 78

87 5.3. Realisierung der einzelnen Views im Dialogfenster zur Wahl gestellt und nach Eingabe des Nachrichtentextes per serverseitig versendeter 4 benachrichtigt. So besteht die Chance, unabhängig von der Verfügbarkeit des NetAnaReporters Nachrichten empfangen zu können ReportComposer-View Abbildung 5.7.: Realisierte ReportComposer-View In der Abbildung 5.7 ist die realisierte ReportComposer-View dargestellt. Nach Laden dieser View werden Informationen zu dem darzustellenden Report und dessen Bestandteilen angefragt. Für die Darstellung von Analyseergebnissen sowie Workflows wird auf die gleiche Weise verfahren, wie dies im Abschnitt dargestellt wurde. Abweichend werden für die Generierung der HTML-basierten Container alternative Jade Templates verwendet. Einerseits sollen die einzelnen, darzustellenden Reportelemente laut Anforderung farblich, nach ihrer jeweiligen Analysezugehörigkeit markiert werden können, andererseits müssen Schaltflächen, die eine Umordnung der Elemente auf der Darstellungsfläche ermöglichen, bereitgestellt werden. Nach Betätigung einer solchen Schaltfläche wird eine Anfrage an die Serverkomponente gestellt, in deren Rahmen die Reihenfolge der Reportelement-Ids in dem zugehörigen Report-Tuple entsprechend der neuen Anordnung der Elemente in der ReportComposer-View geändert wird. Bei Erfolg wird das entsprechende Element in der Dokumentenstruktur der ReportComposer-View neu positioniert. Über die beiden zuvor angesprochenen Elementtypen hinaus zeigt die Abbildung einen weiteren Elementtyp. Hierbei handelt es sich um ein Reportelement, das weitere, in Kapitel bezüglich der möglichen Reportinhalte, definierte Anforderungen erfüllt. Im hier dargestellten Fall ist eine automatisch aus den Metainformationen der diesem Element zugrundeliegenden Analyse generierte Beschreibung in Textform enthalten. Dieses Reportelement besitzt zwei Modi und wird je nach darzustellendem Fall mit Hilfe eines von zwei unterschiedlichen Jade Templates serverseitig erzeugt und in die Dokumentenstruktur des ReportComposers eingefügt. Im hier dargestellten Fall wird der Vorschaumodus gezeigt. In diesem Modus wird der Inhalt des Elements in der gleichen Formatierung 4 In diesem Rahmen kommt das Node.js Modul Nod er zum Einsatz. Siehe hierzu nod er.com/. 79

88 5. Implementierung dargestellt, wie sie auch im Fall der Darstellung in der ReportViewer-View eingesetzt würde. Durch Umschalten in den Editiermodus wird serverseitig für dieses Element ein neuer Container erzeugt, der den zuvor dargestellten in der ReportComposerView ersetzt. Der Container des Editiermodus ermöglicht die anschließende Nutzung des CLEditors 5. Durch die Nutzung dieses Editors kann unter anderem Text in formatierter Form eingegeben, sowie Hyperlinks und Bilder aus Onlinequellen dem Element hinzugefügt werden. Bei der im Rahmen des Wechsels zurück in den Vorschaumodus durchgeführten Anfrage werden die Inhalte als HTML-String an die Serverkomponente übergeben und im jeweiligen Report-Element-Tuple persistiert. Weitere solcher Reportelemente können dem aktuellen Report in der ReportComposer-View hinzugefügt werden. Aus Gründen der Konsistenz zu den anderen vorgestellten Kommunikationsfunktionalitäten sind die zur Erstellung von und Benachrichtigung über statische Reports benötigten Bedienelemente anhand eines dynamisch einzublendenen Dialogfensters realisiert (s. hierzu auch Abb. 6.6 in Kap. 6.2). Im Rahmen der Darstellung dieses Dialogs werden zunächst ähnlich wie in Abschnitt beschrieben, die potentiellen Empfänger eines solchen Berichts ermittelt. In diesem Fall stellen allerdings nicht Analysten, sondern Entscheidungsträger die Zielgruppe dar. Anschließend besteht die Möglichkeit, die zu erzeugenden statischen Formate sowie Empänger auszuwählen. Darüber hinaus kann ein Nachrichtentext eingetragen und entschieden werden, ob die zu erzeugenden statischen Reportformate als Anhang der per zu versenden Nachricht beigefügt werden sollen. Anhand der so ermittelten Informationen und einer zusätzlich übermittelten Kopie der dargestellten Reportelemente, die insbesondere die Übertragung des aktuellen Status der einzelnen Visualisierungen ermöglicht, werden serverseitig entsprechende statische Versionen des Reports erzeugt und im Dateisystem abgelegt. Die Erstellung der statischen Reports erfolgt dabei mit Hilfe von PhantomJS 6 und dem für Node.js zur Verfügung stehenden Modul phantomjs-node 7. Anschließend werden die Nachrichten an die ausgewählten Empfänger versendet ReportViewer-View Die Abbildungen 5.8 und 5.9 zeigen die realisierten Varianten der ReportViewer-View. Nach Laden der View werden zunächst grundlegende Informationen zum Report angefragt und im linken Bereich der View dargestellt. Durch eine Anfrage an die Serverkomponente wird serverseitig geprüft, ob statische Versionen des dargestellten Reports im entsprechenden Verzeichnis des Dateisystems existieren. Ist das der Fall, so können diese durch Anklicken der entsprechenden Schaltflächen heruntergeladen werden. Zu diesem Zweck wird eine HTTP-basierte Anfrage genutzt, wobei die serverseitigen Funktionalitäten anhand einer entsprechenden Route angestoßen werden. Auch alle zu dem geöffneten Report gehörenden Reportelemente werden angefragt und im rechten Bereich der View dargestellt. Das geschieht auf die gleiche Art wie im Falle der Darstellung dieser Elemente in der ReportComposer-View. Für die Generierung der HTML-basierten Container werden allerdings alternative Jade Templates verwendet. Zusätzlich können Nachrichten versendet werden. Das geschieht auf die gleiche Weise wie schon in der 5 CLEditor ist ein WYSIWYG (What You See Is What You Get) HTML Editor. Siehe hierzu http: //premiumsoftware.net/cleditor/. 6 PhantomJS ist eine über die Kommandozeile einsetzbare Version der Browserengine Webkit. Siehe hierzu 7 Siehe hierzu 80

89 5.3. Realisierung der einzelnen Views Abbildung 5.8.: Realisierte ReportViewer-View Abbildung 5.9.: Realisierte ReportViewer-View (mobile Version) AnalysisExplorer-View, wobei die potentiellen Adressaten in diesem Fall die Rolle des Reporters inne haben. Der Bereich der View, in dem die Reportelemente angezeigt werden, befindet sich in der mobilen Variante der ReportViewer-View, wie im Entwurf in Abbildung 3.10 dargestellt, unterhalb der Optionsleiste. An dieser Stelle ist anzumerken, dass auch die Nutzung der anderen Views des NetAnaReporters, mit Ausnahme der Workbench-View, auf mobilen Endgeräten möglich ist. Im Konzept wurde insbesondere die Möglichkeit, vollständige Reports anhand der ReportViewer-View anzeigen zu können, als sinnvoll dargestellt und als Anforderung formuliert. Diese ist somit erfüllt und dem Nutzer ist darüber hinaus freigestellt, auch die anderen Views auf mobilen Endgeräten zu verwenden. 81

90

91 6. Anwendungsbeispiel In diesem Kapitel soll exemplarisch ein Beispiel für den Einsatz des implementierten Systems des NetAnaReporters anhand eines Einsatzszenarios durchgeführt werden. So soll gezeigt werden, dass die im Rahmen dieser Masterarbeit definierten Anforderungen durch die realisierte Web-Applikation erfüllt werden. Zunächst werden zu diesem Zweck die Rahmenbedingungen abgesteckt, um darauf folgend die einzelnen Schritte vorzustellen, die während der Durchführung des Anwendungsbeispiels durchlaufen werden Rahmenbediungungen In Kapitel 3.1 wurde ein mögliches Szenario für den Einsatz des NetAnaReporters vorgestellt. Dabei wurde davon ausgegangen, dass im Rahmen der Verteilung von Fördermitteln an Wissenschaftler oder Forschergruppen, Erkenntnisse, basierend auf Ergebnissen von Analysen sozialer Netzwerke, in die Entscheidungsfindung für die Mittelzuteilung einfließen können. Das hier vorzustellende Anwendungsbeispiel soll sich an dieser Thematik orientieren. Dazu werden drei unterschiedliche Nutzer, die jeweils eine der in Kapitel vorgestellten Rollen Entscheidungsträger, Reporter oder Analyst ausfüllen, unter Zuhilfenahme des NetAnaReporters zusammenarbeiten. Der Ablauf des Anwendungsbeispiels orientiert sich dabei in den einzelnen Schritten an dem in Kapitel 3.4 vorgestellten Prozess der Entscheidungsunterstützung. Als Ausgangspunkt für das hier darzustellende Anwendungsbeispiel wird von einer Situation ausgegegangen, in der einem Entscheidungsträger ein Projektantrag vorliegt. Neben den Ergebnissen aus der Prüfung von inhaltlichen Aspekten des Antrags sollen auch Informationen zu den beteiligten Wissenschaftlern in die Entscheidungsfindung einfließen Durchführung des Anwendungsbeispiels Für den Entscheidungsträger erscheint es wichtig, einschätzen zu können, inwiefern die einzelnen, an dem vorliegenden Antrag beteiligten Wissenschaftler Erfahrungen auf zuvor identifizierten, besonders relevanten Themengebieten besitzen. Zusätzlich sollen Informationen, die Aufschlüsse über die Zusammenarbeit mit anderen beteiligten Wissenschaftlern geben können, mit in die Entscheidungsfindung einfließen. Nach Anmeldung am System legt der Enscheidungsträger einen neuen Report an, um die ReportViewer-View im Kontext des zu erstellenden Reports nutzen zu können. Die Notwendigkeit, einen Bericht an dieser Stelle erstellen bzw. laden zu müssen, steht in direktem Zusammenhang mit dem hier verwendeten Verständnis des View-Begriffs, wonach eine solche die Sicht auf einen bestimmten Report darstellt. Dem Report wird im Rahmen der Erstellung ein Name zugewiesen (Abbildung 6.1 zeigt den dazu verwendeten 83

92 6. Anwendungsbeispiel Dialog). Anschließend stellt der Entscheidungsträger eine Informationsanfrage an einen für ihn verfügbaren Reporter (Abbildung 6.2 zeigt den dazu verwendeten Dialog). Der kontaktierte Reporter liest die empfangene . Falls dieser Nutzer nicht am Abbildung 6.1.: Initiales Anlegen und Benennen eines Reports. Abbildung 6.2.: Kontaktaufnahme mit dem Reporter. System angemeldet ist, so loggt er sich ein und läd den entsprechenden Report. Im Anschluss analysiert er die Anfrage des Entscheidungsträgers und bewertet die einzelnen, ihm zur Verfügung stehenden Datensätze sowie Analysemethoden anhand der einzelnen über die AnalysisExplorer-View parametrisierbaren sowie anwendbaren Templates. In Ermangelung geeigneter Datensätze sowie Analysemethoden wendet sich der Reporter an einen für ihn verfügbaren Analysten. Er sendet hierzu eine Nachricht an diesen und fordert geeignete Templates und in diesem Zusammenhang analysierbare Daten. Der Reporter äußert den Vorschlag, Publikationsdatenbanken für die Beschaffung von analysierbaren Datensätzen einzusetzen. Auch äußert er grundsätzliche Vorstellungen, wie die zu analysierenden Datensätze beschaffen sein sollten, um möglichst den Vorstellungen des Entscheidungsträgers entsprechende Ergebnisse erzielen zu können. Die Entscheidung, Templates zur eigenständigen Durchführung der Analysen anzuforden, anstelle die einzelnen Analyseschritte vom Analyst selbst durchführen zu lassen, wird dabei bewusst getroffen. So können in ähnlichen Situationen die vorbereiteten Methoden erneut, ohne Hilfe des Analysten, durchgeführt werden. Da das Interface im Wesentlichen dem des zur Kontaktaufnahme zwischen Entscheidungsträger und Reporter entspricht, wird an dieser Stelle auf eine Abbildung verzichtet. Der angeschriebene Analyst meldet sich nach Empfang, falls nötig, ebenfalls an der Plattform an und läd den entsprechenden Report. Im Anschluss stellt er zunächst die angeforderten Datensätze zusammen. Auf den Prozess der Datenzusammenstellung soll an dieser Stelle nicht näher eingegangen werden. Für die weitere Beschreibung dieses An- 84

93 6.2. Durchführung des Anwendungsbeispiels wendungsbeispiels wurde ein fiktiver Datensatz erzeugt. Dieser enthält ein Two-Mode- Netzwerk bestehend aus 10 Wissenschaftlern, die teilweise und dabei in unterschiedlich starker Ausprägung an 15 im Netzwerk enthaltenen Publikationen gearbeitet haben (Siehe dazu Anhang B.1). Um dieses Netztwerk darstellen zu können erstellt der Analyst mit Hilfe der Workbench-View ein entsprechendes Template. Dieses sieht verschiedene Visualisierungstypen vor und schränkt die auswählbaren Datensätze nicht ein, als Vorauswahl bestimmt der Analyst den hier erzeugten Datensatz. Ein zweites Template soll dem Reporter ermöglichen, das Two-Mode-Netzwerk zu falten, so dass ein One-Mode- Netzwerk, was die Zusammenarbeit der einzelnen Reporter miteinander darstellen soll, auf unterschiedliche Weise visualisiert werden kann. Zusätzlich soll für jeden Reporter die Degree-Centrality bestimmt und das Ergebnis ebenfalls anhand unterschiedlicher Visualisierungstechniken dargestellt werden. Die Beschränkungen der Parametrisierbarkeit des Templates soll sich am zuvor erstellten orientieren, die Felder des für die Faltung zuständigen Filters sollen nicht parametrisierbar sein. Die hier beschriebenen Schritte der Templateerstellung sind an dieser Stelle nicht anhand von Abbildungen dargestellt, da die im Rahmen dieser Masterarbeit eingesetzte Version der Analytics Workbench dieses Feature noch nicht anbietet. Die den beschriebenen Templates zugrundeliegenden Daten sind im Anhang dieser Arbeit gelistet (siehe hierzu B.2). Der Reporter wird über die Verfügbarkeit der neuen Templates jeweils per in das Benutzerinterface eingeblendetem Popup informiert. Er wählt in der AnalysisExplorer- View zunächst das Template zur Visualisierung des Two-Mode-Netzwerkes aus. Auch das zweite Template nutzt er zum Ausführen des entsprechenden Workflows (Abbildung 6.3). Über die erzeugten Ergebnisse wird der Reporter ebenfalls per jeweils eingeblendetem Popup informiert. Er betrachtet die verschiedenen Ergebnisse mit Hilfe der AnalysisExplorer-View. Da ihm für die Anzeige der Ergebnisse jeweils diejenige Visualisierungsform am verständlichsten erschient, die die enthaltenen Knoten des zu visualisierenden Graphen in zirkulärer Anordnung darstellen, fügt er die jeweiligen Visualisierungen dem geöffneten Report hinzu. Abbildung 6.4 zeigt exemplarisch die Visualisierung des kompletten Netzwerks, wobei die vorgenommene Zuordnung bereits zu erkennen ist. Auf das Hinzufügen weiterer Elemente verzichtet der Reporter, da er in diesem Fall keinen Vorteil darin sieht, Metadaten zu den durchgeführten Analysen oder die eingesetzten Workflows darzustellen. Der Reporter wechselt anschließend in die ReportComposer-View. Hier fügt er dem Bericht vier neue Reportelemente hinzu und ordnet die einzelnen Elemente um. Ein Element, welches die Überschrift und Einleitung des Berichts enthalten soll, positioniert er als erstes Reportelement. Anschließend ordnet er die verbleibenden sechs Elemente so an, dass jeweils eine Visualisierung und ein neu hinzugefügtes Reportelement abwechselnd untereinander angezeigt werden. Anschließend verfasst der Reporter durch Umschalten in den Editiermodus eines jeweiligen Elementes die Überschrift und Einleitung sowie eine kurze Erläuterung zu jeder Visualisierung. Die Abbildung 6.5 zeigt das Eintragen des einleitenden Textes. Der Reporter entscheidet sich im Anschluss daran, den Report per an den Entscheidungsträger, der diesen ursprünglich angefordert hat, zu versenden. Dazu nutzt er das in Abbildung 6.6 dargestellte Dialogfenster. Er wählt den entsprechenden Empfänger aus und trägt einen Nachrichtentext ein. Außerdem entscheidet er sich für die Erzeugung des statischen Berichts für beide verfügbaren Datenformate. Diese sollen zusätzlich auch als Anhang der versendet werden. Der Entscheidungträger betrachtet nach Empfang der Mail zunächst den statischen 85

94 6. Anwendungsbeispiel Abbildung 6.3.: Ausführen des Templates. Abbildung 6.4.: Visualisierung des zu dem Report hinzugefügten Netzwerkes. Report anhand der entsprechenden Dateien im Mailanhang. Abbildung 6.7 zeigt den erstellten, statischen Report. In dieser ist unter anderem ersichtlich, dass insbesondere Scientist A an vielen Veröffentlichungen beteiligt war. Außerdem stellt er für das Netzwerk einen sehr zentralen Akteur im Hinblick auf die Zusammenarbeit mit anderen dargestellten Akteuren dar. Eine weitere Bewertung dieser Erkenntnisse soll hier nicht verfolgt werden. Zur näheren Untersuchung der Ergebnisse entschließt sich der Entscheidungsträger, die Daten zusätzlich über die ReportViewer-View des NetAnaReporters zu betrachten. Hier besteht beispielsweise die Möglichkeit, in einzelne Teile der Visualisierungen hereinzuzoomen, um einzelne Aspekte der jeweiligen Ergebnisse näher betrachten 86

95 6.2. Durchführung des Anwendungsbeispiels Abbildung 6.5.: Bearbeitung der Berichtsinhalte. Abbildung 6.6.: Erzeugen des statischen Reports und Verfassen einer Nachricht. zu können. Abbildung 6.8 zeigt den fertigen Bericht in der ReportViewer-View. Abschließend kann der Entscheidungsträger die ihm zur Verfügung gestellten Informationen in die im Abschnitt 6.1 beschriebene Entscheidungsfindung mit einfließen lassen. 87

96 6. Anwendungsbeispiel Abbildung 6.7.: Der erzeugte statische Bericht. Abbildung 6.8.: Betrachten des erzeugten Reports in der ReportViewer-View. 88

97 7. Zusammenfassung und Ausblick 7.1. Zusammenfassung In dieser Masterarbeit wurde ein System konzipiert und erfolgreich realisiert, das die Nutzung von Ergebnissen aus Analysen sozialer Netzwerke im Rahmen der Unterstützung von Entscheidungsfindungen ermöglicht. So können mit Hilfe des entwickelten NetAna- Reporters verschiedene Werkzeuge eingesetzt werden, die die einzelnen, in diesem Zusammenhang durchzuführenden Arbeitsschritte ermöglichen. Die Applikation ermöglicht das Aufgreifen und Darstellen von Ergebnissen aus Analysen sozialer Netzwerke für die Zielgruppe der sogenannten Decision Makers. Diesen Entscheidungsträgern wird durch Nutzung der Applikation ermöglicht, zuvor zusammengestellte Reports, die aus unterschiedlichen Elementen bestehen, zu betrachten und dadurch vermittelte Informationen sowie gewonnene Erkenntnisse in Entscheidungen einfließen zu lassen. Dazu können sie sowohl auf Berichte, die in statischer Form abrufbar sind als auch auf Reports, die interaktiv navigierbar sind und somit in Teilen einen Dashboardansatz verfolgen, zugreifen. Auch die Nutzung mobiler Endgeräte zur Darstellung der entsprechenden Inhalte wird durch die Applikation ermöglicht. Für die Erstellung sowie Nutzung eines solchen Berichts wurde ein Prozess der Entscheidungsunterstützung entwickelt (s. Kap. 3.4), der verschiedene, zuvor identifizierte Nutzerrollen (s. Kap 3.1.2) und diesen eindeutig zugeordnete Aufgabenbereiche (s ) vorsieht. Dieser Prozess wurde aus einem prototypischen Szenario (s. Kap 3.1), welches eine Problemstellung und mögliche Lösungsansätze vorsieht, die mit Hilfe der den verschiedenen Rollen zugewiesenen Aufgabenbereichen gelöst wurde, entwickelt. Hierbei wurden auch zuvor recherchierte Grundlagen zum Begriff des Decision Makers sowie Grundlagen zu den Begrifflichkeiten des Berichts sowie Berichtswesens (s. Kap. 2.2) berücksichtigt. In dem entworfenen Prozess kommt der Rolle des Analysten die Aufgabe zu, Daten sowie vorkonfigurierte Analyseprozesse ((Templates), s. Kap 3.2.4) bereitzustellen, die zu Analysezwecken genutzt werden können. Die Rolle des Reporters sieht vor, Ergebnisse aus Analysen zu Reports zusammenzustellen und gegebenenfalls auf die von einem Analysten in Form von Templates bereitgestellten Möglichkeiten zu Analysezwecken zurückzugreifen, um eigenständig neue Informationen generieren zu können. Außerdem stellt der Reporter dem Entscheidungsträger den erstellten Bericht zur Verfügung. Um diesen Prozess mit Hilfe der in dieser Arbeit entwickelten Web-Applikation abbilden zu können, mussten verschiedene Problemstellungen behandelt werden. Zunächst musste ein grundlegendes Konzept identifiziert werden (s. Kap ), das den im Rahmen des Applikationsentwurfs formulierten Anforderungen an die von den einzelnen Rollen durchzuführenden Aufgaben genügen kann. Basierend auf den Ansätzen und Konzepten der in Kapitel 2 beschriebenen Management Support Systeme, Business Intelligence sowie vorgestellten Anwendungstypen zur Enscheidungsunterstützung, fiel die Wahl auf den in Kapitel beschriebenen Portalansatz. Hierdurch können verschiedene Rollen und diesen zuzuordnende Werkzeuge in integrierter Form über ein 89

98 7. Zusammenfassung und Ausblick Web-Frontend zugreifbar gemacht werden. Durch ein zentrales Login wird den Nutzern des NetAnaReporters der Zugriff auf die für ihre jeweiligen Rollen zur Verfügung gestellten Werkzeuge in Form sogenannter Views ermöglicht. Die Workbench-View stellt Funktionalitäten der im Rahmen des SISOB Projektes entwickelten und jeweils in den NetAnaReporter integrierten Version der Analytics Workbench für den Analysten bereit. Über die AnalysisExplorer-View sowie die ReportComposer-View kann der Reporter Ergebnisse aus Analysen einem Report hinzufügen, sowie Templates parametrisieren und so entsprechende Analysen ausführen. Anhand der ReportViewer-View kann der Entscheidungsträger sowohl interaktiv Reports betrachten, wie auch statische Varianten abrufen. Wie im Prozess der Entscheidungsunterstützung definiert, bestehen Möglichkeiten, die es bestimmten Nutzern ermöglichen, in vorgesehenem Umfang zu bestimmten Zwecken mit anderen Usern des Systems in Kontakt zu treten. Durch das implementierte Rollenund Gruppenkonzept (siehe Kap ) des NetAnaReporters können dynamisch Zugriffe auf Funktionalitäten und Daten eingeschränkt werden. Dazu verfügen Nutzer der zusätzlich definierten Rolle Administrator über eine entsprechende View, die die Berarbeitung von Nutzerprofilen ermöglicht. Für die technische Realisierung des Systems des NetAnaReporters wurde im Rahmen der Konzeption der benötigten Serverkomponente Node.js als Mittel der Wahl für die Implementierung dieser identifiziert (s. Kap. 4.3). Dieser Ansatz bietet einige Vorteile, wie beispielsweise die Möglichkeit zur Nutzung von Socket.IO, was den Einsatz von Websockets in modernen Browsern bzw. deren Emulation mit Hilfe alternativer Technologien auch in älteren Browsern ermöglicht. Hierdurch besteht die Möglichkeit der serverseitig initiierten Kommunikation mit dem Frontend des NetAnaReporters, was beispielsweise die Übermittlung von Notifications ermöglicht. So werden am System angemeldete Nutzer beispielsweise über neu erstellte Templates und Analyseergebnisse informiert. Auch existiert für Node.js ein Connector zu den SQLSpaces. Um die Funktionalität der Workbench-View zur Verfügung stellen zu können, wurde ein neuer Connector implementiert, der die Kommunikation der Workbench mit der Serverkomponente des Net- AnaReporters ermöglicht. Im Gegensatz zu der Funktionalität des ursprünglich eingesetzten Connectors übernimmt nun die Serverkomponente die Kommunikation mit den SQLSpaces, was die Realisierung einer Zugriffskontrolle ermöglichte. Um die volle Funktionalität des NetAnaReporters zu realisieren, wurden durch die Analytics Workbench genutzte Tupleformate erweitert, sowie eine Reihe neuer Tupletypen definiert (s. Kap. 4.3). Somit kommen auch für den Betrieb des NetAnaReporters die SQLSpaces zum Einsatz. Anhand eines durchgeführten und ausführlich dargestellten Anwendungsbeispiels (s.kap. 6), welches sich an dem für die Konzeption des NetAnaReporters entwickelten Szenario orientiert, konnte nachgewiesen werden, dass das im Rahmen dieser Masterarbeit entwickelte Konzept und die implementierte Web-Applikation die gegebenen Anforderungen erfüllt Ausblick Es lassen sich abschließend verschiedene Möglichkeiten identifizieren, um die hier entwickelte Web-Applikation sowohl in technischer als auch konzeptioneller Hinsicht zu erweitern. 90

99 7.2. Ausblick Das in dieser Arbeit entwickelte Konzept zur Erstellung und Nutzung von Reports orientiert sich an dem Ansatz des in Kapitel vorgestellten Bedarfsberichts. So wird die Berichterstellung jeweils von einem Entscheidungsträger, der einen bestimmten Informationsbedarf hat, initiiert. Grundsätzlich könnte auch die Integration von Features, die eine Reporterzeugung und -nutzung im Sinne der Konzepte des Standard- sowie Abweichungsberichts (siehe Kap ) ermöglichen, zur Unterstützung entsprechender Szenarien sinnvoll sein. Im Falle des Standardberichts könnten in regelmäßigen Abständen automatisch (auf Basis einer eventuell dynamischen Datengrundlage) zuvor definierte Analysen durchgeführt und anhand der Ergebnisse Reports erzeugt werden. Alternativ könnten, unter Nutzung des Ansatzes des Abweichungsberichtes, definierte Analysen automatisch auf Datenbeständen für den Fall durchgeführt werden, dass sich eine Veränderung an diesen ergeben hat. Für die beiden hier vorgeschlagenen, alternativen Varianten des Reportings könnten darüber hinaus zuvor definierte Reportvorlagen, die Layout sowie Inhalt eines automatisch generierten Berichts bestimmen, zum Einsatz kommen. Die Verwendung eines Abonnementmodells, in Anlehung an das in Kapitel für den Ansatz des Enterprise Reportings vorgestellte Modell, scheint für die beiden zuvor dargestellten Reportingvarianten sinnvoll. So könnte über die sich in diesem Fall anbietende Nutzung des Modells auf Basis von Nutzerprofil-Report-Zuweisungen hinaus ebenfalls das im NetAnaReporter integrierte Rollen- und Gruppenkonzept auf unterschiedliche Weise für die Registrierung als Reportempfänger genutzt werden. Es wäre beispielsweise denkbar, dass alle Nutzer einer oder mehrerer Gruppen über neu erstellte Berichte benachrichtigt werden, wobei Möglichkeiten geschaffen werden müssten, entsprechende Zuweisungen vornehmen zu können. Die im Rahmen dieser Arbeit genutzten Ansätze zur Benachrichtigung über neu verfügbare Analyseergebnisse sowie Templates könnten dahingehend erweitert werden. Die Kommunikation, die im Rahmen des in Kapitel 3.4 vorgestellten Prozesses beschrieben wird und zwischen den einzelnen Nutzern eines Systems erfolgt, basiert in der realisierten Version des NetAnaReporters auf über das Frontend initiierter - Kommunikation. Zusätzlich zu diesem wichtigen, zuvor argumentierten Kommunikationsweg, könnte ein In-App-Nachrichtendienst konzipiert werden. So könnten beispielsweise durch das Ermöglichen der Kommunikation, unabhängig von Report- und Viewkontext, Rückfragen oder Hilfestellungen im Rahmen der Durchführung unterschiedlicher Aufgaben ermöglicht werden. Grundsätzlich könnte diese Kommunikation auf Basis des vorhandenen Ansatzes, welcher im Rahmen der Benachrichtigung über neu verfügbare Analyseergebnisse sowie Templates bereits zum Einsatz kommt, realisiert werden. Dieser Ansatz sieht allerdings keine Speicherung von Nachrichten zum Zwecke des späteren Nachrichtenabrufs vor. Deshalb sollte der vorhandene Ansatz um entsprechende Funktionalitäten erweitert werden, insbesondere falls -Kommunikation nur noch optional oder gar nicht mehr zum Einsatz kommen soll. Bedingt durch den Umstand, dass die Analytics Workbench parallel zu der Erstellung dieser Masterarbeit weiterentwickelt wurde, existieren neue Funktionalitäten, die sowohl erweiterte Analyse- und Visualisierungsmethoden als auch Neuerungen und Verbesserungen des Benutzerinterfaces umfassen. Durch die Integration einer entsprechend aktuelleren Version der Analytics Workbench könnten diese somit auch unmittelbar im Kontext des NetAnaReporters genutzt werden. So würde, um ein konkretes Beispiel zu nennen, die Erzeugung von Templates direkt aus der Workbench-View des NetAnaReporters ermöglicht werden, sobald dieses Feature in einer aktuellen Version des Analytics Workbench Systems implementiert und diese in den NetAnaReporter integriert wurde. 91

100 7. Zusammenfassung und Ausblick Ein weiteres Beispiel wäre das Aufgreifen der im Rahmen der Nutzung einer neueren Version der Analytics Workbench aktiv zum Einsatz kommenden Möglichkeiten zur Signalisierung von Fehlerzuständen. Zunächst könnte dieses Feature Berücksichtigung in der integrierten Version der Analytics Workbench finden. Darüber hinaus könnte neben der Benachrichtigung über neu verfügbare Analyseergebnisse und Templates in den einzelnen Views, auf die gleiche Weise über Fehler, die während der Ausführung von Analysen aufgetreten sind, informiert werden. 92

101 Anhang A. Eidesstattliche Erklärung Ich versichere an Eides statt, dass ich für die vorliegende Masterarbeit keine unerlaubten Hilfsmittel gebraucht habe, und dass ich die Arbeit selbstständig und ohne fremde Hilfe angefertigt habe. Ich habe keine anderen als die angegebenen Quellen genutzt, sinngemäße oder wörtliche Entlehnungen daraus habe ich als solche gekennzeichnet. Die Arbeit hat in dieser oder in ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen. Ort, Datum Unterschrift 93

102

103 Anhang B. Verwendete Netzwerkdaten und Templates B.1. Netzwerk Diese Daten (im Pajek 1 -NET-Format) zeigen das im Rahmen des Anwendungsbeispiels (s. Kap. 6) analysierte Netzwerk. 1 Siehe hierzu 95

104 Anhang B. Verwendete Netzwerkdaten und Templates B.2. Template I Dieses Template wurde zur Visualisierung des Netzwerkes (s. Anhang B.1) im Rahmen des Anwendungsbeispiels (s. Kap. 6) verwendet. 96

105 B.2. Template I 97

106 Anhang B. Verwendete Netzwerkdaten und Templates B.3. Template II Dieses Template wurde zur Faltung, Bestimmung der Degree-Centrality und Visualisierung des Netzwerkes (s. Anhang B.1) im Rahmen des Anwendungsbeispiels (s. Kap. 6) verwendet. 98

107 B.3. Template II 99

108 Anhang B. Verwendete Netzwerkdaten und Templates 100

109 B.3. Template II 101

110 Anhang B. Verwendete Netzwerkdaten und Templates 102