Lade Inhalt...

GUI-Prototyping

Seminararbeit 2011 20 Seiten

Informatik - Programmierung

Leseprobe

Inhaltsverzeichnis

Abstract

Abbildungsverzeichnis

1 Einführung

2 Theoretische Grundlagen
2.1 GUI
2.2 Prototyp
2.3 Anforderungen

3 GUI-Prototyping zur Dokumentation von Anforderungen an die Benutzeroberfläche
3.1 Motivation
3.1.1 Abdeckung der Ziele des Requirements Engineering
3.1.2 Geringe Kosten und Kostenreduktion
3.1.3 Erleichterung der Kommunikation
3.2 Umsetzung
3.2.1 Einfaches GUI-Prototyping
3.2.2 Erweitertes GUI-Prototyping
3.3 Spezielle Darstellungstechniken
3.4 Einbettung in den Prozess der Softwareentwicklung

4 Fazit

Literaturverzeichnis

Verzeichnis zitierter Internet-Quellen

Abbildungsverzeichnis

Abbildung 1: GUI von Word

Abbildung 2: Fehler im Softwareentwicklungsprozess und ihre Kosten

Abbildung 3: Einfaches GUI

Abbildung 4: Möglicher Aufbau eines Tests

Abbildung 5: Textfelder

Abbildung 6: Einbettung von GUI-Prototyping in den Entwicklungsprozess

Abbildung 7: Vor- und Nachteile von GUI-Prototyping

Abstract

Anforderungen an die Benutzeroberfläche einer Software müssen spezifiziert und dokumentiert werden. GUI-Prototyping ist eine Möglichkeit zur Dokumentation dieser Anforderungen. Die Benutzeroberfläche als Schnittstelle zwischen Entwickler und Anwender der Software ist ein kritischer Punkt in der Softwareentwicklung. Entwickler sollen Vorstellungen und Wünsche der Anwender an die Benutzeroberfläche in Code umsetzen. Anwender können sich aber mitunter nicht in der Art und Weise technisch ausdrücken, wie es unter Umständen erforderlich wäre. In dieser Seminararbeit werden die generelle Methodik des GUI-Prototyping, spezielle Darstellungstechniken von Elementen der Benutzeroberfläche sowie Möglichkeiten und Grenzen dargestellt und erläutert. Ergebnis dieser Seminararbeit ist, dass GUI-Prototyping die Schnittstellenproblematik löst, indem es die Kommunikation zwischen Technikern und Nicht-Technikern erleichtert. GUI-Prototyping ist einfach und leicht verständlich, so dass auch interdisziplinäre Teams zusammenarbeiten können. Weiterhin senkt es die Kosten im Softwareentwicklungsprozess deutlich, da bereits in einer frühen Phase mit dem System interagiert und das System getestet werden kann

1 Einführung

Softwareentwicklung sieht sich mit wesentlichen Herausforderungen konfrontiert. Solche Herausforderungen sind u.a. zunehmende Komplexität, steigender Kostendruck, kürzere Entwicklungszeiten oder wachsender Qualitätsanspruch.1 Als Quelle für Probleme bei der Softwareentwicklung haben einige Studien Anforderungen an die Software ausfindig gemacht.2 Eine Anforderung ist definiert als „Aussage über eine Eigenschaft oder Leistung eines Produktes, eines Prozesses oder der am Prozess beteiligten Personen“.3 Den oben genannten Herausforderungen und Problemen der Softwareentwicklung kann allerdings mit einem erfolgreichen Requirements Engineering entgegengetreten werden.4 Requirements Engineering (im Folgenden kurz: RE) ermittelt, formuliert und validiert Anforderungen und verwaltet („managt“) sie.5 Für das System relevante Anforderungen werden von Personen oder Institutionen, die ein potenzielles Interesse am zukünftigen System haben, ermittelt und gestellt. Diese Gruppe wird als Stakeholder bezeichnet.6

