Danksagung:

Ich m¨ ochte mich an dieser Stelle bei allen Personen bedanken, die mich bei der Anfertigung meiner Masterarbeit in der ein oder anderen Weise unterst¨ utzt haben. Besonders hervorheben m¨ ochte ich:

• Meinen Betreuer bei der Capgemini sd&m AG Matthias Brusdeylins, der mich auf der Suche nach L¨ osungswegen mit guten Ideen und unerm¨ udlichem Einsatz betreut hat.

• Meine Betreuer an der Universit¨ at Prof. Dr. Bernhard Bauer und Prof. Dr. Alexander Knapp f¨ ur die engagierte Betreuung der Arbeit durch hilfreiche und konstruktive Anregungen.

• Ralf S. Engelschall, Oliver Fl¨ oricke und Christian Kulas von der Capgemini sd&m AG, die mir bei den Gebieten technische Umsetzung, Spezifikation von grafischen Bedienoberfl¨ achen und Usability von Anwendungen mit Rat und Tat zur Seite standen.

• Die Mitarbeiter bei der Capgemini sd&m AG, die sich Zeit f¨ ur ein Interview genommen haben und mir damit bei der Erstellung dieser Arbeit sehr geholfen haben.

• Verena, Aysel und Lisi f¨ ur das Korrekturlesen dieser Arbeit und den hilfreichen Anmerkungen.

• Meine Familie f¨ ur die moralische Unterst¨ utzung w¨ ahrend meines Studiums und vor allem w¨ ahrend der Erstellung meiner Masterarbeit.

Vielen Dank!

Kurzfassung:

Das Aussehen und der Arbeits-Workflow einer grafischen Oberfl¨ ache (engl. Graphical User Interface - GUI) entscheiden oft, ob eine Software von Benutzern akzeptiert wird. Je be-nutzerfreundlicher die GUI ist, desto besser sch¨ atzt der Benutzer die Qualit¨ at der Software ein. Deshalb muss die grafische Bedienoberfl¨ ache fr¨ uhzeitig an den W¨ unschen des Kunden angepasst werden. Dabei ist es wichtig, dass nicht nur das Layout der GUI mit dem Kunden abgestimmt wird, sondern auch der Arbeits-Workflow der Anwendung. Dieser Prozess findet in der Spezifikationsphase statt. Es wird meist das Layout der Oberfl¨ ache auf Papier oder mittels eines Programms gezeichnet und der Workflow nur textuell beschrieben. Doch w¨ are es sicherlich voteilhaft, schon beim Entwurf der GUI zu sehen, wie sich die Software sp¨ ater ” anf¨ uhlt“. Dabei k¨ onnen MockUp-Konzepte helfen, indem ein MockUp der grafischen Oberfl¨ ache erstellt wird.

Mit einem GUI-MockUp kann der Kunde den Workflow der Anwendung besser nachvollziehen und fr¨ uhzeitig Anforderungen erkennen, welche in statischen Konzepten meist ubersehen werden. Ein Beispiel hierf¨ ur w¨ are die Fenstergr¨ oße, die von der Bildschirmauf¨

l¨ osung abh¨ angig ist. Mit einem MockUp k¨ onnte getestet werden, ob die Fenstergr¨ oße zur Bildschirmaufl¨ osung des Kundenrechners passt. Deshalb werden in dieser Arbeit MockUp-Konzepte in den Spezifikationsprozess der Capgemini sd&m AG integriert. Zur Erstellung von MockUps k¨ onnen sogenannte MockUp-Tools verwendet werden. Um ein geeignetes MockUp-Tool zu finden, wird eine Marktanalyse durchgef¨ uhrt und mittels eines eigenen Entscheidungsverfahrens das passende Tool ausgew¨ ahlt.

Zur Erstellung der Spezifikation wird in vielen Softwareprojekten ein Modellierungswerkzeug eingesetzt. Aus diesem Grund wird in der vorliegenden Arbeit eine Architektur zur Inte- gration eines MockUp-Tools in ein Modellierungswerkzeug entwickelt und implementiert.

Inhaltsverzeichnis

1  Einleitung  1

1.1  Motivation  1

1.2  Problemstellung  2

1.3  Gliederung der Arbeit  2

2  Integration von MockUp-Konzepten in das Vorgehensmodell von Ent-  

wicklungsprojekten   5

2.1  Was sind MockUp-Konzepte?  5

2.2  Das Vorgehensmodell der Capgemini sd m AG  6

2.3  Die Spezifikationsmethodik von Capgemini sd m Research  8

2.4  Enterprise Architect in der Spezifikationsphase  9

2.5  Abgrenzung zu verwandten Arbeiten  11

2.5.1  Methoden und Werkzeuge f ur das Prototyping und ihre Integration  11

2.5.2  Vorgehensweisen und Werkzeuge f ur ein Ineinandergreifen von Mo-  

dellierung  und Prototyping  12

3  Entscheidungsverfahren zur Auswahl des MockUp-Tools  15

3.1  Allgemeine Entscheidungsverfahren  15

3.2  Eigenes Entscheidungsverfahren  18

4  Analyse des Spezifikationsprozesses von grafischen Oberfl achen  

und  Analyse der Anforderungen von MockUp-Tools  23

4.1  Vorgehen  23

4.2  Ziele der Interviews  25

4.3  Durchf uhrung der Interviews  25

4.4  Fragebogen zur Durchf uhrung der Interviews  26

4.4.1  Ziel: Spezifikationsprozess und verwendete Werkzeuge und Methoden  26

4.4.2  Ziel: Integration des MockUp-Tools in den Spezifikationsprozess  27

4.4.3  Ziel: Kriterien f ur die Evaluierung der MockUp-Tools finden  27

4.5  Auswertung der Interviews  28

ii Inhaltsverzeichnis

4.5.1 Ergebnisse: Spezifikationsprozess und verwendete Tools und Methoden 28

4.5.2 Ergebnisse: Integration des MockUp-Tools in den Spezifikationsprozess 29

4.5.3 Ergebnisse: Kriterien f¨ ur die Evaluierung der MockUp-Tools finden . 29

5 Evaluierung der MockUp-Tools 33

5.1 Aufbau der Entscheidungsmatrix . . . . . . . . . . . . . . . . . . . . . . . . 33

5.1.1 Die Kriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.1.2 Gewichtung, Bedingungsformeln und Aggregationsformeln der Kriterien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.2 Arten von MockUp-Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.3 Ergebnisse der Evaluierung . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.4 Entscheidung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6 Architektur zur Integration eines MockUp-Tools in ein Modellierungswerkzeug 51

6.1 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.1.1 Anforderungen an die Architektur . . . . . . . . . . . . . . . . . . . 51

6.1.2 Anwendungsf¨ alle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.2 Die entworfene Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.2.1 Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.2.2 Das Common Dialog Model . . . . . . . . . . . . . . . . . . . . . . . 57

6.2.3 Modelltransformationen zur Synchronisation der Daten . . . . . . . 60

6.2.4 Vorteile der entworfenen Architektur . . . . . . . . . . . . . . . . . . 64

7 Technische Umsetzung der entworfenen Architektur 65

7.1 Technische Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.1.1 Balsamiq Mockups . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

7.1.2 Enterprise Architect . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

7.2 Verwendete Programmiersprachen und Technologien . . . . . . . . . . . . . 71

7.3 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

7.3.1 Implementierung der MockUp-Komponente . . . . . . . . . . . . . . 74

7.3.2 Implementierung der Modellierungs-Komponente . . . . . . . . . . . 77

7.3.3 Implementierung der Synchronisations-Komponente . . . . . . . . . 81

7.4 Installer f¨ ur das entwickelte System . . . . . . . . . . . . . . . . . . . . . . . 86

Inhaltsverzeichnis iii

8  Einsatz und Erweiterbarkeit des entwickelten Systems  87

8.1  Installation des Systems  87

8.2  Szenarien zum Einsatz des Systems  88

8.2.1  Erstellen eines neuen MockUps  88

8.2.2  Editieren eines MockUps  90

8.2.3  Exportieren eines MockUps  91

8.2.4  Importieren eines MockUps  93

8.3  Szenarien zum Erweitern des Systems  94

8.3.1  MockUp-Tool wechseln  94

8.3.2  MockUp-Tool hinzuf ugen  96

8.3.3  Modellierungswerkzeug wechseln  97

9  Zusammenfassung und Ausblick  99

A  Frageb ogen  103

A.1  Fragebogen f ur die fachliche Designer  104

A.2  Fragebogen f ur die Usability Experten  113

B  Auswertung der Interviews  121

C  Kriterienkatalog  141

D  Entscheidungsmatrix  147

E  Sequenzdiagramme  171

E.1  MockUp exportieren  171

E.2  MockUp importieren  172

F  XML-Schemas  175

F.1  XML-Schema vom Common Dialog Model  176

F.2  XML-Schema vom BQ-xml  179

F.3  XML-Schema vom EA-xml  182

Glossar   185

Abbildungsverzeichnis   187

Tabellenverzeichnis 191   

Listings   193

Literaturverzeichnis   195

1. Einleitung

1.1 Motivation

Die Qualit¨ at einer Software wird schnell mit dem Verst¨ andnis, dem Aussehen und dem Workflow ihrer grafischen Bedienoberfl¨ ache (engl. Graphical User Interface - GUI) gleichgesetzt. Der Grund hierf¨ ur ist, dass der Benutzer meist nur die GUI einer Software zu sehen bekommt und die grafische Oberfl¨ ache somit der Teil der Anwendung ist, mit dem der Benutzer direkt konfrontiert wird. Je benutzerfreundlicher sie ist, umso besser sch¨ atzt der Benutzer die Qualit¨ at der Software ein. Deshalb ist es umso wichtiger, dass die Dialoge und der Arbeits-Workflow einer Anwendung fr¨ uhzeitig nach den W¨ unschen des Kunden definiert und gestaltet werden. F¨ ur den Entwurf der grafischen Oberfl¨ ache ist der fachliche Designer zust¨ andig. Er k¨ onnte hierf¨ ur verschiedene Programme verwenden. Zum Zeichnen des Layouts einer Anwendung k¨ onnte er zum Beispiel Microsoft PowerPoint oder Microsoft Visio nehmen und damit die GUI mit dem Kunden abstimmen. Doch kann der Kunde so den Workflow einer Anwendung schlecht nachvollziehen, da er nicht vorher testen kann, wie sich die Anwendung ” anf¨ uhlt“ und er nicht sieht, wie er damit arbeiten kann.

