Integration von MockUp-Konzepten in die Spezifikation grafischer Bedienoberflächen

Inhaltsverzeichnis

1 Einleitung
1.1 Motivation
1.2 Problemstellung
1.3 Gliederung der Arbeit

2 Integration von MockUp-Konzepten in das Vorgehensmodell von Ent­wicklungsprojekten
2.1 Was sind MockUp-Konzepte?
2.2 Das Vorgehensmodell der Capgemini sd&m AG
2.3 Die Spezifikationsmethodik von Capgemini sd&m Research
2.4 Enterprise Architect in der Spezifikationsphase
2.5 Abgrenzung zu verwandten Arbeiten
2.5.1 Methoden und Werkzeuge für das Prototyping und ihre Integration .
2.5.2 Vorgehensweisen und Werkzeuge für ein Ineinandergreifen von Mo­dellierung und Prototyping

3 Entscheidungsverfahren zur Auswahl des MockUp-Tools
3.1 Allgemeine Entscheidungsverfahren
3.2 Eigenes Entscheidungsverfahren

4 Analyse des Spezifikationsprozesses von grafischen Oberflächen und Analyse der Anforderungen von MockUp-Tools
4.1 Vorgehen
4.2 Ziele der Interviews
4.3 Durchfuührung der Interviews
4.4 Fragebogen zur Durchführung der Interviews
4.4.1 Ziel: Spezifikationsprozess und verwendete Werkzeuge und Methoden
4.4.2 Ziel: Integration des MockUp-Tools in den Spezifikationsprozess ...
4.4.3 Ziel: Kriterien für die Evaluierung der MockUp-Tools finden
4.5 Auswertung der Interviews
4.5.1 Ergebnisse: Spezifikationsprozess und verwendete Tools und Methoden
4.5.2 Ergebnisse: Integration des MockUp-Tools in den Spezifikationsprozess
4.5.3 Ergebnisse: Kriterien für die Evaluierung der MockUp-Tools finden .

5 Evaluierung der MockUp-Tools
5.1 Aufbau der Entscheidungsmatrix
5.1.1 Die Kriterien
5.1.2 Gewichtung, Bedingungsformeln und Aggregationsformeln der Kri­terien
5.2 Arten von MockUp-Tools
5.3 Ergebnisse der Evaluierung
5.4 Entscheidung

6 Architektur zur Integration eines MockUp-Tools in ein Modellierungs­werkzeug
6.1 Analyse
6.1.1 Anforderungen an die Architektur
6.1.2 Anwendungsfalle
6.1.2.1 Anwendungsfall - MockUp importieren
6.1.2.2 Anwendungsfall - MockUp editieren
6.1.2.3 Anwendungsfall - MockUp exportieren
6.2 Die entworfene Architektur
6.2.1 Komponenten
6.2.2 Das Common Dialog Model
6.2.3 Modelltransformationen zur Synchronisation der Daten
6.2.4 Vorteile der entworfenen Architektur

7 Technische Umsetzung der entworfenen Architektur
7.1 Technische Grundlagen
7.1.1 Balsamiq Mockups
7.1.2 Enterprise Architect
7.2 Verwendete Programmiersprachen und Technologien
7.3 Implementierung
7.3.1 Implementierung der MockUp-Komponente
7.3.2 Implementierung der Modellierungs-Komponente
7.3.3 Implementierung der Synchronisations-Komponente
7.4 Installer für das entwickelte System

8 Einsatz und Erweiterbarkeit des entwickelten Systems
8.1 Installation des Systems
8.2 Szenarien zum Einsatz des Systems
8.2.1 Erstellen eines neuen MockUps
8.2.2 Editieren eines MockUps
8.2.3 Exportieren eines MockUps
8.2.4 Importieren eines MockUps
8.3 Szenarien zum Erweitern des Systems
8.3.1 MockUp-Tool wechseln
8.3.2 MockUp-Tool hinzufügen
8.3.3 Modellierungswerkzeug wechseln

9 Zusammenfassung und Ausblick

A Fragebogen
A.1 Fragebogen für die fachliche Designer
A.2 Fragebogen für die Usability Experten

B Auswertung der Interviews

C Kriterienkatalog

D Entscheidungsmatrix

E Sequenzdiagramme
E.1 MockUp exportieren
E. 2 MockUp importieren

F XML-Schemas
F. 1 XML-Schema vom Common Dialog Model
F.2 XML-Schema vom BQ-xml
F.3 XML-Schema vom EA-xml

Glossar

Abbildungsverzeichnis

Tabellenverzeichnis

Listings

Literaturverzeichnis

1. Einleitung

1.1 Motivation

Die Qualität einer Software wird schnell mit dem Verständnis, dem Aussehen und dem Workflow ihrer grafischen Bedienoberflache (engl. Graphical User Interface - GUI) gleich­gesetzt. Der Grund hierfär ist, dass der Benutzer meist nur die GUI einer Software zu sehen bekommt und die grafische Oberfläche somit der Teil der Anwendung ist, mit dem der Benutzer direkt konfrontiert wird. Je benutzerfreundlicher sie ist, umso besser schatzt der Benutzer die Qualität der Software ein. Deshalb ist es umso wichtiger, dass die Dialoge und der Arbeits-Workflow einer Anwendung frähzeitig nach den Wunschen des Kunden definiert und gestaltet werden. Fur den Entwurf der grafischen Oberfläche ist der fachliche Designer zustandig. Er konnte hierfär verschiedene Programme verwenden. Zum Zeichnen des Layouts einer Anwendung kännte 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ählt“ und er nicht sieht, wie er damit arbeiten kann.

Ahnliche Probleme befinden sich auch außerhalb der Softwareentwicklung. Beispielsweise beim Kauf einer Käche ist folgende Situation vorstellbar: Der Käufer beschreibt dem Ver­käufer welche Küche er haben mochte, woraufhin der Verkäufer einen statischen Bauplan der Käche zeichnet. Aus Sicht des Käufers ist es jedoch anschaulicher, die Käche in 3D präsentiert zu bekommen, damit er sich eine bessere Vorstellung in den eigenen Räumen machen kann. Die Entscheidungsfindung des Kaufers, ob er die Käche kaufen mochte und welche Kuche er nimmt, wird so erheblich erleichtert.

Die Situation eines Kächenkaufs lässt sich leicht auf den Entwurf grafischer Oberflachen äbertragen: Es wäre sicher hilfreich, sowohl fär den Kunden als auch fär den fachlichen Designer, schon beim Entwurf der GUI durch MockUp-Konzepte zu erleben, wie die Soft­ware sich später präsentiert. Dies erleichtert das frähzeitige Auffinden von Designfehlern, Usability-Problematiken und fehlende Funktionalitaäten. GUI-MockUps sind Prototypen der Oberfläche, die ihr Layout visualisieren und ihr Verhalten simulieren, ohne dabei die dahinter steckende fachliche Funktionalitaät zu implementieren.

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 grafi­scher Bedienoberflachen.

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

Die MockUp-Konzepte sollen den fachlichen Designer beim Entwurf der grafischen Ober­flüche unterstützen. Hierzu soll anstelle der üblichen Zeichenwerkzeuge, wie beispielswei­se Microsoft PowerPoint oder Microsoft Visio, ein MockUp-Tool eingesetzt werden. Der Vorteil liegt, wie oben beschrieben, darin, frühzeitig Lücken in der Spezifikation und De­sign zu erkennen. Durch ein MockUp-Tool koünnen auch Probleme rund um die Usability, das heißt die Gebrauchstauglichkeit und Benutzerfreundlichkeit von Programmen, bes­ser gelüost werden. Es werden aber auch technische Einschraünkungen schneller ersichtlich, wie zum Beispiel Einschraünkungen durch die Kunden-Bildschirmauflüosung. Dies kann ein PowerPoint-Bild hingegen nicht bieten.