Im Prozess der Softwareentwicklung implementieren Softwareentwickler (ebenfalls Stakeholder) die gesammelten Anforderungen in das zukünftige System. Dazu müssen sie zwingendermaßen mit den anderen Stakeholdern kommunizieren. Die Schnittstelle Entwickler – andere Stakeholder birgt ein großes Konfliktpotenzial. Dadurch, dass sich Entwickler eher technisch-rational ausdrücken, erwarten sie dies bei der Formulierung von Anwendungen auch von anderen Stakeholdern. Der Großteil der Stakeholder drückt sich allerdings nicht technisch aus. Der normale Anwender oder nicht-technische Abteilungen im Allgemeinen wie das Marketing verfügen in der Regel über keinen technischen Hintergrund. Daher entstehen Missverständnisse, die zu falschen Vorstellungen von Anforderungen führen und typische Probleme der Anforderungsanalyse darstellen.7 Im schlimmsten Fall würde dies bedeuten, dass Entwickler Eigenschaften in die Software implementieren, die beispielsweise vom Marketing nie in dieser Form gefordert wurden.8

„Projektbeteiligte sprechen nicht alle die gleiche Sprache, denn Sprache ist kein genormtes Ausdrucksmedium. Jeder Mensch ist in seinem Sprachgebrauch von seiner Umwelt, seinem Fachgebiet, seinem Hintergrund, seinen Kenntnissen und seinen persönlichen Erfahrungen geprägt“.9

Eine Möglichkeit die Kommunikationsprobleme zwischen Entwicklern und anderen Stakeholdern zu beheben stellt die Technik des GUI-Prototypings dar.10 Ziel dieser Seminararbeit ist es die Methodik des GUI-Prototypings sowohl darzustellen als auch zu untersuchen, inwiefern sie die oben genannte Schnittstellenproblematik aufgreift und löst. Weiterhin sollen Möglichkeiten und Grenzen des GUI-Prototypings dargestellt werden.

Dafür sollen zunächst in Kapitel 2 die Begriffe des GUI und des Prototyps definiert werden. In Kapitel 3 werden Motivation und Methoden des GUI-Prototypings sowie eine mögliche Eignung als Bindeglied für die Schnittstelle Techniker und Nicht-Techniker kritisch hinterfragt. Kapitel 4 fasst schließlich die Untersuchungsergebnisse zusammen.

2 Theoretische Grundlagen

Der Begriff „GUI-Prototyping“ setzt sich aus den Wörtern „GUI“ und „Prototyping“ zusammen. Diese sollen im Folgenden erläutert werden.

2.1 GUI

GUI ist ein Akronym des englischen Begriffs Graphical User Interface.11 Eine gängige deutsche Bezeichnung lautet „grafische Benutzeroberfläche“. Hierbei werden für den Benutzer relevante Informationen bildhaft bzw. grafisch dargestellt. Bestandteile von grafischen Benutzeroberflächen können Fenster, Menüs, Symbole und Steuerelemente sein.12

Abbildung 1: GUI von Word 2010

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Eigene Darstellung

Fenster teilen den Bildschirm in Arbeitsbereiche auf. Diese können sich gegenseitig überlappen, bildschirmfüllend oder benachbart sein. Fenster lassen sich weiterhin unterteilen in Anwendungs-, Dokument- und Dialogfenster.13

Menüs bieten eine übersichtliche Auswahl von Funktionen einer Software (oder Webseite u.ä.) an. Diese können entweder permanent (z.B. am Rand) oder anwendungsbezogen (z.B. während eines bestimmten Arbeitsschritts) angezeigt werden.14

Symbole sind stilisierte Abbildungen von Funktionen, die sich durch einen Mausklick ausführen lassen. Ein bekanntes Symbol ist z.B. eine Schere für die Funktion „Ausschneiden“. Steuerelemente können Scrollbars oder Buttons sein.15

Abbildung 1 zeigt die grafische Oberfläche von Word 2010. Im oberen Bereich befindet sich die Menüleiste, am rechten Rand eine Scrollleiste. Das Fenster „Absatz“ ist geöffnet. Symbole wie die Schere zum Ausschneiden oder ein Kreuz zum Schließen der Anwendung sind ebenfalls zu sehen.

2.2 Prototyp