¨ Ahnliche Probleme befinden sich auch außerhalb der Softwareentwicklung. Beispielsweise beim Kauf einer K¨ uche ist folgende Situation vorstellbar: Der K¨ aufer beschreibt dem Verk¨ aufer welche K¨ uche er haben m¨ ochte, woraufhin der Verk¨ aufer einen statischen Bauplan der K¨ uche zeichnet. Aus Sicht des K¨ aufers ist es jedoch anschaulicher, die K¨ uche in 3D pr¨ asentiert zu bekommen, damit er sich eine bessere Vorstellung in den eigenen R¨ aumen machen kann. Die Entscheidungsfindung des K¨ aufers, ob er die K¨ uche kaufen m¨ ochte und welche K¨ uche er nimmt, wird so erheblich erleichtert.

Die Situation eines K¨ uchenkaufs l¨ asst sich leicht auf den Entwurf grafischer Oberfl¨ achen ubertragen: Es w¨ are sicher hilfreich, sowohl f¨ ur den Kunden als auch f¨ ur den fachlichen ¨

Designer, schon beim Entwurf der GUI durch MockUp-Konzepte zu erleben, wie die Software sich sp¨ ater pr¨ asentiert. Dies erleichtert das fr¨ uhzeitige Auffinden von Designfehlern, Usability-Problematiken und fehlende Funktionalit¨ aten. GUI-MockUps sind Prototypen der Oberfl¨ ache, die ihr Layout visualisieren und ihr Verhalten simulieren, ohne dabei die dahinter steckende fachliche Funktionalit¨ at zu implementieren.

2 1. Einleitung

1.2 Problemstellung

Die vorliegende Arbeit wurde in Zusammenarbeit mit Capgemini sd&m Research erstellt und befasst sich mit der Integration von MockUp-Konzepten bei der Spezifikation grafischer Bedienoberfl¨ achen.

Capgemini sd&m Research ist ein Querschnittsbereich des Software-Unternehmen Capgemini sd&m AG und befasst sich mit Forschung, Entwicklung und Schulungen innerhalb der Firma. Dabei stellen sie viele Methoden, Tools und Softwarekomponenten zur Verf¨ ugung, welche in Projekten in der Capgemini sd&m AG eingesetzt werden. Unter anderem wurde eine Methode zur Erstellung der Spezifikation eines Softwaresystems entwickelt. Hierf¨ ur wird das Modellierungswerkzeug Enterprise Architect (EA) der Firma Sparx Systems [EA] verwendet. Auch die Spezifikation der grafischen Bedienoberfl¨ ache soll mit Enterprise Architect erstellt werden. Dabei sollen MockUp-Konzepte eingesetzt werden.

Die MockUp-Konzepte sollen den fachlichen Designer beim Entwurf der grafischen Oberfl¨ ache unterst¨ utzen. Hierzu soll anstelle der ¨ ublichen Zeichenwerkzeuge, wie beispielsweise Microsoft PowerPoint oder Microsoft Visio, ein MockUp-Tool eingesetzt werden. Der Vorteil liegt, wie oben beschrieben, darin, fr¨ uhzeitig L¨ ucken in der Spezifikation und Design zu erkennen. Durch ein MockUp-Tool k¨ onnen auch Probleme rund um die Usability, das heißt die Gebrauchstauglichkeit und Benutzerfreundlichkeit von Programmen, besser gel¨ ost werden. Es werden aber auch technische Einschr¨ ankungen schneller ersichtlich, wie zum Beispiel Einschr¨ ankungen durch die Kunden-Bildschirmaufl¨ osung. Dies kann ein PowerPoint-Bild hingegen nicht bieten.

Zur Erstellung der Spezifikation von grafischen Oberfl¨ achen wird in der Capgemini sd&m AG der Enterprise Architect eingesetzt. Aus diesem Grund besteht die Hauptaufgabe dieser Arbeit darin, ein geeignetes MockUp-Tool zu finden und dieses in den Spezifikationsprozess und somit in den Enterprise Architect zu integrieren.

1.3 Gliederung der Arbeit

Die vorliegende Arbeit ist, nach diesem einleitenden Teil, in acht weitere Kapitel aufgeteilt. Kapitel 2 beschreibt, was in dieser Arbeit unter MockUp-Konzepten verstanden wird, wie die Capgemini sd&m AG bei der Erstellung der Systemspezifikation vorgeht und wie der Spezifikationsprozess von grafischen Oberfl¨ achen unterst¨ utzt werden kann. Abschließend werden einige verwandte Arbeiten vorgestellt.

In dieser Arbeit soll ein MockUp-Tool in den Spezifikationsprozess integriert werden. Um ein geeignetes Tool zu finden, wird ein eigenes Entscheidungsverfahren entwickelt und verwendet, welches in Kapitel 3 beschrieben wird.

Das beschriebene Entscheidungsverfahren zur Auswahl des MockUp-Tools basiert auf Kriterien, die das MockUp-Tool erf¨ ullen muss. Um diese Kriterien zu definieren, werden Interviews mit Software Ingenieuren (fachliche Designer) und Usability Experten durchgef¨ uhrt. Die Ergebnisse der Interviews sind in Kapitel 4 zu finden.

In Kapitel 5 wird die Evaluierung der MockUp-Tools beschrieben. Dabei werden die evaluierten Tools und das Ergebnis der Evaluierung vorgestellt.

In der vorliegenden Arbeit wird eine Architektur zur Integration eines MockUp-Tools in ein Modellierungswerkzeug entwickelt, welche in Kapitel 6 erl¨ autert wird.

1.3. Gliederung der Arbeit 3

Die hier vorgestellte Architektur wurde f¨ ur ein Modellierungswerkzeug und ein MockUp-Tool implementiert. Die Implementierung der Architektur wird in Kapitel 7 beschrieben.

Der Einsatz des implementierten Systems, wird in Kapitel 8 anhand von verschiedenen Szenarien beschrieben.

Abschließend folgt eine Zusammenfassung der Arbeit und ein Ausblick zur m¨ oglichen Wei- terf¨ uhrung dieser Arbeit.

4 1. Einleitung

2. Integration von MockUp-Konzepten in

das Vorgehensmodell von

Entwicklungsprojekten

In diesem Kapitel wird analysiert, wie der Spezifikationsprozess von grafischen Oberfl¨ achen durch MockUp-Konzepte unterst¨ utzt werden kann. Es wird zun¨ achst definiert, was unter MockUp-Konzepte verstanden wird und danach untersucht, wie die Capgemini sd&m AG bei der Durchf¨ uhrung von Softwareentwicklungsprojekten vorgeht, wie die Systemspezifikation dort erstellt wird und welche Werkzeuge hierf¨ ur eingesetzt werden. Abschließend werden einige verwandte Arbeiten vorgestellt.

2.1 Was sind MockUp-Konzepte?

In der vorliegenden Arbeit sollen fachliche Designer beim Entwurf grafischer Oberfl¨ achen durch die Integration von MockUp-Konzepten in den Spezifikationsprozess unterst¨ utzt werden. Unter MockUp-Konzepten wird in dieser Arbeit das Erstellen von MockUps der grafischen Oberfl¨ ache verstanden, mit dem Ziel, die GUI zu entwerfen, den Arbeitsworkflow zu definieren und diesen zu testen. MockUps sind Prototypen der Bedienoberfl¨ ache, die das Layout der GUI visualisieren und ihr Verhalten simulieren, ohne dabei die fachliche Funktionalit¨ at zu implementieren.

MockUps k¨ onnen nicht nur beim Entwerfen der GUI eingesetzt werden, sondern auch in anderen Phasen der Softwareentwicklung behilflich sein. Sie k¨ onnten zum Beispiel zur Durchf¨ uhrung von Usability Tests benutzt werden. Dadurch kann schon sehr fr¨ uh im Softwareentwicklungsprojekt die Benutzerfreundlichkeit der Software getestet und verbessert werden. Außerdem k¨ onnen Prototypen der GUI beim Festlegen und Validieren von Anforderungen helfen. Nach Ian Sommerville [Somm96] gibt es einige Experimente, die belegen, dass der Einsatz von Prototypen in den fr¨ uhen Phasen der Softwareentwicklung Probleme bei der Spezifikation der Anforderungen und Kosten f¨ ur die Softwareentwicklung verrin- gern kann.

Prototypen am Anfang eines Softwareprojektes zu entwickeln bringt, nach Ian Sommerville ([Somm96]), viele Vorteile. Einige dieser Vorteile sind:

• Missverst¨ andnisse zwischen Softwareentwicklern und Endbenutzern k¨ onnen vermieden werden.

• Fehlende Funktionalit¨ aten der Software k¨ onnen fr¨ uh entdeckt werden.

• Die Benutzerfreundlichkeit kann erh¨ oht werden, indem die f¨ ur den Endbenutzer kompliziert erscheinenden Interaktionen mit dem System fr¨ uhzeitig identifiziert werden.

• Inkonsistente Anforderungen k¨ onnen gefunden werden.

Diese Vorteile gewinnt man, indem Kunden beziehungsweise Endbenutzer den Prototypen testen und Feedback geben. Wenn man von Prototypen einer Software spricht, muss zwischen zwei Arten unterschieden werden: Evolution¨ are Prototypen und Wegwerf-Prototypen (vgl. [Somm96]). Unter einem evolution¨ aren Prototypen versteht man eine Art inkrementelle Implementierung des Prototypen. Dabei wird mit der Implementierung schon in der Spezifikationsphase begonnen und diese St¨ uck f¨ ur St¨ uck weiterentwickelt. Diese Art von Prototypen wird eingesetzt, wenn die Anforderungen an die Anwendung anfangs sehr unklar sind. Je pr¨ aziser die Anforderungen werden, umso mehr werden diese in die Software implementiert. Das Ziel von evolution¨ aren Prototypen ist es, am Ende eine Implementierung der kompletten Anwendung zu erhalten. Ein Wegwerf-Prototyp hingegen, wird nur zum Definieren und Validieren von Anforderungen benutzt und anschließend nicht weiterverwendet. In dieser Arbeit wird genau diese Art von Prototypen betrachtet, wobei bei den hier betrachteten Protoypen der GUI nichts implementiert werden soll. Wegwerf-Prototypen der grafischen Oberfl¨ ache, bei denen nichts implementiert wird, werden oft als MockUps bezeichnet.

2.2 Das Vorgehensmodell der Capgemini sd&m AG

