ein software-werkzeug zur multiperspektivischen bewertung ... · tiver produkte, projekte und...

Ein Software-Werkzeug zur multiperspektivischen Bewertung innovativerProdukte, Projekte und Dienstleistungen

Köninger, Stephan; Heß, Michael

In: ICB Research Reports - Forschungsberichte des ICB / 2014

Dieser Text wird über DuEPublico, dem Dokumenten- und Publikationsserver der UniversitätDuisburg-Essen, zur Verfügung gestellt.

Die hier veröffentlichte Version der E-Publikation kann von einer eventuell ebenfallsveröffentlichten Verlagsversion abweichen.

DOI: https://doi.org/10.17185/duepublico/47027

URN: urn:nbn:de:hbz:464-20180914-095522-6

Link: https://duepublico.uni-duisburg-essen.de/servlets/DocumentServlet?id=47027

Lizenz:Sofern nicht im Inhalt ausdrücklich anders gekennzeichnet, liegen alle Nutzungsrechte bei den Urhebern bzw.Herausgebern. Nutzung - ausgenommen anwendbare Schrankenregelungen des Urheberrechts - nur mit derenGenehmigung.

Quelle: ICB-Research Report No. 62, October 2014

https://doi.org/10.17185/duepublico/47027

http://nbn-resolving.org/urn:nbn:de:hbz:464-20180914-095522-6

https://duepublico.uni-duisburg-essen.de:443/servlets/DocumentServlet?id=47027

��

��

Stephan KöningerMichael Heß

Realisierung im Projekt Hospital Engineering

ICB-Research Report No. 62

October 2014

Research Group Core Research Topics

Prof. Dr. H. H. AdelsbergerInformation Systems for Production and OperationsManagement

E-Learning, Knowledge Management, Skill-Management,Simulation, Artificial Intelligence

Prof. Dr. F. AhlemannInformation Systems and Strategic Management

Strategic planning of IS, Enterprise Architecture Management, IT Vendor Management, Project Portfolio Management, IT Governance, Strategic IT Benchmarking

Prof. Dr. P. ChamoniMIS and Management Science / Operations Research

Information Systems and Operations Research, Business Intelligence, Data Warehousing

Prof. Dr. K. EchtleDependability of Computing Systems

Dependability of Computing Systems

Prof. Dr. S. EickerInformation Systems and Software Engineering

Process Models, Software-Architectures

Prof. Dr. U. FrankInformation Systems and Enterprise Modelling

Enterprise Modelling, Enterprise Application Integration,IT Management, Knowledge Management

Prof. Dr. M. GoedickeSpecification of Software Systems

Distributed Systems, Software Components, CSCW

Prof. Dr. V. GruhnSoftware Engineering

Design of Software Processes, Software Architecture, Usabi-lity, Mobile Applications, Component-based and Generative Software Development

PD Dr. C. KlüverComputer Based Analysis of Social Complexity

Soft Computing, Modeling of Social, Cognitive, and Economic Processes, Development of Algorithms

Prof. Dr. T. KollmannE-Business and E-Entrepreneurship

E-Business and Information Management, E-Entrepreneurship/E-Venture, Virtual Marketplaces and Mobile Commerce, Online-Marketing

Prof. Dr. K. PohlSoftware Systems Engineering

Requirements Engineering, Software Quality Assurance,Software-Architectures, Evaluation of COTS/Open Source-Components

Prof. Dr. Ing. E. RathgebComputer Network Technology

Computer Network Technology

Prof. Dr. R. UnlandData Management Systems and Knowledge Representation

Data Management, Artificial Intelligence, Software Engineering, Internet Based Teaching

Prof. Dr. S. ZelewskiInstitute of Production and Industrial Information Management

Industrial Business Processes, Innovation Management,Information Management, Economic Analyses

ISSN 1860-2770 (Print)ISSN 1866-5101 (Online)

62Ein Software-Werkzeug zur multiperspektivischen Bewertung

innovativer Produkte, Projekte und Dienstleistungen

Die Forschungsberichte des Instituts für Informa- The ICB Research Reports comprise preliminarytik und Wirtschaftsinformatik stellen vorläufige results which will usually be revised for subse-Ergebnisse dar, die i. d. R. noch für spätere Veröf- quent publications. Critical comments would befentlichungen überarbeitet werden. Daher sind appreciated by the authors.die Autoren für kritische Hinweise dankbar.

Die durch das Urheberrecht begründeten Rechte, All rights reserved. No part of this report may beinsbesondere der Übersetzung, des Nachdruckes, reproduced by any means, or translated.des Vortrags, der Vervielfältigung, der Weiterga-be, der Veränderung und der Entnahme von Ab-bildungen und Tabellen – auch bei auszugsweiserVerwertung – bleiben vorbehalten.

Authors’ Address: ICB Research Reports

Stephan Köninger Edited by:

Michael Heß Prof. Dr. Heimo H. Adelsberger

Prof. Dr. Frederik Ahlemann

Lehrstuhl für Wirtschaftsinformatik Prof. Dr. Peter Chamoni

und Unternehmensmodellierung Prof. Dr. Klaus Echtle

Institut für Informatik und Prof. Dr. Stefan Eicker

Wirtschaftsinformatik (ICB) Prof. Dr. Ulrich Frank

Universität Duisburg-Essen Prof. Dr. Michael Goedicke

Universitätsstr. 9 Prof. Dr. Volker Gruhn

45141 Essen PD Dr. Christina Klüver

Prof. Dr. Tobias Kollmann

[email protected] Prof. Dr. Bruno Müller-Clostermann

[email protected] Prof. Dr. Klaus Pohl

Prof. Dr. Erwin P. Rathgeb

Prof. Dr. Rainer Unland

Prof. Dr. Stephan Zelewski

Contact:

Institut für Informatik und

Wirtschaftsinformatik (ICB)

Universität Duisburg-Essen

Universitätsstr. 9

45141 Essen

Tel.: +49 201-183-4041

Fax: +49 201-183-4011

Email: [email protected]

ISSN 1860-2770 (Print)

ISSN 1866-5101 (Online)

Zusammenfassung

Der vorliegende Arbeitsbericht dokumentiert die Konzeption und Implementierung einesSoftware-Werkzeuges zur multiperspektivischen Bewertung innovativer Produkte, Projekteund Dienstleistungen im Projekt Hospital Engineering. Zur Stärkung der eigenen Position imWettbewerb sind Krankenhäuser zunehmend auf den Einsatz von Innovationen angewiesen.Der zugrunde liegende Auswahl- und Entscheidungsprozess sollte dabei möglichst transpa-rent durchgeführt werden. Akteure aller betroffenen Disziplinen und Bereiche sollten aktiveinbezogen werden, um im weiteren Verlauf eine möglichst hohe Akzeptanz der getroffenenEntscheidung zu erreichen. Vor diesem Hintergrund sind im Projekt Hospital Engineering –Innovationspfade für das Krankenhaus der Zukunft Anforderungen an ein diesen Prozess unter-stützendes Software-Werkzeug formuliert worden, die die Grundlage der anschließendenImplementierung bilden.

i

Inhaltsverzeichnis

Abbildungsverzeichnis v

Tabellenverzeichnis vi

Abkürzungsverzeichnis vii

1 Einleitung 11.1 Motivation und Problemstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Das Projekt Hospital Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Forschungsmethodische Einordnung und Gang der Arbeit . . . . . . . . . . . . 5

2 Terminologische Grundlagen 72.1 Zum Innovationsbegriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Zur Entstehung von Innovationen . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3 Zum Projektbegriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.4 Zum Entscheidungsbegriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Anforderungsanalyse 143.1 Beschreibung des Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Allgemeine Anforderungen an das System . . . . . . . . . . . . . . . . . . . . . 163.3 Anforderungen an die Benutzerverwaltung und Authentifizierung . . . . . . . 163.4 Anforderungen an die Projektverwaltung . . . . . . . . . . . . . . . . . . . . . . 203.5 Anforderungen an die Kriterienkatalogverwaltung . . . . . . . . . . . . . . . . 21

4 Systementwurf 254.1 Benutzerverwaltung und Authentifizierung . . . . . . . . . . . . . . . . . . . . . 254.2 Projektverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3 Unternehmensverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.4 Kriterienkatalogverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.5 Auswertungskomponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5 Entwicklungsumgebung 355.1 Entwicklungswerkzeug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.2 Quellcode Versionsverwaltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.3 Continuous Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

iii

6 Dokumentation der Implementierung 406.1 Wahl einer Programmiersprache . . . . . . . . . . . . . . . . . . . . . . . . . . . 406.2 Wahl eines Webframeworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.3 Webframework: Spring MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.4 Datenbank-Framework: Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . 456.5 Servicearchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466.6 Grafische Benutzeroberfläche (GUI) . . . . . . . . . . . . . . . . . . . . . . . . . 48

7 Kritische Würdigung, Fazit und Ausblick 51

A Klassendiagramm 54

B Installationsanleitung 55B.1 Systemanforderung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55B.2 Installationsroutine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

B.2.1 Installation: Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55B.2.2 Installation: MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56B.2.3 Installation: Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56B.2.4 Installation: Web-Applikation . . . . . . . . . . . . . . . . . . . . . . . . . 57B.2.5 Starten der Applikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

C Hinzufügen neuer Sprachen 58

Literatur 59

iv

Abbildungsverzeichnis