Ein Prototyp ist ein Abbild eines zukünftigen Systems mit dem man die Möglichkeit hat zu interagieren, bevor die Endversion fertiggestellt ist. Prototypen sind vor allem auch aus konstruierenden Branchen wie der Automobilindustrie bekannt. Durch die Interaktion mit einem Prototyp können frühzeitig Vorstellungen oder Wünsche von Benutzern an das fertige System identifiziert werden. Auch Probleme oder Missstände lassen sich so bereits vor der Fertigstellung des Endprodukts feststellen.16

Gegenstand dieser Seminararbeit sind Prototypen aus Papier, sogenannte Papierprototypen (englisch: paper prototype17 ). Papierprototypen können bereits mit Papier und Bleistift erstellt werden und stellen damit eine kostengünstige und schnelle Alternative dar, einen Prototyp zu konstruieren.18 Eine weitere Art von Prototypen sind z.B. durch eine Software erstellte Prototypen, die hier nicht weiter behandelt werden sollen.

Die Literatur unterscheidet horizontale und vertikale Prototypen, exploratives, experimentelles und evolutionäres Prototyping sowie High-Fidelity- und Low-Fidelity-Prototypen.19 In Anbetracht der Problemstellung ist es allerdings ausreichend in „einfaches Prototyping“ sowie in „erweitertes Prototyping“ zu differenzieren. Sie hierfür Kapitel 3.2.

Beide Definitionen abschließend betrachtend beschäftigt sich GUI-Prototyping mit dem Erstellen von Prototypen von grafischen Benutzeroberflächen. Menüs, Fenster, Symbole und Steuerungselemente werden auf Papier gezeichnet, um eine Vorstellung vom zukünftigen GUI zu erhalten. Ein weiterer gängiger Begriff ist „User Interface Prototyping“20.

2.3 Anforderungen

Anforderungen an ein System lassen sich unterscheiden in funktionale Anforderungen, Qualitätsanforderungen und Rahmenbedingungen.21

Funktionale Anforderungen beziehen sich auf die zukünftigen Funktionen des Systems. „Eine funktionale Anforderung definiert eine vom System bzw. von einer Systemkomponente bereitzustellende Funktion oder einen bereitzustellenden Service.“22 Qualitätsanforderungen hingegen definieren qualitative Eigenschaften des Systems, wie beispielsweise Sicherheit, Zuverlässigkeit oder Performanz.23 Rahmenbedingungen sind als Einschränkungen des Systems zu verstehen. Dabei können sowohl Prozesse als auch das System eingeschränkt werden.24 Beispiele für Einschränkungen sind Fristen oder einzuhaltende gesetzliche Bestimmungen.

3 GUI-Prototyping zur Dokumentation von Anforderungen an die Benutzeroberfläche

3.1 Motivation

Warum GUI-Prototyping im Softwareentwicklungsprozess eingesetzt wird, sollen die folgenden Abschnitte näherbringen.

3.1.1 Abdeckung der Ziele des Requirements Engineering

Die grundlegende Motivation des GUI-Prototypings ergibt sich aus der in der Einführung genannten Feststellung, dass ein vernünftig durchgeführtes Requirements Engineering Basis für eine erfolgreiche Softwareentwicklung ist.

Betrachtet man eine genauere Definition des Requirements Engineering, so hat RE im Wesentlichen drei Ziele zur Aufgabe:

„Requirements Engineering ist ein kooperativer, iterativer, inkrementeller Prozess, dessen Ziel es ist zu gewährleisten, dass

(1) alle relevanten Anforderungen bekannt und in dem erforderlichen Detaillierungsgrad verstanden sind,
(2) die involvierten Stakeholder eine ausreichende Übereinstimmung über die bekannten Anforderungen erzielen,
(3) alle Anforderungen konform zu den Dokumentationsvorschriften dokumentiert bzw. konform zu den Spezifikationen spezifiziert sind“.25

Da eine grafische Benutzeroberfläche heutzutage in der Regel ein wesentlicher Bestandteil von Software ist, fallen ebenfalls Anforderungen für das GUI an. Diese werden im Rahmen eines ordentlichen RE spezifiziert und dokumentiert. GUI-Prototyping stellt eine Möglichkeit dar, diese Anforderungen zu dokumentieren.26