Diese Arbeit entstand in Zusammenarbeit mit Capgemini sd&m Research. Die MockUp-Konzepte sollen bei der Capgemini sd&m AG in den Spezifikationsprozess von grafischen Oberfl¨ achen integriert werden. In diesem Abschnitt wird untersucht, wie die Capgemini sd&m AG bei der Durchf¨ uhrung von Projekten vorgeht und wie und wann die Spezifikation der grafischen Oberfl¨ achen erstellt wird. Dadurch wird ersichtilich, wie diese durch MockUp-Konzepte unterst¨ utzt werden kann.

Das Vorgehensmodell der Capgemini sd&m AG ist die ” Essenz aus mehreren tausend

Bearbeiterjahren Projekterfahrung und aus der Forschung von sd&m Research“ [SDMP]. Dieses Vorgehensmodell richtet sich nach einem aus jahrelanger Erfahrung entstandenem Projektmodell. Das Projektmodell soll laut dem Verfahrenshandbuch der Capgemini sd&m AG [Verf09], als Orientierungshilfe und Ideengeber bei der t¨ aglichen Projektarbeit dienen. Abbildung 2.1 zeigt die Phasen dieses Projektmodells.

Abbildung 2.1: Phasen des Projektmodells der Capgemini sd&m AG [Verf09]

2.2. Das Vorgehensmodell der Capgemini sd&m AG 7

Das Capgemini sd&m Projektmodell besteht aus den vier Phasen Angebot, Initialisierung, Projektdurchf¨ uhrung und Abschluss, die im Weiteren n¨ aher erl¨ autert werden.

• Angebot: Zu Beginn jedes Projektes befindet sich die Phase Angebot. Das Angebot muss von Seiten der Capgemini sd&m AG erstellt werden. Im Projektmodell wird festgelegt, wie das Angebot erstellt werden soll und was es beinhalten muss.

• Initialisierung: Wurde das Angebot vom Kunden angenommen, findet mit der Initialisierung der eigentliche Beginn eines Projektes statt. Hier wird die Projektdurchf¨ uhrung geplant und vorbereitet. Diese Phase endet mit einem Kickoff, bei dem alle Voraussetzungen f¨ ur die Durchf¨ uhrung des Projektes gepr¨ uft werden.

• Projektdurchf¨ uhrung: Die Phase der Projektdurchf¨ uhrung beinhaltet Prozesse, die f¨ ur die Erstellung der Spezifikation bis hin zur Inbetriebnahme eines Projektauftrages ben¨ otigt werden.

• Abschluss: Jedes Projekt hat einen Abschluss. Dieser dient zur ¨ Ubergabe des Projektes an den Kunden. Hier wird auch das gelernte Wissen aus dem Projekt dokumentiert und m¨ ogliche weitere Folgeprojekte vorbereitet.

Bei der Projektdurchf¨ uhrung arbeitet die Capgemini sd&m AG je nach Projektsituation mit unterschiedlichen eigenen und optimierten Vorgehensmodellen. Diese basieren teilweise auf bekannte Modelle wie RUP oder Scrum. In dieser Arbeit kann hier aufgrund bestehender Non-Disclosure-Agreements nicht genauer eingegangen werden. Abbildung 2.2 zeigt ein idealtypisches Wasserfall-Vorgehensmodell, anhand dieser die Positionierung der vorliegenden Arbeit innerhalb des Vorgehensmodells von Capgemini sd&m veranschaulicht werden soll.

Dieses Modell ist in den drei logische Bereichen Studie/Grobkonzept, Systemerstellung und Wartung aufgeteilt. Im zweiten Bereich (Systemerstellung) wird die Software entwickelt. Dieser Bereich beinhaltet die Phasen Spezifikation, Konstruktion, Realisierung, Integration und Inbetriebnahme. Die vorliegende Arbeit soll die Spezifikationsphase unterst¨ utzen.

In der Spezifikationsphase werden die Anforderungen des Kunden festgelegt und das zu entwickelnde System aus fachlicher Sicht detailliert beschrieben. Hier legt man fest, was das Softwaresystem k¨ onnen muss und was es nicht k¨ onnen soll. Als Ergebnis dieser Phase erh¨ alt man die Spezifikation des Systems. Anhand dieses Dokuments wird das fertige System auf die Erf¨ ullung aller in der Spezifikation festgelegten Anforderungen getestet. Deshalb ist es wichtig, dass dieses Dokument widerspruchsfrei und nachvollziehbar ist. In der Spezifikation werden (aus fachlicher Sicht) das logische Datenmodell, das Objekt- modell, die Anwendungsf¨ alle und die Bedienoberfl¨ ache spezifiziert. In dieser Arbeit sollen

MockUp-Konzepte in diese Phase der Softwareentwicklung eingesetzt werden. Capgemini sd&m Research hat eine Spezifikationsmethodik zur Erstellung der Systemspezifikation entwickelt. Die Spezifikationsmethodik wird in Abschnitt 2.3 n¨ aher beschrieben.

2.3 Die Spezifikationsmethodik von Capgemini sd&m Rese-

arch

Die von Capgemini sd&m Research entwickelte Spezifikationsmethodik [Spec09] beschreibt das Vorgehen zur Erstellung der Systemspezifikation des zu entwickelnden Softwaresystems. Bei der Erstellung der Spezifikation werden Anforderungen des Kunden in einem konzeptuellen Entwurf des zu entwickelnden Softwaresystems umgesetzt. Die Spezifikation dient

• zur Abstimmung der fachlichen Funktionalit¨ at des Softwaresystems mit dem Kunden,

• als Basis f¨ ur den technischen Entwurf des Systems und damit auch dessen Implementierung,

• als Basis f¨ ur die Erzeugung von Testf¨ allen und deren Planung,

• als Basis f¨ ur Aufwandssch¨ atzungen und

• zur Abstimmung mit anderen Entwicklern, falls ein Teil des Systems von anderen Entwicklern realisiert wird.

Zur Erreichung dieser Ziele stellt die Spezifikationsmethodik eine Reihe von Definitionen, Prozesse, Tools und Templates zur Verf¨ ugung (s. Abbildung 2.3).

Abbildung 2.3: Spezifikationsmethodik von Capgemini sd&m Research [SDMP]

Die Spezifikationsmethodik kann in folgende Bereiche aufgeteilt werden:

• Content: Dieser Bereich beschreibt, wie die Spezifikation inhaltlich aufgebaut wird und welche Artefakte dabei erstellt werden m¨ ussen.

• Form: Im Bereich Form wird beschrieben, wie die im Content festgelegten Inhalte in der Spezifikation strukturiert werden. Dabei wird vorgegeben, in welcher Notation diese Artefakte erstellt werden sollen.

2.4. Enterprise Architect in der Spezifikationsphase 9

• Process: Der Bereich Process beschreibt das Vorgehen bei der Erstellung der Spezifikation. Dabei werden die erforderlichen Schritte zur Erstellung der Spezifikation festgelegt und detailliert beschrieben.

• Tools: Dieser Bereich beschreibt, welches Tool zur Erstellung der Spezifikation verwendet werden k¨ onnen. Die Capgemini sd&m AG setzt das Modellierungswerkzeug Enterprise Architect (EA) ein. Der EA kann durch Plugins erweitert und damit individuell konfiguriert werden. Bei der Capgemini sd&m AG wurden einige EA Plugins entwickelt, um die Erstellung der Spezifikation zu unterst¨ utzen.

Im Bereich Content wird unter anderem auch festgelegt wie die grafische Bedienoberfl¨ ache spezifiziert werden soll. Bei der Spezifikation der Oberfl¨ ache wird beschrieben, wie der Benutzer mit dem System interagiert, welche Funktionen er in welchen Dialogen ausf¨ uhren kann und welche Daten er dabei eingeben muss. Dabei wird das Aussehen (Layout) der grafischen Oberfl¨ ache und ihr dynamisches Verhalten definiert. Durch die vorliegende Arbeit soll die Erstellung dieser Spezifikation unterst¨ utzt werden.

2.4 Enterprise Architect in der Spezifikationsphase

Die Capgemini sd&m AG verwendet bei der Durchf¨ uhrung von Softwareentwicklungsprojekten das Modellierungswerkzeug Enterprise Architect. Der EA ist ein sehr m¨ achtiges Tool und kann in verschiedenen Phasen der Softwareentwicklung benutzt werden. Es kann beispielsweise bei der Anforderungsanalyse, bei der Erzeugung der Spezifikation und sogar bei der Implementierung der Software eingesetzt werden. Abbildung 2.4 zeigt einen Screenshot vom Enterprise Architect.

Mit dem EA k¨ onnen UML-Diagramme modelliert werden. Die GUI des EA ist in drei Teile geteilt. Auf der linken Seite befindet sich die Toolbox mit Elementen, die zum Zeichnen von UML-Diagrammen verwendet werden k¨ onnen. Die Zeichenfl¨ ache f¨ ur die Diagramme bildet den zweiten Teil (auf dem Bild in der Mitte zu sehen). Zum Zeichen k¨ onnen die Elemente aus der Toolbox in das Diagramm gezogen werden. Im rechten Teil der Bedienoberfl¨ ache

vom Enterprise Architect wird der Project Browser angezeigt, der alle Elemente des Modells beinhaltet. Auch die Elemente der Diagramme werden im Project Browser dargestellt.

Der EA speichert die Daten in einem UML Modell, das auf dem UML 2.1 Standard basiert. Aus diesem Modell kann mittels eines modellbasierten Ansatzes Code generiert werden. Somit kann der EA sogar bei der Implementierungsphase verwendet werden. Der EA bietet die M¨ oglichkeit individuell konfiguriert und erweitert zu werden. Sparx Systems stellt f¨ ur die Erweiterbarkeit eine API zur Verf¨ ugung (siehe Kapitel 7.1.2).

Das UML Modell, in dem der Enterprise Architect die Daten speichert, kann an die eigenen Anforderungen angepasst werden. Capgemini sd&m Research hat zur Erstellung der Systemspezifikation ein eigenes Spezifikationsmodell, das Specification Modeling Toolkit (SMT), erstellt. Mit diesem Modell k¨ onnen auch grafische Oberfl¨ achen entworfen werden, indem das Layout gezeichnet und ihre Elemente beschrieben werden. Das SMT stellt hierf¨ ur einige Widgets zur Verf¨ ugung. Auf Abbildung 2.5 ist zu sehen, wie der SMT zum Entwerfen der GUI eingesetzt wird.

In der Toolbox auf der linken Seite befinden sich die Widgets zum Entwerfen der GUI. In der Mitte wird das Layout gezeichnet. F¨ ur jedes GUI-Element wird im Project Browser ein Objekt angezeigt. Um die grafische Oberfl¨ ache zu beschreiben, k¨ onnen zu jedem Element des Project Browsers detailliertere Informationen in einem sogenannten Property-Dialog eingetragen werden.