Zur Erstellung der Spezifikation von grafischen Oberflüchen 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 Oberflachen unterstützt 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 Kri­terien, die das MockUp-Tool erfüllen muss. Um diese Kriterien zu definieren, werden Inter­views mit Software Ingenieuren (fachliche Designer) und Usability Experten durchgeführt. Die Ergebnisse der Interviews sind in Kapitel 4 zu finden.

In Kapitel 5 wird die Evaluierung der MockUp-Tools beschrieben. Dabei werden die eva­luierten 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 erlautert wird.

Die hier vorgestellte Architektur wurde für 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üglichen Wei­terführung dieser Arbeit.

2. Integration von MockUp-Konzepten in das Vorgehensmodell von Entwicklungsprojekten

In diesem Kapitel wird analysiert, wie der Spezifikationsprozess von grafischen Oberflächen durch MockUp-Konzepte unterstützt werden kann. Es wird zunächst definiert, was unter MockUp-Konzepte verstanden wird und danach untersucht, wie die Capgemini sd&m AG bei der Durchführung von Softwareentwicklungsprojekten vorgeht, wie die Systemspezifi­kation dort erstellt wird und welche Werkzeuge hierfür 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 Oberflachen durch die Integration von MockUp-Konzepten in den Spezifikationsprozess unterstuützt werden. Unter MockUp-Konzepten wird in dieser Arbeit das Erstellen von MockUps der grafischen Oberfläche verstanden, mit dem Ziel, die GUI zu entwerfen, den Arbeitswork- flow zu definieren und diesen zu testen. MockUps sind Prototypen der Bedienoberfläche, die das Layout der GUI visualisieren und ihr Verhalten simulieren, ohne dabei die fachliche Funktionalität zu implementieren.

MockUps künnen nicht nur beim Entwerfen der GUI eingesetzt werden, sondern auch in anderen Phasen der Softwareentwicklung behilflich sein. Sie künnten zum Beispiel zur Durchführung von Usability Tests benutzt werden. Dadurch kann schon sehr früh im Soft­wareentwicklungsprojekt die Benutzerfreundlichkeit der Software getestet und verbessert werden. Außerdem künnen Prototypen der GUI beim Festlegen und Validieren von Anfor­derungen helfen. Nach Ian Sommerville [Somm96] gibt es einige Experimente, die belegen, dass der Einsatz von Prototypen in den frühen Phasen der Softwareentwicklung Probleme bei der Spezifikation der Anforderungen und Kosten für die Softwareentwicklung verrin­gern kann.

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

- Missverstandnisse zwischen Softwareentwicklern und Endbenutzern können vermie­den werden.
- Fehlende Funktionalitöten der Software können früh entdeckt werden.
- Die Benutzerfreundlichkeit kann erhöht werden, indem die für den Endbenutzer kom­pliziert erscheinenden Interaktionen mit dem System frühzeitig identifiziert werden.
- Inkonsistente Anforderungen können gefunden werden.

Diese Vorteile gewinnt man, indem Kunden beziehungsweise Endbenutzer den Prototypen testen und Feedback geben. Wenn man von Prototypen einer Software spricht, muss zwi­schen zwei Arten unterschieden werden: Evolutionare Prototypen und Wegwerf-Prototypen (vgl. [Somm96]). Unter einem evolutionaren Prototypen versteht man eine Art inkremen­telle Implementierung des Prototypen. Dabei wird mit der Implementierung schon in der Spezifikationsphase begonnen und diese Stuck för Stöck weiterentwickelt. Diese Art von Prototypen wird eingesetzt, wenn die Anforderungen an die Anwendung anfangs sehr un­klar sind. Je präziser die Anforderungen werden, umso mehr werden diese in die Software implementiert. Das Ziel von evolutionaren Prototypen ist es, am Ende eine Implementie­rung der kompletten Anwendung zu erhalten. Ein Wegwerf-Prototyp hingegen, wird nur zum Definieren und Validieren von Anforderungen benutzt und anschließend nicht wei­terverwendet. 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öche, 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öchen integriert werden. In diesem Abschnitt wird untersucht, wie die Capgemini sd&m AG bei der Durchföhrung von Projekten vorgeht und wie und wann die Spezifika­tion der grafischen Oberflöchen erstellt wird. Dadurch wird ersichtilich, wie diese durch MockUp-Konzepte unterstötzt 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 taglichen Projektarbeit dienen. Abbildung 2.1 zeigt die Phasen dieses Projektmodells.

Abbildung in dieser Leseprobe nicht enthalten

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

Das Capgemini sd&m Projektmodell besteht aus den vier Phasen Angebot, Initialisierung, Projektdurchführung und Abschluss, die im Weiteren naher erlautert 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 Projekt­durchführung geplant und vorbereitet. Diese Phase endet mit einem Kickoff, bei dem alle Voraussetzungen für die Durchführung des Projektes geprüft werden.
- Projektdurchführung: Die Phase der Projektdurchführung beinhaltet Prozesse, die für die Erstellung der Spezifikation bis hin zur Inbetriebnahme eines Projektauf­trages benütigt werden.
- Abschluss: Jedes Projekt hat einen Abschluss. Dieser dient zur Übergabe des Pro­jektes an den Kunden. Hier wird auch das gelernte Wissen aus dem Projekt doku­mentiert und mügliche weitere Folgeprojekte vorbereitet.

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

Spezifikation

Inbetriebnahme

Abbildung 2.2: idealtypisches Wasserfall-Modell [SDMP]

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, Integra­tion und Inbetriebnahme. Die vorliegende Arbeit soll die Spezifikationsphase unterstuützen.

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ünnen muss und was es nicht künnen soll. Als Ergebnis dieser Pha­se erhaült man die Spezifikation des Systems. Anhand dieses Dokuments wird das fertige System auf die Erfüllung 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älle und die Bedienoberfläche 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äher 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 Softwaresys­tems. 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 Funktionalitat des Softwaresystems mit dem Kunden,
- als Basis fur den technischen Entwurf des Systems und damit auch dessen Imple­mentierung,
- als Basis fur die Erzeugung von Testfällen und deren Planung,
- als Basis fuär Aufwandsschaätzungen 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 Verfugung (s. Abbildung 2.3).

Abbildung in dieser Leseprobe nicht enthalten

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ässen.
- 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.
- Process: Der Bereich Process beschreibt das Vorgehen bei der Erstellung der Spe­zifikation. Dabei werden die erforderlichen Schritte zur Erstellung der Spezifikation festgelegt und detailliert beschrieben.
- Tools: Dieser Bereich beschreibt, welches Tool zur Erstellung der Spezifikation ver­wendet werden können. Die Capgemini sd&m AG setzt das Modellierungswerkzeug Enterprise Architect (EA) ein. Der EA kann durch Plugins erweitert und damit indi­viduell konfiguriert werden. Bei der Capgemini sd&m AG wurden einige EA Plugins entwickelt, um die Erstellung der Spezifikation zu unterstötzen.

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

2.4 Enterprise Architect in der Spezifikationsphase