1.1 Skizzierter Ablauf eines Innvoationsprojektes (in Anlehnung an Cooper, 2010,S. 146) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2 Struktur des Arbeitsplans im Projekt Hospital Engineering(http://www.hospital-engineering.org/arbeitspakete.html) . . 4

1.3 Struktur des Arbeitsberichtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Generischer Ablauf eines Innovationsprojekts (in Anlehnung an Cooper 2010) . 10

4.1 Schnittstellendiagramm: Benutzerverwaltung . . . . . . . . . . . . . . . . . . . . 264.2 Klassendiagramm: Benutzerverwaltung . . . . . . . . . . . . . . . . . . . . . . . 264.3 Aktivitätsdiagramm: Registrierung und Freischaltung von Benutzern . . . . . . 274.4 Schnittstellendiagramm: Projektverwaltung . . . . . . . . . . . . . . . . . . . . . 284.5 Klassendiagramm: Projektverwaltung . . . . . . . . . . . . . . . . . . . . . . . . 294.6 Klassendiagramm: Unternehmensverwaltung . . . . . . . . . . . . . . . . . . . 304.7 Klassendiagramm: Kriterienkatalogverwaltung . . . . . . . . . . . . . . . . . . . 314.8 Skizze: Reportmatrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.9 Darstellung der Ergebnisse in Form eines Säulen- bzw. Balkendiagramms . . . 334.10 Darstellung der Ergebnisse in Form eines Spinnennetzdiagramms . . . . . . . . 34

5.1 Darstellung der Systeme/Komponenten des Implementierungsprozesses . . . 355.2 Testverlaufsgraph der JUnit-Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.3 Checkstyle Graph zur Darstellung gefundener Verstöße gegen vorgegebene

Code-Konventionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.4 FindBugs Graph zur Darstellung gefundener Fehler . . . . . . . . . . . . . . . . 38

6.1 Ausschnitt der Servicearchitektur der Applikation . . . . . . . . . . . . . . . . . 476.2 Beschreibung des Layouts der Web-Applikation . . . . . . . . . . . . . . . . . . 486.3 Layout der Web-Applikation für komplexe Unterseiten mit Verwaltungscharak-

ter (hier: Projektverwaltung) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.4 Layout der Web-Applikation für kleine Bildschirme . . . . . . . . . . . . . . . . 50

A.1 Klassendiagramm des Systementwurfs . . . . . . . . . . . . . . . . . . . . . . . 54

v

http://www.hospital-engineering.org/arbeitspakete.html

Tabellenverzeichnis

3.1 Zusammenfassende Auflistung der Systemanforderungen . . . . . . . . . . . . 24

6.1 Vergleich von Webentwicklungssprachen . . . . . . . . . . . . . . . . . . . . . . 426.2 Vergleich von Java-Webframeworks . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.1 Als hoch priorisierte und erfüllte Anforderungen . . . . . . . . . . . . . . . . . . 527.2 Als niedrig priorisierte und nicht erfüllte Anforderungen . . . . . . . . . . . . . 52

vi

Abkürzungsverzeichnis

ACL Access Control ListASF Apache Software FoundationBO Business ObjectCI Continuous IntegrationCRUD Create, Read, Update, DeleteDAO Data Access ObjectDBMS Datenbank Management SystemDIN Deutsches Institut für NormungDTO Data Transfer ObjectERM Entity Relationship ModelGPML General Purpose Modelling LanguageGUI Graphical User InterfaceHTML Hypertext Markup LanguageIDE Integrated Development EnvironmentJSP Java Server PagesLDAP Lightweight Directory Access ProtocolMDD Medical Device DirectiveMPG MedizinproduktegesetzMVC Model View ControllerORM Objekt-Relationales MappingOO Objekt-OrientiertUML Unified Modelling Language

vii

Ein Software-Werkzeug zur multiperspektivischen Bewertung innovativer Produkte,

Projekte und Dienstleistungen: Realisierung im Projekt Hospital Engineering

1 Einleitung

In diesem Kapitel wird zunächst die grundlegende Motivation und Problemstellung der Be-wertung von Innovationen im Allgemeinen thematisiert (Abschnitt 1.1). Dann wird das ProjektHospital Engineering – Innovationspfade für das Krankenhaus der Zukunft, in dessen Arbeitsplandie Entwicklung eines Software-Werkzeuges zur multiperspektivischen Bewertung innova-tiver Produkte, Projekte und Dienstleistungen eingeordnet wird, vorgestellt (Abschnitt 1.2).Abschließend erfolgt eine forschungsmethodische Einordnung des Vorhabens aus Sicht derWirtschaftsinformatik sowie die Vorstellung der weiteren Struktur des Arbeitsberichtes (Ab-schnitt 1.3).

1.1 Motivation und Problemstellung

Das Schlagwort „Innovation“ wird in der Unternehmenswelt immer häufiger verwendet,um neue Produkte oder Dienstleistungen zu präsentieren. Oftmals bleibt jedoch unklar, aufwelcher Basis ein neues Produkt oder eine neue Dienstleistung als „innovativ“ bezeichnetwird. Dies liegt in einer teilweise, insbesondere zu Marketingzwecken, unreflektierten oderübertreibenden Verwendung des Innovationsbegriffs begründet. Hinzu kommt, dass keineinheitliches Begriffsverständnis existiert, sodass verschiedene Akteure unterschiedliche Er-wartungen an eine Innovation haben und/oder unterschiedliche Eigenschaften mit einerInnovation verbinden.

Der Entstehungsprozess von Innovationen wird hingegen einheitlich in mehrere Phasen ein-geteilt (siehe Abbildung 1.1). Verallgemeinert liefert eine Innovation eine neuartige Lösungfür ein bekanntes Problem. Dies bedeutet jedoch nicht, dass jede neue/alternative Problemlö-sung gleichzeitig auch eine Innovation darstellt (Rogers, 2003; Hauschildt und Salomo, 2011;Cooper, 2010). Vor diesem Hintergrund herrscht sowohl Bedarf an einer Klärung des BegriffsInnovation sowie zentraler Eigenschaften von Innovationen, die anschließend zur Bewertungeiner Innovation, z. B. hinsichtlich ihres Innovationsgrades, herangezogen werden können.Hierzu bedarf es auch der Berücksichtigung des Kontextes sowie der Domäne, in der dievermeintliche Innovation zum Einsatz kommen soll. Darüber hinaus sollte jede Innovationunter Berücksichtigung der von ihr tangierten Akteure/Akteursgruppen evaluiert werden,die, z. B. aufgrund unterschiedlicher professioneller Hintergründe, unterschiedliche Sichtenauf den Betrachtungsgegenstand haben können. Eine möglichst frühzeitige Einbindung aller

1

1 Einleitung

Ideenfindung

Stufe 1Einleitende Recherche

AblaufrichtungLegende:

Stufe 2Detaillierte Recherche

Stufe 3Entwicklung

Stufe 4Test und Validierung

der Entwicklung

Stufe 5Einführung

Abbildung 1.1: Skizzierter Ablauf eines Innvoationsprojektes (in Anlehnung an Cooper, 2010, S. 146)

betroffenen Akteure/Akteursgruppen erlaubt außerdem eine möglichst umfassende und mul-tiperspektivische Bewertung einer Innovation. Diese kann als Entscheidungsgrundlage oder-unterstützung, ob eine Innovation (oder weiter gefasst ein wie auch immer geartetes Produkt,Projekt oder eine Dienstleistung) in einem Unternehmen eingeführt werden soll, dienen.

Um den Bewertungsprozess entsprechend unterstützen und für alle Beteiligten transparentgestalten zu können, ist im Kontext des Projektes Hospital Engineering – Innovationspfade für dasKrankenhaus der Zukunft ein Software-Werkzeug konzipiert worden, das eine multiperspektivi-sche Bewertung von Innovationen ermöglicht. Die Nutzung existierender Services/Systemediverser Anbieter, wie z. B. von Google mittels Google Spreadsheets oder von SurveyMonkey1,erscheint aufgrund verschiedener Limitationen nur bedingt sinnvoll:

∙ Die Systeme bieten nur beschränkte Konfigurationsmöglichkeiten.

∙ Die Systeme bieten teilweise nur beschränkte Auswertungsmöglichkeiten.

∙ Die Systeme erfordern die Ablage aller relevanten Daten außerhalb des unternehmensei-genen Netzwerks, sodass Bedenken hinsichtlich des Datenschutzes offensichtlich sind.

Demgegenüber ist die Entwicklung eines dezidierten Systems mit einer Reihe von Vorteilenverbunden:

∙ Das System kann an die individuellen Bedürfnisse der Bewertung und Auswertungangepasst werden.

∙ Vorhandene Directory-Dienste innerhalb eines Unternehmens können eingebundenwerden, sodass Benutzer sich nicht an einem weiteren System registrieren müssen.

∙ Das Unternehmen hat die alleinige Kontrolle über alle gespeicherten Daten.

1https://de.surveymonkey.com/

2

https://de.surveymonkey.com/



1.2 Das Projekt Hospital Engineering

„Zielsetzung des Projektes Hospital Engineering – Innovationspfade für das Krankenhaus der Zu-kunft2 ist die Steigerung der Wettbewerbsfähigkeit von Krankenhäusern und damit die Siche-rung der wirtschaftlichen Zukunft durch den Einsatz moderner Informations- und Kommuni-kationstechnologien (IKT) sowie die Hebung von Effizienz- und Effektivitätspotenzialen durchdie Unterstützung ausgewählter Aspekte der primären, sekundären und tertiären Leistungs-erbringung von Krankenhäusern.“ (Heß, 2014, S. 1). Der Einsatz innovativer Produkte oderDienstleistungen sowie die Durchführung innovativer Projekte spielen dabei eine zentraleRolle. Jedoch sind der Einsatz innovativer Produkte oder Dienstleistungen sowie die Durch-führung innovativer Projekte auch immer mit einem ökonomischen Risiko, das den erwartetenpositiven Effekten gegenübersteht, verbunden. Daher sollten Entscheidungen für/gegen denEinsatz/die Durchführung möglichst objektiv, umfassend und transparent getroffen werden,insbesondere, da diese häufig mit größeren Investitionen verbunden sind.

Um dieser Anforderung gerecht werden zu können, sind in Arbeitspaket 3 des ProjektesHospital Engineering (für eine aggregiert Darstellung des Arbeitsplans siehe Abbildung 1.2)existierende Ansätze zur quantitativen und qualitativen Bewertung von Innovationen unter-sucht und hinsichtlich der Bedürfnisse des Projektes angepasst/erweitert worden. Darüberhinaus sind Domänenexperten im Rahmen des vierten Industrie- und Anwenderbords des Pro-jektes Hospital Engineering nach für die Bewertung von Innovationen relevanten qualitativenFaktoren befragt worden (Heß, 2013). Die erzielten Ergebnisse können die Entwicklung einesReferenzkriterienkatalogs zur Bewertung innovativer Produkte, Projekte und Dienstleistungenunterstützen. Während die quantitative Evaluation monetäre und zeitliche Werte, d. h. Kostenund Zeitdauern des Personal- und Materialeinsatzes in der medizinischen Versorgung, fokus-siert, gestaltet sich die Evaluation von Innovationen hinsichtlich qualitativer Aspekte weitausschwieriger. Zunächst müssen auch hier geeignete Bewertungskriteiren identifiziert werden.Zur Durchfürhung der Evaluation und Auswertung bedarf es anschließend eines möglichstintuitiv einsetzbaren Instruments. Das Verfahren der Nutzwertanalyse hat sich hierzu in derVergangenheit praktisch bewährt (z. B. Schlüchtermann, 2013, S. 255-260; Ammenwerth undHaux, 2005, S. 214-223; Zangemeister, 1976). Nutzwertanalysen können in zwei Phasen der(Investitions-)Entscheidungsfindung eingesetzt werden: Zunächst werden sie üblicherweise inder Planungsphase von Investitionsentscheidungen eingesetzt, um gegebene Alternativen, imSinne grundsätzlich verschiedener Innovationen/Investitionen, vergleichend zu bewerten undhinsichtlich ihres zu erwartenden Nutzens zu priorisieren (Decker und Decker, 2008, S. 141 ff.).Darüber hinaus können gleichartige Alternativen, d. h. z. B. verschiedene Varianten einer Inno-

2Nähere Informationen zum Projekt Hospital Engineering finden sich z. B. bei Heß (2014, S. 1–2), unter http://www.wi-inf.uni-duisburg-essen.de/FGFrank/index.php?lang=de&groupId=1&contentType=Project&projId=21 sowie unter http://www.hospital-engineering.org/.

3

http://www.wi-inf.uni-duisburg-essen.de/FGFrank/index.php?lang=de&groupId=1&contentType=Project&projId=21

http://www.wi-inf.uni-duisburg-essen.de/FGFrank/index.php?lang=de&groupId=1&contentType=Project&projId=21

http://www.hospital-engineering.org/

1 Einleitung

Abbildung 1.2: Struktur des Arbeitsplans im Projekt Hospital Engineering(http://www.hospital-engineering.org/arbeitspakete.html)

vation/Investition, vergleichend bewertet werden, um eine Auswahlentscheidung durch dieBerücksichtigung qualitativer Aspekte zu unterstützen (Schlüchtermann, 2013, S. 255-257).

Vor diesem Hintergrund präsentiert der vorliegende Arbeitsbericht die Konzeption und Imple-mentierung eines korrespondierenden Software-Werkzeuges, dass eine multiperspektivischeBewertung von Innovationen3 ermöglicht. Das resultierende Software-Werkzeug soll einen Bei-trag zur Förderung der intersubjektiven Nachvollziehbarkeit der Bewertung von Innovationen,d. h. zur Steigerung der Transparenz des Bewertungs- und Entscheidungsprozesses, leisten,indem alle qualitativen, entscheidungsrelevanten Kriterien offengelegt werden (hierzu und imFolgenden Grob, 1990, S. 337). Dem Ergebnis einer Nutzwertanalyse kann schließlich keine„objektiven Rationalität“ (Grob, 1990, S. 337) sondern lediglich eine subjektive Rationalitätzugesprochen werden, da sowohl die Auswahl der Kriterien als auch deren Gewichtung durcheine oder mehrere Personen erfolgt. In diesem Zusammenhang ist immer auch auf die Gefahr

3Der Begriff „Innovation“ wird im Folgenden stellvertretend für „innovative Produkte, Projekte und Dienst-leistungen“ verwendet.

4

http://www.hospital-engineering.org/arbeitspakete.html



einer möglichen Manipulation bei der Wahl der zu beurteilenden Kriterien sowie der denKriterien zugeordneten Kriteriengewichte hinzuweisen.

Das Projekt Hospital Engineering ist im Zeitraum vom 01. Januar 2011 bis 31. März 2014 von derLandesregierung NRW und der Europäischen Union – Europäischer Fonds für regionaleEntwicklung unter dem Förderkennzeichen 005-GW01-066E gefördert worden.

1.3 Forschungsmethodische Einordnung und Gang der Arbeit

Konzeption und Implementierung eines Software-Werkzeuges sind forschungsmethodisch dergestaltungsorientierten Wirtschaftsinformatik zuzuordnen (Österle et al. 2011, S. 9). Der demForschungsvorhaben zugrunde liegende, iterativ zu durchlaufende Forschungsprozess bestehtaus den Phasen Analyse, Entwurf, Evaluation und Diffusion und sollte den wissenschaftlichenPrinzipien Abstraktion, Originalität, Begründung und Nutzerstiftung genügen (Österle et al.2011, S. 9).

Kapitel 1Einleitung

Kapitel 2Grundlagen

Kapitel 3Anforderungserhebung

Kapitel 4Systementwurf

Kapitel 5Entwicklungsumgebung

Kapitel 6Dokumentation der Implementierung

Kapitel 7Fazit und Würdigung der Arbeitfließt ein in...

Kapitelfolge

Legende:

Abbildung 1.3: Struktur des Arbeitsberichtes

Abbildung 1.3 zeigt die Struktur des Arbeitsberichtes und der einzelnen Phasen der Konzep-tion und Implementierung des Software-Werkzeuges auf. Motivation und Problemstellungadressieren die Phase der Analyse in Kapitel 1. Dann werden relevante terminologische

5

1 Einleitung

Grundlagen thematisiert (Kapitel 2). Anschließend werden zentrale Anforderungen an das zuentwickelnde System erhoben und dokumentiert (Kapitel 3). Diese Aktivitäten sind ebenfallsder Analyse-Phase zuzuordnen. Auf Basis der erhobenen Anforderungen wird in Kapitel 4 einkonzeptueller Systementwurf erstellt und die getroffenen Entwurfsentscheidungen begründet.In Kapitel 5 wird die eingesetzte Entwicklungsumgebung vorgestellt und deren Verwendungerklärt. Die Dokumentation der Implementierungsphase sowie die Diskussion aufgetretenerProbleme erfolgt in Kapitel 6. Die Kapitel 4 bis 6 lassen sich der Entwurfs-Phase zuordnen.Der Arbeitsbericht endet mit einem Fazit, das eine Evaluation des resultierenden IT-Artefaktesgegen die zugrunde liegenden Anforderungen beinhaltet, und einem Ausblick auf weiteremögliche Forschungs-, Konzeptions- und Implementierungsaktivitäten in Kapitel 7. Daher istdieses Kapitel der Evaluations-Phase zuzuordnen. Die Diffusion der Ergebnisse erfolgt durchdie Publikation dieses Arbeitsberichts.

6



2 Terminologische Grundlagen

Da ein Software-Werkzeug zur Bewertung von Innovationen konzipiert werden soll, wird zu-nächst der im Arbeitsbericht verwendete Innovationsbegriff sowie der Prozess zur Entstehungvon Innovationen vorgestellt (Abschnitt 2.1 und 2.2). Daran schließen sich Ausführungen zumProjektbegriff an (Abschnitt 2.3), bevor der Entscheidungsbegriff differenziert betrachtet wird(Abschnitt 2.4).

2.1 Zum Innovationsbegriff

Nach Rogers (2003, S. 12) kann eine Innovation eine Idee, ein Vorgehen oder ein Objekt sein, dasvon einem einzelnen als neu angesehen wird. Diese allgemein gefasste Definition birgt jedoch„die Gefahr großer Missverständnisse“, da die Belegung des Begriffs Innovation „semantischvielfältig“ ist (Hauschildt und Salomo, 2011, S. 4). Um diese semantische Vielfalt – oder negativgewendet den resultierenden Interpretationsspielraum – zu reduzieren, schlagen Hauschildtund Salomo (2011, S. 4) folgende Definition vor:

„Innovationen sind qualitativ neuartige Produkte oder Verfahren, die sich gegen-über einem Vergleichszustand ‚merklich‘ – wie auch immer das zu bestimmen ist –unterscheiden.“

Diese Definition besagt, dass Innovation die Neuartigkeit von Produkten bzw. Verfahren betontund die konkrete Verwendung unberücksichtigt bleibt. Hauschildt und Salomo (2011, S. 4)stellen zudem fest, dass der Verwendung und dem Nutzen einer Innovation eine essentielleBedeutung zukommt, da Innovationen in einer Zweck-Mittel-Beziehung stehen. Innovationenofferieren also neue Mittel, um bestimmte Zwecke zu erfüllen oder neue Ziele zu erreichen.Rogers (2003, S. 13) formuliert dies ähnlich: Für ihn liefern Innovationen „neue Lösungen fürbekannte Probleme“.

Nicht adressiert wird in den vorgenannten Definitionen der Innovationsgrad, d. h. der Grad derNeuartigkeit einer Innovation. Rogers (2003, S. 12) begrenzt die wahrgenommene Neuartigkeiteiner Innovation auf ein einzelnes Individuum. Dies entspricht der subjektiven Dimension desInnovationsgrades nach Hauschildt und Salomo (2011, S. 11 f.) (s. u.). Eine Quantifizierungder Neuartigkeit ist basierend auf dieser Aussage nicht möglich, da die Neuartigkeit einesProdukts nicht objektiv erfasst werden kann. Vor diesem Hintergrund schlagen Hauschildt

7


und Salomo (2011, S. 11 f.) fünf Kriterien – sie sprechen von Dimensionen der Neuartigkeit –vor, die eine Quantifizierung und objektive Erfassung des Innovationsgrades erlauben:

∙ Inhaltliche DimensionDie Inhaltliche Dimension geht der Frage „Was ist neu?“ nach und beschreibt denInnovationsgegenstand.

∙ IntensitätsdimensionGegenstand der Intentsitätsdimension ist die Bewertung des Grades der Neuartigkeitdes Innovationsgegenstands.

∙ Subjektive DimensionDie subjektive Dimension stellt die Frage nach der Neuartigkeit für eine Betrachtungs-gruppe. Der Innovationsgrad ist subjektiv geprägt, da verschiedene Akteure eine Inno-vation unterschiedlich hinsichtlich ihrer Neuartigkeit bewerten können.

∙ Prozessuale DimensionDie Autoren beschreiben ein generisches Phasenmodell, das die Entwicklung von Inno-vationen beschreibt:

1. Idee/Initiative:Erforschung eines bisher nicht näher untersuchten Gegenstands, um im Rahmender Forschung auf Neuerungen zu stoßen.

2. Entdeckung/Beobachtung:Entdeckung eines bisher unbekannten Aspekts.

3. Forschung:Fundierte Nachforschungen, ob der entdeckte, unbekannte Aspekt gemäß der sub-jektiven Dimension in anderen Bereichen bereits erwähnt wurde.

4. Erfindung:Anfertigung einer formalen Definition (Beschreibung) des unbekannten Aspekts,die zur Anmeldung als Patent oder zur Publizierung herangezogen werden kann.

5. Entwicklung:Umsetzung der formalen Definition und Aufbau von Prototypen.

6. Verwertungsanlauf:Einführung des Innovationsgegenstands in die Praxis.

7. Laufende Verwertung:Pflege und Instandhaltung des neu eingeführten Innovationsgegenstands.

Die prozessuale Dimension fragt danach, wo der Prozess, welcher zu einer Innovationführt, letztlich beginnt und endet.

8



∙ Normative DimensionDie normative Dimension stellt die Frage, ob das neuartige Produkt oder Verfahren aucherfolgreich ist und welchen Einfluss die Innovation auf den Zielerfüllungsgrad hat.

2.2 Zur Entstehung von Innovationen

Innovationen sind das Ergebnis verschiedenster Einflüsse. Bei näherer Betrachtung der Lite-ratur zeigt sich, dass Konsens über die Quellen von Innovationen bestehen. So spricht manoftmals von „Market Push“ oder „Technology Pull“ als ausschlaggebende Strömungen fürInnovationsquellen (Disselkamp, 2012, S. 44; Weis, 2012, S. 110). Im Rahmen eines TechnologyPushes werden Innovationen durch Entdeckung neuer technischer Möglichkeiten realisiert.Disselkamp spricht in diesem Zusammenhang von der „Unwissenheit des Marktes“, da dieserdie neuen Potenziale der Technik noch nicht kennt. Im Umkehrschluss existieren jedoch auchBedürfnisse der Konsumenten am Markt, die im Rahmen eines Market Pulls zu Innovationenführen können und durch Marktforschungen aufgedeckt werden müssen (Rennings, 2000,S. 326). Besonders im medizinischen Bereich werden vom Gesetzgeber strikte Auflagen de-finiert, die zu entsprechenden Bedarfen in einer Domäne führen („Regulatory Pull“). Diesewerden häufig in anwendungsorientierten Forschungs- oder Industrieprojekten adressiert.Quellen eines Regulatory Pulls sind im Gesundheitswesen beispielsweise die Medical DeviceDirective (MDD) oder das Medizinproduktegesetz (MPG).

Entsprechende (Forschungs-)Projekte folgen üblicherweise einem generischen Phasenmodell(Gassmann und Sutter, 2008, S. 46; Cooper, 2010). Innovationsprojekte beginnen typischerweisemit einer unstrukturierten Phase, die zur Ideenfindung dient und durch die Kreativität derbeteiligten Personen fördern soll (Weis, 2012, S. 156). An diese Phase schließen sich zwei dieErgebnisse der Phase „Ideenfindung“ strukturierende und selektierende Phasen an, in denenzunächst einleitende, dann detaillierte Recherchen vorgenommen werden, und die Grundlageder dann folgenden Entwicklungsaktivitäten bilden. Die Resultate der Entwicklungsaktivitätenwerden anschließend getestet und validiert, um sie bei positivem Ergebnis schließlich in denMarkt oder ein Unternehmen einzuführen. Abbildung 2.1 zeigt den idealtypischen Ablaufeines Innovationsprozesses in Anlehnung an den von Cooper (2010) definierten „State-Gate-Process“. Die einzelnen Phasen sind über „Gates“ verbunden, welche den Abschluss einerPhase und den Übergang in die nächste Phase definieren. Zwar sind Iterationen innerhalb einerPhase vorgesehen, jedoch sind im State-Gate-Process keine Rücksprünge in vorherige Phasenvorgesehen. Hieran wird bereits deutlich, dass es sich dabei – im Gegensatz zu detaillierterenVorgehensmodellen – nur um eine grobe Strukturierung des Ablaufs eines Innovationsprojekteshandelt.

Nach Schumpeter und Backhaus (2003) liegt einer Innovation eine Erfindung (Invention)zugrunde, welche den aktuellen technologischen Wissenstand erweitert. Zu diesem Zeitpunkt

9


Ideenfindung

Stufe 1Einleitende Recherche

AblaufrichtungLegende:

Stufe 2Detaillierte Recherche

Stufe 3Entwicklung

Stufe 4Test und Validierung

der Entwicklung

Stufe 5Einführung

Abbildung 2.1: Generischer Ablauf eines Innovationsprojekts (in Anlehnung an Cooper 2010)

kann noch nicht von einer Innovation gesprochen werden, da zunächst der Grad der Innovationsowie die subjektive Dimension geprüft werden muss. Die Weiterentwicklung ist bisher nurals neuartig zu bezeichnen und bedarf weiterer Untersuchungen. Der neue Wissensstanderöffnet neue Nutzungsoptionen, die im Rahmen von Innovationsprojekten aufgedeckt undzur Massentauglichkeit gebracht werden können. Dieser letzte Schritt wird auch als „Diffusion“bezeichnet (Schumpeter und Backhaus, 2003, S. 301 f.).

Da Innovationen in Projekten entwickelt werden, wird nachfolgend auf den Projektbegriffsowie auf eine mögliche Abgrenzung von klassischen Projekten und Innovationsprojekteneingegangen.

2.3 Zum Projektbegriff

Obwohl der Projektbegriff in der Literatur je nach Fokus unterschiedlich definiert wird, fin-den sich im Kern der verschiedenen Definitionen viele Gemeinsamkeiten: Viele der Autorenbeginnen ihre Ausführungen unter Rückgriff auf die DIN-Norm 69901, in der verschiedene Pro-jektmanagementbegriffe definiert werden. Der Projektbegriff wird dort wie folgt beschriebenDIN (69901):

“Vorhaben, das im Wesentlichen durch die Einmaligkeit der Bedingungen in ihrerGesamtheit gekennzeichnet ist, wie z. B.

∙ Zielvorgabe,

∙ zeitliche, finanzielle, personelle und andere Begrenzungen,

∙ Abgrenzung gegenüber anderen Vorhaben,

∙ projektspezifische Organisation”.

Bei näherer Betrachtung dieser Definition wird deutlich, dass diese in vielen Belangen nichtpräzise ist. So wird nicht weiter darauf eingegangen, was unter „andere Begrenzungen“ oder

10



„andere Vorhaben“ zu verstehen ist. Ebenso wird nicht beschrieben, was die Autoren mit einer„projektspezifische[n] Organisation“ ausdrücken wollen. Die Definition des Project ManagementInstitute ist in ihrer Ausführung präziser und definiert ein Projekt als „[a] unique in that it isnot a routine operation, but a specific set of operations designed to accomplish a singular goal“.Die angeführten Definitionen sind in Teilen gleich und es lassen sich Merkmale ableiten, diesich unter anderem auch bei Bea, Scheurer und Hesselmann (2008, S. 33 f.), Burghardt (2008,S. 22) und Corsten, Corsten und Gössinger (2008, S. 18 ff.) wiederfinden und dort präzisiertwerden:

∙ Einmaligkeit

Projekte sind einmalige Vorhaben, die von Routineaufgaben abzugrenzen sind (Bea,Scheurer und Hesselmann, 2008, S. 34). Diese Einmaligkeit ist nicht wie von vielen Au-toren beschrieben ausschließlich auf die Ausführung zu beziehen, sondern muss aufden situativen Kontext bezogen werden (Corsten, Corsten und Gössinger, 2008, S. 3).Deutlich wird dies, wenn man Softwareentwickungsprojekte betrachtet: Auf den erstenBlick scheinen alle Entwicklungsprojekte identisch zu sein und sind daher Routineauf-gaben zuzuordnen. Erweitert man den Fokus und betrachtet nicht nur die Aktivitäteneines Projekts, sondern auch den Kontext in dem das Projekt durchgeführt wird, wirddeutlich, dass sich die Rahmenbedingungen von Projekt zu Projekt ändern und über dieGesamtheit der Projekte für Einmaligkeit sorgen.

∙ Zeitliche Befristung

Das Merkmal der zeitlichen Befristung von Projekten findet sich bei allen genanntenAutoren wieder. Bea, Scheurer und Hesselmann (2008, S. 33) schreiben diesbezüglich,dass Projekte einen „Termin für den Projektabschluss“ aufweisen und daher determi-nistisch sind. Laut Corsten, Corsten und Gössinger (2008, S. 1) resultiert die Befristungeines Projekts bereits aus der Tatsache heraus, dass Projekte Singularitäten sind unddementsprechend nach einmaliger Durchführung beendet werden. Da die Eigenschaftder Einmaligkeit eines Projekts jedoch noch keine Aussage über die Dauer eines Projektszulässt, verweisen Corsten, Corsten und Gössinger (2008) auf Dülfer (1982, S. 10), derschreibt, dass die im Rahmen eines Projekts auszuführenden Aktivitäten in kurzmög-lichster oder aber kosteneffizientester Ausführungszeit durchzuführen sind. Dies istinsofern kritisch zu betrachten, da hier keinerlei Aussagen über die erwartete/geforderteQualität des Projektergebnisses berücksichtigt werden.

∙ Neuartigkeit

Da jedes Projekt unter Hinzuziehung der gegebenen Rahmenbedingungen einmaligdurchgeführt wird, stellt jede Projektdurchführung eine neue Herausforderung dar. Man

11


ist bei jeder Durchführung mit sich ändernden Rahmenbedingungen konfrontiert, die eszu analysieren und im Projekt zu berücksichtigen gilt (Bea, Scheurer und Hesselmann,2008, S. 34). In dieser Ausführung wird deutlich, dass die Eigenschaft der Neuartigkeitsubjektiv geprägt ist. Dies verhält sich ähnlich zur Bewertung der Neuartigkeit von Inno-vationen: Was für den Einen neuartig ist, kann für einen Anderen Routine sein. Corsten,Corsten und Gössinger (2008, S. 2) schreiben diesbezüglich, dass das Merkmal besserunter dem Namen „relative Neuartigkeit“ zu fassen ist, da dies der zentralen Aussage desMerkmals präziser nachkommt. Auch Hauschildt und Salomo (2011, S. 18 ff.) beschreiben,dass die Neuartigkeit eine subjektive Komponente besitzt (vgl. Abschnitt 2.1).

Stellt man der zuvor genannten Definition des Projektbegriffs das Phasenmodell eines In-novationsprojektes gegenüber, wird deutlich, dass die vorgelagerte, unstrukturierte Phasezur Ideenfindung den zentralen Unterschied darstellt. Diese vorgelagerte Phase lässt sichim Gegensatz zu den Folgephasen nicht strukturieren und kann daher nicht strukturiert imRahmen des Projektmanagements geleitet werden. Der Verlauf eines Projekts wird durchzwischen den beteiligten Akteuren getroffenen Entscheidungen gelenkt. Diese betreffen dieDurchführung, Ausrichtung und abschließende Bewertung des Projekts. Daher ist es nötig,die getroffenen Entscheidungen und somit auch den Prozess, der zu einer Entscheidung führt,für alle beteiligten Akteure/Akteursgruppen offenzulegen, um die Nachvollziehbarkeit vonEntscheidungen zu fördern. Die zentralen Merkmale des Entscheidungsbegriffs sowie dieverschiedenen Bedeutungen werden im folgenden Abschnitt erörtert.

2.4 Zum Entscheidungsbegriff

Entscheidungen nehmen eine zentrale Rolle in der Betriebswirtschaftslehre ein, da durch dieseein Unternehmen gelenkt und geleitet wird (Bea, Scheurer und Hesselmann, 2008, S. 332). Inder Entscheidungstheorie wird eine Entscheidung als Auswahl einer Alternative aus einergegebenen Menge von Handlungsalternativen unter Berücksichtigung bestimmter Umweltzu-stände definiert, wobei eine Entscheidung durch einen Entscheidungsträger getroffen wird(Bea, Scheurer und Hesselmann, 2008, S. 333; Laux, Gillenkirch und Schenk-Mathes, 2012, S. 3;Heß, Schlieter und Täger, 2013). Die Rolle des Entscheidungsträgers ist jedoch nicht auf eineeinzelne Person beschränkt, sondern kann auch von einer Personengruppe wahrgenommenwerden (Laux, Gillenkirch und Schenk-Mathes, 2012, S. 3). Heß, Schlieter und Täger (2013,S. 270) weiten das Verständnis der Rolle des Entscheidungsträgers basierend auf Ferstl undSinz (2013, S. 10) aus, indem sie neben menschlichen Akteuren auch Anwendungssystemeals Entscheidungsträger ansehen, sofern der Entscheidungsprozess eine Automatisierungzulässt.

12



Nach Laux, Gillenkirch und Schenk-Mathes (2012, S. 52 ff.) lässt sich der Entscheidungsbegriffbzw. eine Entscheidungssituation noch weiter systematisieren: So existieren beispielsweiseEntscheidungssituationen, die entweder ein Ziel (z. B. Gewinnmaximierung) oder auch auchmehrere Ziele (z. B. Simplex-Verfahren) verfolgen. Ferner lassen sich Entscheidungen hin-sichtlich ihrer Periodizität in zeitlich unabhängig zu treffende (einperiodische, einmalige)Entscheidungen, Entscheidungen mit zeitlichem Kontext (mehrperiodische) Entscheidungenund zukünftig zu treffende Entscheidungen unterteilen. Mehrperiodische Entscheidungenkönnen z. B. durch einen Entscheidungsbaum visualisiert werden. Außerdem lässt sich auchzwischen deterministischen und stochastischen Entscheidungssituationen unterscheiden. De-terministische Entscheidungssituationen sind geprägt durch fest vorgegebene, nicht verän-derbare Handlungsalternativen, wohingegen stochastische Entscheidungssituationen anhandgegebener Wahrscheinlichkeiten gesteuert werden.

Anhand der vorgenannten Unterscheidungsmerkmale wird deutlich, dass die Komplexitäteiner Entscheidung zwischen verschiedenen Entscheidungssituationen eine hohe Varianzaufweisen kann. Sie wird insbesondere durch die Anzahl möglicher Handlungsalternativenund durch die Art und Komplexität der jeweiligs zulässigen, den Entscheidungskriterienzugrunde liegenden Kriterienausprägungen beeinflusst. Heß, Schlieter und Täger (2013, S. 270)unterteilen die Komplexität von Entscheidungen in drei Kategorien: Binäre Komplexität,wenn eine Handlungsalternative vorliegt, die nur mit zwei Entscheidungsausprägungenbewertet werden kann. Einfache Komplexität, wenn eine Entscheidungssituation auftritt,die nicht mehr als drei Handlungsalternativen aufweist und durch jeweils maximal dreiEntscheidungsausprägungen bewertet werden kann. Alle anderen Entscheidungssituationenwerden als komplex angesehen.

Sind mehrere Akteure an einem Entscheidungsfindungsprozess beteiligt, entsteht weitereKomplexität hinsichtlich der Anzahl beteiligter Akteure, für welche es eine Lösung zu findengilt. Es muss geklärt werden, welche Entscheidungskritieren aufgestellt werden und wie/vonwem diese Kriterien gewichtet werden. Im Zuge dieser Überlegung müssen Aspekte wie dieVerfolgung eigener Interessen auch im Rahmen von „hidden-agendas“ berücksichtigt werden.Darüber hinaus ist die Nachvollziehbarkeit des gesamten Entscheidungfindungsprozesseswichtig für die Begründung, z. B. dem Management oder anderen betroffenen Stakeholderngegenüber.

Nachdem die grundlegenden Charakteristika des Forschungsgegenstandes beschrieben sind,werden im nächsten Kapitel wesentliche Anforderungen an das zu implementierende Systemformuliert.

13

3 Anforderungsanalyse


In Abschnitt 3.1 wird das zu implementierende System beschrieben und dient als Grundlageder anschließenden Anforderungsanalyse (Abschnitt 3.2 bis 3.5).

3.1 Beschreibung des Systems

Das zu implementierende System soll die Bewertung von innovativen Produkten, Projektenund Dienstleistungen durch Stakeholder ermöglichen, um so vor dem Beginn eines Innova-tionsprojekts dessen Relevanz für verschiedene Stakeholder und deren Erwartungen an dieInnovation zu sondieren. Um eine differenzierte Bewertung ermöglichen zu können, sollte dieBewertung einer Innnovation aus Sicht verschiedener Stakeholdergruppen vorgenommen wer-den können. Dies bedeutet für das System, dass Benutzer in verschiedene Gruppen eingeordnetwerden können müssen und aus der Sicht der jeweiligen Gruppe eine Bewertung abgegebenwerden kann. So wird die multiperspektivische Bewertung von Projekten aus verschiedenenSichten ermöglicht, die sich z. B. in Anlehnung an die zentralen Berufsgruppen (ärztlicherDienst, Pflegedienst, Verwaltung), deren Unterscheidung sich bis zur Leistungsebene findet(Heil, 2007, S. 129).

Aus der bisherigen Beschreibung des Systems geht hervor, dass verschiedene Benutzer dasSystem verwenden können sollen. Hieraus folgt, dass das System eine Verwaltung von Benut-zern sowie eine Authentifizierung ermöglichen muss. Da die Bewertung von Innovationenmeist im Rahmen von Projekten erfolgt, muss zudem eine Projektverwaltung implementiertwerden. Um eine Bewertung zu ermöglichen müssen Benutzer Kriterien bzw. Kriterienkatalogeanlegen, anwenden und diese auch wiederverwenden können.

Aus den bisherigen Ausführungen lässt sich die Notwendigkeit folgender Module ableiten,die im Anschluss näher beschrieben werden:

∙ Benutzerverwaltung,

∙ Authentifizierung,

∙ Projektverwaltung,

∙ Kriterienkatalogverwaltung.

14



Mit Blick auf die Bereitstellung von Funktionalitäten, die sich auf die Registrierung und Ver-waltung von Benutzern des Systems beziehen, wird eine Benutzerverwaltungskomponentekonzipiert. Diese ermöglicht beispielsweise das Anlegen neuer Benutzer, das Bearbeiten undLöschen von Benutzern sowie die Vergabe von Zugriffsrechten an bestimmte Benutzer.

Die Komponente zur Überprüfung von Zugriffsrechten und sonstigen Berechtigungen imSystem ist orthogonal zu allen anderen Komponenten zu sehen, da sie mit allen anderenKomponenten interagiert. Diese Komponente stellt Funktionalitäten zur Authentifizierungeines Benutzers bereit. Sie stellt sicher, dass nur berechtigte Nutzer Aktionen im System(beispielsweise das Löschen von Projekten) vornehmen. Die Komponente ist unsichtbar fürden Benutzer, aber von hoher Relevanz für das System, da sie maßgeblich für die Integrität desSystems Sorge trägt, indem sie permanent prüft, ob Benutzer zur Ausführung einer bestimmtenAktion berechtigt sind.

Eine weitere Komponente stellt die Projektverwaltung dar. Sie stellt Funktionalitäten bereit,die die Erstellung und Verwaltung von Projekten im System erlauben. Abhängig von denZugriffsrechten eines Benutzers werden Funktionen wie Erstellung eines Projekts, Bearbeiteneines Projekts oder Löschen eines Projekts angeboten.

Die Komponente zur Verwaltung von Kriterienkatalogen wird mit Funktionen ausgestattet,die es einem Benutzer erlauben bestehende Kriterien für ein Projekt zu verwenden, Kriterienzu bearbeiten, Gewichtungen festzulegen, Skalen für die jeweiligen Kriterien zu definieren undggf. auch Skalentransformationsregeln festzulegen, die bei der Aggregation mehrerer Kriteriennötig sind. Obgleich dieses Vorgehen in der betrieblichen Praxis regelmäßig angewendet wird,erscheint es aus methodischer Sicht problematisch, da durch die Transformation nominal oderordinal skalierter Werte zu kardinal skalierten Werten ein “Informationsgehalt” geschaffenwird, der nominal sowie ordinal skalierten Kriterien nicht entnommen werden kann (Grob,1990, S. 337). Diesem Umstand müssen sich Anwender bewusst sein, wenn sie das hier vorge-stellte Werkzeug entsprechend einsetzen. Es sei ausdrücklich darauf hingewiesen, dass eineBeschränkung der Anwendung auf kardinal skalierte Kriterien empfohlen wird. Ferner sollder Im- und Export von Kriterienkatalogen unterstützt werden, um die Pflege des Katalogsunabhängig vom System vornehmen zu können.

Nach der abstrakten Beschreibung des Systems unter Auflistung der einzelnen Komponenten,erfolgt nun die Erhebung der für die einzelnen Komponenten gegebenen Anforderungen,sowie allgemeiner Anforderungen an das System. Hierfür werden in Abschnitt 3.2 zunächstallgemeine Anforderungen an das System aufgestellt. Anschließend werden weitere Anforde-rungen für die einzelnen Komponenten definiert: Anforderungen an die Benutzerverwaltungsind in Abschnitt 3.3 dokumentiert, Anforderungen an die Projektverwaltung in Abschnitt 3.4und Anforderungen an die Kriterienkatalogverwaltung in Abschnitt 3.5.

15


3.2 Allgemeine Anforderungen an das System

Unter allgemeinen Anforderungen werden Anforderungen verstanden, die sich nicht auf eineder oben genannten Komponenten beziehen, sondern für das System als Ganzes gelten. Dervorgegebene Rahmen sieht vor, dass das System als Webanwendung implementiert wird.Durch diese Anforderung soll das System unabhängig von bestimmten Betriebssystemenfunktionieren und auf einer Vielzahl unterschiedlicher Endgerätetypen nutzbar sein. Zudemwird durch die Implementierung als Webanwendung eine ubiquitäre und zeitlich unabhängigeNutzung angestrebt. Entsprechend resultieren die Anforderungen A.1 und A.2:

A.1: Das System soll als Webanwendung implementiert werden.

A.2: Die Webanwendung soll plattformunabhängig sein.

Da das System als Webanwendung implementiert werden soll, ergibt sich daraus folgendauch die Anforderung, dass mehrere Benutzer gleichzeitig das System bedienen könnensollen. Hierbei wird zudem der Fokus auf die gleichzeitige Bewertbarkeit von Projekten durchverschiedene Benutzer gelegt, ohne dass das System in einen inkonsistenten Status verfällt.Entsprechend resultiert Anforderung A.3:

A.3: Das System soll durch mehrere Benutzer gleichzeitig bedient werden können, ohnedass dies zu unerwünschten Seiteneffekten führt.

Um die vom System angebotenen Funktionen nur bestimmten Benutzern zugänglich zu ma-chen, wird eine Benutzerverwaltungskomponente benötigt, welche die Vergabe und Kontrollevon Benutzerrechten regelt.

3.3 Anforderungen an die Benutzerverwaltung und Authentifizierung

Um größtmögliche Flexibilität bei der Benutzerregistrierung zu ermöglichen, soll das Systemverschiedene Arten der Benutzerregistrierung anbieten. Einerseits soll es möglich sein neue Be-nutzer über ein Formular im System zu erstellen, andererseits soll ein Benutzer die Möglichkeithaben, sich selbst registrieren zu können. Entsprechend resultiert Anforderung BV.1:

16



BV.1: Das System soll sowohl die Registrierung als auch die manuelle Erstellung vonBenutzern erlauben.

Zudem existiert in einer Vielzahl an Unternehmen ein Active-Directory-Dienst (AD-Dienst),welcher die Zugangsdaten für alle Mitarbeiter eines Unternehmens enthält (Gerber, 2006,S. 502 ff.). Zur Vereinfachung der Benutzerverwaltung der Webanwendung in Unternehmen,bietet sich die Wiederverwendung der im AD-Dienst vorhandenen Benutzerzugänge an. Hier-für soll die Web-Applikation eine Schnittstelle zur Nutzung dieses Dienstes implementieren.Entsprechend resultiert Anforderung BV.2:

BV.2: Das System soll eine Active-Directory-Schnittstelle anbieten, um vorhandene Benut-zer eines Unternehmens in das System importieren zu können.

Falls kein AD-Dienst verwendet wird oder Benutzer nicht über den AD-Dienst abgebildetwerden sollen, ist es notwendig Benutzer einladen zu können. Hierfür soll ein bereits regis-trierter Benutzer über die Möglichkeit verfügen, einen neuen Benutzer durch Angabe einerE-Mail-Adresse einzuladen. Entsprechend resultiert Anforderung BV.3:

BV.3: Das System soll Einladungen zur Bewertung von Projekten per E-Mail versendenkönnen.

Um die Anmeldung eines registrierten Benutzers am System zu ermöglichen, sollen zweiVerfahren angeboten werden: Der Benutzer soll durch Eingabe seines Benutzernamens oderseiner E-Mail Adresse sowie seines Passwortes Zugang zum System erlangen. Entsprechendresultiert Anforderung BV.4:

BV.4: Das System soll die Anmeldung über einen Benutzernamen oder die E-Mail-Adressein Kombination mit einem Passwort erlauben.

Sollte ein Benutzer in das System eingeladen worden sein, soll sich dieser unter Angabe seinerE-Mail-Adresse und einem für die jeweilige Einladung gültigen Passwort anmelden können.Darüberhinaus soll der Benutzer bei der ersten Anmeldung dazu aufgefordert werden, dasinitial vom System generierte Passwort durch ein vom Benutzer selbst gewähltes Passwort zuersetzen. Entsprechend resultiert Anforderung BV.5:

17


BV.5: Eingeladene Benutzer können unter Angabe eines auf die jeweilige Einladungbezogenen Passworts schnell Zugang zum System erlangen. Ist ein eingeladener Benutzerbereits im System registriert, wird statt eines einladungsbezogenen Passworts ein Linkgeschickt, mittels dessen ein existierender Benutzer zu einem Projekt hinzufügt werdenkann.

Da in Unternehmen sowie Projekten verschiedene Rollen existieren, soll das System dieMöglichkeit bieten, Rollen und somit auch Verantwortlichkeiten an registrierte Benutzer zuvergeben. Hierfür müssen verschiedene, fest definierte und nicht löschbare Rollen im Systemexistieren, über die der Zugriff auf einzelne Funktionen des Systems gesteuert werden kann.An dieser Stelle muss zwischen Systemrollen und Projektrollen unterschieden werden. Sys-temrollen haben globale Gültigkeit und sind nicht abhängig von einem Kontext. Dies trifftauf Projektrollen nicht zu: Sie sind abhängig davon, welches Projekt ein Benutzer gerade be-trachtet. Das bedeutet, dass ein Benutzer in zwei Projekten zwei unterschiedliche Projektrolleneinnehmen kann. Entsprechend resultiert Anforderung BV.6:

BV.6: Das System soll verschiedene System- und Projektrollen anbieten.

Im Kontext von Projekten lassen sich die Projektrollen Projektleiter und Projektmitarbeiter identi-fizieren. Diese Projektrollen sollen bei einer Installation des Systems bereits vorhanden sein.Zudem ist eine globale Systemrolle nötig, welche als Verwalter des Systems fungiert. DieseSystemrolle trägt den Namen Administrator und verfügt über uneingeschränkte Rechte aufdem ganzen System. Entsprechend resultiert Anforderung BV.7:

BV.7: Das System soll standardmäßig die Systemrollen Administrator, Benutzer sowie dieProjektrollen Projektleiter und Projektmitarbeiter anbieten.

Um die Zugriffsrechte der Rollen steuern zu können und das System flexibel zu gestalten,sollen die Zugriffsrechte pro Rolle und pro Benutzer im System konfiguriert werden können.Entsprechend resultiert Anforderung BV.8:

BV.8: Zugriffsrechte sollen an Rollen und Benutzer vergeben und konfiguriert werdenkönnen.

Neben der Zuordnung von Zugriffsrechten zu Rollen, sollen zudem auch einzelne Benutzer-rechte individuell konfiguriert werden können. Hierbei ist vorgesehen, dass die Zugriffsrechteder Rollen, welche ein Benutzer einnimmt, an die jeweiligen Benutzer vererbt werden. Jedoch

18



sollen diese Zugriffsrechte auch benutzerspezifisch erweitert werden können, wobei alle voneiner Rolle geerbten Zugriffsrechte nicht verändert werden können dürfen. Dies verhindertbeispielsweise, dass Administratoren sich selbst notwenige Rechte zur Verwaltung des Sys-tems entziehen und damit das System in einen inkonsistenten Zustand versetzen können.Entsprechend resultiert Anforderung BV.9:

BV.9: Vererbte Berechtigungen sollen nicht verändert werden können.

Wird das System auf einem frei zugänglichem Server installiert, soll das System so konfiguriertwerden können, dass alle Benutzer die Möglichkeit haben Projekte anzulegen. Im Falle einerInstallation innerhalb einer Organisation oder eines geschlossenen Benutzerkreises, soll dasSystem so konfiguriert werden können, dass nur ein Benutzer mit der Rolle ProjektmanagerProjekte anlegen kann. Entsprechend resultiert Anforderung BV.10:

BV.10: Das System soll zwei Modi unterstützen: Einen Modus, in welchem jeder BenutzerProjekte anlegen kann und einen weiteren Modus, welcher nur Benutzern in der RolleProjektmanager das Erstellen von Projekten erlaubt.

Da bei der Registrierung benutzerbezogene Daten gespeichert werden, ist darauf zu achten,dass nur authorisierte Benutzer Zugriff auf diese Daten erhalten. Dieser Schutz soll durchden Einsatz aktueller Verschlüsselungsverfahren gewährleistet werden. In einer Vielzahl vonWebanwendungen werden nach wie vor Verschlüsselungsverfahren wie MD5 oder SHA1eingesetzt. Aktuelle Erkenntnisse zeigen jedoch, dass diese Verfahren nicht mehr als sichergelten und andere Algorithmen herangezogen werden sollten. Aktuell als sicher eingestuftwird der Algorithmus BCRYPT, welcher u. a. auch in aktuellen Linuxdistributionen wie Ubuntuzum Einsatz kommt. Die Sicherheit dieses Algorithmus resultiert nicht zuletzt daraus, dassBCRYPT im Gegensatz zu MD5 bzw. SHA1 langsamer arbeitet, weil komplexere Berechnungendurchführt werden (Wang und Yu, 2005; Percival, 2005). Durch die langsamere Berechnungeines Hashes, erhöht sich die Dauer zur Entschlüsselung erheblich, da bei jedem Versuch dieselbe Zeit zum Prüfen eines Passwortes aufgebracht werden muss, wie sie zum Verschlüsselnbenötigt wird. Entsprechend resultiert Anforderung BV.11:

BV.11: Die Passwörter der Benutzer sollen nicht reversibel verschlüsselt abgelegt werden.

Durch die irreversible Verschlüsselung ist es nicht mehr möglich, dem Benutzer sein Passwortim Klartext zuzusenden, falls dieser es vergessen haben sollte. Stattdessen wird auf das heutegängige Verfahren zurückgegriffen, das dem Benutzer das Einrichten eines neuen Passwortesermöglicht, indem er zunächst ein neues Passwort über eine Webseite anfordert, dann einen

19


Link per E-Mail zugesandt bekommt, der zu einer nur für eine begrenze Zeitdauer gültigenWebseite führt, auf der der Benutzer ein neues Passwort für seinen Zugang vergeben kann.Entsprechend resultieren die Anforderungen BV.12 und BV.13:

BV.12: Die Benutzer sollen ein neues Passwort für ihre Zugänge anfordern können(„Passwort-vergessen“-Funktion).

BV.13: Die Möglichkeit zum Zurücksetzen eines Passwortes soll nach Anforderung einesneuen Passworts nur eine begrenze Zeit zur Verfügung stehen.

Um Benutzer gruppieren zu können, sollen Benutzer einer Benutzergruppe zugeordnet wer-den können. Dies ermöglicht die logische Verwaltung von Benutzern in einzelnen Gruppen(beispielsweise „Ärzte“ oder „Software-Entwickler“). Die Gruppierung von Benutzern dientausschließlich zur Kategorisierung und hat im Gegensatz zu den jeweiligen Rollen eines Be-nutzers keine Aussage über die Zugriffsberechtigungen in der Web-Applikation. Daher istfolgende Konstellation denkbar: Benutzer A hat die Rolle Administrator und ist den GruppenSoftware-Entwickler und Ärzte zugeordnet. Entsprechend resultiert Anforderung BV.14:

BV.14: Das System soll die Gruppierung von Benutzern ermöglichen, indem es Funktio-nen anbietet, um Benutzergruppen zu erstellen und diesen Gruppen einzelne Benutzerzuzuordnen.

Nach der Definition der Anforderungen an die Benutzerverwaltungskomponente werden imfolgenden Abschnitt die Anforderungen an die Projektverwaltung vorgestellt.

3.4 Anforderungen an die Projektverwaltung

Die Komponente zur Projektverwaltung stellt Funktionen bereit, die Benutzern abhängig vonderen Berechtigungen erlauben verschiedene Aktionen auszuführen, die die Verwaltung vonProjekten betreffen. Im Wesentlichen konzentriert sich die Komponente auf die Funktionenzum Erstellen, Aktualisieren, Löschen und Lesen von Projekten. Diese Funktionen sind mit denDatenbankoperationen Create, Read, Update, Delete (CRUD) gleichzusetzen. Entsprechendresultiert Anforderung PV.1:

20



PV.1: Benutzer sollen – abhängig von ihren Berechtigungen – Projekte betrachten, bearbei-ten, anlegen oder löschen können.

Um die Berechtigung eines Benutzers für ein bestimmtes Projekt zu erkennen, muss dieKomponente zudem erkennen, welche Rolle ein Benutzer im jeweiligen Projekt einnimmt.Entsprechend resultiert Anforderung PV.2:

PV.2: Die Komponente soll projektspezifische Rollen (Projektrollen) des Benutzers erken-nen und mit den bereits vorhandenen Rechten des Benutzers (Systemrolle) zusammenfüh-ren.

Diese Anforderung setzt voraus, dass die Applikation eine Funktion anbietet, Benutzer zuProjekten hinzuzufügen und einzelnen Benutzern verschiedene Rollen und damit verbundeneRechte im Rahmen eines Projekts zuzuordnen (PV.3).

PV.3: Einem Projekt sollen Benutzer hinzugefügt werden können, welche mit einer Projekt-rolle verknüpft werden.

Um einzelne Projekte im System strukturieren zu können, sollen Projektkategorien eingeführtwerden. Hierfür muss das System eine Funktion bieten, Projektkategorien zu verwalten undeinzelne Projekte diesen Kategorien zuzuordnen. Entsprechend resultiert Anforderung PV.4:

PV.4: Das System soll die Spezifikation von Projektkategorien ermöglichen, die Projektenzugeordnet werden können sollen.

Es empfiehlt sich die Erstellung von Projektkategorien ausschließlich durch Administratorenzu erlauben, um doppelte Kategorien (beispielsweise durch Rechtschreibfehler) zu vermeidenund die Übersichtlichkeit, die durch Einführung von Kategorien erreicht werden soll nichtzu gefährden. Da es sich hierbei nur um eine Empfehlung handelt, stellt dies jedoch keinekonkrete Anforderung dar.

Da die Bewertung von Projekten mittels Kriterien erfolgen soll, werden nachfolgend Anforde-rungen an eine entsprechende Komponente beschrieben.

3.5 Anforderungen an die Kriterienkatalogverwaltung

Die Bewertung der Innovationen in den einzelnen Projekten erfolgt anhand zuvor definierterKriterien in Form einer Nutzwertanalyse (z. B. Schlüchtermann, 2013, S. 255-260; Ammenwerth

21


und Haux, 2005, S. 214-223; Zangemeister, 1976). Da diese Kriterien vor Beginn der Bewertungs-phase durch alle Beteiligten festgelegt werden sollen, muss das System eine Funktion anbieten,Kriterien in das System einpflegen zu können. Dabei soll es möglich sein, einzelne Kriterienin Kriteriengruppen zusammenzufassen. Ferner soll es möglich sein, einzelne Kriterien undKriteriengruppen in Kriterienkatalogen zu verwalten. Entsprechend resultiert AnforderungKK.1:

KK.1: Das System soll eine Funktion anbieten, um Bewertungskriterien definieren zu kön-nen. Zudem sollen diese Kriterien in Gruppen zusammengefasst und in Kriterienkatalogenverwaltet werden können.

Da der Austausch und die Festlegung der Kriterien nicht nur mit Hilfe des Systems möglichsein soll, soll das System eine Im- und Exportfunktion für Kriterien anbieten. Dies eröffnet dieMöglichkeit, die Kriterien beispielsweise in Microsoft Excel zu definieren und anschließend indas System importieren zu können. Entsprechend resultiert Anforderung KK.2:

KK.2: Das System soll den Im- und Export von Kriterien erlauben, um eine Bearbeitungder Kriterien außerhalb des Systems zu ermöglichen.

Neben der Definition von Bewertungskriterien muss das System eine Gewichtung der Kriteriensowie die Auswahl einer Skala erlauben. Durch die Gewichtung einzelner Kriterien wirdes möglich, der Relevanz eines Kriteriums Ausdruck zu verleihen. Entsprechend resultiertAnforderung KK.3:

KK.3: Das System soll die Gewichtung von Kriterien und eine Auswahl von Skalenermöglichen.

Die Ausprägung eines Kriteriums wird über eine Skala definiert, welche eine der folgendenEigenschaften aufweist (hierzu und im Folgenden Kohn, 2005, S. 14 f. Berekoven, Eckert und El-lenrieder, 2009, S. 64 f.). Die Skalen sind hierarchisch geordnet, sodass ein höheres Skalenniveaualle Eigenschaften eines niedrigeren Niveaus umfasst. Dabei stellt die Nominalskala die nied-rigste und die Verhältnisskala die höchste Ordnung dar. Dies erlaubt die Transformation vonAusprägungen eines hierarchisch höher eingeordneten Skalenniveaus zu einem Skalenniveauniedrigerer Ordnung. Jedes Skalenniveau erlaubt die Anwendung bestimmter statistischer Ver-fahren, die eine Auswertung der abgegebenen Bewertungen erlauben. Entsprechend resultiertAnforderung KK.4:

22



KK.4: Das System soll die Auswertung von Skalen anhand der erlaubten, gegebenenstatistischen Verfahren ermöglichen.

Mögliche Skalen und korrespondierende statistische Verfahren können der nachfolgendenAuflistung entnommen werden:

∙ Nicht-metrische Skalen: Skalen, deren Ausprägungen nicht aus Zahlen besteht.

– Nominalskala: Skala, deren Ausprägungen sich nur ihrer Art nach unterscheidenlassen. Für die Ausprägungen existiert keine natürlich Ordnung.

Beispiel: Geschlecht: männlich, weiblich.

Statistisches Verfahren: Modalwert.

– Ordinalskala: Die Skalenwerte der Ordinalskala sind nicht nur in ihrer Art nachunterscheidbar, sondern besitzen zudem eine natürliche Reihenfolge.

Beispiel: Zensuren: sehr gut, . . . , ungenügend; Likert-Skala: trifft zu, . . . , trifft nichtzu.

Statistische Verfahren: Median, Quantile.

∙ Metrische Skalen: Skalen, deren Ausprägungen reelle Zahlen sind.

– Intervallskala: Metrische Skala, die keinen natürlichen Nullpunkt und keine Einheitbesitzt.

Beispiel: Kalender: Zeitabstände können berechnet werden.

Statistisches Verfahren: Mittelwert (arithmetisches Mittel).

– Verhältnisskala: Metrische Skala, die einen natürlichen Nullpunkt, aber keine na-türliche Einheit besitzt.

Beispiel: Temperatur: 1∘ C entspricht 33,8∘ F. Das Verhältnis nennt sich Umrechnungs-faktor.

Statistisches Verfahren: Geometrisches Mittel.

Aufbauend auf den formulierten Anforderungen an das zu implementierende System wird imnächsten Kapitel ein Systementwurf erstellt. Eine zusammenfassende Übersicht der formulier-ten Anforderungen kann Tabelle 3.1 entnommen werden.

23


Tabelle 3.1: Zusammenfassende Auflistung der Systemanforderungen

Anforderung Kurzbeschreibung der Anforderung

A.1 Implementierung als Web-ApplikationA.2 Plattformunabhängige ImplementierungA.3 MehrbenutzertauglichkeitBV.1 Manuelles Anlegen sowie Selbstregistrierung von BenutzernBV.2 Implementierung einer Active-Directory-SchnittstelleBV.3 E-Mail-Einladung zur Registrierung von BenutzernBV.4 Anmeldung über E-Mail / Benutzername und PasswortBV.5 Einladung enthält temporäres Passwort, welches bei der ersten

Anmeldung geändert werden mussBV.6 Implementierung verschiedener System- / ProjektrollenBV.7 Standardrollen: Administrator, Benutzer; Projektrollen: Projektlei-

ter, ProjektmitarbeiterBV.8 Zugriffsrechte können an Rollen und Benutzer vergeben werdenBV.9 Vererbte Berechtigungen nicht veränderbarBV.10 „Kiosk-Modus“: Jeder Benutzer darf Projekte anlegen; „Managed-

Modus“: Nur Projektleiter dürfen Projekte anlegenBV.11 Irreversible Verschlüsselung der PasswörterBV.12 „Passwort-vergessen“-FunktionBV.13 Link zum ändern eines Passwortes ist nur begrenzte Zeit gültigBV.14 Benutzer können in Gruppen verwaltet werden

PV.1 Projektbearbeitung abhängig von der Rolle / den Berechtigungeneines Benutzers

PV.3 Projekten sollen Benutzer zugeordnet werden könnenPV.2 Projektspezifische Zugriffsrechte sollen mit Systemrechten zusam-

mengeführt werdenPV.4 Projekte sollen Kategorien zugeordnet werden können

KK.1 Erstellung eines KriterienkatalogsKK.2 Im- und Export von Kriterien / KriterienkatalogenKK.3 Kriterien können gewichtet werdenKK.4 Auswertung der Evaluation

24



4 Systementwurf

Nachfolgend wird der konzeptuelle Systementwurf basierend auf den in Kapitel 3 formulier-ten Anforderungen mithilfe verschiedener Diagrammtypen der General Purpose ModellingLanguage (GPML) UML vorgestellt. Für das System wesentliche Klassen werden in Formeines Klassendiagramms festgehalten, das vollständig in Anhang A zu finden ist. Das Systemwird bedingt durch die Größe und Komplexität in einzelne Module aufgeteilt, um Wartbeikeitund zukünftige Weiterentwicklungen zu erleichtern. Die Vorstellung der einzelnen Systembe-standteile erfolgt analog zur Reihenfolge der Analyse spezifischer Anforderungen in Kapitel 3und wird um im Kontext relevante Bestandteile ergänzt. In Abschnitt 4.1 wird der Entwurfder Benutzerverwaltung und der Authentifizierung, in Abschnitt 4.2 der Projektverwaltungund in Abschnitt 4.3 die Unternehmensverwaltung vorgestellt. Die Kriterienkatalogverwal-tung wird in Abschnitt 4.4 vorgestellt und in Abschnitt 4.5 der Fokus auf Überlegungen zurAuswertungskomponente gelegt.

4.1 Benutzerverwaltung und Authentifizierung

Abbildung 4.1 visualisiert die von der Benutzerkomponente angebotenen Schnittstellen. Diesekapseln die im Inneren der Komponente befindlichen Objektstrukturen (siehe Abbildung 4.2)nach außen zu den anderen Komponenten ab, um die Implementierung einer Methode ändernzu können, ohne dass dies Auswirkungen auf die Komponenten hat, die Funktionalitäten derBenutzerverwaltungskomponente verwenden, da sich die Signaturen der Schnittstellen nichtändern.

Im Zentrum steht die Klasse „User“, welche gemäß der Anforderung BV.4 die Attribute userna-me und password enthält, die für die Anmeldung am System verwendet werden. Die Klasse„SystemRole“ ermöglicht es, Benutzern eine oder beliebig viele Systemrollen zuzuweisen. DasRollenkonzept erfüllt die Anforderung BV.6 und implizit auch die geforderte Möglichkeit,Zugriffsrechte an Benutzer und Rollen vergeben zu können (BV.8). Das System bietet zunächstzwei Rollen an, die Benutzer-Rolle und die Administrator-Rolle. Diese unterscheiden sichmaßgeblich darin, dass Benutzer mit Administrator-Rolle Zugriff auf das gesamte Systemhaben, wohingegen Benutzer mit der Benutzer-Rolle nur auf zugelassene Bereiche zugreifendürfen.

25

4 Systementwurf

«Annotation»AdminOnly

«Annotation»UserOnlycount():long

delete(User):voidfindAll():List<User>findAllEmailAddresses():List<String>findAllUsernames():List<String>findByActivationCode(code:String):UserfindByEmail(email:String):UserfindByPasswordResetToken(token:String):UserfindByUsername(username:String):UserfindByUsernameOrEmail(login:String):UserfindOne(id:String):UsergetAllUsers():List<User>save(user:User):void

UserService

authenticate(username:String, password:String):AuthStatuscheckPassword(plainText:String, hashed:String):booleanhashPassword(plainText:String):StringisAuthorized(userId:String, identifyable:Identifyable, permissionType:PermissionType):boolean

«Interface»AuthService

count():longdelete(systemRole:SystemRole)findAll():List<SystemRole>findById(id:String):SystemrolegetAdminRole():SystemRolegetRoleByName(name:String):SystemRolegetUserRole():SystemRolesave(systemRole:SystemRole):void

SystemRoleService

ERRORUSER_NOT_ACTIVATEDSUCCESS

«Enum»AuthStatus

setId(id:String):voidgetId():String

«Interface»Identifyable

ALLCREATEDELETEMANAGE_ADDRESSESMANAGE_MEMBERMANAGE_ROLESREADUPDATEUPLOAD_FILE

«Enum»PermissionType

Abbildung 4.1: Schnittstellendiagramm: Benutzerverwaltung

Für die Erzeugung von Benutzer-Objekten und deren Verwaltung wird die Schnittstelle „User-Service“ bereitgestellt. Sie bietet Zugriff auf Methoden, die für die Verwaltung von Benutzern(Erstellen, Lesen, Aktualisieren und Löschen) benötigt werden.

Element hat BerechtigungenACL

username : Stringpassword : Stringemail : String

User

firstName : Stringsurename : Stringbirthdate : Date

UserProfilehas 1..1

1..10..*

0..*

name : String

Usergroup#1

name : String

SystemRoleACL

#2

ACL

0..* 0..*member of

acts as

1..1

Abbildung 4.2: Klassendiagramm: Benutzerverwaltung

26



Um die Erzeugung von Systemrollen zu ermöglichen, wird eine weitere Schnittstelle – „System-RoleService“ – angeboten. Sie bietet Zugriff auf Methoden zum Erstellen, Lesen, Aktualisierenund Löschen von Systemrollen.

Eng verbunden mit der Verwaltung von Benutzern und Rollen sind Methoden, die prüfen, obein Benutzer über benötigte Zugriffsrechte verfügt. Diese Prüfung erfolgt über die Schnittstelle„AuthService“, die Zugriff auf Methoden zum Verschlüsseln und Überprüfen von Passwörternermöglicht. Mithilfe der Methode „isAuthorized“ bietet der Security-Manager die Möglichkeitzu prüfen, ob ein Benutzer für den Aufruf einer Webseite über benötigte Zugriffsrechte verfügt,die mithilfe der Annotationen „AdminOnly“ oder „UsersOnly“ gesetzt werden. Hierbei gilt,dass im Falle einer Seite, die mit dem Zugriffsrecht für „UsersOnly“ versehen ist, grundsätzlichnur angemeldete Benutzer Zugriff haben (dies schließt Administratoren ein). Webseiten, diemit dem Zugriffsrecht „AdminOnly“ versehen sind, können nur von registrierten Benutzern,die über die Systemrolle Administrator verfügen, aufgerufen werden.

User anhand Aktivierungs-token suchen

ODER

Keinen Benutzer gefunden

Fehlermeldung anzeigen Benutzer aktivieren

Benutzer gefunden

Registrierungs-formular ausfüllen

Registrierungs-formular absenden

ODER

Aktivierungstokenvia Mail verschicken

Formular ok

Benutzer in Datenbank speichern

Formulardaten fehlerhaft

Formulardatenkorrigieren

Abbildung 4.3: Aktivitätsdiagramm: Registrierung und Freischaltung von Benutzern

Damit sich Benutzer am System anmelden können, ist eine vorherige Registrierung nötig(Abbildung 4.3). Zur Registrierung muss der Benutzer formularbasiert einen Benutzernamenbzw. eine E-Mail-Adresse sowie ein Passwort angeben, um sich nach erfolgreicher Aktivierungdes Benutzerkontos am System anmelden zu können. Zuvor werden die eingegebenen Datenauf Korrektheit überprüft und nach erfolgreicher Prüfung ein Aktivierungsschlüssel an den

27

4 Systementwurf

Benutzer versendet, mit dessen Hilfe der Benutzer seinen Zugang freischalten und verifizierenkann, dass seine Daten nicht missbraucht wurden (Abbildung 4.3).

Die in Abbildung 4.2 modellierte Klasse „Benutzerprofil“ befindet sich außerhalb der Benut-zerverwaltung, da diese für die Funktionsweise der Benutzerverwaltung nicht zwingendnotwendig ist, sondern ausschließlich im späteren System verwendet wird, um das Konzept„Benutzer“ um weitere Semantik anzureichern.

Um angelegte Benutzer zu Projekten zuordnen zu können und um Projekte anlegen zu können,wird eine Komponente zur Projektverwaltung benötigt, die im folgenden Abschnitt vorgestelltwird.

4.2 Projektverwaltung

Da Innovationen im Rahmen von Projekten bewertet werden (siehe Abschnitt 2.3), nimmtdie Verwaltung von Projekten eine essentielle Rolle im zu entwickelnden System ein. DieProjektverwaltungskomponente (Abbildung 4.4, Abbildung 4.5) bietet hierfür verschiedeneMethoden an, die das Erstellen, Bearbeiten oder Löschen von Projekten erlauben. Da derZugriff auf diese Methoden von der Rolle eines Benutzers in einem Projekt abhängig sein soll –dies verhindert den unautorisierten Zugriff auf bestimmte Funktionen – muss eine Methodeangeboten werden, die die jeweilige Rolle eines Benutzers in einem Projekt identifizierenkann. Dies wird durch die Methode „isAuthorized“ realisiert, welche anhand der Projektrolleeines Benutzers entscheidet, ob und welche Aktionen der Benutzer im Kontext eines Projektsausführen darf. Hierfür wird der Benutzer, das Projekt und die Art des Zugriffs („Permis-sionType“) übergeben. Innerhalb der Methode wird anschließend geprüft, ob der BenutzerMitglied des Projektes ist und welche Projektrolle dieser einnimmt. Anhand der Projektrollewird entschieden, ob die Zugriffsart für den Benutzer zulässig ist oder nicht.

+ delete(id:String):void+ save(project:Project):void+ findOne(id:String):Project+ findAll():List<Project>+ findAll(page:Page):List<Project>+ findByUser(userId:String):List<Project>+ isAuthorized(userId:String, projectId:String, permission:PermissionType):boolean+ getNextProjectStatus(project:Project)

ProjectService

Abbildung 4.4: Schnittstellendiagramm: Projektverwaltung

Die Projektverwaltung besteht grundsätzlich aus den Klassen „Project“, „ProjectRole“ und„ProjectMember“. Ein Projektteam bildet sich implizit aus der Gesamtheit aller einem Projektzugehörigen Projektmitglieder. Alle Mitglieder eines Projekts nehmen (genau) eine Rolle im

28



name : Stringdescription : String

Projectworks on 1..*

name : String

ProjectRoleACL

#3

name : String

ProjectMember#4

name : String

ProjectMemberGroup

1..*

acts as1..*

0..*1..1

Abbildung 4.5: Klassendiagramm: Projektverwaltung

Projekt ein. Jeder Projektrolle können Zugriffsrechte zugeordnet werden, die sich auf dieBenutzer übertragen, die der jeweiligen Rolle zugeordnet sind. Abhängig von den gesetztenZugriffsrechten werden auf der grafischen Benutzerschnittstelle (graphical user interface, GUI)nur solche Schaltflächen und Links angezeigt, die der Benutzer verwenden darf. Alle anderenAktionsmöglichkeiten werden ausgeblendet.

Der Geltungsbereich einer Projektrolle ist auf ein bestimmtes Projekt beschränkt. Die in denAnforderungen geforderte Rolle eines Projektmanagers hat jedoch eine projektübergreifendeFunktion. Entsprechend muss neben der Möglichkeit projektspezifische Rollen zu vergebenauch die Vergabe der projektübergreifend zu vergebenden Rolle Projektmanager gegeben sein.

4.3 Unternehmensverwaltung

Die Unternehmensverwaltungskomponente (Abbildung 4.6) erlaubt die Verwaltung von Unter-nehmen, Mitarbeitern und Rollen (CompanyRole). Eine dieser Rollen ist die des Projektmanagers.Diese Rolle kann von Mitarbeitern des Unternehmens ausgefüllt werden, sodass diese alleProjekte eines Unternehmens administrieren können. Ein Projektmanager hat die Befugnis,Projekte im Namen des Unternehmens anzulegen, zu bearbeiten und andere Benutzer zuProjektleitern zu ernennen. Da das Projektmanagement bzw. ein Projektmanager nicht zwin-gend explizit als Mitglied eines Projektes gelistet werden muss, ist der Projektmanager nichtBestandteil eines Projektteams. Soll der Projektmanager auch als Mitglied eines Projektesauftauchen, muss dieser, wie jeder andere Benutzer auch, dem Projekt als Mitglied hinzugefügtwerden.

Legt ein Projektmanager ein neues Projekt an, wird dieses mit dem Unternehmen, in dem derProjektmanager tätig ist, assoziiert. Die Assoziation wird über die Rolle des Projektmanagerssowie das jeweils erstellte Projekt realisiert, d. h., dass die Referenz nicht auf einen konkretenMitarbeiter des Unternehmens zeigt, sondern ausschließlich auf die Rolle im Unternehmen.

29

4 Systementwurf

Dies hat den Vorteil, dass der als Projektmanager agierende Mitarbeiter wechseln kann, ohnedass die Referenz eines Projekts auf das Unternehmen neu angelegt oder aktualisiert werdenmuss. Eine Aktualisierung der Rolle ist erst dann notwendig, wenn sich die Rahmenbedingun-gen der Rolle Projektmanager selbst ändern.

name : String

Company

name : String

CompanyRole

Employee

1..*1..1

works for

1..1

0..*

1..1

0..* has

street : Stringnumber : Stringzip : Stringcity : Stringcountry : String

Address

1..*

1..1

has

Abbildung 4.6: Klassendiagramm: Unternehmensverwaltung

Die Evaluation von Innovationen erfolgt im Rahmen von Projekten. Daher muss das Systemdie Möglichkeit bieten, Bewertungskriterien sowie Ausprägungen zu definieren und dieseeinem Projekt zuordnen zu können. Die hierzu konzipierte Komponente zur Kriterienkatalog-verwaltung wird im folgenden Abschnitt vorgestellt.

4.4 Kriterienkatalogverwaltung

Die Kriterienkatalogverwaltung (Abbildung 4.7) stellt die größte und auch komplexeste Kom-ponente des Systems dar, da diese die Kernfunktionalitäten des Systems anbietet. Sie erlaubtes Benutzern, Kriterien zu erstellen anhand derer ein Projekte bewertet werden kann. Um dieAuswahl an Kriterien zu erleichtern, kann ein Projekt mit einer Projektkategorie assoziiert wer-den, die bereits an eine vordefinierte Kriteriengruppe gebunden ist. Außerdem ist es möglich,einen Kriterienkatalog bedarfsorientiert anzupassen.

Da Kriterien in Gruppen organisiert werden können, muss die Skala bzw. Bewertung einesKriteriums bei Betrachtung einer Kriteriengruppe entsprechend aggregiert werden können.Hierzu müssen ggf. Skalentransformationen vorgenommen werden. Dies bedeutet im Fallevon kardinalen Skalen beispielsweise, dass ein Mittelwert oder Durchschnittswert für die

30



gesamte Gruppe berechnet werden können muss. Hierbei sind diverse Faktoren, u. A. dieGewichtung einzelner Kriterien, zu berücksichtigen.

ProjectCriteriaCatal.

weight : Double

WeightCriterion 1..* 1..1has

CriterionGroup

consists of 0..*

0..*

NominalScaledCriterion

OrdinalScaledCriterion

NominalValue

rank : int

OrdinalValue

value : Stringorder : int

MeasurementValue

measured by1..1 0..*

MultiScaledCriterion

SingleScaledCriterion2..*

consists of1..1

measured by1..1 0..*

name : Stringorder : int

CriterionPage1..* 1..1consists ofname : String

description : Stringorder : intreferenceType : boolean

PageElement#5

0..*0..*

Abbildung 4.7: Klassendiagramm: Kriterienkatalogverwaltung

Auch wenn die Skalenverwaltung in Abbildung 4.7 abgesetzt dargestellt ist, ist sie wichtiger Be-standteil der Kriterienverwaltung, da diese wechselseitig existenziell miteinander verbundensind. Dies bedeutet, dass die Kriterienverwaltung zwar auf die Skalenverwaltung zurück-greifen kann, aber die Transformation von Skalen nicht sichtbar für die Kriterienverwaltungvorgenommen wird. Im folgenden wird näher auf die Auswertung der Kriterien eingegangenund beschrieben, wie die grafische Repräsentation erfolgt. Das vollständige Klassendiagrammdes Systementwurfs findet sich in Anhang A, Abbildung A.1.

4.5 Auswertungskomponente

Die Präsentation der Auswertung der eingegebenen Daten erfolgt mittels verschiedener Dia-grammtypen, um einen einfachen visuellen Zugang zu den Ergebnissen der Innovationsbewer-tung zu erhalten (z. B. Ammenwerth und Haux, 2005, S. 217 ff.; Meyer, 1999). Zur Auswertung

31

4 Systementwurf

ist zunächst die Aggregation der gesammelten Daten, die in Abhängigkeit der dem Kriteriumzugrunde liegenden Skala erfolgt, notwendig. Ordinal skalierte Kriterien beispielsweise habenals Resultat immer genau eine ausgewälte Ausprägung, wohingegen nominal skalierte Kriteri-en auch Mehrfachauswahl ermöglichen (bspw. „Welche der folgenden Eigenschaften wärenIhnen im Falle der Einführung der Innovation besonders wichtig?“). Aus diesem Grund wirdin einer abstrakten Klasse „Report“ über alle Kriterien eines Projekts iteriert und die Ergebnissein Form einer Matrix abgelegt. Abbildung 4.8 zeigt die interne Darstellung: Für ein Kriteriumdas eine Mehrfachauswahl vorsieht bzw. explizit erlaubt, wird für jede Ausprägung hinterlegt,ob ein Benutzer diese gewählt hat, oder nicht. Diese Information wird in Form von bool’schenWerten gespeichert, wobei TRUE (1) als „Benutzer hat die Ausprägung gewählt“ bzw. FALSE

(0) als „Benutzer hat die Ausprägung nicht gewählt“ definiert ist. Für Kriterien, die nur dieAuswahl genau einer Ausprägung vorsehen, wird die vom Benutzer gewählte Ausprägunggespeichert. Basierend auf dieser Matrix können einfache Berechnungen durchgeführt undderen Ergebnisse grafisch dargestellt werden können.

Benutzer 2 1

…

0

…

1

0 0

Aus

präg

ung

4

Benutzer N

Aus

präg

ung

1

männlich

Aus

präg

ung

5

…

1

Benutzer 1

…

…

Aus

präg

ung

2

……

weiblich

männlich

1 0

… …

0

…

0

Aus

präg

ung

3

0 …

…

1 0

1

0

Geschlecht

…Bitte geben Sie Ihr Geschlecht an.

Welche der folgenden Eigenschaften wären Ihnen im Falle der Einführung der Innovation besonders wichtig?

Abbildung 4.8: Skizze: Reportmatrix

Abbildung 4.9 zeigt die Darstellung der Auswertung in Form eines Säulen- und eines Balken-diagramms, Abbildung 4.10 in Form eines Spinnennetzdiagramms. In den Diagrammen ist einLabel „JS chart by amCharts“ zu sehen, da das verwendete Framework zur Generierung derCharts dies in der kostenfrei lizensierten Version verlangt1.

Das Spinnennetzdiagramm erlaubt ebenfalls eine aggregierte und gleichzeitig differenzierteDarstellung der Auswertungsergebnisse anhand des Kriterienkatalogs. Im Beispiel werden diezulässigen Ausprägungen eines Kriteriums in Abhängigkeit ihrer Nennung pro Berufsgruppedargestellt. Die Anzahl der Nennungen erscheint auf jeder der verschiedenen Achsen, die für

1Weitere Informationen hierzu sind auf der Webseite der Entwickler, http://www.amcharts.com, zu finden.

32

http://www.amcharts.com



Abbildung 4.9: Darstellung der Ergebnisse in Form eines Säulen- bzw. Balkendiagramms

jede Ausprägung des betrachteten Kriteriums existieren. Die Berufsgruppe eines Benutzerswird im jeweiligen Benutzerprofil hinterlegt.

33

4 Systementwurf

Die Einführung eines neuen Systems zur Vergabe und Verwaltung von Terminen istaufwendig.

Nennungen Spinnennetzdiagram

0

5

10

15Stimme zu

Stimme eher zu

Weder nochStimme eher nicht zu

Stimme nicht zu

JS chart by amCharts (http://www.amcharts.com/javascript-charts/)

OP-Pflege Ärtzlicher Dienst MTA

Administrator

Abbildung 4.10: Darstellung der Ergebnisse in Form eines Spinnennetzdiagramms

Nachdem der Systementwurf offengelegt worden ist, wird im nächsten Kapitel die verwendeteEntwicklungsumgebung vorgestellt.

34



5 Entwicklungsumgebung

Nachfolgend wird dargelegt, wie die Entwicklung der Web-Applikation vorgenommen wurde.Es werden zentrale Werkzeuge und deren Aufgabe im Rahmen des Implementierungspro-zesses vorgestellt. Die Kernkomponenten des Implementierungsprozesses, auf die in dennachfolgenden Abschnitten eingegangen wird, sowie die Informationsflüsse zwischen denverschiedenen Systemen zeigt Abbildung 5.1.

<<CI-Server>>Jenkins

<<Remote-Repository>>Git Repository

<<Lokales Repository>>Git Repository

<<Entwicklungswerkzeug>>Eclipse IDE

Java-Applikation

Dokumentation

Testergebnisse

synchronisiereQuellcode

synchronisiereQuellcode

hole aktuellenQuellcode

generiert

kompiliert

publiziert

Quellcodeaustausch

Legende:

Automatisch generierte Daten

Abbildung 5.1: Darstellung der Systeme/Komponenten des Implementierungsprozesses

5.1 Entwicklungswerkzeug

Für die Implementierung der Web-Applikation wurde das Integrated Development Environ-ment (IDE) Eclipse gewählt, da dieses durch verschiedene Plug-Ins1 an die Bedürfnisse desEntwicklers angepasst werden kann (Gamma und Beck, 2004, S. 5 f.). Mithilfe der Eclipse IDEwurden alle für das Projekt relevanten Klassen, HTML-Templates und sonstige Ressourcen

1Ein Plug-In ist eine Erweiterung für ein bestimmtes Softwaresystem, welche das System um neue Funktionali-täten erweitert. Hierfür ist es nötig, dass die Software Schnittstellen anbietet, welche von den Plug-Ins genutztwerden können. Solche Schnittstellen werden oftmals in Form von Interfacedefinitionen zur Verfügung gestellt.Im Kontext der Eclipse IDE wird von extension points, den offerierten Schnittstellen und extensions, den konkretenPlug-Ins gesprochen (Gamma und Beck, 2004, S. 5).

35


erstellt und verwaltet. Bereits existierende Java-Pakete wie bspw. Hash-Alogrithmen zumVerschlüsseln von Passwörtern, wurden durch ein zusätzliches Werkzeug namens Maveneingebunden. Maven ist ein Dependency sowie Software Project Management Werkzeug, dasin Eclipse integriert werden kann und die Verwaltung von Paketabhängigkeiten erleichtert(Spiller, 2011, S. 27 ff.). Mithilfe von Maven ist es möglich, Pakete anderer Entwickler, die ihreProdukte frei zur Verfügung stellen (bspw. von APACHE COMMONS), in das eigene Produktzu integrieren. Hierfür muss der Entwickler die in einem zentralen Repository2 befindlichenArtefakte über eine Maven Konfigurationsdatei referenzieren. Anschließend fügt Maven diebenötigte Komponente automatisch dem Projekt hinzu, ohne dass für den Entwickler weitererKonfigurationsaufwand entsteht. Um die Arbeit mit den stetig wachsenden Ressourcen zuvereinfachen und Änderungen zu verfolgen, ist eine Struktur zur Versionsverwaltung angelegtworden, die über ein entsprechendes Eclipse Plug-In (EGit) benutzt werden konnte.

5.2 Quellcode Versionsverwaltung

Die Verwaltung und Versionierung des Quellcodes einer Software ist wichtiger Bestandteileines jeden Softwareentwicklungsprojektes, da nur so Änderungen nachverfolgt und Fehlernachvollziehbar behoben werden können. Zudem ermöglicht eine zentrale Verwaltung desQuellcodes das gleichzeitige Entwickeln mit mehreren Entwicklern am selben Projekt, ohnedass Änderungen gegenseitig überschrieben werden. Die im Rahmen dieses Projekts verwen-dete Versionierungssoftware GIT benötigt im Gegensatz zum Pendant SVN keinen zentralenServer, sondern ausschließlich ein installiertes Kommandozeilenwerkzeug (Collins-Sussman,Fitzpatrick und Pilato, 2008, S. 191f; Loeliger und McCullough, 2012, S. 235). Das Fehlen einerServerstruktur war zugleich ausschlaggebender Punkt zur Nutzung von GIT, da dies denInstallationsaufwand erheblich reduziert hat.

Um Datenverlust vorzubeugen und das Risiko implementierten Code zu verlieren zu redu-zieren, wurde auf einem zweiten Computer ein weiteres GIT Repository eingerichtet, das alsentferntes Backup-Repository gedient hat. Damit die Qualität des in das Repository eingespiel-ten Codes überprüft werden kann, ist der eingespielte Code von einem Continuous IntegrationServer einmal am Tag kompiliert, alle implementierten Tests durchgeführt und anschließendein entsprechender Bericht generiert worden.

2Das zentrale Maven Repository kann unter der URL http://search.maven.org abgerufen und durch-sucht werden.

36

http://search.maven.org



5.3 Continuous Integration

Da der Quellcode einer Software bedingt durch die fortschreitende Entwicklung ständigenÄnderungen unterliegt, ist es von hoher Relevanz die bisher implementierten Programmteilezu testen. Zwar wird durch die Implementierung von Unit-Tests3 bereits im Vorfeld durchden Entwickler getestet, doch existieren weitere Testroutinen, die zeitlich so aufwendig sind,dass diese nicht bei jeder Änderung vom Entwickler angestoßen werden können. Dies trifftbeispielsweise auf Integrationstests zu, da diese oftmals in Verbindung mit einer Datenbankverschiedene Tests vorsehen. Da solche Tests dennoch für den Verlauf und die Qualität derImplementierung von hoher Bedeutung sind – sie testen die bisher implementierte Logik unddecken Fehler auf, die im Entwicklungsprozess durch Seiteneffekte entstanden sind –, werdendiese im Rahmen von Continuous Integration (CI) Prozessen angestoßen (Smart, 2011, S. 1 f.).Abbildung 5.2 zeigt den exemplarischen Verlauf der Unit-Test-Ergebnisse für die letzten dreiKompiliervorgänge.

Abbildung 5.2: Testverlaufsgraph der JUnit-Tests

Continuous Integration ermöglicht eine zeitnahe Code-Analyse, die detailliert Aufschlussüber die Qualität gibt und mögliche Probleme des Quellcodes anzeigt, wie beispielsweiseVerstöße gegen existierende Formatierungskonventionen (Abbildung 5.3; Abbildung 5.4). Sokann im Rahmen der Entwicklung der Analysebericht in die Planung der weiteren Schrittedes Softwareentwicklungsprojektes einfließen, ein qualitativ hochwertiges Softwareproduktausgeliefert werden und bei auftretenden Problemen zeitnah reagiert werden.

3Ein Unit-Test ruft eine zu testende Methode auf und überprüft anhand definierter Annahmen die Korrektheitder getesteten Methode. Eine Unit stellt hierbei die kleinste testbare Einheit einer Applikation, d. h. eine Methodeoder Funktion, dar (Beck, 2009).

37


Abbildung 5.3: Checkstyle Graph zur Darstellung gefundener Verstöße gegen vorgegebene Code-Konventionen

Abbildung 5.4: FindBugs Graph zur Darstellung gefundener Fehler

Im Rahmen dieses Projekts ist die CI-Software Jenkins eingesetzt worden, die es erlaubt die imRahmen von CI vorgeschlagenen Analysen durchzuführen und zu publizieren, sodass einepermanente Überwachung des Implementierungsstands gewährleistet werden kann. So veröf-fentlicht Jenkins u. a. die Dokumentation der Web-Applikation in Form von JavaDoc-HTML-Seiten, die kompilierte Web-Applikation selbst, sowie Testergebnisse aller implementiertenTestarten (Abbildung 5.1).

Die in diesem Kapitel vorgestellte Struktur der einzelnen Unterstützungssysteme entsprichtdem gängigen Vorgehen in der Praxis. Zwar fehlen ergänzend noch Bugtracking-Systeme oderein eigenes zentrales Maven Repository, das öffentliche und private Pakete beinhaltet, da dieEntwicklung dieses Systems jedoch zunächst auf einen geschlossenen, kleinen Benutzerkreis

38



begrenzt war, stand der Aufwand der Initialisierung o. g. Systeme in keinem Verhältnis zumNutzen. Daher ist bewusst auf diese zusätzlichen Systeme verzichtet worden.

Nachdem die Software-Infrastruktur vorgestellt wurde, die als Grundlage zur Implemen-tierung dient, wird im folgenden Kapitel die Implementierung der entwickelten Softwaredokumentiert.

39

6 Dokumentation der Implementierung


In diesem Kapitel wird die Implementierung der Web-Applikation dokumentiert. Zunächstwird die Auswahl einer geeigneten Programmiersprache (Abschnitt 6.1) beschrieben, dann dieWahl eines Webframework (Abschnitt 6.2). Anschließend wird das ausgewähle Webframeworkin Abschnitt 6.3 sowie das verwendete Datenbank-Framework in Abschnitt 6.4 vorgestellt.Die Abschnitte 6.5 und 6.6 beschreiben die Architektur der Web-Applikation, die sich an denzugrunde liegenden Anforderungen orientiert.

6.1 Wahl einer Programmiersprache

Wie in Anforderung A.1 beschrieben, soll das System als Web-Applikation entwickelt werden.Um dies realisieren zu können, muss eine geeignete Programmiersprache gefunden werden.Einer Studie der Freien Universität Berlin hat verschiedene Web-Entwicklungssprachen mit-einander verglichen (Hardy, 2007). Eine Umfrage unter insgesamt 268 Teilnehmern ergab,dass Ruby, PHP, Java und ASP.NET die am häufigsten verwendeten Programmiersprachenim Bereich des Web-Engineerings sind (Hardy, 2007, S. 16). Zwar sind in den vergangenenJahren neue Sprachen, wie D, Go, Clojure u. v. a, hinzugekommen, doch ist die Einsatzhäu-figkeit der von Hardy (2007) vorgestellten Sprachen nach wie vor unbestritten.1 Dies zeigtsich vor allem darin, dass die meistbesuchten Webseiten des Internets mittels der vermeintlichalten Sprachen realisiert worden sind.2 Eine kürzlich durch das IEEE veröffentlichte Statistiknennt die von Hardy genannten Sprachen nach wie vor unter den Top-10 der meistgefragtenWeb-Entwicklungssprachen (Cass, Diakopoulos und Romero, 2014).

Um eine Sprache für die Implementierung des Systems auszuwählen, werden folgende Bewer-tungskriterien herangezogen:

∙ Typisierung:Starke Typisierung kann hohe Semantik bedeuten und Integration fördern. So wird derBenutzername eines Kunden beispielsweise als String username deklariert und nichtals untypisierte Variable var username initialisiert.

1http://githut.info2http://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_

websites

40

http://githut.info

http://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites

http://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites



Ausprägungen: Abhängig vom Typisierungsgrad: schwach (1), dynamisch (2) stark/sta-tisch (3).

∙ Plattformabhängigkeit:Ist es möglich, die spätere Applikation auf verschiedenen Plattformen zu installieren,oder ist sie an eine bestimmte Plattform gebunden?Ausprägungen: Läuft auf allen Plattform (3), läuft nur auf bestimmten Plattformen (1).

∙ Objektorientierung:Ist die betrachtete Programmiersprache objekt-orientiert (OO)? Das OO-Paradigma eignetsich für das hier vorgestellte Systemkonzept, da es „separation of concerns“ ermöglichtund so das System in Module unterteilt werden kann.Ausprägungen: Sprache ist OO (3), Sprache ist teilweise OO (2), Sprache ist nicht OO (1).

∙ Installationsaufwand:Wie viel Zeit nimmt die Installation aller benötigten Softwarekomponenten (Datenbank,Server, etc.) in Anspruch.Ausprägungen: gering [< 1h] (3), mittel [1-2h] (2), hoch [> 2h] (1).

∙ Portierbarkeit:Wie komplex ist der Prozess, eine in der jeweiligen Sprache entwickelte Applikation aufeine andere Maschine zu portieren? Ausprägungen: einfach (3), mäßig (2), schwer (1).

∙ Datenbank-Anbindung:Wie hoch ist der Aufwand mit der betrachteten Programmiersprache eine Anbindung anein Datenbank Management System (DBMS) herzustellen?Skala: gering (3), mittel (2), hoch (1).

Das Ergebnis der Evaluation ist in Tabelle 6.1 zu sehen und zeigt, dass Java die zu präferierendeProgrammiersprache ist. Sie bietet Plattformunabhängigkeit, Objektorientierung sowie Typsi-cherheit durch statische Typisierung. Die Plattformunabhängigkeit soll gewährleisten, dass dieWeb-Applikation flexibel genug ist, auf verschiedenen Plattformen zu funktionieren. Eine ob-jektorientierte Entwicklung erlaubt die logische Trennung der einzelnen Web-Applikationsteilein sinnvolle Artefakte, wie beispielsweise verschiedene Komponenten, und erhöht damitdie Wartbarkeit und Wiederverwendbarkeit der Komponenten. Die Typsicherheit von Javaerhöht zudem die Sicherheit einer Web-Applikation. Es ist beispielsweise nicht möglich beieiner Datenbankabfrage, welche eine ID des Typs Integer erwartet, einen Wert vom TypString zu übergeben. Dies bietet vor allem Schutz gegen „SQL-Injections“, über die durchManipulation einer Datenbankabfrage ein nicht autorisierter Zugriff auf das DBMS ermöglichtwerden könnte.

41


Tabelle6.1:V

ergleichvon

Webentw

icklungssprachen

Ruby

PHP

JavaA

SP.NET

Erscheinungsjahr1995

19951995

2002A

ktuelleVersion

2.1.25.5.12

8.04.5

LetzteA

ktualisierung9.M

ai20141.M

ai201418.M

ärz2014

15.August2012

Typisierungdynam

isch2

schwach,dynam

isch1

stark,statisch3

stark,statisch3

Plattformalle

3alle

3alle

3W

indows

1O

bjekt-Orientiert

ja3

teilweise

2ja

3ja

3Installationsaufw

andm

äßig2

mäßig

2einfach

3schw

er1

Portierbarkeitm

äßig2

mäßig

2einfach

3nichtm

öglich0

DBM

S-Anbindung

mäßig

2m

äßig2

mäßig

2m

äßig2

Summ

e14

1217

10

42



Nach der Auswahl einer geeigneten Programmiersprache wird im folgenden Abschnitt dieAuswahl eines geeigneten Frameworks, dessen Einsatz der Erleichterung und Beschleunigungder Implementierung dient, vorgestellt.

6.2 Wahl eines Webframeworks

Die Erleichterung und Beschleunigung der Implementierung durch das Framework wirddadurch gegeben, dass bestimmte Standardfunktionalitäten, wie beispielsweise Sessions oderTemplates, bereits durch das Framework implementiert werden. Eine Eingrenzung der mög-lichen Frameworks ist dadurch gegeben, dass die Web-Applikation als Java-Anwendungentwickelt werden soll.

Für die Wahl eines Frameworks sind drei Kriterien ausschlaggebend gewesen: Intuitive Nut-zung, Anpassbarkeit der Hypertext Markup Language (HTML)-Templates und Integrationanderer Technologien (beispielsweise Hibernate). Um diese Kriterien zu überprüfen, wurde einUse-Case, der mit jedem Framework durchgeführt wurde, entwickelt, der wie folgt definiertwurde: Mithilfe des gewählten Frameworks soll eine Webseite mit einem Standardlayoutimplementiert werden. Das Standardlayout soll über das CSS-Framework „Bootstrap“3 rea-lisiert werden. Bootstrap wurde gewählt, da es hochgradig anpassbar und einfach in eineWeb-Applikation zu implementieren ist. Im Gegensatz zu anderen CSS-Frameworks wie bei-spielsweise YAML (Yet Another Multicolumn Layout)4, welches aus insgesamt 22 Dateienbesteht, ist Bootstrap kompakt und besteht aus insgesamt vier Dateien. Zudem setzt Bootstrapauf die dynamische Stylesheet-Sprache LESS5, welche die Standard-Stylesheet-Sprache CSSum Konzepte wie Vererbung, Variablen und Mixins erweitert. Mixins sind ein Konzept, überdas wiederverwendbare Artefakte, wie beispielsweise abgerundete Ecken, definiert werdenkönnen. Einem Mixin können Parameter übergeben werden, die beispielsweise den Radiusabgerundeter Ecken definieren. Die Webseite soll aus insgesamt zwei statischen Unterseitenbestehen, die über eine Navigation erreicht werden können. Anhand dieses Use-Cases sindanschließend die in Tabelle 6.2 aufgelisteten Frameworks untersucht worden.

Da die Implementierung des Standardlayouts mit GWT bereits erhebliche Schwierigkeitenbereitete und insgesamt keine Intuitive Nutzung möglich war, wurde GWT sehr früh nichtweiter als Kandidat in Betracht gezogen. Neben GWT wurde auch Vaadin als Framework inBetracht gezogen, jedoch zeigten erste Recherchen, dass Vaadin auf GWT aufbaut und somitaus o. g. Gründen ebenfalls nicht berücksichtigt wurde. Das Play Framework kann zwar mitJava und Scala verwendet werden, doch unterliegt die API dieses Frameworks starken Ände-rungen und ist bei Versionssprüngen nicht konsistent, sodass sich eine Verwendung dieses

3http://www.getbootstrap.com4http://www.yaml.de5http://www.lesscss.org

43

http://www.getbootstrap.com

http://www.yaml.de

http://www.lesscss.org


Tabelle 6.2: Vergleich von Java-Webframeworks

Name Sprachen Version Letztes Update

Apache Wicket Java 6.15.0 17. April 2014Google Web Toolkit (GWT) Java 2.6.1 9. Mai 2014

Vaadin Java 7.2.0 14. Mai 2014Play Framework Java, Scala 2.2.3 1. Mai 2014

Spring MVC Java 4.1.0 3. September 2014

Frameworks als problematisch herausgestellt hat. Zudem werden die Views und enthaltenelogische Operationen, wie Schleifen oder Bedingungen, in Scala implementiert, was dazuführt, dass Java-Code und Scala-Code vermischt werden. Anschließend wurde der Use-Casemithilfe des Frameworks Apache Wicket umgesetzt. Die Umsetzung war im Vergleich zu GWTerheblich einfacher und die Viewprogrammierung frei von Steuerangaben wie Schleifen oderBedingungen. Insgesamt war Apache Wicket intiutiver zu verwenden und ist als möglicherKandidat in Betracht gezogen worden. Zuletzt wurde das Webframework Spring MVC un-tersucht und der Use-Case umgesetzt. Dadurch, dass Spring MVC eine deutliche Trennungder einzelnen Schichten (Model, View und Controller) vorsieht, war die Implementierung imVergleich zu Apache Wicket intuitiver und die Rüstzeit deutlich geringer. Deutlich zeigte sichdie steile Produktivitätskurve, die mit dem Einsatz des Spring MVC-Frameworks einherging.Betrachtet man die für das Erlernen des Frameworks, sowie die Umsetzung des Use-Casesbenötigte Dauer, so konnte sich Spring MVC deutlich von den anderen Frameworks absetzen,was nicht zuletzt auf der ausführlichen Dokumentation beruht. Konsequenterweise ist daherdas Framework Spring MVC, das nachfolgend beschrieben wird, ausgewählt worden.

6.3 Webframework: Spring MVC

Spring MVC ist ein von Pivotal Software (im folgenden Pivotal genannt) entwickeltes Frame-work, welches die Erstellung von Web-Applikationen ermöglicht. Pivotal pflegt das Frame-work als Open-Source-Projekt und monetarisiert das Framework über Beratungsleistungen.Zur Trennung der Anzeige und Logik baut Spring MVC auf das Entwurfsmuster Model-View-Controller auf, das die Darstellung, Ausführungs-Logik und Datenhaltung voneinandertrennt.

Ein wesentlicher Vorteil von Spring gegenüber anderen Frameworks bzw. Herangehensweisenist, dass das HTML-Template keine Anzeigelogik enthält, was die Lesbarkeit signifikant erhöht.Die im Hintergrund eingesetzte Templateengine Thymeleaf folgt dem Ansatz des „naturaltemplating“. Dies besagt, dass HTML-Templates als statische Seiten im Browser entwickeltwerden und anschließend ohne weitere Änderungen in das Spring MVC-Framework über-nommen werden können. Hierdurch wird die Entwicklung der View erheblich vereinfacht, da

44



hierfür kein Server installiert werden muss, sondern das Öffnen einer HTML-Datei in einemBrowser genügt. Deutlich wird dieser Vorteil im folgenden Beispiel für die Sprache Java ServerPages (JSP), in der die Logik zum Iterieren über eine Liste von Benutzern (hier: Variable $users)im HTML Dokument implementiert wird.

Listing 6.1: JSP HTML-Template

<ul><c : forEach var=" user " items=" $ { users } ">

< l i ><c : out value=" { user . name} " />

</ l i ></c : forEach>

</ul>

Das korrespondierende HTML-Template für Spring MVC sieht hingegen wie folgt aus:

Listing 6.2: Thymeleaf HTML-Template

<ul>< l i th : each=" user : $ { users } ">

<span th : t e x t =" $ { user . name} "></span></ l i >

</ul>

Es wird deutlich, dass die Logik der Iteration nicht im HTML-Template definiert wird, sondernin einer Klasse, die das HTML-Template mit Werten befüllt. Ferner besteht das HTML-Templatebei Spring MVC ausschließlich aus validen HTML-Tags, sodass dies im Browser fehlerfreiangezeigt werden kann. Das JSP-Pendant hingegen muss zunächst durch einen Server in-terpretiert und in valides HTML transformiert werden. Dieser Umstand widerspricht demLeitgedanken des „natural templating“ und behindert die Frontendentwicklung.

Um Inhalte, wie beispielsweise Benutzerdaten, aus einer Datenbank auslesen zu können unddem Benutzer über eine Webseite anzuzeigen, muss eine Persistenzschicht entwickelt werden,die mit einem DBMS kommuniziert. Im folgenden Abschnitt wird das ausgewählte Frame-work zur Realisierung der Persistenzschicht beschrieben und Gründe für die Verwendungangeführt.

6.4 Datenbank-Framework: Hibernate

Als Datenbanktechnologie wird auf eine relationale Datenbank zurückgegriffen. Da relationaleDatenbanken mathematisch fundiert und bereits sehr lange im Einsatz sind, stellen sie eine

45


elaborierte und robuste Technologie zur Persistierung von Daten dar. Um den Bruch zwischenobjektorientierter Programmierung und relationalen Datenbanken zu überwinden, wird dasDatenbank-Framework Hibernate verwendet, das ein Objekt-Relationales-Mapping erlaubt(Bauer und King, 2007, S. XXVI).

Der Bruch zwischen Objektorientierung und relationalen Datenbanken besteht darin, dassObjekte einerseits statisch sind (die Attribute eines Objekts), aber andererseits über Methodenaktiv auf Methodenaufrufe von außen reagieren können. Werden Objekte in einer relationalenDatenbank persistiert, geht diese Möglichkeit verloren, da nur die Attribute eines Objekts per-sistiert werden. Um dem weiteren Problem der Adressierbarkeit entgegenzuwirken, werdenüber die Laufzeit der Applikation hinaus invariante IDs generiert, die jedes Objekt eindeutigidentifizieren können. Diese eindeutige Identifizierung ist während der Laufzeit einer Soft-ware durch eine Speicheradresse gegeben, die jedoch variabel ist. Damit Objekte nach derPersistierung weiterhin eindeutig adressiert werden können, müssen daher künstliche IDsverwendet werden (Bauer und King, 2007, S. 14 f.).

Wichtiger Bestandteil der Software ist die Architektur zur Persistierung von Objekten. Umden Zugriff auf die in der Datenbank persistierten Objekte (bzw. Objektstati) zu ermöglichen,mussten diverse Schichten entworfen werden, die das Arbeiten mit den persistierten Objektenermöglichen. Diese Schichten werden im folgenden Abschnitt näher beschrieben.

6.5 Servicearchitektur

Die Trennung in drei separate Schichten erfolgt aufgrund des separation of concerns-Prinzips,das vorsieht, jeder Schicht eine bestimmte Aufgabe zuzuteilen und eine möglichst scharfeAbgrenzung der Aufgaben zu ermöglichen. Dies schafft zudem Transparenz für den Entwicklerund erleichtert die Wartbarkeit der Software.

Der in Abbildung 6.1 dargestellte Ausschnitt der verschiedenen Service Layer soll die Trennungder Aufgaben verdeutlichen. Die Aufgaben der einzelnen Schichten werden im folgendenjeweils kurz vorgestellt.

Business Object Layer

Der Business Object Layer enthält Business Objects, die relevante Konzepte für die Applikationdarstellen (beispielsweise Benutzer, Projekt, Systemrolle, etc.). Die formale Definition dieserBusiness Objects erfolgt mittels eines Entity Relationship Model (ERM) Diagramms. In diesenModellen werden die einzelnen Business Objects und deren Relationen zueinander definiert.

46



Busi

ness

Obj

ect L

ayer

Serv

ice

Laye

r

«Interface»UserRepository

UserService

User

«Interface»ProjectRepository

ProjectService

Project

Abbildung 6.1: Ausschnitt der Servicearchitektur der Applikation

Service Layer

Da oftmals der Zugriff auf die Objekte in der Datenbank nicht ausreichend ist und weitereOperationen auf den ausgelesenen Objekten ausgeführt werden müssen, wurde eine weitereSchicht entwickelt: Der Service Layer erlaubt den Zugriff auf die Datenbank und bietet zusätz-liche Funktionen an. Für den Loginprozess ist es beispielsweise nötig, alle Benutzer mit demangegebenen Loginnamen aus der Datenbank auszulesen und zu prüfen, ob das angegebenePasswort mit einem der Passwörter (bzw. dem gespeicherten Hash-Wert) der ausgelesenenBenutzer übereinstimmt.

Die Aufspaltung in mehrere kleine Services erscheint auf den ersten Blick zwar unlogisch,ist jedoch in Hinblick auf die Wartbarkeit der Software sinnvoll. So wird vermieden, dass ineinem Service in mehreren hundert Zeilen Code verschiedene Aufgaben unterschiedlicherAufgabenbereiche (Benutzer, Mail, Projekt, etc.) gebündelt werden. Dies fördert die Übersicht-lichkeit und erleichtert die Wiederverwendung der angebotenen Services, weil die Zuordnungder Aufgaben zu bestimmten Bereichen explizit ist.

Nachdem in diesem Abschnitt auf die Implementierung der Model-Schicht eingegangen wurde,wird im folgenden Abschnitt die grafische Benutzeroberfläche beschrieben. Durch diese istein Benutzer in der Lage mit der Web-Applikation zu interagieren und auf die gespeichertenDaten zuzugreifen bzw. neue Daten zu generieren und zu speichern.

47


6.6 Grafische Benutzeroberfläche (GUI)

Im Rahmen der Anforderungsanalyse ist der Fokus hauptsächlich auf die Funktionsweise derWeb-Applikation gelegt worden. Genaue Bestimmungen oder Rahmenbedingungen wurdenfür die Planung und Umsetzung des Graphical User Interface (GUI) nicht gegeben. Ausdiesem Grund wurden implizite Annahmen für die Implementierung der GUI getroffen, dienachfolgend beschrieben werden.

Abbildung 6.2 zeigt das Layout der Web-Applikation auf einem Desktop-PC. Zu sehen sind diewesentlichen Elemente und Bereiche der Applikation: Hauptnavigation, Benutzernavigation,Systemnachricht, Hauptinhaltsbereich, Fußzeile.

Hauptnavigation

Benutzernavigation

Hauptinhaltsbereich

Seitentitel

Abbildung 6.2: Beschreibung des Layouts der Web-Applikation

∙ Hauptnavigation: Auf der Hauptnavigation befinden sich Navigationselemente dieeinem Besucher den Aufruf von für ihn zugänglichen Seiten der Web-Applikation erlau-ben. Die Inhalte der Hauptnavigation ändern sich je nach Zugriffsberechtigungen einesBenutzers. Besucher der Seite, die nicht angemeldet sind, sehen so kein Navigationsele-ment „Projektübersicht“, da ihnen hierfür die Berechtigung fehlt. Angemeldete Benutzerhingegen haben diese Berechtigung und bekommen somit dieses Navigationselementangezeigt.

∙ Benutzernavigation: Diese Navigation bietet einem Besucher die Möglichkeit sich miteinem bestehendem Benutzerzugang anzumelden oder einen Zugang am System zu

48



registrieren. Ist ein Benutzer angemeldet, so kann dieser über weitere Schaltflächen seinBenutzerprofil einsehen und bearbeiten oder die aktuelle Sitzung beenden.

∙ Systemnachricht: Der Bereich über dem Hauptinhalt ist reserviert für Systemnachrichten,die dem Benutzer Fehler- oder Erfolgsnachrichten anzeigen. Wird beispielsweise einFormular mit Fehlern abgeschickt, wird der Benutzer darauf hingewiesen und gebeten,die markierten Felder zu überarbeiten.

∙ Hauptinhaltsbereich: Im Hauptinhaltsbereich werden alle Seiteninhalte angezeigt. DieDarstellungsart der Seiteninhalte ist hierbei variabel und kann von einfachem Blocktextbis hin zu komplexen Eingabeformularen reichen (Abbildung 6.3).

∙ Fußzeile: In der Fußzeile werden allgemeine Hinweise zur Applikation, wie z. B. Copy-right-Hinweise oder die Versionsnummer, dargestellt.

SeitenspezifischeSubnavigation

Seitentitel: Name eines Projekts

Hauptinhaltsbereichdieser Unterseite

Abbildung 6.3: Layout der Web-Applikation für komplexe Unterseiten mit Verwaltungscharakter (hier: Projekt-verwaltung)

49


Da die entwickelte Web-Applikation über Browser abrufbar ist, soll das Layout der Applika-tion auf einer Vielzahl von Endgerätetypen darstellbar sein. Um eine Layoutanpassung fürverschiedene Endgerätetypen zu umgehen, wird ein „responsives“ Layout eingesetzt (Abbil-dung 6.4). Diese Art Layout erkennt selbständig die Bildschirmgröße (maximale Auflösungdes Bildschirms) und passt das Layout dementsprechend an. Da die Web-Applikation auchauf Tablet-Computern bedienbar sein soll, wird auf die Verwendung eines großen und somitraumfordernden Kopf- sowie Fußbereich verzichtet. Dies lenkt zudem den Fokus auf denInhalt der Web-Applikation und vermeidet unnötige Ablenkungen des Nutzers.

Hauptnavigation

Schaltfläche zum ein-/ausklappen der Hauptnavigation

Abbildung 6.4: Layout der Web-Applikation für kleine Bildschirme

Mit der Beschreibung der grafischen Benutzeroberfläche ist die Dokumentation der Implemen-tierung abgeschlossen. Im folgenden, schließenden Kapitel erfolgt eine kritische Würdigungdes erzielten Ergebnisses, die Offenlegung von im Implementierungsprozess aufgetretenenProblemen sowie die Skizzierung offener Punkte und möglicher nächster Aktivitäten imKontext der Pflege und Weiterentwicklung des implementierten Systems.

50



7 Kritische Würdigung, Fazit und Ausblick

Der vorliegende Arbeitssbericht präsentiert die Ergebnisse der Konzeption und Implementie-rung eines Software-Werkzeuges zur multiperspektivischen Bewertung innovativer Produkte,Projekte und Dienstleistungen im Projekt Hospital Engineering. Dazu sind zunächst diskursivzentrale Anforderungen an das System erhoben worden, die die Grundlage der Konzeption so-wie der Auswahl geeigneter Technologien darstellen. Aufgrund gegebener Projektrestriktionenim Spannungsfeld des “magischen Dreiecks” (Buchenau, Koch und Schüttler, 2011, S. 10-11)konnten letztlich nicht alle Anforderungen adressiert werden. Um dennoch ein funktionsfähi-ges System bereitstellen zu können, sind die Anforderungen intern derart priorisiert worden,dass alle für ein die grundlegenden Funkionalitäten anbietendes System erforderlichen Anfor-derungen realisiert werden sollten. Tabelle 7.1 listet alle als hoch priorisierten Anforderungeninkl. einer Kurzbeschreibung ihres Gegenstandes auf. Es wird ersichtlich, dass alle als hochpriorisierten Anforderungen erfüllt worden sind und somit ein die grundlegend erforderlichenFunktionalitäten zur Durchführung multiperspektivischer Bewertungen innovativer Produkte,Projekte und Dienstleistungen bereitstellendes System implementiert worden ist. Demgegen-über listet Tabelle 7.2 alle als niedrig priorisierten Anforderungen inkl. einer Kurzbeschreibungihres Gegenstandes auf, die nicht realisiert worden sind und damit in den Bereich möglicherzukünftiger Aktivitäten eingeordnet werden können.

Betrachtet man Tabelle 7.2, so fällt auf, dass insbesondere Anforderungen an die Benutzer-verwaltungskomponente nicht erüllt worden sind. Die Anbindung des Systems an Active-Directory-Dienste durch Lightweight Directory Access Protocol (LDAP) hätte den Einsatzaufwendiger Testumgebungen – Installation und Konfiguration eines dedizierten LDAP-Servers – erfordert und ist daher nicht realisiert worden (Anforderung BV.2). Ebenso nichtrealisiert worden ist die Einbindung eines E-Mail-Servers, um entsprechende Registrierungs-Einladungen inkl. eines nur für einen begrenzten Zeitraum gültigen Passwortes versendenzu können (Anforderungen BV.3 und BV.5). Darüber hinaus können in der vorliegenden Fas-sung des Systems nur Projektleiter Projekte anlegen, (siehe Anforderung BV.10). Auch die“Passwort-vergessen”-Funktion (Anforderung BV.12) ist infolge der nicht vorhandenen Einbin-dung eines E-Mail-Servers ebenso wenig realisiert wie die Erzeugung nur begrenzt gültigerLinks zum automatisierten Zurücksetzen eines vergessenen Passworts (Anforderung BV.13).Auch ist es nicht möglich Benutzer in Gruppen zu verwalten (Anforderung BV.14). Nebendiesen Anforderungen an die Benutzerverwaltungskomponente ist auch je eine Anforderungder Projektverwaltungskomponente, die Zuordnung von Projekten zu einer Projektkategorie

51

7 Kritische Würdigung, Fazit und Ausblick

Tabelle 7.1: Als hoch priorisierte und erfüllte Anforderungen


A.1 Implementierung als Web-ApplikationA.2 Passt sich an Bildschirmgröße anA.3 Mehrbenutzertauglichkeit

BV.1 Anlegen und registrieren von BenutzernBV.4 Anmeldung über E-Mail / Benutzername und PasswortBV.6 Implementierung verschiedener System- / ProjektrollenBV.7 Standardrollen: Administrator, BenutzerBV.8 Zugriffsrechte können an Rollen und Benutzer vergeben werdenBV.9 Vererbte Berechtigungen nicht veränderbarBV.11 Irreversible Verschlüsselung der Passwörter

PV.1 Projektbearbeitung abhängig von der Rolle / den Berechtigungen einesBenutzers

PV.2 Projektspezifische Zugriffsrechte sollen mit Systemrechten zusammenge-führt werden

PV.3 Projekten sollen Benutzer zugeordnet werden können

KK.1 Erstellung eines KriterienkatalogsKK.2 Im- und Export von Kriterien / KriterienkatalogenKK.4 Auswertung der Evaluation

Tabelle 7.2: Als niedrig priorisierte und nicht erfüllte Anforderungen


BV.2 LDAP-Anbindung erlaubenBV.3 E-Mail-Einladung zur RegistrierungBV.5 Einladung enthält temporäres PasswortBV.10 „Kiosk-Modus“: Jeder Benutzer darf Projekte anlegen; „Managed-Modus“:

Nur Projektleiter dürfen Projekte anlegenBV.12 „Passwort-vergessen“-FunktionBV.13 Link zum ändern eines Passwortes ist nur begrenzte Zeit gültigBV.14 Benutzer können in Gruppen verwaltet werden

PV.4 Projekte sollen Kategorien zugeordnet werden können

KK.3 Kriterien können gewichtet werden

(Anforderung PV.4), sowie der Kriterienkatalogverwaltungskomponente, die Möglichkeit zurindividuellen Gewichtung von Kriterien (Anforderung KK.3), nicht realisiert worden.

52



Jenseits der nicht erfüllten Anforderungen sollte zukünftig Benutzern die Möglichkeit ge-geben werden, eigene Skalen zu definieren, da dies individualisiere und projektspezifischeBewertungen unter Verwendung selbst definierter Kriterien und Skalen erlauben würde. Umdann weiterhin bereits vorhandene Auswertungsmechanismen verwenden zu können, müssteaußerdem für jede neu angelegte Skala eine Transformation zu allen anderen bereits im Systemvorhandenen Skalen definiert werden, um z. B. bei Aggregation verschieden skalierter Kriterienein valides (d. h. nachvollziehbares und sinnvolles) Ergebnis erhalten zu können. Hierfür bietetes sich an eine abstrakte Sprache zur Definition von Skalentransformationen zu entwerfen, umeinen Benutzer bei der Spezifikation von Transformationsregeln zu unterstützen.

Die Evaluation der Benutzbarkeit („Usability“) des Systems kann z. B. durch den begleitendenEinsatz des Systems zur multiperspektivischen Bewertung einer Innovation durch entspre-chende Akteure eines Unternehmens erfolgen und ist für die Zukunft geplant. Die Ergebnisseder Evaluation werden in die Weiterentwicklung des Systems einfließen.

53

A Klassendiagramm

A Klassendiagramm

user

nam

e : S

tring

pass

wor

d : S

tring

emai

l : S

tringUser

first

Nam

e : S

tring

sure

nam

e : S

tring

birth

date

: D

ate

UserProfile

has

1..1

1..1

0..*

0..*

nam

e : S

tring

desc

riptio

n : S

tring

Project

wor

ks o

n1.

.*

ProjectCriteriaCatal.

1..*

0..*

wei

ght :

Dou

ble

Weight

Criterion

1..*

1..1

has

CriterionGroup

cons

ists

of

0..*

0..*

nam

e : S

tring

Usergroup

#1

nam

e : S

tring

System

Role

ACL

#2

ACL

1..*

appl

ies

1..1

nam

e : S

tring

ProjectRole

ACL

#3

0..*

0..*

mem

ber o

f

is a

0..*

1..*

nam

e : S

tring

ProjectMem

ber

#4

nam

e : S

tring

ProjectMem

berGroup

1..*

nam

e : S

tring

size

: Lo

ngcr

eate

d : D

atet

ime

Document

0..*

uplo

aded

by

atta

ched

1..1

0..*

0..*

acts

as

1..*

0..*

1..1

NominalScaledCriterion

OrdinalScaledCriterion

NominalValue

rank

: in

t

OrdinalValue

valu

e : S

tring

orde

r : in

tMeasurementValue

mea

sure

d by

1..1

0..*

MultiScaledCriterion

SingleScaledCriterion

2..*

cons

ists

of

1..1

mea

sure

d by

1..1

0..*

nam

e : S

tring

orde

r : in

t

CriterionPage

1..*

1..1

cons

ists

of

rate

d by

nam

e : S

tring

desc

riptio

n : S

tring

orde

r : in

tre

fere

nceT

ype

: boo

lean

PageElem

ent

nam

e : S

tring

Company

nam

e : S

tring

CompanyRole

Employee

acts

as

acts

as

1..1

0..*

1..*

1..1

wor

ks fo

r

1..1

0..*

1..1

0..*

has

stre

et :

Strin

gnu

mbe

r : S

tring

zip

: Stri

ngci

ty :

Strin

gco

untry

: St

ring

Address

1..*

1..1

#5

0..*

0..*

Benu

tzer

grup

pen

sind

Gru

ppen

, die

un

abhä

ngig

von

Pro

jekt

en ih

re

Gül

tigke

it ha

ben.

Die

s si

nd

beis

piel

swei

se A

rzt,

MTA

, MR

A, e

tc.

#1

Syst

emro

llen

sind

Rol

len,

die

von

Be

nutz

er im

Sys

tem

aus

gefü

llt w

erde

n.

Die

s si

nd A

dmin

istra

tor,

Leitu

ng

Proj

ektm

anag

emen

t ode

r Ben

utze

r.

#2

Proj

ektro

llen

sind

im G

egen

satz

zu

den

Syst

emro

llen

dyna

mis

ch u

nd a

bhän

gig

vom

jew

eilig

en P

roje

kt:

- Pro

jekt

leite

r- P

roje

ktm

itarb

eite

r- .

..

#3El

emen

t mit

Bere

chtig

unge

nACL

Abst

rakt

es E

lem

ent a

ggre

gier

t alle

El

emen

te d

ie a

n ei

nem

Pro

jekt

bet

eilig

t si

nd u

nd d

ie B

ewer

tung

vor

nehm

en

dürfe

n.

#4

Das

abs

trakt

e El

emen

t Pag

eEle

men

t ste

llt

die

ober

ste

Abst

rakt

ions

eben

e al

ler

Elem

ente

dar

, die

ein

em K

riter

ienk

atal

og

hinz

ugef

ügt w

erde

n m

üsse

n. D

ies

besc

hrän

kt s

ich

nich

t nur

auf

ab

zufra

gend

e Kr

iterie

n, s

onde

rn k

ann

auch

Fre

itext

elem

ente

bei

nhal

ten.

#5

has

Abbildung A.1: Klassendiagramm des Systementwurfs

54



B Installationsanleitung

B.1 Systemanforderung

Für die Installation der Web-Applikation OASIS sind folgende Systemanforderungen zuerfüllen:

∙ Java 8,

∙ Apache Tomcat 7,

∙ 2 GB freier Arbeitsspeicher,

∙ MySQL Server 5.5.

Sie können versuchen die Applikation mit neueren Versionen der angegebenen Software zuinstallieren, jedoch empfehlen wir Ihnen sich an die vorgegebenen Informationen zu halten,da das System mit diesen getestet wurde.

B.2 Installationsroutine

Folgende Schritte beschreiben, wie die Web-Application OASIS auf Ihrem System installiertwerden kann.

B.2.1 Installation: Java

Die Installation von Java ist abhängig von der jeweiligen Distribution des Betriebssystems. FürWindows bietet sich der Download eines Installationspakets direkt von der Oracle Webseitean: http://www.java.com/de/download/. Die Installation unter Linux ist abhängig vonder Distribution und erfolgt bspw. unter Ubuntu über die Befehle:

sudo add−apt−r e p o s i t o r y ppa : webupd8team/javasudo apt−get updatesudo apt−get i n s t a l l orac le−java8− i n s t a l l e r

55

http://www.java.com/de/download/

B Installationsanleitung

Es ist ausreichend eine Java Runtime Environment (JRE) zu installieren. Ein Java DevelopmentKit (JDK) ist für die Ausführung der Applikation nicht erforderlich, kann jedoch auch verwen-det werden. Bitte beachten Sie, dass das jeweilige JRE bzw. JDK von Oracle sein sollte, da dieVerwendung von OpenJDK nicht getestet ist.

B.2.2 Installation: MySQL

Für die Installation eines MySQL-Servers greifen Sie bitte im Falle eines Linux-Systems aufdas Paketverwaltungssystem zurück: sudo apt-get install mysql-server

Unter Windows kann der MySQL-Server unter folgender URL heruntergeladen werden:http://dev.mysql.com/downloads/mysql/

Nach der Installation legen Sie bitte ein neues Datenbankschema mit dem Namen oa-sis an. Dies erfolgt über die MySQL-Query CREATE DATABASE oasis;. Legen Sie an-schließend einen neuen Benutzer an, der alle Rechte auf der neu erstellten Datenbank be-kommt: GRANT ALL PRIVILEGES ON oasis.* TO ’oasis-user’@’%’ IDENTIFIED

BY ’oasis-password’;

Erläuterung: Es wird eine neue Datenbank mit dem Namen oasis angelegt. Anschließendwerden dem Benutzer oasis-user auf alle Tabellen der Datenbank oasis (gekennzeichnetdurch folgenden Ausdruck: oasis.* lesende und schreibende Rechte vergeben. Der AusdruckIDENTIFIED BY ’oasis-password’ legt das Passwort des Benutzers fest.

B.2.3 Installation: Tomcat

Der Applikationsserver Apache Tomcat kann von der Webseite http://tomcat.apache.org bezogen werden. Empfohlen wird die Version 7.0.47, da mit dieser Version die Applika-tion getestet wurde. Führen Sie nun folgenden Schritte aus, um die Tomcat Installation zukonfigurieren:

1. Erstellen Sie einen Ordner (bspw. /opt/tomcat/), in den Sie das heruntergeladene Archiventpacken. Der Ordner, in den Sie das Archiv entpackt haben, wird im folgenden als<TOMCAT_HOME> bezeichnet.

2. Öffnen Sie die Datei server.xml im Ordner conf und suchen Sie die Zeile, die folgendenText enthält: <Connector port=”8080” ... />. Fügen Sie dort folgendes Attributein: URIEncoding=”UTF-8”.Erläuterung: Diese Einstellung wandelt die in einer URL angegebenen Eingaben in UTF-8-Encoding um und stellt sicher, dass der übergebene Wert mit der richtigen Encodierungübertragen wird.

56

http://dev.mysql.com/downloads/mysql/

http://tomcat.apache.org

http://tomcat.apache.org



3. Öffnen Sie die Datei setenv.sh im Ordner bin. Sollte diese Datei nicht exis-tieren, legen Sie diese an. Fügen Sie nun folge Zeile in diese Datei ein:JAVA_OPTS=”-Djavax.servlet.request.encoding=UTF-8

-Dfile.encoding=UTF-8 -Xmx2048m -Xms1024m”

Erläuterung: Der Source-Code der Applikation wurde mit UTF-8-Encoding entwickeltund muss von der Java Virtual Machine (JVM) als UTF-8-Encodierter Code ausgeführtwerden. Da HTML-Seiten Umlaute enthalten können, muss die JVM diese mit UTF-8 en-codieren und an den Browser des Benutzers übertragen, da dieser sonst eine fehlerhafteAusgabe erhält. Die Parameter Xmx und Xms legen fest, wie viel Arbeitsspeicher die JVMallokieren darf. Xms legt fest, wie viel Arbeitsspeicher initial belegt werden und Xmx wieviel Arbeitsspeicher die JVM maximal belegen kann.

4. Es bietet sich an die installierte Tomcat-Instanz als Dienst (Service) einzurichten, sodassdieser bei einem Neustart automatisch hochgefahren wird. Da die Installation als Dienstabhängig von Ihrer Plattform ist, bieten wir Ihnen ein Installation-Script für Linux an,das unter Ubuntu 12.04 getestet wurde.

B.2.4 Installation: Web-Applikation

Im folgenden Abschnitt werden weitere notwendige Änderungen an Ihrer Tomcat-Installationbeschrieben. Ersetzen Sie im folgenden die Variable <TOMCAT_HOME> mit dem Pfad zuIhrer Tomcat-Installation.

1. Kopieren Sie den Kontext-Descriptor (idss.xml) in den Ordner<TOMCAT_HOME>/conf/Catalina/localhost/. Ggf. müssen Sie die angegebenenOrdner erstellen.

2. Legen Sie einen neuen Ordner im <TOMCAT_HOME>-Verzeichnis an (bspw. idss) undkopieren sie die WAR-Datei in dieses Verzeichnis.

3. Öffnen Sie erneut den Kontext-Descriptor (s. Schritt 1) und passen Sie den Wert docBaseso an, dass dieser den absoluten Pfad zur WAR-Datei auf der Festplatte aus Schritt 2enthält.

Möchten Sie, dass die Web-Applikation unter einem bestimmten Pfad erreichbar ist (bspw.http://localhost:8080/app), passen Sie den Wert path ebenfalls an (bspw. path=”/app”)

B.2.5 Starten der Applikation

Nach abgeschlossener Installation starten Sie den Tomcat-Server über entsprechende Skripteim bin-Verzeichnis via catalina.sh bzw. catalina.bat.

57

C Hinzufügen neuer Sprachen

C Hinzufügen neuer Sprachen

Um der Applikation OASIS weitere Sprachen hinzuzufügen, muss die Standardsprach-DateiOASISWebApplication.properties.xml kopiert und die enthaltenen Werte übersetztwerden. Die Datei ist unter dem Pfad /oasis-webui/src/main/java/de/stekoe/idss

zu finden. Der Name der Datei ist relevant für die Applikation und wirdnur dann korrekt erkannt, wenn dieser dem folgenden Schema entspricht:OASISWebApplication_<Länderkürzel>.properties.xml (für eine polnische Über-setzung bpsw. OASISWebApplication_pl.properties.xml).

58



Literatur

Ammenwerth, Elske und Reinhold Haux (2005). IT-Projektmanagement in Krankenhaus undGesundheitswesen. Stuttgart: Schattauer.

Bauer, Christian und Gavin King (2007). Java persistence with Hibernate. Rev. ed. Greenwich undConn: Manning.

Bea, Franz Xaver, Steffen Scheurer und Sabine Hesselmann (2008). Projektmanagement. Bd. 2388: Betriebswirtschaftslehre. UTB. Stuttgart: Lucius & Lucius.

Beck, Kent (2009). Test driven development: By example. 14. Aufl. The Addision-Wesley signatureseries. Boston: Addision-Wesley.

Berekoven, Ludwig, Werner Eckert und Peter Ellenrieder (2009). Marktforschung: MethodischeGrundlagen und praktische Anwendung. 12., überarb. und erw. Aufl. Lehrbuch. Wiesbaden:Gabler.

Buchenau, Gerrit, Oliver Koch und Ralf Schüttler (2011). Analyse ausgewählterProjektmanagement-Standards für große und mittelständische Unternehmen. WITEC-Verlag.

Burghardt, Manfred (2008). Projektmanagement: Leitfaden für die Planung, Überwachung undSteuerung von Projekten. 8., wesentl. überarb. und erw. Aufl. Erlangen: Publicis Corp. Publ.

Cass, Stephen, Nick Diakopoulos und Joshua J. Romero (2014). Interactive: The Top ProgrammingLanguages. Website. URL: http://spectrum.ieee.org/static/interactive-the-top-programming-languages.

Collins-Sussman, Ben, Brian W. Fitzpatrick und C. Michael Pilato (2008). Version control withSubversion. 2. ed. Beijing: O’Reilly.

Cooper, Robert G. (2010). Top oder Flop in der Produktentwicklung: Erfolgsstrategien: von der Ideezum Launch. 2. Aufl., Sonderausg. Weinheim: Wiley-VCH.

Corsten, Hans, Hilde Corsten und Ralf Gössinger (2008). Projektmanagement: Einführung. 2.,vollst. überarb. und wesentlich erw. Aufl. Lehr- und Handbücher der Betriebswirtschaftsleh-re. München: Oldenbourg.

59

http://spectrum.ieee.org/static/interactive-the-top-programming-languages

http://spectrum.ieee.org/static/interactive-the-top-programming-languages

Literatur

DIN (69901). Projektmanagement. o.O.

Decker, Franz und Alfred Decker (2008). Management in Gesundheits- und Sozialbetrieben. Be-triebswirtschaftliche Grundlagen für Führungskräfte und Nachwuchs. Baden-Baden: Nomos.

Disselkamp, Marcus (2012). Innovationsmanagement: Instrumente und Methoden zur Umsetzungim Unternehmen. 2. Aufl. Wiesbaden: Springer Fachmedien.

Dülfer, Eberhard (1982). Projektmanagement international. Stuttgart: Poeschel.

Ferstl, Otto K. und Elmar J. Sinz (2013). Grundlagen der Wirtschaftsinformatik. 7., aktualisierteAufl. München: Oldenbourg.

Gamma, Erich und Kent Beck (2004). Contributing to Eclipse: Principles, patterns, and plug-ins.The Eclipse series. Boston: Addison-Wesley.

Gassmann, Oliver und Philipp Sutter (2008). Praxiswissen Innovationsmanagement: Von der Ideezum Markterfolg. München: Hanser.

Gerber, Barry (2006). Mastering Microsoft Exchange Server 2003. Hoboken: John Wiley & SonsInc.

Grob, Heinz Lothar (1990). „Investitionsrechnung für Informations- und Kommunikations-systeme auf der Grundlage von Preis-Leistungs-Modellen“. In: Integration und Flexibilität.Hrsg. von Dietrich Adam et al. Wiesbaden: Gabler, S. 335–352.

Hardy, Will (2007). Comparing Web Development Platforms Through the Eyes of Professional Devel-opers: Technical Report. Berlin.

Hauschildt, Jürgen und Sören Salomo (2011). Innovationsmanagement. 5., überarb., erg. und ak-tualisierte Aufl. Vahlens Handbücher der Wirtschafts- und Sozialwissenschaften. München:Vahlen.

Heil, Jörg (2007). Invesititonsentscheidungen in der Gruppe. Empirische Untersuchung deutscherKrankenhäuser auf Basis der präskriptiven Entscheidungstheorie. Berlin: LIT Verlag Dr. W. Hopf.

Heß, Michael (2013). „Überlegungen zur umfassenden Bewertung von Innovationen im Projekt"Hospital Engineering"“. In: eHealth 2013. Big Data – eHealth von der Datenanalyse bis zumWissensmanagement. Tagungsband der eHealth2013 vom 23.-24.5.2013 in Wien. Hrsg. von ElskeAmmenwerth et al. Wien: Österreichische Computer Gesellschaft, S. 197–206.

Heß, Michael (2014). Multiperspektivische Dokumentation und Informationsbedarfsanalyse kardio-logischer Prozesse sowie Konzeptualisierung medizinischer Ressourcentypen im Projekt HospitalEngineering. ICB Research Report No. 60. Essen: Universität Duisburg-Essen, Institut für

60



Informatik und Wirtschaftsinformatik (ICB). URL: http://www.icb.uni-due.de/fileadmin/ICB/research/research_reports/ICB-Report-No60.pdf.

Heß, Michael, Hannes Schlieter und Georg Täger (2013). „Modellierung komplexer Entschei-dungssituationen in Prozessmodellen: Anwendung am Beispiel der Tumorklassifikationbei Weichteilsarkomen“. In: Dienstleistungsmodellierung 2012. Hrsg. von Oliver Thomas undMarkus Nüttgens. Wiesbaden: Springer Fachmedien, S. 268–290.

Kohn, Wolfgang (2005). Statistik: Datenanalyse und Wahrscheinlichkeitsrechnung. Statistik undihre Anwendungen. Berlin: Springer.

Laux, Helmut, Robert M. Gillenkirch und Heike Y. Schenk-Mathes (2012). Entscheidungstheorie.8. Aufl. Springer-Lehrbuch. Berlin: Springer.

Loeliger, John und Matthew McCullough (2012). Version Control with Git: Powerful Tools andTechniques for Collaborative Software Development. 2. Aufl. Sebastopol: O’Reilly.

Meyer, Jörn-Axel (1999). Visualisierung von Informationen. Verhaltenswissenschaftliche Grundregelnfür das Management. Wiesbaden: Gabler.

Österle, Hubert et al. (2011). „Memorandum on design-oriented information systems research“.In: European Journal on Informafion Systems 20, S. 7–10.

Percival, Colin (2005). Stronger key derivation via sequential memory-hard functions.

Rennings, Klaus (2000). „Redefining innovation — eco-innovation research and the contributi-on from ecological economics“. In: Ecological Economics 32.2, S. 319–332.

Rogers, Everett M. (2003). Diffusion of innovations. 5. Aufl. New York: Free Press.

Schlüchtermann, Jörg (2013). Betriebswirtschaft und Management im Krankenhaus. Grundlagen undPraxis. Berlin: Medizinisch Wissenschaftliche Verlagsgesellschaft.

Schumpeter, Joseph Alois und Jürgen G. Backhaus (2003). Entrepreneurship, Style, and Vision.Bd. 1. The European heritage in economics and the social sciences. Boston: Kluwer Acad.Publ.

Smart, John Ferguson (2011). Jenkins: The Deifinitive Guide. Sebastopol: O’Reilly.

Spiller, Martin (2011). Maven 3: Konfigurationsmanagement mit Java. Heidelberg: Mitp.

Wang, Xiaoyun und Hongbo Yu (2005). „How to Break MD5 and Other Hash Functions“. In:Advances in cryptology. Hrsg. von Ronald Cramer. Bd. 3494. LNCS. Berlin: Springer, S. 19–25.

61

http://www.icb.uni-due.de/fileadmin/ICB/research/research_reports/ICB-Report-No60.pdf

http://www.icb.uni-due.de/fileadmin/ICB/research/research_reports/ICB-Report-No60.pdf

Literatur

Weis, Bernd X. (2012). Praxishandbuch Innovation: Leitfaden für Erfinder, Entscheider und Unterneh-men. Wiesbaden: Gabler Verlag.

Zangemeister, Christof (1976). Nutzwertanalyse in der Systemtechnik: eine Methodik zur multidimen-sionalen Bewertung dun Auswertung von Projektalternativen. 4. Aufl. München: WittenmanscheBuchhandlung.

62

Previously Published ICB Research Reports

2014

No 61 (August 2014)

Schauer, Carola; Frank, Ulrich: „Wirtschaftsinformatik an Schulen – Status und Desideratamit Fokus auf Nordrhein-Westfalen“

No 60 (May 2014)

Heß, Michael: „Multiperspektivische Dokumentation und Informationsbedarfsanalysekardiologischer Prozesse sowie Konzeptualisierung ausgewählter medizinischer Ressour-centypen im Projekt Hospital Engineering“

No 59 (May 2014)

Goedicke, Michael; Kurt-Karaoglu, Filiz; Schwinning, Nils; Schypula, Melanie; Striewe,Michael: „Zweiter Jahresbericht zum Projekt ‚Bildungsgerechtigkeit im Fokus‘ (Teilprojekt1.2 – ‚Blended Learning‘) an der Fakultät für Wirtschaftswissenschaften“

No 58 (March 2014)

Breitschwerdt, Rüdiger; Heß, Michael: „Konzeption eines Bezugsrahmens zur Analyse undEntwicklung von Geschäftsmodellen mobiler Gesundheitsdienstleistungen – Langfassung“

No 57 (March 2014)

Heß, Michael; Schlieter, Hannes (Hrsg.): „Modellierung im Gesundheitswesen – Tagungs-band des Workshops im Rahmen der "Modellierung 2014"“

2013

No 56 (July 2013)

Svensson, Richard Berntsson; Berry,Daniel M.; Daneva, Maya; Doerr, Joerg; Espana,Sergio; Herrmann, Andrea; Herzwurm, Georg; Hoffmann, Anne; Pena, Raul Mazo; Op-dahl, Andreas L.; Pastor, Oscar; Pietsch,Wolfram; Salinesi, Camille; Schneider, Kurt; Seyff,Norbert; van de Weerd, Inge; Wieringa, Roel; Wnuk, Krzysztof (Eds.): „19th Internatio-nal Working Conference on Requirements Engineering: Foundation for Software Quality(REFSQ 2013). Proceedings of the REFSQ 2013 Workshops CreaRE, IWSPM, and RePri-Co, the REFSQ 2013 Empirical Track (Empirical Live Experiment and Empirical ResearchFair), the REFSQ 2013 Doctoral Symposium, and the REFSQ 2013 Poster Session”“

No 55 (May 2013)

Daun, Marian; Focke, Markus; Holtmann, Jörg; Tenbergen, Bastian „Goal-Scenario-Oriented Requirements Engineering for Functional Decomposition with BidirectionalTransformation to Controlled Natural Language. Case Study “Body Control Module”“

No 54 (March 2013)

Fischotter, Melanie; Goedicke, Michael; Kurt-Karaoglu, Filiz; Schwinning, Nils; Striewe,Michael „Erster Jahresbericht zum Projekt “Bildungsgerechtigkeit im Fokus” (Teilprojekt1.2 – “Blended Learning”) an der Fakultät für Wirtschaftswissenschaften“

2012

No 53 (December 2012)

Frank, Ulrich: „Thoughts on Classification / Instantiation and Generalisation / Specialisa-tion“

No 52 (July 2012)

Berntsson-Svensson, Richard; Berry, Daniel; Daneva, Maya; Dörr, Jörg; Fricker, SamuelA; Herrmann, Andrea; Herzwurm, Georg; Kauppinen, Marjo; Madhavji, Nazim H; Ma-haux, Martin; Paech, Barbara; Penzenstadler, Birgit; Pietsch, Wolfram; Salinesi, Camille;Schneider, Kurt; Seyff, Norbert; van de Weerd, Inge (Eds.): „18th International WorkingConference on Requirements Engineering – Foundation for Software Quality. Proceedingsof the Workshops RE4SuSy, REEW, CreaRE, RePriCo, IWSPM and the Conference RelatedEmpirical Study, Empirical Fair and Doctoral Symposium“

No 51 (May 2012)

Frank, Ulrich: „Specialisation in Business Process Modelling – Motivation, Approachesand Limitations“

No 50 (March 2012)

Adelsberger, Heimo; Drechsler, Andreas; Herzig, Eric; Michaelis, Alexander; Schulz,Philipp ; Schütz, Stefan; Ulrich, Udo: „Qualitative und quantitative Analyse von SOA-Studien – Eine Metastudie zu serviceorientierten Architekturen“

2011


Frank, Ulrich: „MEMO Organisation Modelling Language (2) – Focus on BusinessProcesses“


Frank, Ulrich: „MEMO Organisation Modelling Language (1) – Focus on OrganisationalStructure“


Frank, Ulrich: „Multiperspective Enterprise Modelling – Requirements and Core DiagramTyps“


Frank, Ulrich: „Multiperspective Enterprise Modelling – Background and TerminologicalFoundation“

No 45 (November 2011)

Frank, Ulrich; Strecker, Stefan; Heise, David; Kattenstroth, Heiko; Schauer, Carola: „Leit-faden zur Erstellung wissenschaftlicher Arbeiten in der Wirtschaftsinformatik“

No 44 (September 2011)

Berenbach, Brian; Daneva, Maya; Dörr, Jörg; Fricker, Samuel; Gervasi, Vincenzo; Glinz,Martin; Herrmann, Andrea; Krams, Benedikt; Madhavji, Nazim H; Paech, Barbara; Scho-ckert, Sixten; Seyff, Norbert (Eds.): „17th International Working Conference on Require-ments Engineering: Foundation for Software Quality (REFSQ 2011) – Proceedings of theREFSQ 2011 Workshops REEW, EPICAL and RePriCo, the REFSQ 2011 Empirical Track(Empirical Live Experiment and Empirical Research Fair), and the REFSQ 2011 DoctoralSymposium“

No 43 (February 2011)

Frank, Ulrich: „The MEMO Meta Modelling Language (MML) and Language Architec-ture. 2nd Edition“

2010


Frank, Ulrich: „Outline of a Method for Designing Domain-Specific Modelling Languages“


Adelsberger, Heimo; Drechsler, Andreas (Hrsg.): „Ausgewählte Aspekte des Cloud-Computing aus einer IT-Management-Perspektive – Cloud Governance, Cloud Securityund Einsatz von Cloud Computing in jungen Unternehmen“

No 40 (October 2010)

Bürsner, Simone; Dörr, Jörg; Gehlert, Andreas; Herrmann, Andrea; Herzwurm, Georg;Janzen, Dirk; Merten, Thorsten; Pietschm, Wolfram; Schmid, Klaus; Schneider,Kurt;Thurimella, Anil Kumar: „16th International Working Conference on Requirements En-gineering: Foundation for Software Quality – Proceedings of the Workshops CreaRE,PLREQ,RePriCo and RESC“

No 39 (May 2010)

Strecker, Stefan; Heise, David; Frank, Ulrich: „Entwurf einer Mentoring-Konzeption fürden Studiengang M.Sc. Wirtschaftsinformatik an der Fakultät für Wirtschaftswissenschaf-ten der Universität Duisburg-Essen“


Schauer, Carola : „Wie praxisorientiert ist die Wirtschaftsinformatik? Einschätzungen vonCIOs und WI-Professoren“

No 37 (January 2010)

Benavides, David; Batory, Don; Grunbacher, Paul (Eds.): „Fourth International Workshopon Variability Modelling of Software–intensive Systems“

2009


Strecker, Stefan: „Ein Kommentar zur Diskussion um Begriff und Verstandnis der IT–Governance – Anregungen zu einer kritischen Reflexion“

No 35 (August 2009)

Rüngeler, Irene; Tüxen, Michael; Rathgeb, Erwin P.: „Considerations on Handling LinkErrors in SCTP“

No 34 (June 2009)

Karastoyanova, Dimka; Kazhamiakan, Raman; Metzger, Andreas; Pistore, Marco (Eds.):„Workshop on Service Monitoring, Adaptation and Beyond“

No 33 (May 2009)

Adelsberger, Heimo; Drechsler, Andreas; Bruckmann, Tobias; Kalvelage, Peter; Kinne,Sophia; Pellinger, Jan; Rosenberger, Marcel; Trepper, Tobias: „Einsatz von Social Softwarein Unternehmen - Studie über Umfang und Zweck der Nutzung“

No 32 (April 2009)

Barth, Manfred; Gadatsch, Andreas; Kutz, Martin; Ruding, Otto; Schauer, Hanno; Stre-cker, Stefan: „Leitbild IT–Controller/–in . Beitrag der Fachgruppe IT–Controlling derGesellschaft fur Informatik e. V.“

No 31 (April 2009)

Frank, Ulrich; Strecker, Stefan: „Beyond ERP Systems: An Outline of Self–ReferentialEnterprise Systems – Requirements, Conceptual Foundation and Design Options“


Schauer, Hanno; Wolff, Frank: „Kriterien guter Wissensarbeit - Ein Vorschlag aus demBlickwienkel der Wissenschaftstheorie (Langfassung)“


Benavides, David; Metzger, Andreas; Eisenecker, Ulrich (Eds.): „Third InternationalWorkshop on Variability Modelling of Software–intensive Systems“

2008


Goedicke, Michael; Striewe, Michael; Balz, Moritz: „Computer Aided Assessments andProgramming Exercises with JACK“


Schauer, Carola: „Größe und Ausrichtung der Disziplin Wirtschaftsinformatik an Univer-sitaten im deutschsprachigen Raum – Aktueller Status und Entwicklung seit 1992“


Milen, Tilev; Bruno Muller–Clostermann:„ CapSys: A Tool for Macroscopic CapacityPlanning“

No 25 (August 2008)

Eicker, Stefan; Spies, Thorsten; Tschersich, Markus: „Einsatz von Multi–Touch beimSoftwaredesign am Beispiel der CRC Card–Methode“

No 24 (August 2008)

Frank, Ulrich: „The MEMO Meta Modelling Language (MML) and Language Architec-ture - Revised Version“


Sprenger, Jonas; Jung, Jürgen: „Enterprise Modelling in the Context of Manufacturing -Outline of an Approach Supporting Production Planning“


Heymans, Patrick; Kang, Kyo–Chul; Metzger, Andreas, Pohl, Klaus (Eds.): „SecondInternational Workshop on Variability Modelling of Software–intensive Systems.“

2007


Eicker, Stefan; Annett Nagel; Peter M. Schuler: „Flexibilität im Geschäftsprozess-management-Kreislauf“

No 20 (August 2007)

Blau, Holger; Eicker, Stefan; Spies, Thorsten: „Reifegradüberwachung von Software“

No 19 (June 2007)

Schauer, Carola: „Relevance and Success of IS Teaching and Research: An Analysis of theRelevance Debate“

No 18 (May 2007)

Schauer, Carola: „Rekonstruktion der historischen Entwicklung der Wirtschaftsinformatik:Schritte der Institutionalisierung, Diskussion zum Status, Rahmenempfehlungen für dieLehre“

No 17 (May 2007)

Schauer, Carola; Schmeing, Tobias: „Development of IS Teaching in North-America: AnAnalysis of Model Curricula“

No 16 (May 2007)

Müller-Clostermann, Bruno; Tilev, Milen: „Using G/G/m-Models for Multi-Server andMainframe Capacity Planning“

No 15 (April 2007)

Heise, David; Schauer, Carola; Strecker, Stefan: „Informationsquellen für IT-Professionals -Analyse und Bewertung der Fachpresse aus Sicht der Wirtschaftsinformatik“

No 14 (March 2007)

Eicker, Stefan; Hegmanns, Christian; Malich, Stefan: „Auswahl von Bewertungsmethodenfür Softwarearchitekturen“


Eicker, Stefan; Spies, Thorsten; Kahl, Christian: „Softwarevisualisierung im Kontextserviceorientierter Architekturen“


Brenner, Freimut: „Cumulative Measures of Absorbing Joint Markov Chains and anApplication to Markovian Process Algebras“


Kirchner, Lutz: „Entwurf einer Modellierungssprache zur Unterstützung der Aufgabendes IT Managements - Grundlagen, Anforderungen und Metamodell“


Schauer, Carola; Strecker, Stefan: „Vergleichende Literaturstudie aktueller einführenderLehrbücher der Wirtschaftsinformatik: Bezugsrahmen und Auswertung“


Strecker, Stefan; Kuckertz, Andreas; Pawlowski, Jan M.: „Überlegungen zur Qualifizie-rung des wissenschaftlichen Nachwuchses: Ein Diskussionsbeitrag zur (kumulativen)Habilitation“


Frank, Ulrich; Strecker, Stefan; Koch, Stefan: „Open Model - Ein Vorschlag für einForschungspro-gramm der Wirtschaftsinformatik (Langfassung)“

2006


Frank, Ulrich: „Towards a Pluralistic Conception of Research Methods in InformationSystems Research“

No 6 (April 2006)

Frank, Ulrich: „Evaluation von Forschung und Lehre an Universitäten - Ein Diskussions-beitrag“

No 5 (April 2006)

Jung, Jürgen: „Supply Chains in the Context of Resource Modelling“


Lange, Carola: „Development and status of the Information Systems / Wirtschaftsinforma-tik discipline: An interpretive evaluation of interviews with renowned researchers, Part III- Results Wirtschaftsinformatik Discipline“

2005


Lange, Carola: „Development and status of the Information Systems / Wirtschaftsinforma-tik discipline: An interpretive evaluation of interviews with renowned researchers, Part II -Results Information Systems Discipline“


Lange, Carola: „Development and status of the Information Systems / Wirtschaftsinforma-tik discipline: An interpretive evaluation of interviews with renowned researchers, Part I -Research Objectives and Method“

No 1 (August 2005)

Lange, Carola: „Ein Bezugsrahmen zur Beschreibung von Forschungsgegenständen und-methoden in Wirtschaftsinformatik und Information Systems“

��

��

Felix Föcker, Frank Houdek, Marian Daun, Thorsten Weyer

Realistic Example Specifications of

Behavioral Requirements and

Functional Design

ICB-Research Report No. 64

January 2015

Research Group Core Research Topics

Prof. Dr. H. H. AdelsbergerInformation Systems for Production and OperationsManagement

E-Learning, Knowledge Management, Skill-Management,Simulation, Artificial Intelligence

Prof. Dr. F. AhlemannInformation Systems and Strategic Management

Strategic planning of IS, Enterprise Architecture Management, IT Vendor Management, Project Portfolio Management, IT Governance, Strategic IT Benchmarking

Prof. Dr. P. ChamoniMIS and Management Science / Operations Research

Information Systems and Operations Research, Business Intelligence, Data Warehousing

Prof. Dr. K. EchtleDependability of Computing Systems

Dependability of Computing Systems

Prof. Dr. S. EickerInformation Systems and Software Engineering

Process Models, Software-Architectures

Prof. Dr. U. FrankInformation Systems and Enterprise Modelling

Enterprise Modelling, Enterprise Application Integration,IT Management, Knowledge Management

Prof. Dr. M. GoedickeSpecification of Software Systems

Distributed Systems, Software Components, CSCW

Prof. Dr. V. Gruhn Software Engineering

Design of Software Processes, Software Architecture, Usabi-lity, Mobile Applications, Component-based and Generative Software Development

PD Dr. C. Klüver Computer Based Analysis of Social Complexity

Soft Computing, Modeling of Social, Cognitive, and Economic Processes, Development of Algorithms

Prof. Dr. T. Kollmann E-Business and E-Entrepreneurship

E-Business and Information Management, E-Entrepreneurship/E-Venture, Virtual Marketplaces and Mobile Commerce, Online-Marketing

Prof. Dr. K. PohlSoftware Systems Engineering

Requirements Engineering, Software Quality Assurance,Software-Architectures, Evaluation of COTS/Open Source-Components

Prof. Dr. Ing. E. RathgebComputer Network Technology

Computer Network Technology

Prof. Dr. R. UnlandData Management Systems and Knowledge Representation

Data Management, Artificial Intelligence, Software Engineering, Internet Based Teaching

Prof. Dr. S. ZelewskiInstitute of Production and Industrial Information Management

Industrial Business Processes, Innovation Management,Information Management, Economic Analyses

ISSN 1860-2770 (Print)ISSN 1866-5101 (Online)

64Model-Based Engineering of an Automotive Adaptive Exterior Lighting System

ein software-werkzeug zur multiperspektivischen bewertung ... · tiver produkte, projekte und...

Documents