Zur Erzeugung der Spezifikation hat Capgemini sd&m Research mittels der von Sparx Systems zur Verf¨ ugung gestellten API ein Tool entwickelt (den Document Generator ), welches die Spezifikation aus den Daten im Spezifikationsmodell automatisch generiert. Dabei wird unter anderem auch die Spezifikation der grafischen Oberfl¨ ache erstellt.

In dieser Arbeit soll der Entwurf von grafischen Oberfl¨ achen durch die Integration von MockUp-Konzepten unterst¨ utzt werden, indem die Bedienoberfl¨ ache in einem MockUp-

2.5. Abgrenzung zu verwandten Arbeiten 11

Tool entworfen und die Elemente der GUI in den Enterprise Architect importiert werden. Von dort aus muss sie editiert und auch wieder exportiert werden k¨ onnen. Beim Importieren soll der Objektbaum mit den GUI-Elemente generiert und im Project Browser zu sehen sein. Dabei muss im Diagramm ein Screenshot der entworfenen GUI angezeigt werden. Das SMT wird also nicht durch das MockUp-Tool ersetzt, sondern zum Erzeugen des Objektbaumes benutzt. Dadurch wird es m¨ oglich, dass die GUI-Elemente weiterhin im EA detailliert beschrieben und die Spezifikation mit dem Document Generator generiert werden kann.

2.5 Abgrenzung zu verwandten Arbeiten

Im folgenden Abschnitt werden zwei verwandte wissenschaftliche Artikel und deren Unterschiede zu dieser Arbeit vorgestellt. Diese sind:

• Die Arbeit Methoden und Werkzeuge f¨ ur das Prototyping und ihre Integration von G. Pomberger, W. Pree und A. Stritzinger, welche 1992 erschienen ist [PoPS92].

• Die Arbeit Vorgehensweisen und Werkzeuge f¨ ur ein Ineinandergreifen von Modellierung und Prototyping von Josef Voss. Diese ist 1997 ver¨ offentlicht worden [Voss97].

2.5.1 Methoden und Werkzeuge f¨ ur das Prototyping und ihre Integration

Bei dem Paper Methoden und Werkzeuge f¨ ur das Prototyping und ihre Integration geht es um die Integration von Prototyping-Methoden in den Entwicklungsprozess von Softwaresystemen. Dabei umfasst Prototyping alle T¨ atigkeiten zur Erstellung von Prototypen, welche in diesem Paper als ” ein ausf¨ uhrbares Modell mit wesentlichen Eigenschaften des

Zielsystems, das Grundlage f¨ ur die Systemspezifikation und die Kommunikation zwischen Kunden und Entwicklern unterst¨ utzt“ [PoPS92] verstanden werden.

Das Paper stellt ein Konzept f¨ ur eine Prototyp-orientierte Softwareentwicklung vor. Dieses Konzept erweitert die klassisch sequentielle Softwareentwicklungsmethode um die Erstellung von Prototypen f¨ ur die grafische Bedienoberfl¨ ache und Prototypen f¨ ur die Architektur (siehe Abbildung 2.6).

F¨ ur dieses Konzept wurden einige Werkzeuge entwickelt, welche ebenfalls beschrieben werden. Es wurden unter anderem ein Tool zur Erstellung von GUI-Prototypen und eins zur Erstellung von Architekturprototypen entwickelt, welche detailliert erkl¨ art werden.

Der Unterschied zu der vorliegenden Arbeit ist, dass in diesem Paper eine Softwareentwicklungsmethode entwickelt wurde, welche die herk¨ ommliche Methode durch den Einsatz von Prototypen erweitert. In der vorliegenden Arbeit werden MockUp-Konzepte in einen bestehenden Softwareentwicklungsprozess integriert und kein eigenes Werkzeug zu Erstellung von Prototypen entwickelt. Außerdem werden in der vorliegenden Arbeit nur Prototypen der GUI betrachtet. Architekturprototoypen werden nicht ber¨ ucksichtigt.

2.5.2 Vorgehensweisen und Werkzeuge f¨ ur ein Ineinandergreifen von Modellierung und Prototyping

In dem Paper Vorgehensweisen und Werkzeuge f¨ ur ein Ineinandergreifen von Modellierung und Prototyping geht es um den Zusammenhang zwischen Prototypen und den Modellen der Spezifikation. Es werden hier nur Prototypen der grafischen Oberfl¨ ache betrachtet. Dabei wird speziell der Weg vom Prototyp zum Modell untersucht, bei der die Ergebnisse aus den Prototypen zur Erstellung der Modelle verwendet werden.

In diesem Paper wird zwischen vier Modellen unterschieden:

• Aufgabenmodell (Task-Modell): Im Task-Modell werden die T¨ atigkeiten modelliert, welche der Benutzer mit dem System ausf¨ uhren k¨ onnen soll.

• Objektmodell (OOA-Modell): Das Objektmodell wird mit einer objektorientierten Analyse erstellt. Dabei beschreibt dieses Modell die Problemwelt mit Hilfe von Klassen, Attributen und Beziehungen zwischen diesen.

• Abstraktes Modell der Benutzerschnittstelle (UIA-Modell): Im abstrakten Modell der Benutzerschnittstelle wird definiert, wie die GUI aufgebaut sein muss. Es wird beispielsweise festgelegt, welche Navigationsm¨ oglichkeiten vorhanden sein m¨ ussen oder welche Informationen wo dargestellt werden sollen.

• Konkretes Modell der Benutzerschnittstelle (UIO-Modell): Das konkrete Modell der Benutzerschnittstelle beschreibt das Layout der GUI und definiert die Interaktionsm¨ oglichkeiten.

• Software-Architekturmodell (OOD-Modell): Das Software-Architekturmodell spielt in diesem Paper eine untergeordnete Rolle und wird deshalb nicht weiter betrachtet.

Zum Erstellen von Prototypen k¨ onnen verschiedene Techniken verwendet werden. Es k¨ onnen Nutzungsszenarien, Oberfl¨ achenskizzen, Oberfl¨ achenprototypen oder eine erste Version des Systems in der Zielumgebung erstellt werden. Durch den Einsatz dieser Techniken kann die Erstellung der oben beschriebenen Modelle unterst¨ utzt werden, wie Abbildung 2.7 zeigt. Dieser Zusammenhang zwischen Prototypen und Modellen wird im Paper anhand eines Beispiels beschrieben.

2.5. Abgrenzung zu verwandten Arbeiten 13

Abbildung 2.7: Der Zusammenhang von Prototypen und Modellen [Voss97]

In der vorliegenden Arbeit werden Oberfl¨ achenprototypen betrachtet. Es soll mit Hilfe eines MockUp-Tools die GUI entworfen werden und mit diesen MockUps die Spezifikation unterst¨ utzt werden. Es wird also hier, ¨ ahnlich wie beim Paper Vorgehensweisen und Werkzeuge f¨ ur ein Ineinandergreifen von Modellierung und Prototyping, das MockUp bei der Erstellung der Spezifikation eingesetzt.

3. Entscheidungsverfahren zur Auswahl

des MockUp-Tools

Dieses Kapitel befasst sich mit dem Auswahlverfahren des MockUp-Tools. Es werden g¨ angige Entscheidungsverfahren, die zur Auswahl des Tools benutzt werden k¨ onnten, und das verwendete Verfahren beschrieben.

3.1 Allgemeine Entscheidungsverfahren

Um das MockUp-Tool in den Spezifikationsprozess gut integrieren zu k¨ onnen, ist es wichtig ein geeignetes Tool zu finden. Es existieren viele Tools, mit denen GUIs entworfen werden k¨ onnen. Die Aufgabe ist nun, aus diesen verschiedenen Tools das richtige auszuw¨ ahlen. Es gibt einige Entscheidungsmethoden, die bei der Entscheidungsfindung in verschiedenen Bereichen und Situationen unterst¨ utzen k¨ onnen. Diese Methoden k¨ onnen auch zur Auswahl eines MockUp-Tools behilflich sein. Man unterscheidet bei diesen Verfahren zwischen Entscheidungsalternativen und Entscheidungskriterien. Entscheidungsalternativen sind die verschiedenen M¨ oglichkeiten, f¨ ur die man sich entscheiden kann. Ziel ist, sich am Ende f¨ ur eine Alternative zu entscheiden. Dabei k¨ onnen gewisse Kriterien die Entscheidung beeinflussen, diese werden Entscheidungskriterien genannt. In der vorliegenden Arbeit sind die MockUp-Tools die Entscheidungsalternativen und die Anforderungen, die das Tool erf¨ ullen soll, sind die Entscheidungskriterien. Die Art und Weise, wie diese Entscheidungskriterien ermittelt und verwendet werden, h¨ angt vom eingesetzten Entscheidungsverfahren ab. Typische Entscheidungsverfahren sind:

• CAF (Consider All Facts),

• PMI (Plus Minus Interesting),

• Entscheidungsmatrizen und

• Nutzwertanalyse,

die im Folgenden n¨ aher erl¨ autert werden.

16 3. Entscheidungsverfahren zur Auswahl des MockUp-Tools

CAF

Bei der Methode CAF, nach Edward de Bono, werden alle Kriterien, die in irgendeiner Weise etwas mit der Entscheidung zu tun haben, gesammelt und aufgelistet. Die Kriterien werden anschließend nach ihrer Wichtigkeit sortiert und den Entscheidungsalternativen gegen¨ ubergestellt. Diese Methode eignet sich sehr gut, um einen ¨ Uberblick ¨ uber die Entscheidungssituation zu bekommen. Sie liefert aber kein eindeutiges Ergebnis. Bei dieser Methode versucht man so viele Informationen wie m¨ oglich ¨ uber die Entscheidungssituation zu bekommen [Senf].

PMI

Beim PMI, ebenfalls nach Edward de Bono, werden alle positiven und negativen Auswirkungen der Entscheidungsalternativen betrachtet und in verschiedenen Listen eingetragen. Neben den Listen ” Positiv“ und ” Negativ“ gibt es die Liste ” Interessant“, die f¨ ur Auswirkungen, die weder negativ noch positiv sind, gedacht ist. F¨ ur alle Entscheidungsalternativen werden diese drei Listen aufgebaut, um damit eine Entscheidung treffen zu k¨ onnen. Auch diese Methode liefert kein eindeutiges Ergebnis, sondern dient dazu, Klarheit ¨ uber die

Auswirkungen einer Entscheidung zu bekommen. [Senf].

Entscheidungsmatrix