Weitere Methoden Anforderungen zu dokumentieren sind u.a. Tabellen oder natürliche Sprache.27 Insbesondere die natürliche Sprache stößt dabei schnell an ihre Grenzen. Ein anschauliches Beispiel ist es, sämtliche Elemente, die das GUI von Word 2010 in Abbildung 1 bietet, auszuformulieren. Ein langer Text entsteht, von dem sich lesende Stakeholder kaum ein Bild machen können.28 Wesentlich effektiver ist es das GUI mit Papier und Bleistift abzubilden. So lässt sich bei den Stakeholdern auch eine bessere Übereinstimmung über die Anforderungen erlangen (Nr. 2 der Definition). Gleichzeitig erleichtert es die Kommunikation (s. Punkt 3.1.3), was sicherstellt, dass die Anforderungen „bekannt“ und „verstanden“ sind (Nr. 1 der Definition).

3.1.2 Geringe Kosten und Kostenreduktion

Ein weiterer wichtiger Grund für GUI-Prototyping ergibt sich aus dem Einsatz in einer frühen Phase des Softwareentwicklungsprozesses. GUI-Prototyping findet vor allem in der Entwurfsphase statt.

Abbildung 2: Fehler im Softwareentwicklungsprozess und ihre Kosten

Abbildung in dieser Leseprobe nicht enthalten

Quelle: Liggesmeyer 2009, S. 33

Betrachtet man Abbildung 2 so fällt auf, dass 40% der Fehler im Entwicklungsprozess im Entwurf entstehen. Gleichzeitig sind die Kosten pro Fehlerkorrektur mit 250€ pro Korrektur vergleichsweise gering. Es empfiehlt sich also, Fehler bereits in einer frühen Phase zu beseitigen, da die Beseitigungskosten im späteren Entwicklungsverlauf exorbitant ansteigen.

Weiterhin sind die absoluten Kosten (Papier und Stifte) für die Erstellung eines Papierprototypens ebenfalls sehr gering.

[...]


1 Vgl. Pohl 2007, S. 7

2 Vgl. Pohl 2007, S. 9

3 Rupp 2007, S. 13

4 Vgl. Pohl 2007, S. 7

5 Vgl. Rupp 2007, S. 540 ff.

6 Vgl. Pohl 2007, S. 65

7 Vgl. Rupp 2007, S. 24

8 Vgl. Snyder 2003, S. 65

9 Rupp 2007, S. 25

10 Vgl. Snyder 2003, S. 12

11 Vgl. Laudon/Laudon/Schoder 2009, S. 339

12 Vgl. Stahlknecht/Hasenkamp 2005, S. 81

13 Vgl. Stahlknecht/Hasenkamp 2005, S. 81

14 Vgl. Stahlknecht/Hasenkamp 2005, S. 81

15 Vgl. Stahlknecht/Hasenkamp 2005, S. 81

16 Vgl. Grechenig/Bernhart/Breitender/Kappel 2010, S. 541

17 Vgl. Snyder 2003, S. 3

18 Vgl. Rupp 2007, S. 68

19 Lese hierzu vertiefend Pohl 2007, S. 368ff. , Grechenig/Bernhart/Breitender/Kappel 2010, S. 541ff. sowie Rupp 2007, S. 66ff.

20 Richter/Flückiger 2010, S. 21

21 Vgl. Pohl 2007, S. 14

22 Pohl 2007, S. 15

23 Vgl. Pohl 2007, S. 15f.

24 Vgl. Pohl 2007, S. 18f.

25 Pohl 2007, S. 43

26 Vgl. Rupp 2007, S. 267 ff.

27 Vgl. Rupp 2007, S. 271

28 Beispiel in Anlehnung an Rupp 2007, S. 267

Details

Seiten
20
Jahr
2011
ISBN (eBook)
9783656037149
ISBN (Buch)
9783656037118
Dateigröße
1.1 MB
Sprache
Deutsch
Katalognummer
v180670
Institution / Hochschule
Fachhochschule Aachen
Note
1,7
Schlagworte
GUI-Prototyping Anforderungs- und Testmanagement Anforderungen Anforderungsdokumentation Softwareentwicklung Paper prototyping Benutzeroberfläche GUI Schnittstelle Requirements Engineering

Autor

Zurück

Titel: GUI-Prototyping