Die Capgemini sd&m AG verwendet bei der Durchföhrung von Softwareentwicklungspro­jekten das Modellierungswerkzeug Enterprise Architect. Der EA ist ein sehr machtiges Tool und kann in verschiedenen Phasen der Softwareentwicklung benutzt werden. Es kann beispielsweise bei der Anforderungsanalyse, bei der Erzeugung der Spezifikation und so­gar bei der Implementierung der Software eingesetzt werden. Abbildung 2.4 zeigt einen Screenshot vom Enterprise Architect.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.4: Der Enterprise Architect

Mit dem EA können 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 konnen. Die Zeichenflache fur die Diagramme bildet den zweiten Teil (auf dem Bild in der Mitte zu sehen). Zum Zeichen koönnen die Elemente aus der Toolbox in das Diagramm gezogen werden. Im rechten Teil der Bedienoberflaöche vom Enterprise Architect wird der Project Browser angezeigt, der alle Elemente des Mo­dells 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öglichkeit individuell konfiguriert und erweitert zu werden. Sparx Systems stellt für die Erweiterbarkeit eine API zur Verfügung (siehe Kapitel 7.1.2).

Das UML Modell, in dem der Enterprise Architect die Daten speichert, kann an die eige­nen 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önnen auch grafische Oberflüchen entworfen werden, indem das Layout gezeichnet und ihre Elemente beschrieben werden. Das SMT stellt hier­für einige Widgets zur Verfugung. Auf Abbildung 2.5 ist zu sehen, wie der SMT zum Entwerfen der GUI eingesetzt wird.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.5: Specification Modeling Toolkit

In der Toolbox auf der linken Seite befinden sich die Widgets zum Entwerfen der GUI. In der Mitte wird das Layout gezeichnet. Für jedes GUI-Element wird im Project Browser ein Objekt angezeigt. Um die grafische Oberflüche zu beschreiben, künnen 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 Sys­tems zur Verfügung 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 Oberflache erstellt.

In dieser Arbeit soll der Entwurf von grafischen Oberflüchen durch die Integration von MockUp-Konzepten unterstuützt werden, indem die Bedienoberflaüche in einem MockUp-

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önnen. Beim Impor­tieren 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 wer­den. Das SMT wird also nicht durch das MockUp-Tool ersetzt, sondern zum Erzeugen des Objektbaumes benutzt. Dadurch wird es möglich, 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 Un­terschiede zu dieser Arbeit vorgestellt. Diese sind:

- Die Arbeit Methoden und Werkzeuge für das Prototyping und ihre Integration von G. Pomberger, W. Pree und A. Stritzinger, welche 1992 erschienen ist [PoPS92].
- Die Arbeit Vorgehensweisen und Werkzeuge fur ein Ineinandergreifen von Modellie­rung und Prototyping von Josef Voss. Diese ist 1997 veröffentlicht worden [Voss97].

2.5.1 Methoden und Werkzeuge für das Prototyping und ihre Integra­tion

Bei dem Paper Methoden und Werkzeuge für das Prototyping und ihre Integration geht es um die Integration von Prototyping-Methoden in den Entwicklungsprozess von Softwa­resystemen. Dabei umfasst Prototyping alle Tatigkeiten zur Erstellung von Prototypen, welche in diesem Paper als ein ausfuöhrbares Modell mit wesentlichen Eigenschaften des Zielsystems, das Grundlage för die Systemspezifikation und die Kommunikation zwischen Kunden und Entwicklern unterstötzt“ [PoPS92] verstanden werden.

Das Paper stellt ein Konzept för eine Prototyp-orientierte Softwareentwicklung vor. Dieses Konzept erweitert die klassisch sequentielle Softwareentwicklungsmethode um die Erstel­lung von Prototypen för die grafische Bedienoberflöche und Prototypen för die Architektur (siehe Abbildung 2.6).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2.6: Prototyp-orientierte Softwareentwicklung [PoPS92]

Für dieses Konzept wurden einige Werkzeuge entwickelt, welche ebenfalls beschrieben wer­den. Es wurden unter anderem ein Tool zur Erstellung von GUI-Prototypen und eins zur Erstellung von Architekturprototypen entwickelt, welche detailliert erklürt werden.

Der Unterschied zu der vorliegenden Arbeit ist, dass in diesem Paper eine Softwareentwick­lungsmethode entwickelt wurde, welche die herkömmliche Methode durch den Einsatz von Prototypen erweitert. In der vorliegenden Arbeit werden MockUp-Konzepte in einen be­stehenden 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 beruücksichtigt.

2.5.2 Vorgehensweisen und Werkzeuge für ein Ineinandergreifen von Modellierung und Prototyping

In dem Paper Vorgehensweisen und Werkzeuge für 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üche 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 Tatigkeiten model­liert, welche der Benutzer mit dem System ausführen konnen soll.
- Objektmodell (OOA-Modell): Das Objektmodell wird mit einer objektorientier­ten 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 Navigationsmoglichkeiten vorhanden sein müssen 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 be­trachtet.

Zum Erstellen von Prototypen künnen verschiedene Techniken verwendet werden. Es kün- nen Nutzungsszenarien, Oberflüchenskizzen, Oberflüchenprototypen oder eine erste Versi­on des Systems in der Zielumgebung erstellt werden. Durch den Einsatz dieser Techniken kann die Erstellung der oben beschriebenen Modelle unterstützt werden, wie Abbildung 2.7 zeigt. Dieser Zusammenhang zwischen Prototypen und Modellen wird im Paper anhand eines Beispiels beschrieben.

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

In der vorliegenden Arbeit werden Oberflächenprototypen betrachtet. Es soll mit Hilfe eines MockUp-Tools die GUI entworfen werden und mit diesen MockUps die Spezifikati­on unterstätzt werden. Es wird also hier, ähnlich wie beim Paper Vorgehensweisen und Werkzeuge fUr 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än­gige Entscheidungsverfahren, die zur Auswahl des Tools benutzt werden kännten, und das verwendete Verfahren beschrieben.

3.1 Allgemeine Entscheidungsverfahren

Um das MockUp-Tool in den Spezifikationsprozess gut integrieren zu können, ist es wichtig ein geeignetes Tool zu finden. Es existieren viele Tools, mit denen GUIs entworfen werden kännen. Die Aufgabe ist nun, aus diesen verschiedenen Tools das richtige auszuwahlen. Es gibt einige Entscheidungsmethoden, die bei der Entscheidungsfindung in verschiedenen Bereichen und Situationen unterstätzen kännen. Diese Methoden kännen auch zur Aus­wahl eines MockUp-Tools behilflich sein. Man unterscheidet bei diesen Verfahren zwischen Entscheidungsalternativen und Entscheidungskriterien. Entscheidungsalternativen sind die verschiedenen Moglichkeiten, fär die man sich entscheiden kann. Ziel ist, sich am Ende fär eine Alternative zu entscheiden. Dabei konnen gewisse Kriterien die Entscheidung beein­flussen, diese werden Entscheidungskriterien genannt. In der vorliegenden Arbeit sind die MockUp-Tools die Entscheidungsalternativen und die Anforderungen, die das Tool erfuällen soll, sind die Entscheidungskriterien. Die Art und Weise, wie diese Entscheidungskriteri­en 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 naäher erlaäutert werden. 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übergestellt. Diese Methode eignet sich sehr gut, um einen Überblick über die Ent­scheidungssituation zu bekommen. Sie liefert aber kein eindeutiges Ergebnis. Bei dieser Methode versucht man so viele Informationen wie möglich über die Entscheidungssitua­tion zu bekommen [Senf]. PMI