Die Entscheidungsmatrix (oft auch Entscheidungstabelle genannt) ist, anders als CAF und PMI, eine rationale Entscheidungsmethode. Der Vorteil der Entscheidungsmatrix ist, dass diese am Ende meist ein eindeutiges Ergebnis beziehungsweise Entscheidung liefert, welches jederzeit nachvollzogen werden kann. Bei der Entscheidungsmatrix werden zun¨ achst Kriterien f¨ ur die Entscheidungsfindung gesammelt. Dabei muss beachtet werden, dass die Kriterien gleich formuliert sind. Soll zum Beispiel gelten, dass eine Alternative umso besser ist, je mehr Kriterien sie erf¨ ullt, dann m¨ ussen alle Kriterien positiv formuliert werden. Nach dem Sammeln und Ausformulieren der Kriterien werden diese in einer Tabelle den Entscheidungsalternativen gegen¨ ubergestellt. In dieser Tabelle k¨ onnen f¨ ur jede Alternative Punkte zu den Kriterien vergeben werden. Es werden Punkte beispielsweise von 1 bis 6 vergeben. 6 Punkte bedeutet, dass das Kriterium optimal von der Alternative erf¨ ullt wird und 1 Punkt, dass es gar nicht erf¨ ullt wird. Diese Punkte werden f¨ ur jede Alternative zu einer Gesamtpunktzahl addiert. Die Entscheidung f¨ allt auf die Alternative mit den h¨ ochsten Punkten. Ein Beispiel f¨ ur eine Entscheidungsmatrix ist in Tabelle 3.1 zu sehen, bei der es um die Entscheidung geht, welches Jobangebot man annehmen soll. Samson GmbH erh¨ alt hier am meisten Punkte, weshalb die Entscheidung auch auf diese Alternative f¨ allt [Senf].

¹ Beispiel aus der Quelle [Senf]

3.1. Allgemeine Entscheidungsverfahren 17

Gewichtete Entscheidungsmatrix

Mit der oben vorgestellten Entscheidungsmatrix erh¨ alt man durch das Festlegen von Kriterien, die die Entscheidungsalternative erf¨ ullen muss, meist ein klares Ergebnis. Es wird jedoch nicht die Wichtigkeit der Kriterien ber¨ ucksichtigt. Oft gibt es aber Kriterien, die unterschiedlich gewichtet werden m¨ ussen. Im Beispiel der Entscheidung f¨ ur ein Jobangebot k¨ onnte es beispielsweise wichtiger sein Spaß an der Arbeit zu haben als viel Urlaub zu erhalten. In solchen F¨ allen hilft die gewichtete Entscheidungsmatrix. Bei dieser Methode werden die Kriterien mittels eines Prozentsatzes gewichtet, der in die Berechnung der Gesamtpunktzahl der Alternative einfließt (s. Tabelle 3.2).

F¨ ur die Bestimmung der Gesamtpunktzahl werden die Punkte f¨ ur jedes Kriterium mit dem entsprechenden Prozentsatz multipliziert und anschließend addiert. Auch bei diesem Verfahren gewinnt die Alternative mit den meisten Punkten. Im Beispiel oben ist das die Alternative Tuwas AG [Senf].

Nutzwertanalyse

Die Nutzwertanalyse hat eine ¨ ahnliche Vorgehensweise wie die gewichtete Entscheidungsmatrix. Auch hier werden im ersten Schritt Kriterien f¨ ur die Entscheidungsfindung gesammelt. Jedoch werden nicht alle Kriterien betrachtet, sondern zum Beispiel nur die ca. f¨ unf wichtigsten. Anschließend werden diese Kriterien gewichtet, wobei die Gewichtung rechnerisch ermittelt wird. Dazu werden die Kriterien in einer Tabelle zueinander in Bezug gestellt (siehe Tabelle 3.3).

² Beispiel aus der Quelle [Senf]

³ Beispiel aus der Quelle [Nikl04]

18 3. Entscheidungsverfahren zur Auswahl des MockUp-Tools

In die Tabelle wird eingetragen, wie wichtig ein Kriterium im Vergleich zu einem anderen Kriterium ist. Dabei werden Punkte von 0 bis 2 vergeben, die unterschiedliche Bedeutungen haben:

• 0 Punkte: das Kriterium ist nicht wichtiger als das andere Kriterium.

• 1 Punkt: beide Kriterien sind gleich wichtig.

• 2 Punkte: das Kriterium ist wichtiger als das andere Kriterium.

Sind die Punkte vergeben, werden diese f¨ ur jedes Kriterium addiert und in die Spalte erhaltene Punkte“ eingetragen. Wenn man diese erhaltenen Punkte prozentual angibt, ”

bekommt man die Gewichtung der Kriterien.

¨ Ahnlich zur Entscheidungsmatrix werden auch bei der Nutzwertanalyse die Kriterien den Entscheidungsalternativen gegen¨ ubergestellt und bewertet. Im Beispiel auf Tabelle 3.4 werden Punkte zwischen 1 und 7 vergeben. Die Bewertung der Alternativen steht in der Spalte ” Zielerf¨ ullung“. Der Zielerf¨ ullungswert wird mit der Gewichtung multipliziert und in die Spalte ” Nutzwert“ eingetragen. Addiert man diese Werte f¨ ur jede Alternative, erh¨ alt man ihren gesamten Nutzwert. Die Entscheidung f¨ allt dabei auf die Alternative mit dem h¨ ochsten (Nutz-)Wert. Im Beispiel in Tabelle 3.4 ist das die Alternative B [Nikl04].

3.2 Eigenes Entscheidungsverfahren

F¨ ur die Auswahl des MockUp-Tools wird eine modifizierte Version der gewichteten Entscheidungsmatrix verwendet. Die Entscheidungsalternativen sind die MockUp-Tools und die Entscheidungskriterien die Anforderungen, die das Tool erf¨ ullen soll.

In der vorliegenden Arbeit wird zwischen atomaren Kriterien und Kriterien-Gruppen unterschieden. Eine Kriterien-Gruppe ist eine Aggregation von mehreren atomaren Kriterien. Es k¨ onnen auch mehrere Kriterien-Gruppen zu einer Gruppe zusammengefasst werden. Dadurch kann die Gruppierung von Kriterien eine beliebige Tiefe erreichen. Die gesamte Entscheidungsmatrix besteht aus mehreren atomaren Kriterien und Kriterien-Gruppen und wird in dieser Arbeit ebenfalls als eine Gruppe gesehen. Dadurch kann man das Gesamtergebnis der Matrix schnell und einfach am Ergebnis der gesamten Gruppe ablesen.

Bei der Entscheidung f¨ ur ein MockUp-Tool muss die Wichtigkeit der Anforderungen (beziehungsweise Kriterien) beachtet werden. Dies wird mit einer Gewichtung der Kriterien erreicht. Die Gewichtung zeigt dabei den prozentualen Anteil des Kriteriums innerhalb

⁴ Beispiel aus der Quelle [Nikl04]

3.2. Eigenes Entscheidungsverfahren 19

einer Gruppe. Folglich bildet die Summe der Prozents¨ atze innerhalb einer Gruppe immer 100%.

Durch die Gruppierung von Kriterien ¨ andert sich gegen¨ uber der herk¨ ommlichen gewichteten Entscheidungsmatrix die Berechnung der Gesamtpunkte der Alternativen. Es werden weiterhin f¨ ur jede Alternative beziehungsweise jedes Tool Punkte f¨ ur die atomaren Kriterien vergeben. Zur Bewertung der MockUp-Tools werden Punkte zwischen 0 und 6 vergeben. 0 Punkte bedeutet, dass das MockUp-Tool die Anforderung gar nicht erf¨ ullt und 6 Punkte, dass es sie optimal erf¨ ullt. Da nur die atomaren Kriterien bewertet werden, m¨ ussen die Punkte f¨ ur die Kriterien-Gruppen berechnet werden. Daf¨ ur werden Aggregati-onsformeln verwendet, mit denen die gewichteten Punkte innerhalb einer Gruppe zusammengefasst werden. Beispiele f¨ ur Aggregationsformeln sind: Summe, Max, Min und Avg (Durchschnitt).

Es gibt verschiedene Arten von Kriterien. Dabei unterscheidet man zwischen Pflicht-Kriterien und optionalen Kriterien. Die Pflicht-Kriterien m¨ ussen, anders als die optionalen Kriterien, vom MockUp-Tool in jedem Fall erf¨ ullt werden. Einige Anforderungen an das MockUp-Tool k¨ onnen unterschiedlich gut durch alternative Unterkriterien erf¨ ullt werden. Die Kriterienarten k¨ onnen auch kombiniert auftreten: Zum Beispiel kann ein Pflicht-Kriterium durch unterschiedliche alternative Unterkriterien erf¨ ullt werden. In der Entscheidungsmatrix f¨ ur die Auswahl des MockUp-Tools werden diese Arten durch Be-dingungsformeln repr¨ asentiert. Jedes atomare Kriterium und auch jede Kriterien-Gruppe, besitzt eine Bedingungsformel. Es handelt sich hier um eine boolsche Formel, die angibt, ob ein Kriterium von einer Alternative erf¨ ullt worden ist. Bei den atomaren Kriterien gibt die Bedingungsformel an, welche Mindestpunkte ein Kriterium haben muss. Die Formel >2“ ist ein Beispiel f¨ ur eine Bedingungsformel eines atomaren Kriteriums, das mindestens ”

3 Punkte erhalten muss. Bei den Kriterien-Gruppen gibt die Bedingungsformel an, welche Kriterien erf¨ ullt werden m¨ ussen und welche optional sind. In Tabelle 3.5 ist der Aufbau der Entscheidungsmatrix dargestellt.

In obiger Tabelle sind sechs atomare Kriterien und drei Gruppen zu sehen. Kriterien werden durch dickere Umrandungen und Gruppen durch unterschiedliche Schattierungen markiert. Die Aggregations- beziehungsweise Bedingungsformeln stehen jeweils unter den Kriterien.

20 3. Entscheidungsverfahren zur Auswahl des MockUp-Tools

Die bei der Evaluierung vergebenen Bewertungen stehen in der Spalte ” Punkte“. Punkte

werden hier nur f¨ ur atomare Kriterien eingetragen und f¨ ur die Gruppen mit Hilfe der Aggregationsformeln berechnet. Diese Punkte werden mit der Gewichtung multipliziert

und stehen in der Spalte ” resultierende Punkte“. (s. Tabelle 3.5). Ob die Bedingungsformel erf¨ ullt worden ist, sieht man in der Spalte ”