Beim PMI, ebenfalls nach Edward de Bono, werden alle positiven und negativen Auswir­kungen der Entscheidungsalternativen betrachtet und in verschiedenen Listen eingetragen. Neben den Listen „Positiv“ und „Negativ“ gibt es die Liste „Interessant“, die für Auswirkun­gen, die weder negativ noch positiv sind, gedacht ist. Für alle Entscheidungsalternativen werden diese drei Listen aufgebaut, um damit eine Entscheidung treffen zu künnen. Auch diese Methode liefert kein eindeutiges Ergebnis, sondern dient dazu, Klarheit über 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, wel­ches jederzeit nachvollzogen werden kann. Bei der Entscheidungsmatrix werden zunächst Kriterien für die Entscheidungsfindung gesammelt. Dabei muss beachtet werden, dass die Kriterien gleich formuliert sind. Soll zum Beispiel gelten, dass eine Alternative umso bes­ser ist, je mehr Kriterien sie erfüllt, dann müssen alle Kriterien positiv formuliert werden. Nach dem Sammeln und Ausformulieren der Kriterien werden diese in einer Tabelle den Entscheidungsalternativen gegenübergestellt. In dieser Tabelle künnen fur 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üllt wird und 1 Punkt, dass es gar nicht erfüllt wird. Diese Punkte werden für jede Alternative zu einer Gesamtpunktzahl addiert. Die Entscheidung fallt auf die Alternative mit den hüchs- ten Punkten. Ein Beispiel für eine Entscheidungsmatrix ist in Tabelle 3.1 zu sehen, bei der es um die Entscheidung geht, welches Jobangebot man annehmen soll. Samson GmbH erhült hier am meisten Punkte, weshalb die Entscheidung auch auf diese Alternative füllt [Senf].

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.1: Beispiel: Entscheidungsmatrix^[1]

Gewichtete Entscheidungsmatrix

Mit der oben vorgestellten Entscheidungsmatrix erhält man durch das Festlegen von Kri­terien, die die Entscheidungsalternative erfällen muss, meist ein klares Ergebnis. Es wird jedoch nicht die Wichtigkeit der Kriterien beräcksichtigt. Oft gibt es aber Kriterien, die unterschiedlich gewichtet werden mässen. Im Beispiel der Entscheidung fär ein Jobange­bot kännte es beispielsweise wichtiger sein Spaß an der Arbeit zu haben als viel Urlaub zu erhalten. In solchen Fällen hilft die gewichtete Entscheidungsmatrix. Bei dieser Metho­de werden die Kriterien mittels eines Prozentsatzes gewichtet, der in die Berechnung der Gesamtpunktzahl der Alternative einfließt (s. Tabelle 3.2).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.2: Beispiel: gewichtete Entscheidungsmatrix2

Fär die Bestimmung der Gesamtpunktzahl werden die Punkte fär 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]. N utzwertanalyse

Die Nutzwertanalyse hat eine ähnliche Vorgehensweise wie die gewichtete Entscheidungs­matrix. Auch hier werden im ersten Schritt Kriterien fär die Entscheidungsfindung gesam­melt. Jedoch werden nicht alle Kriterien betrachtet, sondern zum Beispiel nur die ca. fänf wichtigsten. Anschließend werden diese Kriterien gewichtet, wobei die Gewichtung rech­nerisch ermittelt wird. Dazu werden die Kriterien in einer Tabelle zueinander in Bezug gestellt (siehe Tabelle 3.3).

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.3: Nutzwertanalyse - Bewertung der Kriterien^{[2] [3]}

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ür jedes Kriterium addiert und in die Spalte „erhaltene Punkte“ eingetragen. Wenn man diese erhaltenen Punkte prozentual angibt, bekommt man die Gewichtung der Kriterien.

Ähnlich zur Entscheidungsmatrix werden auch bei der Nutzwertanalyse die Kriterien den Entscheidungsalternativen gegenübergestellt und bewertet. Im Beispiel auf Tabelle 3.4 werden Punkte zwischen 1 und 7 vergeben. Die Bewertung der Alternativen steht in der Spalte „Zielerfüllung“. Der Zielerfüllungswert wird mit der Gewichtung multipliziert und in die Spalte „Nutzwert“ eingetragen. Äddiert man diese Werte für jede Alternative, erhalt man ihren gesamten Nutzwert. Die Entscheidung fallt dabei auf die Alternative mit dem hüchsten (Nutz-)Wert. Im Beispiel in Tabelle 3.4 ist das die Alternative B [Nikl04].

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.4: Beispiel: Nutzwertanalyse^[4]

3.2 Eigenes Entscheidungsverfahren

Für die Auswahl des MockUp-Tools wird eine modifizierte Version der gewichteten Ent­scheidungsmatrix verwendet. Die Entscheidungsalternativen sind die MockUp-Tools und die Entscheidungskriterien die Anforderungen, die das Tool erfüllen soll.

In der vorliegenden Arbeit wird zwischen atomaren Kriterien und Kriterien-Gruppen un­terschieden. Eine Kriterien-Gruppe ist eine Aggregation von mehreren atomaren Kriterien. Es koünnen auch mehrere Kriterien-Gruppen zu einer Gruppe zusammengefasst werden. Dadurch kann die Gruppierung von Kriterien eine beliebige Tiefe erreichen. Die gesam­te Entscheidungsmatrix besteht aus mehreren atomaren Kriterien und Kriterien-Gruppen und wird in dieser Arbeit ebenfalls als eine Gruppe gesehen. Dadurch kann man das Ge­samtergebnis der Matrix schnell und einfach am Ergebnis der gesamten Gruppe ablesen.

Bei der Entscheidung für ein MockUp-Tool muss die Wichtigkeit der Anforderungen (be­ziehungsweise Kriterien) beachtet werden. Dies wird mit einer Gewichtung der Kriterien erreicht. Die Gewichtung zeigt dabei den prozentualen Anteil des Kriteriums innerhalb einer Gruppe. Folglich bildet die Summe der Prozentsätze innerhalb einer Gruppe immer 100%.

Durch die Gruppierung von Kriterien ändert sich gegenäber der herkämmlichen gewich­teten Entscheidungsmatrix die Berechnung der Gesamtpunkte der Alternativen. Es wer­den weiterhin fär jede Alternative beziehungsweise jedes Tool Punkte fär 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ällt und 6 Punkte, dass es sie optimal erfällt. Da nur die atomaren Kriterien bewertet werden, mässen die Punkte fär die Kriterien-Gruppen berechnet werden. Dafär werden Aggregati­onsformeln verwendet, mit denen die gewichteten Punkte innerhalb einer Gruppe zusam­mengefasst werden. Beispiele fär 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ässen, anders als die optio­nalen Kriterien, vom MockUp-Tool in jedem Fall erfuällt werden. Einige Anforderungen an das MockUp-Tool können unterschiedlich gut durch alternative Unterkriterien erfällt werden. Die Kriterienarten kännen auch kombiniert auftreten: Zum Beispiel kann ein Pflicht-Kriterium durch unterschiedliche alternative Unterkriterien erfällt werden. In der Entscheidungsmatrix fär die Auswahl des MockUp-Tools werden diese Arten durch Be­dingungsformeln repräsentiert. 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ällt worden ist. Bei den atomaren Kriterien gibt die Bedingungsformel an, welche Mindestpunkte ein Kriterium haben muss. Die Formel „>2“ ist ein Beispiel fär eine Bedingungsformel eines atomaren Kriteriums, das mindestens 3 Punkte erhalten muss. Bei den Kriterien-Gruppen gibt die Bedingungsformel an, welche Kriterien erfällt werden mässen und welche optional sind. In Tabelle 3.5 ist der Aufbau der Entscheidungsmatrix dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.5: Aufbau der Entscheidungsmatrix fär die MockUp-Tools

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.