boolscher Wert steht. In Tabelle 3.6 ist ein Beispiel f¨ ur eine Entscheidungsmatrix mit zwei MockUp-Tools zu sehen.

F¨ ur das Berechnen der Punkte der Kriterien-Gruppen wird meist die Aggregationsformel Summe“ eingesetzt, außer bei Gruppen mit mehreren alternativen Kriterien. Bei diesen ”

Gruppen werden die Punkte mit der Formel ” Max“ berechnet, um die h¨ ochste Bewertung der Gruppe zu selektieren.

Im Beispiel wird das Kriterium ” A3“ beim ” MockUp-Tool 1“, wie man am Ergebnis der

Bedingungsformel sieht, nicht erf¨ ullt. In der Bedingung seines Oberkriteriums wird aber gefordert, dass dieses Kriterium eingehalten werden muss. Da dies hier nicht so ist, ist

das Resultat der Bedingungsformel seiner Gruppe auch negativ. Beim ” wird das Kriterium ” A2“ nicht erf¨ ullt. Dieses Kriterium ist aber ein optionales Kriterium, deshalb ist das Ergebnis der Bedingungsformel des Oberkriteriums hier trotzdem positiv.

Oberkriterium B“ kann von mehreren Alternativen erf¨ ullt werden. Es erh¨ alt darum die ”

Punkte seines Unterkriteriums, das am besten bewertet wurde. Beim ” ist das das Kriterium ”

dieser Oberkriterien weichen in Tabelle 3.6 von den Unterkriterien ab, da die Gewichtung der Gruppe schon ber¨ ucksichtigt wurde.

Insgesamt bekommt ” Mockup-Tool 1“ die meisten Punkte, doch wird die Bedingung der gesamten Entscheidungsmatrix bei diesem Tool nicht erf¨ ullt. Dadurch ist der Gewinner

3.2. Eigenes Entscheidungsverfahren 21

dieser Entscheidungsmatrix ” MockUp-Tool 2“, obwohl dieses Tool weniger Punkte erhalten hat.

Das gew¨ ahlte Entscheidungsverfahren f¨ ur die Auswahl des MockUp-Tools ben¨ otigt Kriterien, die das MockUp-Tool erf¨ ullen muss. Zus¨ atzlich m¨ ussen diese Kriterien gewichtet und geeignete Aggregations- und Bedingungsformeln definiert werden. Zur Definitionsfindung werden Endanwender interviewt.

22 3. Entscheidungsverfahren zur Auswahl des MockUp-Tools

4. Analyse des Spezifikationsprozesses

von grafischen Oberfl ¨ achen

und Analyse der Anforderungen von

MockUp-Tools

Dieses Kapitel befasst sich mit der Analyse des Spezifikationsprozesses von grafischen Oberfl¨ achen und der Suche von Anforderungen an das MockUp-Tool. Es wird beschrieben wie diese Analyse stattfindet und die Ergebnisse vorgestellt.

4.1 Vorgehen

Das MockUp-Tool soll von fachlichen Designern zum Entwerfen von GUIs verwendet werden und sie beim Spezifikationsprozess von grafischen Oberfl¨ achen bestm¨ oglich unterst¨ utzen. Um zu entscheiden, welches Tool den Designer am besten unterst¨ utzt, werden Kriterien beziehungsweise Anforderungen an das Tool definiert. Dabei werden Interviews mit fachlichen Designern durchgef¨ uhrt, wobei es sich meist um Software Ingenieure handelt.

Neben den fachlichen Designern werden auch Usability Experten interviewt. Die Gebrauchstauglichkeit einer Software gewinnt in der Softwareentwicklung in der heutigen Zeit an Bedeutung und wird immer mehr zu einer Qulit¨ atseigenschaft [Nebe09]. Der Grund daf¨ ur ist, dass die Benutzer mit der grafischen Oberfl¨ ache direkt interagieren und schnell die Qualit¨ at einer Software mit dem Verst¨ andnis, dem Aussehen und dem Workflow einer grafischen Bedienoberfl¨ ache gleichsetzen. Umso wichtiger ist es, dass die Dialoge und der Arbeits-Workflow einer Anwendung fr¨ uhzeitig nach den Bed¨ urfnissen des Kunden definiert und in der fr¨ uhen Phase der Spezifikation durch Usability Tests evaluiert werden. Im Hinblick auf die Unterst¨ utzung von Usability Tests ergeben sich zus¨ atzliche Anforderungen, die durch Interviews mit Usability Experten gefunden werden sollen.

Interviewart

Es gibt verschiedene Arten von Interviews. Man unterscheidet zwischen strukturierten, unstrukturierten und semi-strukturierten Interviews [AnLe]. Unstrukturierte Interviews geben keine Vorgaben bei der Durchf¨ uhrung der Interviews. Hier passt sich der Interviewer der Situation und dem Gespr¨ achsverlauf an. Bei dieser Art kann es durchaus vorkom- men, dass den Befragten nicht die selben Fragen gestellt werden, da der Interviewer die

Fragen spontan formuliert. Dadurch erschwert sich die Auswertung der Interviews. Es ist einfacher, wenn jeder Befragte die gleichen Fragen bekommt. Dies ist das Hauptmerkmal strukturierter Interviews. Hier werden Interviews mittels Frageb¨ ogen durchgef¨ uhrt. Man bekommt von jedem Befragten eine Antwort auf alle Fragen. So ist es leichter Antworten miteinander zu vergleichen oder zusammenzufassen. Bei strukturierten Interviews wird dem Befragten typischerweise der Fragebogen gegeben und er f¨ ullt den Fragebogen selbst aus. Bei Unklarheiten hat der Befragte, anders als beim unstrukturierten Interview, keine M¨ oglichkeit den Interviewer zu fragen, ob er die Frage richtig verstanden hat. Dadurch k¨ onnten Fragen falsch interpretiert und so das Ergebnis des Interviews verf¨ alscht werden. Außerdem k¨ onnen Aspekte, an die der Interviewer bei der Erstellung des Fragebogens nicht gedacht hat, w¨ ahrend eines Gespr¨ achs mit dem Befragten zum Vorschein kommen, die sonst verloren gingen. Deshalb ist es sinnvoll, eine Mischung von strukturierten und unstrukturierten Interviews zu w¨ ahlen. Diese werden semi-strukturierte Interviews genannt.

In der vorliegenden Arbeit werden semi-strukturierte Interviews mit Hilfe eines eigens erstellten Fragebogens durchgef¨ uhrt. Der Interviewer befragt die Personen pers¨ onlich und gibt ihnen die M¨ oglichkeit Antworten und ¨ Außerungen selbst zu formulieren. Der Befragte kann auch zu jeder Frage Anmerkungen geben.

Erstellen eines Fragebogens

Bevor man den Fragebogen erstellt, m¨ ussen die Ziele der Interviews definiert werden, um die Fragen besser formulieren zu k¨ onnen. Die vorliegende Arbeit zielt unter anderem darauf ab, Anforderungen an das MockUp-Tool zu finden und einen ¨ Uberblick ¨ uber den Spezifikationsprozess von grafischen Bedienoberfl¨ achen der Capgemini sd&m AG zu erhalten.

Nach der Definition der Ziele werden die Fragen formuliert. Es gibt zwei Formen von Fragen: offene und geschlossene Fragen. Offene Fragen geben dem Befragten die M¨ oglichkeit, frei zu antworten, w¨ ahrend geschlossene Fragen Antwortm¨ oglichkeiten vorgeben. Bei den Antwortm¨ oglichkeiten kann es sich auch um eine Skala handeln (zum Beispiel die Frage Wie h¨ aufig kommt es vor, dass . . . ?“ mit den Antworten ” sehr h¨ aufig, h¨ aufig, nicht so oft, ”

selten, gar nicht“). Jede dieser Fragearten hat Vor- und Nachteile. Bei offenen Fragen kann der Befragte seine Meinung mit eigenen Worten formulieren und es k¨ onnen, wie bei den unstrukturierten Interviews, keine unbedachten Aspekte verloren gehen. Doch erschwert sich die Auswertung der Fragen durch die Vielzahl der Antwortm¨ oglichkeiten. Gibt man Antwortm¨ oglichkeiten vor, erleichtert sich zwar die Auswertung, doch m¨ ussen die vorgegebenen Optionen alle sinnvollen Antworten abdecken. Deshalb sollte man bei der Erstellung von Fragen sowohl geschlossene als auch offene Fragen verwenden. Zum Formulieren der Fragen k¨ onnen folgende Regeln [AnLe] helfen:

• Lange Fragen und verschachtelte S¨ atze sollten vermieden werden.

• Bei Verwendung von Skalen als Antwort sollte es ca. 5-7 Optionen geben.

• Bei Vorgabe von Antwortm¨ oglichkeiten sollten diese sich nicht ¨ uberschneiden.

• Pro Antwortm¨ oglichkeit sollte es nur eine Antwort geben.

• Doppelte Verneinungen sollten vermieden werden.

• Man sollte jeder Frage nur einen sachlichen Inhalt / Gedanken zugrunde legen.

4.2. Ziele der Interviews 25

In der vorliegenden Arbeit wird der Fragebogen nach dem Ansatz des sog. leitfadenorientierten Interviews [AnLe] erstellt. Bei diesen Interviews wird der Fragebogen in verschiedene Themengebiete aufgeteilt. Dabei werden alle Fragen, die zu einem bestimmten Thema geh¨ oren, zusammengefasst. Dadurch k¨ onnen Ergebnisse f¨ ur die einzelnen Themen erhalten werden. Wie der Fragebogen in dieser Arbeit aufgebaut ist und welche Fragen gestellt werden, wird in Abschnitt 4.4 beschrieben.

4.2 Ziele der Interviews

F¨ ur die Entscheidung, welches MockUp-Tool verwendet werden soll, muss der Spezifikationsprozess betrachtet werden. Es muss untersucht werden, wie die GUI spezifiziert wird und welche Artefakte dabei erstellt werden. Artefakte sind zum Beispiel Dialoglandkarten, Feldlisten (Beschreibung der Felder eines Dialogs) und Aktionslisten (Beschreibung der Aktionen in einem Dialog). Die Entscheidung f¨ ur ein MockUp-Tool wird, wie in Kapitel 3 beschrieben, mit Hilfe einer modifizierten Variante der gewichteten Entscheidungsmatrix getroffen. Um die Entscheidungsmatrix aufzubauen, m¨ ussen Kriterien, die das MockUp-Tool erf¨ ullen muss, definiert werden. Das verwendete Entscheidungsverfahren verlangt auch eine Gewichtung der Kriterien und das Definieren von geeigneten Aggregations- und Be-dingungsformeln. Diese sollen ebenfalls mit Hilfe der Interviews gefunden werden.