Die bei der Evaluierung vergebenen Bewertungen stehen in der Spalte „Punkte“. Punkte werden hier nur für atomare Kriterien eingetragen und für 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üllt worden ist, sieht man in der Spalte „Ergebnis Bedingungsformel“, in der immer ein boolscher Wert steht. In Tabelle 3.6 ist ein Beispiel für eine Entscheidungsmatrix mit zwei MockUp-Tools zu sehen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 3.6: Beispiel: Entscheidungsmatrix für die MockUp-Tools

Für 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 hoüchste Bewertung der Gruppe zu selektieren.

Im Beispiel wird das Kriterium „A3“ beim „MockUp-Tool 1“, wie man am Ergebnis der Bedingungsformel sieht, nicht erfüllt. 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 „MockUp-Tool 2“ wird das Kriterium ,,A2“ nicht erfüllt. 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üllt werden. Es erhält darum die Punkte seines Unterkriteriums, das am besten bewertet wurde. Beim „MockUp-Tool 1“ ist das das Kriterium ,,B2“ und beim „MockUp-Tool 2“ das Kriterium ,,B1“. Die Punkte dieser Oberkriterien weichen in Tabelle 3.6 von den Unterkriterien ab, da die Gewichtung der Gruppe schon berücksichtigt wurde.

Insgesamt bekommt „Mockup-Tool 1“ die meisten Punkte, doch wird die Bedingung der gesamten Entscheidungsmatrix bei diesem Tool nicht erfüllt. Dadurch ist der Gewinner
dieser Entscheidungsmatrix „Mocküp-Tool 2“, obwohl dieses Tool weniger Punkte erhal­ten hat.

Das gewählte Entscheidungsverfahren für die Auswahl des Mocküp-Tools benötigt Krite­rien, die das Mocküp-Tool erfüllen muss. Zusätzlich müssen diese Kriterien gewichtet und geeignete Aggregations- und Bedingungsformeln definiert werden. Zur Definitionsfindung werden Endanwender interviewt.

4. Analyse des Spezifikationsprozesses von grafischen Oberflachen und Analyse der Anforderungen von MockUp-Tools

Dieses Kapitel befasst sich mit der Analyse des Spezifikationsprozesses von grafischen Oberflächen 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 wer­den und sie beim Spezifikationsprozess von grafischen Oberflachen bestmöglich unterstät­zen. Um zu entscheiden, welches Tool den Designer am besten unterstätzt, werden Krite­rien beziehungsweise Anforderungen an das Tool definiert. Dabei werden Interviews mit fachlichen Designern durchgefährt, wobei es sich meist um Software Ingenieure handelt.

Neben den fachlichen Designern werden auch Usability Experten interviewt. Die Gebrauchs­tauglichkeit einer Software gewinnt in der Softwareentwicklung in der heutigen Zeit an Bedeutung und wird immer mehr zu einer Qulitatseigenschaft [Nebe09]. Der Grund da- fär ist, dass die Benutzer mit der grafischen Oberfläche direkt interagieren und schnell die Qualität einer Software mit dem Verständnis, dem Aussehen und dem Workflow einer grafischen Bedienoberflaäche gleichsetzen. Umso wichtiger ist es, dass die Dialoge und der Arbeits-Workflow einer Anwendung frähzeitig nach den Bedärfnissen des Kunden definiert und in der frähen Phase der Spezifikation durch Usability Tests evaluiert werden. Im Hin­blick auf die Unterstuätzung von Usability Tests ergeben sich zusaätzliche Anforderungen, die durch Interviews mit Usability Experten gefunden werden sollen. Interviewart

Es gibt verschiedene Arten von Interviews. Man unterscheidet zwischen strukturierten, un­strukturierten und semi-strukturierten Interviews [AnLe]. Unstrukturierte Interviews ge­ben keine Vorgaben bei der Durchfuährung der Interviews. Hier passt sich der Interviewer der Situation und dem Gespraächsverlauf 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ögen durchgeführt. 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üllt den Fragebogen selbst aus. Bei Unklarheiten hat der Befragte, anders als beim unstrukturierten Interview, keine Möglichkeit den Interviewer zu fragen, ob er die Frage richtig verstanden hat. Dadurch könnten Fragen falsch interpretiert und so das Ergebnis des Interviews verfölscht werden. Außerdem können Aspekte, an die der Interviewer bei der Erstellung des Fragebogens nicht gedacht hat, wöhrend eines Gespröchs mit dem Befragten zum Vorschein kommen, die sonst verloren gingen. Deshalb ist es sinnvoll, eine Mischung von strukturierten und un­strukturierten Interviews zu wöhlen. Diese werden semi-strukturierte Interviews genannt.

In der vorliegenden Arbeit werden semi-strukturierte Interviews mit Hilfe eines eigens er­stellten Fragebogens durchgeföhrt. Der Interviewer befragt die Personen personlich und gibt ihnen die Moglichkeit Antworten und Äußerungen selbst zu formulieren. Der Befragte kann auch zu jeder Frage Anmerkungen geben.

Erstellen eines Fragebogens

Bevor man den Fragebogen erstellt, mössen die Ziele der Interviews definiert werden, um die Fragen besser formulieren zu koönnen. Die vorliegende Arbeit zielt unter anderem darauf ab, Anforderungen an das MockUp-Tool zu finden und einen Uberblick öber den Spezifika­tionsprozess von grafischen Bedienoberflachen der Capgemini sd&m AG zu erhalten.