Zusammenfassend ergeben sich folgende Ziele f¨ ur die Durchf¨ uhrung von Interviews. Es soll herausgefunden werden

• wie der Spezifikationsprozess von GUIs bei der Capgemini sd&m AG funktioniert und welche Werkzeuge und Methoden momentan daf¨ ur eingesetzt werden,

• wie die Entscheidungsmatrix aufgebaut werden soll

- welche Kriterien das MockUp-Tool erf¨ ullen soll,

- wie die Kriterien gewichtet werden sollen,

- welche Aggregations- und Bedingungsformeln die Kriterien besitzen sollen

• und wie der Spezifikationsprozess durch ein MockUp-Tool unterst¨ utzt werden kann.

4.3 Durchf¨ uhrung der Interviews

Insgesamt wurden 14 Personen befragt. Darunter befanden sich elf fachliche Designer und drei Usability Experten. Bei der Auswahl der Personen wurde Wert darauf gelegt, dass sie aus unterschiedlichen Projekten kommen. Damit wird sichergestellt, dass man sich f¨ ur ein MockUp-Tool entscheidet, welches f¨ ur viele Projekte geeignet ist. Die Interviews haben ca. 1-2 Stunden gedauert und wurden immer in einem pers¨ onlichen Gespr¨ ach durchgef¨ uhrt. Die Capgemini sd&m AG ist auf viele Standorte in Deutschland, ¨ Osterreich und

der Schweiz verteilt. Deshalb gibt es auch fachliche Designer und Usablity Experten, die in anderen Standorten arbeiten. Konnte man sich mit diesen Personen f¨ ur ein Interview nicht pers¨ onlich treffen, wurden in solchen F¨ allen die Interviews per Telefon durchgef¨ uhrt. F¨ ur die Durchf¨ uhrung der Interviews werden zwar Frageb¨ ogen (s. Abschnitt 4.4) verwendet, aber die Frageb¨ ogen werden den befragten Personen nicht ausgeh¨ andigt oder zugeschickt, sondern der Interviewer liest die Fragen selbst vor. So werden allen Personen die selben Fragen gestellt und die Befragten haben trotzdem die M¨ oglichkeit frei zu antworten. Auch k¨ onnen die Interviewten bei Unklarheiten fragen, ob sie die Frage richtig verstanden hat- ten.

4.4 Fragebogen zur Durchf¨ uhrung der Interviews

Zum Erreichen der in Abschnitt 4.2 definierten Ziele werden Interviews mit zwei verschiedenen Gruppen von Personen durchgef¨ uhrt. Zum einen werden fachliche Designer, welche ¨ uberwiegend Software Ingenieure sind, und zum anderen Usability Experten befragt. Durch die Befragung dieser beiden Personengruppen sollen jeweils unterschiedliche Ziele erreicht werden. Abh¨ angig davon m¨ ussen entsprechende Fragen formuliert werden. F¨ ur diese beiden Gruppen werden daher zwei verschiedene Frageb¨ ogen erstellt und zus¨ atzlich in verschiedene Themengebiete aufgeteilt.

Den fachlichen Designern werden Fragen aus den folgenden Themengebieten gestellt:

• GUI-Spezifikation bei der Capgemini sd&m AG

• Fragen bez¨ uglich der von Capgemini sd&m Research gelieferten Spezifikationsmethode

• Welche Ergebnisse werden am Ende vom MockUp-Tool erwartet?

• Was muss das MockUp-Tool sonst noch unterst¨ utzen?

• Fragen bez¨ uglich der Usability-Unterst¨ utzung

• Sonstiges

F¨ ur die Usability Experten sind zus¨ atzliche Fragen aus den folgenden Themengebieten vorbereitet:

• GUI-Spezifikation bei der Capgemini sd&m AG

• Fragen bez¨ uglich der Usability-Community

• Sonstiges

Mit diesen Themengebieten, die in den n¨ achsten Abschnitten n¨ aher beschrieben werden, lassen sich verschiedene Ziele erreichen.

4.4.1 Ziel: Spezifikationsprozess und verwendete Werkzeuge und Methoden

Mit den Fragen aus den Themengebieten, die in diesem Abschnitt beschrieben werden, bekommt man einen ¨ Uberblick ¨ uber den Spezifikationsprozess der Capgemini sd&m AG. Es

werden auch Fragen zu den verwendeten Werkzeugen und Methoden gestellt. Die verwendeten Werkzeuge werden bei der Evaluierung der Tools ber¨ ucksichtigt und dienen somit als Ausgangspunkt zur Marktanalyse, um geeignete MockUp-Tools zu finden.

GUI-Spezifikation bei der Capgemini sd&m AG

Dieser Bereich enth¨ alt Fragen, die sich speziell an die Situation der Spezifikation von grafischen Oberfl¨ achen bei der Capgemini sd&m AG richten. Hier wird beispielsweise die Anzahl der Dialoge bei typischen Capgemini sd&m-Projekten ermittelt und die Zeit, die man f¨ ur die Spezifikation zur Verf¨ ugung hat. Außerdem wird auch gefragt, welche Artefakte bei der Spezifikation von grafischen Bedienoberfl¨ achen erstellt werden m¨ ussen. Diese Fragen richten sich sowohl an die fachlichen Designer als auch an die Usability Experten.

4.4. Fragebogen zur Durchf¨ uhrung der Interviews 27

Die Fragen aus diesem Themengebiet werden auch an die Usability Experten gestellt, weil die befragten Usability Experten zur Zeit bei Capgemini sd&m GUIs spezifizieren beziehungsweise fr¨ uher GUIs spezifiziert haben.

Fragen bez¨ uglich der Usability-Community

Bei der Capgemini sd&m AG hat sich vor kurzer Zeit eine Usability-Community gegr¨ undet. Die Community befasst sich mit dem Thema der Gebrauchstauglichkeit von grafischen Bedienoberfl¨ achen. Fachliche Designer k¨ onnen sich, wenn sie eine GUI entwerfen m¨ ussen, die eine gute Usabiltiy bieten muss, an die Community wenden und sich dort Unterst¨ utzung holen. Die Fragen zu diesem Themengebiet werden nur den Usability-Experten gestellt, die Mitglieder der Usability-Community sind. Es wird hier gefragt, wie die Usability-Community die Spezifikation von GUIs unterst¨ utzt.

4.4.2 Ziel: Integration des MockUp-Tools in den Spezifikationsprozess

Mit den Fragen aus folgenden Themengebieten werden die W¨ unsche der Befragten zur Integration des MockUp-Tools in den Spezifikationsprozess und damit zur Integration in das Modellierungswerkzeug gesammelt. Dies dient als erste Anregung f¨ ur den Entwurf der technischen Integration, welche in den Kapiteln 6 und 7 beschrieben wird.

Fragen bez¨ uglich der von Capgemini sd&m Research gelieferten Spezifikationsmethode

Capgemini sd&m Research hat eine Spezifikationsmethodik zur Spezifikation von Softwaresystemen entwickelt. Darunter befindet sich auch eine Methode f¨ ur die Spezifikation grafischer Bedienoberfl¨ achen. Diese basiert auf die Verwendung des Modellierungswerkzeugs Enterprise Architect. Das MockUp-Tool hat daher in diesem Kontext nur Sinn, wenn es in den Enterprise Architect integriert werden kann. Durch die Fragen aus diesem Themengebiet soll gekl¨ art werden, wie die Integration des MockUp-Tools in die Spezifikationsmethodik von Capgemini sd&m Research und damit auch die Integration in den Enterprise Architect stattfinden kann. Außerdem soll ¨ uberpr¨ uft werden, ob die Art, die

GUI mit Hilfe eines MockUp-Tools zu spezifizieren, akzeptiert wird. Die Fragen dieses Themengebietes werden nur den fachlichen Designern gestellt.

Welche Ergebnisse werden am Ende vom MockUp-Tool erwartet? Dieses Gebiet befasst sich mit dem Thema, welche Ergebnisse der Endanwender vom MockUp-Tool erwartet. Hier soll ermittelt werden, welche T¨ atigkeiten im MockUp-Tool und welche im Modellierungswerkzeug durchgef¨ uhrt werden sollen. Es wird beispielsweise gefragt, ob es m¨ oglich sein muss im MockUp-Tool eine Dialoglandkarte und/oder eine Feldliste erstellen zu k¨ onnen.

4.4.3 Ziel: Kriterien f¨ ur die Evaluierung der MockUp-Tools finden

Die letzten drei Themengebiete dienen zum Aufbau des Kriterienkatalogs f¨ ur die Entscheidungsmatrix (s. Kaptitel 3). Es wird nach Kriterien, ihren Gewichtungen und dem Zusammenhang zwischen ihnen (den Bedingungs- und Aggregationsformeln) gesucht.

Was muss das MockUp-Tool sonst noch unterst¨ utzen?

Mit den Fragen aus diesem Bereich soll herausgefunden werden, wie das MockUp-Tool den fachlichen Designer beim Entwurf des GUI Layouts unterst¨ utzen soll. Es wird beispielsweise

gefragt, ob man mit dem MockUp-Tool eigene Widgets (beziehungsweise Widget-Gruppen) erstellen k¨ onnen soll, oder ob das Tool Templates mit Corporate Identity Vorgaben unterst¨ utzen soll.

Fragen bez¨ uglich der Usability-Unterst¨ utzung

Diese Fragen richten sich an die fachlichen Designer. Es soll herausgefunden werden, wie sich die fachlichen Designer eine Unterst¨ utzung zum Thema Usability w¨ unschen und wie die Usability-Community sie dabei unterst¨ utzen kann. Vor allem aber soll ermittelt werden, welche Kriterien das MockUp-Tool erf¨ ullen soll, um den fachlichen Designer beim Entwurf von benutzerfreundlichen Systemen zu unterst¨ utzen.

Sonstiges

Dieses Themengebiet ist f¨ ur Fragen, die zu keinem der oben genannten Themengebiete passen. Das sind zum Beispiel Fragen bez¨ uglich der Lizenz, die das MockUp-Tool haben soll beziehungsweise haben darf.

Die beiden Frageb¨ ogen sind im Anhang A zu finden.

4.5 Auswertung der Interviews

Da die Frageb¨ ogen und damit auch die Auswertung der Interviews sehr umfangreich sind werden nur die wichtigsten Ergebnisse vorgestellt. Eine ausf¨ uhrliche Auswertung befindet sich im Anhang B.