Nach der Definition der Ziele werden die Fragen formuliert. Es gibt zwei Formen von Fra­gen: offene und geschlossene Fragen. Offene Fragen geben dem Befragten die Möglichkeit, frei zu antworten, waöhrend geschlossene Fragen Antwortmoöglichkeiten vorgeben. Bei den Antwortmöglichkeiten kann es sich auch um eine Skala handeln (zum Beispiel die Frage „Wie höufig kommt es vor, dass ... ?“ mit den Antworten „sehr haufig, haufig, 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 koönnen, wie bei den unstrukturierten Interviews, keine unbedachten Aspekte verloren gehen. Doch erschwert sich die Auswertung der Fragen durch die Vielzahl der Antwortmoöglichkeiten. Gibt man Antwortmöglichkeiten vor, erleichtert sich zwar die Auswertung, doch mössen die vorgege­benen 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önnen folgende Regeln [AnLe] helfen:

- Lange Fragen und verschachtelte Sötze sollten vermieden werden.
- Bei Verwendung von Skalen als Antwort sollte es ca. 5-7 Optionen geben.
- Bei Vorgabe von Antwortmoöglichkeiten sollten diese sich nicht uöberschneiden.
- Pro Antwortmoöglichkeit sollte es nur eine Antwort geben.
- Doppelte Verneinungen sollten vermieden werden.
- Man sollte jeder Frage nur einen sachlichen Inhalt / Gedanken zugrunde legen.

In der vorliegenden Arbeit wird der Fragebogen nach dem Ansatz des sog. leitfadenorien­tierten Interviews [AnLe] erstellt. Bei diesen Interviews wird der Fragebogen in verschiede­ne Themengebiete aufgeteilt. Dabei werden alle Fragen, die zu einem bestimmten Thema gehören, zusammengefasst. Dadurch können Ergebnisse für die einzelnen Themen erhal­ten 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ür die Entscheidung, welches MockUp-Tool verwendet werden soll, muss der Spezifika­tionsprozess 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ür ein MockUp-Tool wird, wie in Kapitel 3 beschrieben, mit Hilfe einer modifizierten Variante der gewichteten Entscheidungsmatrix getroffen. Um die Entscheidungsmatrix aufzubauen, müssen Kriterien, die das MockUp- Tool erfüllen 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ür die Durchführung von Interviews. Es soll herausgefunden werden

- wie der Spezifikationsprozess von GUIs bei der Capgemini sd&m AG funktioniert und welche Werkzeuge und Methoden momentan dafur eingesetzt werden,
- wie die Entscheidungsmatrix aufgebaut werden soll
— welche Kriterien das MockUp-Tool erfüllen soll,
— wie die Kriterien gewichtet werden sollen,
— welche Aggregations- und Bedingungsformeln die Kriterien besitzen sollen
- und wie der Spezifikationsprozess durch ein MockUp-Tool unterstuützt werden kann.

4.3 Durchführung 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ür ein MockUp-Tool entscheidet, welches für viele Projekte geeignet ist. Die Interviews haben ca. 1-2 Stunden gedauert und wurden immer in einem persünlichen Gesprüch durchge­führt. Die Capgemini sd&m AG ist auf viele Standorte in Deutschland, Österreich 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ür ein Interview nicht persünlich treffen, wurden in solchen Füllen die Interviews per Telefon durchgeführt. Für die Durchführung der Interviews werden zwar Fragebügen (s. Abschnitt 4.4) verwendet, aber die Fragebüogen werden den befragten Personen nicht ausgehaündigt 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üglichkeit frei zu antworten. Auch koünnen die Interviewten bei Unklarheiten fragen, ob sie die Frage richtig verstanden hat­ten.

4.4 Fragebogen zur Durchführung der Interviews

Zum Erreichen der in Abschnitt 4.2 definierten Ziele werden Interviews mit zwei ver­schiedenen Gruppen von Personen durchgeführt. Zum einen werden fachliche Designer, welche überwiegend Software Ingenieure sind, und zum anderen Usability Experten be­fragt. Durch die Befragung dieser beiden Personengruppen sollen jeweils unterschiedliche Ziele erreicht werden. Abhüngig davon müssen entsprechende Fragen formuliert werden. Für diese beiden Gruppen werden daher zwei verschiedene Fragebügen erstellt und zusütz- lich in verschiedene Themengebiete aufgeteilt.

Den fachlichen Designern werden Fragen aus den folgenden Themengebieten gestellt:

- GUI-Spezifikation bei der Capgemini sd&m AG
- Fragen bezüglich der von Capgemini sd&m Research gelieferten Spezifikationsme­thode
- Welche Ergebnisse werden am Ende vom MockUp-Tool erwartet?
- Was muss das MockUp-Tool sonst noch unterstützen?
- Fragen bezuüglich der Usability-Unterstuützung
- Sonstiges

Für die Usability Experten sind zusatzliche Fragen aus den folgenden Themengebieten vorbereitet:

- GUI-Spezifikation bei der Capgemini sd&m AG
- Fragen bezüglich der Usability-Community
- Sonstiges

Mit diesen Themengebieten, die in den nüachsten Abschnitten naüher beschrieben werden, lassen sich verschiedene Ziele erreichen.

4.4.1 Ziel: Spezifikationsprozess und verwendete Werkzeuge und Metho­den

Mit den Fragen aus den Themengebieten, die in diesem Abschnitt beschrieben werden, be­kommt man einen Uberblick über den Spezifikationsprozess der Capgemini sd&m AG. Es werden auch Fragen zu den verwendeten Werkzeugen und Methoden gestellt. Die verwen­deten Werkzeuge werden bei der Evaluierung der Tools beruücksichtigt und dienen somit als Ausgangspunkt zur Marktanalyse, um geeignete MockUp-Tools zu finden.

GUI-Spezifikation bei der Capgemini sd&m AG

Dieser Bereich enthaült Fragen, die sich speziell an die Situation der Spezifikation von gra­fischen Oberflachen 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ür die Spezifikation zur Verfügung hat. Außerdem wird auch gefragt, welche Arte­fakte bei der Spezifikation von grafischen Bedienoberflächen erstellt werden mussen. Diese Fragen richten sich sowohl an die fachlichen Designer als auch an die Usability Experten.

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 bezie­hungsweise früher GUIs spezifiziert haben.

Fragen bezüglich der Usability-Community

Bei der Capgemini sd&m AG hat sich vor kurzer Zeit eine Usability-Community gegrün­det. Die Community befasst sich mit dem Thema der Gebrauchstauglichkeit von grafischen Bedienoberflachen. Fachliche Designer künnen sich, wenn sie eine GUI entwerfen müssen, die eine gute Usabiltiy bieten muss, an die Community wenden und sich dort Unterstüt­zung holen. Die Fragen zu diesem Themengebiet werden nur den Usability-Experten ge­stellt, die Mitglieder der Usability-Community sind. Es wird hier gefragt, wie die Usability- Community die Spezifikation von GUIs unterstützt.

4.4.2 Ziel: Integration des MockUp-Tools in den Spezifikationsprozess

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

Fragen bezüglich der von Capgemini sd&m Research gelieferten Spezifikati­onsmethode

Capgemini sd&m Research hat eine Spezifikationsmethodik zur Spezifikation von Soft­waresystemen entwickelt. Darunter befindet sich auch eine Methode für die Spezifikation grafischer Bedienoberflächen. Diese basiert auf die Verwendung des Modellierungswerk­zeugs 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 geklaürt werden, wie die Integration des MockUp-Tools in die Spezifi­kationsmethodik von Capgemini sd&m Research und damit auch die Integration in den Enterprise Architect stattfinden kann. Außerdem soll überprüft 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 Tatigkeiten im MockUp-Tool und welche im Modellierungswerkzeug durchgefuührt werden sollen. Es wird beispielswei­se gefragt, ob es möglich sein muss im MockUp-Tool eine Dialoglandkarte und/oder eine Feldliste erstellen zu konnen.

4.4.3 Ziel: Kriterien für die Evaluierung der MockUp-Tools finden

Die letzten drei Themengebiete dienen zum Aufbau des Kriterienkatalogs fur die Ent­scheidungsmatrix (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ützen?

Mit den Fragen aus diesem Bereich soll herausgefunden werden, wie das MockUp-Tool den fachlichen Designer beim Entwurf des GUI Layouts unterstützen soll. Es wird beispielsweise gefragt, ob man mit dem MockUp-Tool eigene Widgets (beziehungsweise Widget-Gruppen) erstellen können soll, oder ob das Tool Templates mit Corporate Identity Vorgaben unter­stützen soll.

Fragen bezüglich der Usability-Unterstützung

Diese Fragen richten sich an die fachlichen Designer. Es soll herausgefunden werden, wie sich die fachlichen Designer eine Unterstützung zum Thema Usability wünschen und wie die Usability-Community sie dabei unterstützen kann. Vor allem aber soll ermittelt wer­den, welche Kriterien das MockUp-Tool erfullen soll, um den fachlichen Designer beim Entwurf von benutzerfreundlichen Systemen zu unterstutzen.

Sonstiges

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

Die beiden Fragebogen 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ührliche Auswertung befindet sich im Anhang B.

4.5.1 Ergebnisse: Spezifikationsprozess und verwendete Tools und Me­thoden

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

Um die Spezifikation der GUI auszuarbeiten, werden hüufig neben dem Layout der GUI, auch einige andere Artefakte erstellt. Es werden beispielsweise Dialoglandkarten, Feldlis­ten 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 Aktionslis­ten 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^[5] aus dem Enterprise Architect die Spezifikation der Oberflache.

Die gesamte Spezifikation eines zu entwerfenden Systems wird bei der Capgemini sd&m AG von mehreren Personen erstellt. Dabei müssen unter anderem Anforderungen an die Software definiert, Anwendungsfülle formuliert und das Layout der GUI entworfen werden. Die Tütigkeiten zur Erstellung der Spezifikation werden meist fachlich auf die Personen aufgeteilt. Fachlich aufgeteilt bedeutet, dass eine Person nicht nur eine Art von Tätigkei­ten ausübt, zum Beispiel das Entwerfen der grafischen Oberflache, sondern einen gewissen Bereich der GUI zugewiesen bekommt und zu diesem Bereich die gesamte Spezifikation, mit Entwurf von Anwendungsfüllen, Entwurf der grafischen Oberflüche usw., erstellt. Aus diesem Grund kommt es selten vor, dass mehrere Personen am Entwurf der gleichen Dia­loge arbeiten.

Zur Erstellung der Spezifikation von grafischen Oberflüchen 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 En­terprise Architect. Der Enterprise Architect wird jedoch nur von wenigen Personen be­nutzt. Dies liegt daran, dass der Enterprise Architect erst vor kurzem eingeführt worden ist und viele laufende Projekte es nicht mehr einsetzen konnten. Bei den zur Zeit verwen­deten Tools handelt es sich nicht um richtige MockUp-Tools und es werden mit diesen Werkzeugen auch keine lauffühigen MockUps erstellt. Dennoch werden diese Tools in der vorliegenden Arbeit zusammen mit anderen Tools evaluiert. Falls waührend der Spezifikati­onsphase ein Prototyp der GUI benütigt wird, erstellt man oft ein HTML-Prototyp. Viele fachliche Designer entwerfen die grafische Oberflache 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ünnen sich viele Befragte vorstellen, hierfür künftig ein solches Hilfsmittel einzusetzen. Ein minimal hüherer Aufwand zur bisherigen Arbeitsweise wird hier gerne in Kauf genommen. Das Tool müsste jedoch „gut“ sein. Nach Meinung der Befragten trifft dies zu, wenn es müglichst viele Kriterien des Kriterienkatalogs (der Entscheidungsmatrix) erfüllt. Außerdem künnen MockUp-Tools bei der Durchfuührung von Usability-Tests behilflich sein. Das Thema Usa­bility sollte nach Meinung der Befragten in einigen Projekten starker unterstützt werden. Das ist ein weiterer Grund für den Einsatz von MockUp-Tools und lässt 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 Spezifikations­prozess

Die meisten Befragten waren der Meinung, dass das MockUp-Tool nur zum Entwerfen des GUI Layouts und deren Interaktionen benutzt werden soll. Für die detaillierte Beschrei­bung 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ütigt, welches sich im Enterprise Architect befindet. Deswegen fanden es die meisten fachlichen Designer besser, wenn die Beschreibung der Oberflüche auch im Enterprise Architect bearbeitet wird. So kann man einfach auf das Datenmodell verweisen und muss die GUI-Spezifikation nicht andern, falls das Datenmodell geandert wird. Kann man jedoch im MockUp-Tool detaillierte Beschreibungen zu den Elementen eingeben, sollten diese in den Enterprise Architect übernommen werden.

4.5.3 Ergebnisse: Kriterien für die Evaluierung der MockUp-Tools fin­den

Im Folgenden befindet sich ein Ausschnitt der Auswertung der Interviews mit den wich­tigsten Ergebnissen und den Folgerungen daraus. Diese Ergebnisse sind Einflussfaktoren für den Aufbau des Kriterienkatalogs:

- Dialoglandkarten könnte man auch automatisch im Enterprise Architect erstellen, deshalb muss das MockUp-Tool die Erstellung von Dialoglandkarten nicht unter­stützen.
- Die GUI-Spezifikation kann sich oft und zu jeder Phase in der Softwareentwicklung aöndern.
- Da sich die GUI-Spezifikation oft und zu jeder Phase in der Softwareentwicklung öndern kann, sollte man die entworfene GUI vom MockUp-Tool in das Modellier­ungswerkzeug, und auch zuröck, synchronisieren können.
- Dialoge beziehungsweise Dialogmasken werden selten von mehreren Personen bear­beitet. Eine Versionierung der Stande wöre jedoch wönschenswert, da sich die Spe­zifikation der grafischen Oberflache zu jeder Phase der Softwareentwicklung andern kann. Deshalb wird verlangt, dass das Tool eine Versionierung der Dialogmasken unterstötzt.
- 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öteren Zeitpunkt statt, da sich der Kunde meist nur för das Verhalten und das Aussehen der grafischen Oberflache interessiert und nicht wie diese technisch umgesetzt wird. Es muss deshalb mit dem Tool möglich sein, die Dialoge dynamisch (zuerst nur grob und spöter detailliert) modellieren zu können. Außerdem muss das Tool einfach zu bedienen sein, damit die GUI zusammen mit dem Kunden entworfen werden kann.
- Für Diskussionen mit dem Kunden, zum Finalisieren der GUI und zur Erzeugung der Spezifikation werden Screenshots der Dialogmasken benoötigt, deshalb muss mit dem MockUp-Tool automatisch Screenshots generiert werden können.
- Es werden verschiedene Arten von Anwendungen bei der Capgemini sd&m AG entwi­ckelt. Diese sind Desktop-, Web-, Mobile- und Multimedia-Anwendungen. Deshalb sollte das MockUp-Tool das Modellieren von verschiedenen Anwendungsarten un- terstötzen, wobei Desktop- und Webanwendungen in jeden Fall unterstötzt werden mössen, da diese am höugfisten entwickelt werden. Schon ware es auch, wenn man zwischen den Anwendungsarten switchen könnte, das ist aber kein Pflichtkriterium.
- Da der (nicht technische) Unterschied zwischen Desktop- und Webanwendungen zur heutigen Zeit immer geringer wird, waöre es naheliegend ein Tool, das den Entwurf eines der beiden Arten unterstötzt, för den Entwurf beider Anwendungsarten zu benutzen. Um herauszufinden, ob dies sinnvoll ist, wurden die fachlichen Designer öber die (nicht technischen) Unterschiede zwischen Web- und Desktopanwendungen befragt. Sie wurden gebeten ihre Meinung zur Idee, nur ein Tool zu verwenden, zu öußern. Aus den Interviews folgt, dass es immer noch Unterschiede beim Design zwischen den beiden Anwendungsarten gibt und es nicht erwuönscht ist, ein Tool zu benutzen, welches nur eine der beiden Arten unterstötzt.
- Aus der Befragung der fachlichen Designer ergibt sich, dass Anwendungen oft ver­schiedene Sprachen unterstuötzen muössen. Beim Entwurf solcher Anwendungen wuörde es dem fachlichen Designer helfen, wenn er im MockUp-Tool zwischen verschiedenen Sprachen umschalten koönnte. Doch ist dieses Feature nicht zwingend notwendig, da die GUI meist nur einmal und in nur einer Sprache spezifiziert wird. Falls sich die Sprachen sehr unterscheiden (beispielsweise Englisch und Japanisch), würde die Oberfläche mehrmals spezifizieren, da in einem solchen Fall das ganze Layout ge- ündert werden muss. Deshalb wird dieses Kriterium zwar in den Kriterienkatalog aufgenommen, aber das MockUp-Tool muss es nicht zwingend erfüllen.
- Da viele der Befragten wünschen, dass das Thema Usability in den Projekten stär­ker etabliert wird, sollte das Tool einige Usability-Konzepte beim Entwurf von GUIs unterstuützen. Es sollte beispielsweise die Durchfuührung von Usabiltiy-Tests ermüogli- chen. Usability-Tests künnten durch folgende Features des MockUp-Tools unterstützt werden:
— Loggen von Interaktionen mit dem MockUp — Benutzer soll Notizen zu dem MockUp eingeben künnen — Skizzenartige Darstellung der grafischen Oberflüche
- Die Mehrheit der Befragten wollen die Müglichkeit eigene Widgets (beziehungswei­se Teildialoge) erstellen zu künnen. Einige meinen auch, dass dies nicht unbedingt notwendig ist. Da nur wenige dagegen gestimmt haben, muss dieses Kriterium vom MockUp-Tool erfüllt werden.
- Ähnlich wie bei der Frage eigene Widgets erstellen zu künnen, wollte die Mehrheit der Befragten, dass das Tool CI-Vorgaben unterstützt. Da die Zahl der Personen, die dagegen gestimmt haben, hier deutlich hüoher ist als bei der Frage nach eigenen Widgets, muss dieses Kriterium nicht zwingend erfüllt werden.
- Ein eigenes Design der GUI-Elemente zu definieren, sahen die Interviewten als nicht sehr wichtig an.
- Beispiel-Daten sollen im MockUp-Tool eingegeben werden können, müssen aber nicht unbedingt in den EÄ uübernommen werden.
- Es soll ein lauffahiger Prototyp erstellt werden konnen, damit der Kunde das MockUp auf seinem Rechner ausführen kann.
- Das MockUp-Tool darf etwas kosten, wenn es „gut“ ist. Äber es darf nicht zu teuer sein, da sich kleine Projekte das Tool sonst nicht leisten künnen! Ein Tool ist gut, wenn es die Kriterien aus dem Kriterienkatalog (der Entscheidungsmatrix) erfüllt.
- Das MockUp soll nicht als Prototyp zum weiterimplementieren benutzt werden, son­dern nur für den Entwurf der GUI und der Spezifikation dienen. Deshalb muss es nicht müglich sein, den Quellcode der GUI mit dem MockUp-Tool zu generieren.

5. Evaluierung der MockUp-Tools

Dieses Kapitel beschreibt die Marktanalyse zur Auswahl des MockUp-Tools. Dabei wird der Kriterienkatalog für die Entscheidungsmatrix unter Beachtung der Ergebnisse des vor­herigen Kapitels aufgebaut und es werden verschiedene MockUp-Tools bewertet. Anschlie­ßend werden die Ergebnisse der Evaluierung vorgestellt und ein MockUp-Tool für die Integration in den Spezifikationsprozess gewahlt.

5.1 Aufbau der Entscheidungsmatrix

Zum Aufbau der Entscheidugsmatrix werden die Kriterien und ihre Gewichtung, Aggre­gationsformeln und Bedingungsformeln benütigt. Im Folgenden wird beschrieben, welche Kriterien festgestellt und definiert wurden und einige Beispiele genannt.

5.1.1 Die Kriterien

Die Kriterien, die das MockUp-Tool erfüllen muss, werden aus den Ergebnissen der Inter­views mit Software Ingenieuren und Usability Experten definiert (s. Kapitel 4). Insgesamt werden 80 atomare Kriterien und 27 Kriteriengruppen definiert. Die 5 obersten Kritrien- gruppen sind:

- Technische Anforderungen
- Anforderungen an die Akzeptanz
- Anforderungen zur Modellierung
- Anforderungen aus Sicht der Usability
- Sonstiges

Welche Kriterien diese Kriteriengruppen jeweils zusammenfassen, wird im Folgenden be­schrieben.

Technische Anforderungen

Diese Gruppe fasst Kriterien zusammen, die technische Anforderungen an das MockUp stellen. Die Kriterien dieser Gruppe müssen erfüllt werden, um das Tool aus technischer Sicht in den Spezifikationsprozess integrieren zu können. In dieser Gruppe befinden sich daher auch technische Kriterien zur Integration des MockUp-Tools in das Modellierungs­werkzeug. Beispiele für Kriterien dieser Gruppe sind:

- Das Tool soll auf dem Betriebssystem Windows laufen
- Versionierung der Stünde muss müglich sein
- Es muss müglich sein, eindeutige IDs beziehungweise interne Namen für alle Elemente zu definieren

Anforderungen an die Akzeptanz

Das MockUp-Tool soll von fachlichen Designern genutzt werden und sie beim Entwurf der Spezifikation grafischer Oberflachen unterstützen. Aus den Interviews (s. Kapitel 4) ergab sich, dass die fachlichen Designer momentan verschiedene Tools dafür benutzen. Damit der fachliche Designer ein neues Tool zum Entwerfen der GUI akzeptiert, muss das MockUp-Tool einige Kriterien erfüllen, welche sich in dieser Gruppe befinden. Beispiele hierfuür sind:

- Schneller Zugriff auf gängigen Standard-Widgets (zum Beispiel Button, Label, usw.)
- Das Tool soll einen geringen Lernaufwand haben
- Das Tool soll eine Unterstützung beim Ausrichten der GUI-Elemente (Widgets) bie­ten

Anforderungen zur Modellierung

Diese Gruppe fasst Kriterien zusammen, durch welche die fachlichen Designer beim Mo­dellieren unterstützt werden. Folgende Kriterien gehoren zum Beispiel zu dieser Gruppe:

- Mit dem Tool sollten verschiedene Arten von Anwendungen erstellt werden koünnen (beispielsweise Web-Anwendungen, Desktop-Anwendungen, Mobile-Anwendungen, usw.)
- Man sollte im Tool die Auflüosung der Anwendung definieren koünnen
- Ein Free-Form-Design soll müglich sein (kein Layoutzwang)

Anforderungen aus Sicht der Usability

Kriterien, die dem fachlichen Designer beim Entwerfen von benutzerfreundlichen Anwen­dungen helfen, befinden sich in dieser Gruppe. Beispiele für solche Kriterien sind:

- Damit keine Layout-Diskussionen entstehen, sollen unscharf gezeichnete Dialoge mit dem Tool erzeugt werden künnen (Sketchmode)
- Man sollte Szenarien definieren künnen
- Papierprototypen sollen erzeugt werden konnen

Sonstiges

Diese Gruppe enthült Kriterien, die in keine der oben genannten Gruppen passen. Hier befinden sich zum Beispiel Anforderungen an die Lizenz, die das Tool haben soll bezie­hungsweise haben darf, oder über die Zukunftssicherheit sowie Supportsicherheit des Tools.

[...]

---

^[1] '"Beispiel aus der Quelle [Senf]

^[2] Beispiel aus der Quelle [Senf]

^[3] Beispiel aus der Quelle [Nikl04]

^[4] Beispiel aus der Quelle [Nikl04]

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