4.5.1 Ergebnisse: Spezifikationsprozess und verwendete Tools und Methoden

Der Spezifikationsprozess von grafischen Oberfl¨ achen bei der Capgemini sd&m AG beginnt meist damit, dass die Firma das Layout der zu entwickelnden Oberfl¨ ache entwirft. Falls es sich um gr¨ oßere Dialoge handelt, werden diese zusammen mit dem Kunden in Workshops verfeinert. Um die grafische Oberfl¨ ache zu finalisieren, wird ein Dokument (die Spezifikation der GUI) erstellt, das der Kunde abnehmen muss.

Um die Spezifikation der GUI auszuarbeiten, werden h¨ aufig neben dem Layout der GUI, auch einige andere Artefakte erstellt. Es werden beispielsweise Dialoglandkarten, Feldlisten und Aktionslisten erstellt. Dialoglandkarten sind Diagramme, die den Navigationsfluss zwischen entworfenen Dialogen beziehungsweise Dialogmasken veranschaulicht. Meist sind auf Dialoglandkarten Screenshots der Dialoge und Pfeile, die den ¨ Ubergang zwischen den

Dialogen darstellen, abgebildet. Feldlisten beschreiben die Dialogelemente und Aktionslisten das dynamische Verhalten der entworfenen GUI. Diese Artefakte sollen nach der von Capgemini sd&m Research entwickelten Spezifikationsmethode (siehe Kapitel 2.3) mit den Enterprise Architect erstellt werden. Anschließend generiert der Document Generator ⁵ aus dem Enterprise Architect die Spezifikation der Oberfl¨ ache.

Die gesamte Spezifikation eines zu entwerfenden Systems wird bei der Capgemini sd&m AG von mehreren Personen erstellt. Dabei m¨ ussen unter anderem Anforderungen an die Software definiert, Anwendungsf¨ alle formuliert und das Layout der GUI entworfen werden. Die T¨ atigkeiten zur Erstellung der Spezifikation werden meist fachlich auf die Personen

⁵ Der Document Generator ist ein von Capgemini sd&m Research entwickeltes Tool zum Generieren von Spezifikationen aus dem Enterprise Architect.

4.5. Auswertung der Interviews 29

aufgeteilt. Fachlich aufgeteilt bedeutet, dass eine Person nicht nur eine Art von T¨ atigkeiten aus¨ ubt, zum Beispiel das Entwerfen der grafischen Oberfl¨ ache, sondern einen gewissen Bereich der GUI zugewiesen bekommt und zu diesem Bereich die gesamte Spezifikation, mit Entwurf von Anwendungsf¨ allen, Entwurf der grafischen Oberfl¨ ache usw., erstellt. Aus diesem Grund kommt es selten vor, dass mehrere Personen am Entwurf der gleichen Dialoge arbeiten.

Zur Erstellung der Spezifikation von grafischen Oberfl¨ achen werden bei der Capgemini sd&m AG zur Zeit verschiedene Tools verwendet. Die verwendeten Tools sind Microsoft PowerPoint, Microsoft Word, Microsoft Excel, Microsoft Access, Microsoft Visio und Enterprise Architect. Der Enterprise Architect wird jedoch nur von wenigen Personen benutzt. Dies liegt daran, dass der Enterprise Architect erst vor kurzem eingef¨ uhrt worden ist und viele laufende Projekte es nicht mehr einsetzen konnten. Bei den zur Zeit verwendeten Tools handelt es sich nicht um richtige MockUp-Tools und es werden mit diesen Werkzeugen auch keine lauff¨ ahigen MockUps erstellt. Dennoch werden diese Tools in der vorliegenden Arbeit zusammen mit anderen Tools evaluiert. Falls w¨ ahrend der Spezifikationsphase ein Prototyp der GUI ben¨ otigt wird, erstellt man oft ein HTML-Prototyp. Viele fachliche Designer entwerfen die grafische Oberfl¨ ache auch auf Papier. Deswegen wird das Tool“ Papier auch zusammen mit anderen Tools bewertet. ”

Obwohl zur Zeit keine MockUp-Tools zum Entwurf der GUI verwendet werden, k¨ onnen sich viele Befragte vorstellen, hierf¨ ur k¨ unftig ein solches Hilfsmittel einzusetzen. Ein minimal h¨ oherer Aufwand zur bisherigen Arbeitsweise wird hier gerne in Kauf genommen. Das Tool m¨ usste jedoch ” gut“ sein. Nach Meinung der Befragten trifft dies zu, wenn es m¨ oglichst viele Kriterien des Kriterienkatalogs (der Entscheidungsmatrix) erf¨ ullt. Außerdem k¨ onnen MockUp-Tools bei der Durchf¨ uhrung von Usability-Tests behilflich sein. Das Thema Usability sollte nach Meinung der Befragten in einigen Projekten st¨ arker unterst¨ utzt werden. Das ist ein weiterer Grund f¨ ur den Einsatz von MockUp-Tools und l¨ asst vermuten, dass das in dieser Arbeit integrierte MockUp-Tool von vielen fachlichen Designern akzeptiert wird.

4.5.2 Ergebnisse: Integration des MockUp-Tools in den Spezifikationsprozess

Die meisten Befragten waren der Meinung, dass das MockUp-Tool nur zum Entwerfen des GUI Layouts und deren Interaktionen benutzt werden soll. F¨ ur die detaillierte Beschreibung der Dialoge (mit Feldliste, Aktionsliste, Dialoglandkarte, usw.) soll der Enterprise Architect benutzt werden. Um die Datentypen der Eingabefelder zu definieren, wird das fachliche Datenmodell ben¨ otigt, welches sich im Enterprise Architect befindet. Deswegen fanden es die meisten fachlichen Designer besser, wenn die Beschreibung der Oberfl¨ ache auch im Enterprise Architect bearbeitet wird. So kann man einfach auf das Datenmodell verweisen und muss die GUI-Spezifikation nicht ¨ andern, falls das Datenmodell ge¨ andert wird. Kann man jedoch im MockUp-Tool detaillierte Beschreibungen zu den Elementen eingeben, sollten diese in den Enterprise Architect ¨ ubernommen werden.

4.5.3 Ergebnisse: Kriterien f¨ ur die Evaluierung der MockUp-Tools finden

Im Folgenden befindet sich ein Ausschnitt der Auswertung der Interviews mit den wichtigsten Ergebnissen und den Folgerungen daraus. Diese Ergebnisse sind Einflussfaktoren f¨ ur den Aufbau des Kriterienkatalogs:

• Dialoglandkarten k¨ onnte man auch automatisch im Enterprise Architect erstellen, deshalb muss das MockUp-Tool die Erstellung von Dialoglandkarten nicht unterst¨ utzen.

• Die GUI-Spezifikation kann sich oft und zu jeder Phase in der Softwareentwicklung ¨ andern.

• Da sich die GUI-Spezifikation oft und zu jeder Phase in der Softwareentwicklung ¨ andern kann, sollte man die entworfene GUI vom MockUp-Tool in das Modellierungswerkzeug, und auch zur¨ uck, synchronisieren k¨ onnen.

• Dialoge beziehungsweise Dialogmasken werden selten von mehreren Personen bearbeitet. Eine Versionierung der St¨ ande w¨ are jedoch w¨ unschenswert, da sich die Spezifikation der grafischen Oberfl¨ ache zu jeder Phase der Softwareentwicklung ¨ andern kann. Deshalb wird verlangt, dass das Tool eine Versionierung der Dialogmasken unterst¨ utzt.

• Bei der Capgemini sd&m AG werden nur Microsoft Windows-Rechner verwendet. Deshalb muss das MockUp-Tool auf den Betriebssystem Microsoft Windows laufen.

• Die Dialoge werden oft zusammen mit dem Kunden entworfen. Dabei wird meist nur das Layout mit dem Kunden entwickelt und die detaillierte Beschreibung der GUI findet zu einem sp¨ ateren Zeitpunkt statt, da sich der Kunde meist nur f¨ ur das Verhalten und das Aussehen der grafischen Oberfl¨ ache interessiert und nicht wie diese technisch umgesetzt wird. Es muss deshalb mit dem Tool m¨ oglich sein, die Dialoge dynamisch (zuerst nur grob und sp¨ ater detailliert) modellieren zu k¨ onnen. Außerdem muss das Tool einfach zu bedienen sein, damit die GUI zusammen mit dem Kunden entworfen werden kann.

• F¨ ur Diskussionen mit dem Kunden, zum Finalisieren der GUI und zur Erzeugung der Spezifikation werden Screenshots der Dialogmasken ben¨ otigt, deshalb muss mit dem MockUp-Tool automatisch Screenshots generiert werden k¨ onnen.

• Es werden verschiedene Arten von Anwendungen bei der Capgemini sd&m AG entwickelt. Diese sind Desktop-, Web-, Mobile- und Multimedia-Anwendungen. Deshalb sollte das MockUp-Tool das Modellieren von verschiedenen Anwendungsarten unterst¨ utzen, wobei Desktop- und Webanwendungen in jeden Fall unterst¨ utzt werden m¨ ussen, da diese am h¨ augfisten entwickelt werden. Sch¨ on w¨ are es auch, wenn man zwischen den Anwendungsarten switchen k¨ onnte, das ist aber kein Pflichtkriterium.

• Da der (nicht technische) Unterschied zwischen Desktop- und Webanwendungen zur heutigen Zeit immer geringer wird, w¨ are es naheliegend ein Tool, das den Entwurf eines der beiden Arten unterst¨ utzt, f¨ ur den Entwurf beider Anwendungsarten zu benutzen. Um herauszufinden, ob dies sinnvoll ist, wurden die fachlichen Designer uber die (nicht technischen) Unterschiede zwischen Web- und Desktopanwendungen ¨

befragt. Sie wurden gebeten ihre Meinung zur Idee, nur ein Tool zu verwenden, zu ¨ außern. Aus den Interviews folgt, dass es immer noch Unterschiede beim Design zwischen den beiden Anwendungsarten gibt und es nicht erw¨ unscht ist, ein Tool zu benutzen, welches nur eine der beiden Arten unterst¨ utzt.

• Aus der Befragung der fachlichen Designer ergibt sich, dass Anwendungen oft verschiedene Sprachen unterst¨ utzen m¨ ussen. Beim Entwurf solcher Anwendungen w¨ urde es dem fachlichen Designer helfen, wenn er im MockUp-Tool zwischen verschiedenen Sprachen umschalten k¨ onnte. Doch ist dieses Feature nicht zwingend notwendig, da die GUI meist nur einmal und in nur einer Sprache spezifiziert wird. Falls sich