Usability-Anforderungen in der Praxis

Transkript

1 Institut für Softwaretechnologie Universität Stuttgart Universitätsstraße 38 D Stuttgart Diplomarbeit Nr Usability-Anforderungen in der Praxis Manuel Breitfeld Studiengang: Softwaretechnik Prüfer: Betreuer: Prof. Dr. rer. nat. Jochen Ludewig Dipl.-Inf. Holger Röder begonnen am: 1. Februar 2009 beendet am: 3. August 2009 CR-Klassifikation: D.2.1, D.2.9, H.1.2, H.5.2

2 Zusammenfassung Diese Arbeit stellt eine Übersicht zur Rolle von Usability-bezogenen Aktivitäten in der Praxis der Softwareentwicklung dar. Die vorliegende Arbeit zeigt auf, dass das Usability Engineering und das Software Engineering kaum miteinander verbunden sind und beschreibt einige Usability-Techniken des Usability Engineerings. Existierende Softwareentwicklungsprozesse binden solche Techniken hingegen nicht ein. Zwar existiert Literatur, die eine solche Integration in verschiedene Softwareentwicklungsprozesse beschreibt; in wie weit die sehr allgemein gehaltenen theoretischen Erkenntnisse in der Praxis Anwendung finden, ist in bestehender Literatur jedoch kaum untersucht. In dieser Arbeit wurde eine Industriebefragung durchgeführt, die darüber Aufschluss gibt, inwiefern Usability explizit in der Praxis berücksichtigt wird. Als Ergebnis der Befragung lässt sich festhalten, dass Usability nur einen geringen Stellenwert während der gesamten Entwicklung besitzt und spezielle Usability-Techniken zumeist unbekannt sind beziehungsweise kaum Anwendung finden. Usability wird vielmehr mit reinen Gestaltungstätigkeiten bezüglich der Benutzungsschnittstelle gleichgesetzt umfassendere Aktivitäten wie die systematische Einbeziehung der Benutzer, die explizite Dokumentation von Usability- Anforderungen oder konkrete Prüfungen in Bezug auf die Usability der Software finden nicht statt. Die Arbeit zeigt für die drei fiktiven Praxissituationen Kleinunternehmen, Marktentwicklung und Individualsoftware auf, wie eine verbesserte Berücksichtigung von Usability-Aspekten im Entwicklungsprozess aussehen kann. Sie beschreibt die ermittelten Maßnahmen ausführlich anhand von identifizierten Best Practices aus der Praxis. Dabei lehnen sich die in der vorliegenden Arbeit konzipierten Praxissituationen an die vorgefundenen Konstellationen der befragten Unternehmen an, so dass sich die empfohlenen Maßnahmen auf konkrete Probleme und Ausgangssituationen der Industrie beziehen. I

3 Abstract This thesis presents an overview of the role of usability related activities in the software development in the field. The paper examines that usability engineering and software engineering are separate fields. Several usability techniques which are described in this thesis are promoted by the usability engineering research; however these techniques currently are hardly integrated into software development processes. Although a few papers have been published describing the integration of such techniques into different software development processes in general, only little is known about the situation in the field from existing literature. Therefore, a survey of the industry has been conducted which provides information about how usability explicitly gets considered in practice. The survey reveals that usability has a low significance during the entire value chain of the development process and specific usability techniques are mostly unknown so they are not applied often. In fact, usability is rather seen as a field that is only involved in the graphical user interface of the software broader approaches to usability in terms of systematic user involvement, explicit documentation of usability requirements or accurate usability tests usually do not take place. Hence, this thesis demonstrates measures for the three fictitious real-life situations small company, market development and individual software how usability aspects can be considered during the development process. These measures that consist of identified best practices, recommendations of the literature and own considerations are explained in detail. The described fictitious real-life situations designed in this thesis are based on the constellations found in the field so that the advised measures refer to concrete problems of the industry. II

4 Danksagung Hiermit möchte ich mich herzlich bei Prof. Dr. Jochen Ludewig und meinem Betreuer Dipl.-Inf. Holger Röder bedanken. Die Unterstützung und konstruktiven Ratschläge haben sehr zum Gelingen dieser Arbeit beigetragen. Weiterhin bedanke ich mich bei allen Interviewpartnern, die sich die Zeit für die Interviews genommen haben und mir auf diese Weise erst die Möglichkeit zur Durchführung dieser Arbeit gegeben haben. Aus Gründen der Vertraulichkeit verzichte ich an dieser Stelle auf die namentliche Nennung der Personen und Unternehmen. III

5 Inhaltsverzeichnis Inhaltsverzeichnis Abbildungsverzeichnis... V Tabellenverzeichnis... VI 1 Einleitung Aufgabenstellung Aufbau der Arbeit Sprachliche Konvention Grundlagen Usability Usability Engineering Usability im Softwareentwicklungsprozess Stand der Praxis Konzeption und Durchführung der Industriebefragung Erstellung und Aufbau des Fragebogens Durchführung der Interviews Profil der befragten Interviewpartner und Unternehmen Bewertung des Vorgehens Auswertung der Industriebefragung Allgemeine Ergebnisse Bewertung der Ergebnisse Best Practices in der Industrie Typische Praxissituationen: Merkmale und Maßnahmen P1: Kleinunternehmen P2: Marktentwicklung P3: Individualsoftware Fazit und Ausblick Fazit Ausblick A Fragebogen B Aufgabenstellung Literaturverzeichnis IV

6 Abbildungsverzeichnis Abbildungsverzeichnis Abbildung 2 1: Usability im Nutzungskontext (nach Bevan)... 5 Abbildung 2 2: Bedienbarkeit im Modell unter Systemakzeptanz (nach Nielsen)... 6 Abbildung 2 3: Verändertes Wasserfallmodell (Quelle: Costabile) Abbildung 2 4: RUP mit Usability Design Discipline (Quelle: Göransson et al.) Abbildung 2 5: Verändertes Workflow Detail im RUP (nach Sousa & Furtado) Abbildung 3 1: Ja-Nein-Frage als Filterfrage Abbildung 3 2: Ja-Nein-Frage mit Ergänzungsfrage Abbildung 3 3: Frage mit Einfachnennung Abbildung 3 4: Frage mit Mehrfachnennungen Abbildung 3 5: Frage mit Antwortmatrix Abbildung 3 6: Offene Frage Abbildung 3 7: Rollen der Befragten ( 5) Abbildung 3 8: Jahre an Softwareentwicklung in den Unternehmen ( 6) Abbildung 3 9: Entwicklungsprozess der Unternehmen ( 13) Abbildung 4 1: Dokumentation von Usability-bezogenen Anforderungen ( 21) Abbildung 4 2: Eingesetzte Verfahren zur Anforderungsanalyse ( 22) Abbildung 4 3: Verfahren zur Prüfung der Usability ( 32) Abbildung 4 4: Berücksichtigung von Usability ( 34) Abbildung 4 5: Bewertung der Usability durch Benutzer ( 36) Abbildung 4 6: Kunden-Meinung zu Usability ( 35) Abbildung 4 7: Geeignete Phasen für Usability-Verbesserungen ( 38) Abbildung 4 8: Konkrete Möglichkeiten für Verbesserungen ( 39) Abbildung 4 9: Arten von Prototypen ( 23) Abbildung 4 10: Zweck der Prototypen ( 24) Abbildung 4 11: Behandlung des Prototyps während der Entwicklung ( 25) Abbildung 4 12: Usability-bezogene Richtlinien ( 27) Abbildung 4 13: Inhalte der Styleguides ( 28) Abbildung 4 14: Einhaltung der Usability-bezogenen Richtlinien ( 29) Abbildung 4 15: Entwickler der Benutzungsschnittstelle ( 30) Abbildung 4 16: Entwickler des Prototyps ( 26) Abbildung 4 17: Auszug einer Checkliste (Quelle: GNOME-Projekt) Abbildung 5 1: Auszug eines Styleguides (Quelle: Microsoft) Abbildung 5 2: Auszug eines Styleguides (Quelle: Microsoft) V

7 Tabellenverzeichnis Tabellenverzeichnis Tabelle 2 1: Übersicht über ausgewählte Studien Tabelle 4 1: Planung von Usability-bezogenen Maßnahmen ( 40) Tabelle 4 2: Schulungen zu Usability-bezogenen Themen ( 17) Tabelle 4 3: Existenz der Rolle des Usability-Experten ( 14) VI

8 Einleitung 1 Einleitung Software kommt in der heutigen Zeit in nahezu allen Bereichen des Lebens vor. Sie wird dabei nicht mehr nur von Experten verwendet, auch Laien benutzen Software täglich. Dabei existieren ganz unterschiedliche Nutzungsszenarien, die vor allem durch das Vorwissen der Personen und die Dauer des Gebrauchs der Software bestimmt sind. Während beispielsweise Personen mit umfangreichem Fachwissen eine Software häufig benutzen, findet dieselbe Software von Personen ohne besondere Vorkenntnisse nur sporadisch Anwendung. Dabei erwarten beide Benutzer eine intuitive Software, die ohne größere Vorbereitung in Form von Schulungen oder Einweisungen bedient werden kann. Unter diesen Bedingungen stellt sich die Frage, wie in der Softwareentwicklung mit den beschriebenen Anforderungen umgegangen werden kann. Neben den funktionalen Anforderungen, in welchen die Funktion der zu entwickelnden Software beschrieben wird, existieren nichtfunktionale Anforderungen, die über die Beschreibung der konkreten Funktion der Software hinausgehen. Häufig auch als Qualitätsanforderungen bezeichnet (Chung et al. 2000), treffen diese unter anderem Aussagen über die Usability der Software. Wie wichtig die nichtfunktionalen Anforderungen sind, lässt sich daran erkennen, dass eine Software vor allem dann für Zufriedenheit beim Benutzer sorgt, wenn sie schnell, robust oder benutzerfreundlich ist (Chung et al. 2000). Während existierende Softwareentwicklungsprozesse die Erhebung von nichtfunktionalen Anforderungen thematisieren und obwohl die Bedeutung klar spezifizierter Usability- Anforderungen in der Literatur stets hervorgehoben wird, sehen die existierenden Prozesse eine explizite Berücksichtigung von Usability-Anforderungen nur selten vor. Es ist daher unklar, inwiefern Usability-Anforderungen in der Praxis tatsächlich erhoben, dokumentiert, umgesetzt und geprüft werden. 1.1 Aufgabenstellung Ziel der vorliegenden Diplomarbeit ist, herauszufinden, welche Rolle Usability- Anforderungen in der Praxis beigemessen wird und ob und wenn ja, wie diese bei der Softwareentwicklung berücksichtigt werden. Dazu ist die Arbeit in drei Teile gegliedert. Zum einen sollte untersucht werden, wie Usability-Anforderungen in existierenden Softwareentwicklungsprozessen, speziell im Requirements Engineering, berücksichtigt werden können. Durch eine Literaturrecherche sollte daher erörtert werden, ob und wie Usabilitybezogene Tätigkeiten durch existierende Prozessmodelle unterstützt werden. 1

9 Einleitung Im Mittelpunkt der Arbeit stand die Industriebefragung zum Thema Usability-Anforderungen in der Praxis. Durch die Befragung von Industriepartnern sollte geklärt werden, wie mit Usability-Anforderungen tatsächlich in der Praxis umgegangen wird, um somit zu ermitteln, welche Rolle diese bei der Softwareentwicklung spielen. Ausgehend von den Ergebnissen der Befragung sollte konstruktiv gezeigt werden, wie mögliche Verbesserungen bei der Erhebung und Dokumentation von Usability-Anforderungen in der Praxis aussehen können. Ursprünglich war geplant, diese Teilaufgabe der Arbeit mit einem der Industriepartner durchzuführen. Im Verlauf der Arbeit wurde jedoch mit dem Prüfer festgelegt, sich nicht nur auf ein einzelnes Unternehmen zu konzentrieren, sondern vielmehr eine für mehrere Unternehmen anwendbare Lösung zu erarbeiten. 1.2 Aufbau der Arbeit In Kapitel 2 werden die Grundlagen der Problemstellung vermittelt, indem der Begriff Usability definiert und erklärt wird. Das Kapitel setzt sich weiter mit der Frage auseinander, wie Anforderungen an Usability erhoben werden können und stellt in Kapitel 2.2 und 2.3 entsprechende Möglichkeiten vor. Kapitel 2.4 gibt einen Überblick zu bisherige Untersuchungen, die zum Thema dieser Diplomarbeit durchgeführt worden sind. Das Kapitel 3 beschreibt die Konzeption und Durchführung der Industriebefragung. Dabei wird der Fragebogen, der den Befragungen zugrunde lag, vorgestellt, und es folgt eine detaillierte Beschreibung der konkreten Durchführung eines Interviews. Zudem wird das Profil der befragten Interviewpartner und Unternehmen vorgestellt. Das Kapitel schließt mit einer Bewertung, die das Vorgehen kritisch betrachtet. Die Auswertung der Industriebefragung mit den gewonnenen Ergebnissen erfolgt in Kapitel 4. Neben einer Bewertung der Ergebnisse werden Verfahren aus der Industrie vorgestellt, die sich bei den Unternehmen als besonders nützlich herausgestellt haben (so genannte Best Practices). Kapitel 5 stellt die aus den Ergebnissen der Industriebefragung konzipierten Verbesserungsvorschläge bezüglich der Berücksichtigung von Usability-Aspekten in einem Softwareentwicklungsprozess vor. Die Arbeit schließt mit einem Fazit und einem Ausblick in Kapitel 6. In Anhang A befindet sich der bei der Industriebefragung verwendete Fragebogen. Wenn Bezug auf Fragen aus diesem Fragebogen genommen wird, werden Verweise auf eine Frage 2

10 Einleitung durch eine Grafik mit Angabe der Nummer der Frage dargestellt. 34 bezieht sich demnach auf Frage 34 des in Anhang A abgebildeten Fragebogens. In Anhang B befindet sich die Aufgabenstellung zur vorliegenden Arbeit. 1.3 Sprachliche Konvention In dieser Arbeit werden Rollenbezeichnungen in ihrer Grundform verwendet, was in der Regel der männlichen Form entspricht. Wenn also vom Projektleiter gesprochen wird, bedeutet dies nicht, dass die Rolle des Projektleiters ausschließlich von einem Mann eingenommen wird. In den hier durchgeführten Interviews wurden sowohl Männer als auch Frauen befragt. 3

11 Grundlagen 2 Grundlagen Dieses Kapitel stellt die theoretischen Grundlagen dieser Arbeit vor. Es wird der Begriff Usability und dessen Verständnis in der vorliegenden Arbeit erläutert. Zudem wird erläutert, in welcher Weise die im Titel der Arbeit aufgeführten Usability-Anforderungen zu interpretieren sind. Außerdem wird gezeigt, was unter Usability Engineering zu verstehen ist und wie Usability in verbreitete Softwareentwicklungsprozesse eingebunden ist oder eingebunden werden kann. Das Kapitel schließt mit einer Vorstellung von Studien, die zu diesem Thema durchgeführt wurden und gibt damit einen Überblick über den aktuellen Stand der Praxis. 2.1 Usability Gebrauchstauglichkeit (engl. Usability 1 ) wird nach DIN EN ISO (Deutsches Institut für Normung 1999) definiert als: Das Ausmaß, in dem ein Produkt durch bestimmte Benutzer in einem bestimmten Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv, effizient und zufriedenstellend zu erreichen. Aus der Definition ist zu erkennen, dass sich die Usability einer Software nicht objektiv bewerten lässt. Sie ist vielmehr von mehreren Faktoren abhängig. System: In der Regel besteht ein System aus Hardware- und Softwarekomponenten, die beide aufeinander abgestimmt sein müssen. Bei interaktiven Systemen, die Gegenstand dieser Arbeit sind, ist der für die Usability ausschlaggebende Teil durch die grafische Benutzungsschnittstelle bestimmt. Wie bedienungsfreundlich das System ist, hängt in diesem Fall demnach stark von der Gestaltung der Benutzungsschnittstelle ab. Benutzer: Die Usability hängt von den Eigenschaften des Benutzers ab. Dabei spielen das Wissen und die Erfahrung des Benutzers in Bezug auf Software im Allgemeinen, aber auch dessen Kenntnisse über die spezielle Software wie beispielsweise ihr fachlicher Hintergrund eine wesentliche Rolle. Ein weiterer Faktor ist die Lernfähigkeit des Benutzers und seine Auffassungsgabe. Ziele: Die Usability einer Software ist abhängig von den Zielen und Aufgaben, die mit ihr erreicht und bewältigt werden sollen. Dabei ist entscheidend, ob sich die Software generell für die Aufgabe eignet, sie also aufgabenangemessen ist, oder ob sie gar nicht für 1 Im deutschen Sprachgebrauch hat sich Usability als Begriff durchgesetzt, so dass in dieser Arbeit im Weiteren ebenfalls Usability dem Begriff Gebrauchstauglichkeit vorgezogen wird. 4

12 Grundlagen die zugrunde liegende Problemstellung konzipiert ist. Schließlich existiert eine Software nicht zum Selbstzweck, sondern dient einem Benutzer als Werkzeug für bestimmte Aufgaben. Usability wird demnach nicht nur von der Software 2, sondern auch vom Nutzungskontext, in welchem sie benutzt wird, beeinflusst. Abbildung 2 1 (angelehnt an Bevan 1995) verdeutlicht diesen Zusammenhang: Es handelt sich um ein Zusammenspiel von Benutzer, Software und Aufgabe in einem bestimmten technischen, physischen, sozialen und organisatorischen Kontext. Nutzungskontext Ziele Sozialer und organisatorischer Kontext Physischer Kontext Technischer Kontext Benutzer Interaktion Software Abbildung 2 1: Usability im Nutzungskontext (nach Bevan) 2 Der Fokus dieser Arbeit liegt auf interaktiven Informationssystemen, die mit Standardhardware wie Maus oder Tastatur bedient und über gewöhnliche Bildschirme angezeigt werden. Der Faktor Hardware kann daher vernachlässigt werden, weswegen im Weiteren von Software anstatt System gesprochen wird. 5

13 Grundlagen Ob eine Software eine gute oder schlechte Usability aufweist, kann folglich verallgemeinernd nicht beantwortet werden. Bevan (1995) führt in diesem Zusammenhang auf, dass eine Software, deren Usability unerfahrene Benutzer als schlecht bewerten würden, durchaus eine gute Usability für erfahrene Benutzer bieten kann. Neben dem beschriebenen allumfassenden Verständnis von Usability, welches neben der Software auch Benutzer und Ziele einbezieht, nennt Bevan (1995) noch eine weitere Möglichkeit, Usability zu definieren ( narrow and broad approach ). Diese Möglichkeit versteht Usability im Sinne von Bedienbarkeit und lässt Benutzer und deren Ziele außen vor. Es werden also in erster Linie das Aussehen und das Verhalten der Benutzungsoberfläche betrachtet. Soziale Akzeptanz Praktische Akzeptanz Kosten Nützlichkeit Systemakzeptanz Kompatibilität Verlässlichkeit Brauchbakeit Bedienbarkeit Abbildung 2 2: Bedienbarkeit im Modell unter Systemakzeptanz (nach Nielsen) Abbildung 2 2 zeigt, wie sich dieses engere Verständnis von Usability (hier: Bedienbarkeit) in das Modell zur Systemakzeptanz einordnet (Nielsen 1993). Die Systemakzeptanz, also die Frage, inwiefern ein System vom Benutzer akzeptiert oder bewertet wird, wird in zwei Bereiche unterteilt: Soziale und praktische Akzeptanz. Während die soziale Akzeptanz damit zu tun hat, wie sich die Ziele, die mit der Software erreicht werden sollen, in das soziale Gesellschaftsbild einordnen lassen, hängt die praktische Akzeptanz von der Software selbst ab. Dabei spielen nach Nielsen (1993) die Kategorien Kosten, Verlässlichkeit, Kompatibilität zu existierenden Systemen und die Brauchbarkeit eine entscheidende Rolle. Die 6

14 Grundlagen Brauchbarkeit der Software ergibt sich aus dem Nutzen, den die Software schafft, und der Bedienbarkeit, die die Software bietet. Es gibt jedoch einige Punkte, die das Modell in seiner dargestellten Form in Frage stellen. Beispielsweise ist stark zu bezweifeln, ob die in der Kategorie der praktischen Akzeptanz aufgeführten Punkte sich wirklich so separieren lassen. So beeinflusst die Verlässlichkeit einer Software ebenso die Brauchbarkeit. Nach diesem Verständnis kann es eine Software geben, die gut bedienbar, gleichzeitig aber nicht nützlich ist. Sie ist also an sich gut und ansprechend gestaltet, bietet aber nicht die gewünschte Funktionalität, was sie letztendlich nutzlos macht. Die Interpretationen von Usability sind im Modell der Systemakzeptanz nach Nielsen (1993) und der DIN EN ISO Norm sehr unterschiedlich. Die DIN-Definition versteht Usability nicht nur als Bedienbarkeit, vielmehr geht es bei Usability im Verständnis der Norm um die Ziele des Benutzers, welche effektiv, effizient und zufriedenstellend erreicht werden sollen. Außerdem fließt der Nutzungskontext, in welchem die Software zum Einsatz kommt, mit ein. All diese Aspekte hängen mit den unter Praktische Akzeptanz aufgeführten Kategorien zusammen, so dass es nicht sinnvoll erscheint, Usability allein als Bedienbarkeit zu interpretieren. Diese weiter gefasstere Definition von Usability nach DIN EN ISO ist Grundlage der vorliegenden Arbeit Usability-Anforderungen Wie in der Aufgabenstellung zu dieser Arbeit in Kapitel 1.1 genannt ist, zählen Anforderungen an die Usability einer Software zu den nichtfunktionalen Anforderungen. Lauesen & Younessi (1998) geben an, dass Usability-Anforderungen festlegen, wie einfach eine Software zu bedienen sein muss. Usability-Anforderungen sind nach ihrer Aussage deswegen nichtfunktionale Anforderungen, weil durch sie nur spezifiziert wird, wie die Funktionalität der Software durch den Benutzer wahrgenommen wird. Die Norm ISO/IEC 9126 ist ein Modell zur Sicherstellung von Softwarequalität (International Organization for Standarization 1991). In ihr werden verschiedene Qualitätsmerkmale genannt. Unter den sechs Merkmalen und 25 Teilmerkmalen trifft ein Punkt auch Aussagen zur Usability. Das Qualitätsmerkmal Usability stellt dabei die Frage, welchen Aufwand der Einsatz der Software vom Benutzer fordert und wie er vom Benutzer beurteilt wird. Die Teilmerkmale sind: 7

15 Grundlagen Verständlichkeit: Der Aufwand für den Benutzer, das Konzept der Software zu verstehen Erlernbarkeit: Der Aufwand für den Benutzer, die Bedienung der Software zu erlernen Bedienbarkeit: Der Aufwand für den Benutzer, die Software zu bedienen Attraktivität: Der Anreiz der Software auf den Benutzer, mit ihr zu arbeiten Konformität: Der Grad, zu welchem die Software Gestaltungsnormen folgt Diese Anforderungen an die Usability können nicht direkt gemessen werden. Die einzelnen Anforderungen müssen greifbar gemacht werden, so dass sie in gewisser Weise indirekt gemessen werden können. Dabei können beispielsweise Vorgaben an die maximale Zeit, die ein Benutzer für eine bestimmte Aufgabe benötigen darf, ein Kriterium sein, um einige der genannten Teilmerkmale zu messen. Eine weitere Möglichkeit ist die Angabe einer maximalen Fehleranzahl, die bei der Absolvierung einer Aufgabe nicht überschritten werden sollte. Dabei handelt es sich nicht um Fehler der Software, sondern um Fehler, die dem Benutzer bei der Bedienung der Software unterlaufen. Außerdem helfen persönliche Befragungen, um nicht quantifizierbare Aspekte wie die Attraktivität einer Software auf den Benutzer bewerten zu können. Jokela et al. (2006) beschreiben, wie solche Anforderungen an die Usability bei der Entwicklung einer Benutzungsoberfläche für ein Mobiltelefon aussahen. Beim beschriebenen Fall wurden für einzelne Aufgaben maximale Zeiten definiert, die ein typischer Benutzer zur Erledigung der jeweiligen Aufgabe benötigen darf. Als Ausgangs- oder Vergleichswerte dienten die Zeiten, die mit der Vorgängerversion der Benutzungsschnittstelle erreicht wurden. Der Hintergrund solcher Festlegungen ist: Die (neue) Benutzungsschnittstelle muss eine Usability haben, die es dem Benutzer ermöglicht, die entsprechende Aufgabe in der vorgegebenen Zeit zu erledigen. Die damit dokumentierten Anforderungen sind quantifiziert und können geprüft werden. Dies ist somit ein möglicher Weg, Usability, wie zuvor beschrieben, indirekt zu messen. Solche Vorgehensmaßnahmen haben sich in der Literaturrecherche jedoch als Einzelfälle herausgestellt, so dass vermutet werden kann, dass sich derartige explizit dokumentierten und quantifizierten Usability-Anforderungen nicht oder nur sehr vereinzelt in der Praxis 8

16 Grundlagen finden lassen 3. Vielmehr hat sich herausgestellt, dass die Usability einer Software sowohl von vielen verschiedenen Produktmerkmalen als auch von unterschiedlichen Vorgehensweisen in der Softwareentwicklung beeinflusst wird. Es ist daher sinnvoll, den gesamten Softwareentwicklungsprozess eines Unternehmens in Bezug auf die Usability beeinflussenden Maßnahmen zu untersuchen. In der vorliegenden Arbeit werden unter Usability-Anforderungen daher nicht ausschließlich quantifizierbare Anforderungen an die Usability im Sinne von nichtfunktionalen Anforderungen innerhalb eines Requirements-Engineering-Prozesses verstanden. Der Begriff Usability-Anforderungen umfasst all jene Tätigkeiten und Aspekte, die Einfluss auf die Usability einer Software haben. Diese Tätigkeiten und Aspekte kommen im gesamten Softwareentwicklungsprozess, das heißt von der Anforderungsanalyse über Design und Implementierung bis zur Prüfung und dem Support vor. 2.2 Usability Engineering Usability Engineering ist ein Teilgebiet der Mensch-Computer-Interaktion. Im Usability Engineering wird die Erstellung von Software mit Hilfe spezieller Techniken und Prozesse, die zu einer guten Usability führen, angestrebt. Als Ergebnis wird auf eine gute Usability der Software hingearbeitet. In der Literatur werden eine Menge von Vorgehens- und Prozessmodellen zum Usability Engineering beschrieben. Bekannte Modelle sind vor allem der Usability Engineering Lifecycle von Nielsen (1993), Contextual Design von Beyer & Holtzblatt (1998), der Usability Engineering Lifecycle von Mayhew (1999) und Scenario-based Design von Rosson & Carroll (2002). Dabei haben alle Vorgehensmodelle gemeinsam, dass sie den Benutzer frühzeitig einbeziehen, den Entwicklungsprozess in mehreren Zyklen durchführen und den Kontext, in welchem die Software ausgeführt werden soll, stärker beachten. Zu diesem Zweck sind in den Vorgehensmodellen Verfahren vorgeschlagen, die zur Einhaltung dieser Vorhaben führen. Dabei unterscheiden sich die Vorgehensmodelle in erster Linie in der Auswahl der vorhandenen Verfahren. Neben den genannten Vorgehensmodellen existiert außerdem die Norm DIN EN ISO 13407, die einen iterativen Entwicklungsprozess beschreibt, in welchem die Eigenschaften 3 Dass sich diese Vermutung bestätigt hat, ist in Kapitel 4 und ganz speziell in Kapitel ausführlich beschrieben. 9

17 Grundlagen der Benutzer und deren Aufgaben im Vordergrund stehen und die Entwicklung bestimmen (Deutsches Institut für Normung 2000) Verfahren aus dem Usability Engineering Im Folgenden werden häufig vorgeschlagene Verfahren aus den zuvor genannten Usabilitybezogenen Vorgehens- und Prozessmodellen vorgestellt. Im Einzelnen sind das Benutzerprofile, Aufgabenanalysen, Mock-up-Erstellung / Prototyping, Heuristische Evaluation, Cognitive Walkthrough, Usability-Testing und Fragebögen und Interviews. Benutzerprofile Es gibt verschiedene Arten von Benutzern mit unterschiedlichen Eigenschaften und Voraussetzungen in Bezug auf den Gebrauch der Software. Benutzerprofile geben einen Überblick über die Benutzer, die mit der Software arbeiten werden und ermöglichen damit frühzeitige individuelle Anpassungen. So ist es ein erheblicher Unterschied, ob ein Benutzer eine Software nur selten oder sehr häufig benutzt beide Arten von Benutzern stellen andere Ansprüche an die Software, insbesondere was die Erlernbarkeit und die Möglichkeiten zur Interaktion betrifft. Tastenkombinationen sind für Experten, die die Software häufig benutzen, ein Weg um effizienter mit der Software zu arbeiten. Unerfahrene Benutzer, die die Software zudem nur unregelmäßig benutzen, kennen jene Tastenkombinationen in der Regel nicht oder wenden sie nur selten an (Mayhew 1999). Ein Benutzerprofil sollte nach Mayhew (1999) Aussagen zu den folgenden Eigenschaften treffen: Psychologische Eigenschaften (zum Beispiel Einstellung und Motivation der Benutzer) Wissen und Erfahrung (beispielsweise allgemeine Erfahrung mit Computern und fachliche Kenntnisse) Beruf- und Aufgabeneigenschaften (zum Beispiel die Häufigkeit der Durchführung bestimmter Abläufe) Physische Eigenschaften (beispielsweise die Frage, ob ein Benutzer farbenblind ist) Diese Eigenschaften lassen sich durch Interviews mit strukturierten Fragebögen herausfinden. Mayhew (1999) weist außerdem darauf hin, dass einige Informationen aus der Marketing- oder Personalabteilung eines Unternehmens gewonnen werden können. Benutzerprofile kommen daher dem Modell der Persona (ursprünglich in Cooper 1999 vorgestellt) sehr ähnlich. Eine Persona ist jedoch noch konkreter definiert als ein Benutzerpro- 10

18 Grundlagen fil: Als eine Art imaginäres Modell einer Person werden bei jeder Persona konkrete Eigenschaften wie beispielsweise der Name, die Art der Ausbildung und das entsprechende Nutzungsverhalten angegeben. Aufgabenanalysen Bei Aufgabenanalysen werden die Aufgaben eines Benutzers und die konkreten Ziele, die ein Benutzer mit der Software erreichen will, ermittelt. Nach Mayhew (1999) sind Aufgabenanalysen besonders dann angebracht, wenn bereits Funktionen oder Merkmale bekannt sind, die nicht automatisch von der Software abgearbeitet werden können. Durch eine Aufgabenanalyse soll bei manuellen Arbeitsschritten herausgefunden werden, wie der Benutzer die Aufgabe bisher erledigt hat. Diese Information kann ermittelt werden, indem direkt mit den Benutzern über die Aufgaben gesprochen wird und die Benutzer bei der Arbeit in ihrer normalen Arbeitsumgebung beobachtet werden und gezielte Nachfragen gestellt bekommen. Eine Aufgabenanalyse beinhaltet folgende grundlegende Schritte: Beschaffen von Hintergrundinformationen der zu automatisierenden Arbeit Sammeln und Analysieren von Daten aus Beobachtungen und Befragungen mit Benutzern, während diese ihrer normalen Arbeit in ihrer gewöhnlichen Arbeitsumgebung nachgehen Konstruieren (und Validieren) eines Modells über die Arbeitsvorgänge des Benutzers Mock-up-Erstellung / Prototyping Mock-ups bieten die Möglichkeit, frühzeitig in der Entwicklung Rückmeldung von den Benutzern einzuholen. Dabei kommt es bei den Mock-ups laut Mayhew (1999) nicht darauf an, ob es sich um lauffähige Prototypen handelt; Papierprototypen sind in frühen Entwicklungsphasen genauso effektiv. Da die Zeit zum Erstellen eines solchen Mock-ups gering ist, empfiehlt Mayhew (1999), dem Benutzer mehrere unterschiedliche Varianten zu präsentieren. Nielsen (1993) weist auf die unterschiedlichen Dimensionen des Prototypings hin: Horizontales Prototyping versucht so viel Funktionen wie möglich anzubieten, geht dabei aber nicht in die Tiefe. Vertikales Prototyping bietet nur einen geringen Teil der finalen Software an, die realisierten Funktionen sind jedoch bereits funktionsfähig. 11

19 Grundlagen Der Vorteil des horizontalen Prototypings besteht darin, dass Benutzungsschnittstellen mit entsprechenden Werkzeugen rasch erstellt werden können, so dass es auf diese Weise möglich ist, das Look & Feel der Software effizient mit dem Benutzer abzusprechen. Das vertikale Prototyping, welches im Usability Engineering kaum Anwendung findet, dient dabei in erster Linie zur Klärung der funktionalen Anforderungen. Heuristische Evaluation Die Heuristische Evaluation ist ein auf grafische Benutzungsschnittstellen angewendetes systematisches Prüfverfahren. Dabei untersuchen Experten die Benutzungsoberfläche und bewerten die Kompatibilität zu anerkannten Gestaltungsnormen oder vorhandenen Styleguides. Eine Heuristische Evaluation wird in ihrer formalen Form durchgeführt, indem mehrere Experten Dialoge der Benutzungsoberfläche unabhängig voneinander bewerten. Die beanstandeten Mängel werden notiert und von allen Experten eingesammelt. Dabei ist die Anzahl der Experten maßgebend: Nielsen (1993) gibt an, dass ein einzelner Experte durchschnittlich ca. 35 % der Usability-bezogenen Probleme entdeckt, wohingegen fünf Experten bereits fast 75 % und zehn Experten 85 % der Usability-bezogenen Probleme aufspüren. Ein großer Vorteil dieser Methode ist, dass sie bereits früh in der Entwicklung angewendet werden kann, da nicht zwingend eine lauffähige oder voll funktionsfähige Software vorausgesetzt wird. Es ist dabei wichtig zu bemerken, dass dieses Verfahren sich nur auf die Gestaltung der Benutzungsschnittstelle bezieht also auf die Bedienbarkeit, wie sie in Kapitel 2.1 beschrieben ist. Cognitive Walkthrough Cognitive Walkthrough ist ein weiteres auf grafische Benutzungsschnittstellen angewendetes systematisches Prüfverfahren. Dabei untersuchen Experten die Gestaltung der Benutzungsoberfläche und bewerten, ob ein Benutzer die von ihm mit dem entsprechenden Dialog zu erledigenden Aufgaben auch wirklich erledigen kann. Den Experten müssen also neben dem Dialog auch eine Aufgabenbeschreibung, explizite Angaben zum Kenntnisstand des Benutzers, des Nutzungskontexts und eine Reihe von Aktivitäten, die der Benutzer erfolgreich zur Erledigung der Aufgabe absolvieren können sollte, vorliegen (Polson et al. 1992). Die Bewertung erfolgt, indem sich einer der Experten 12

20 Grundlagen laut denkend in die Situation des Benutzers hineinversetzt und versucht, dessen Gedanken nachzuvollziehen und damit mit der Benutzungsoberfläche zu interagieren. Da das Verfahren keine lauffähige Software benötigt, sondern bereits simple Zeichnungen der Benutzungsoberfläche ausreichen, kann es in sehr frühen Entwicklungsstadien eingesetzt werden. Cognitive Walkthrough verfolgt dabei andere Ziele als die Heuristische Evaluation: Im Vordergrund steht das Ziel des Benutzers und die möglichst effiziente Abarbeitung der dazu nötigen Aufgaben. Es kommt nicht oder nur zu einem kleinen Teil auf das konkrete Aussehen verschiedener Elemente der Benutzungsschnittstelle an. Usability-Testing Usability-Testing ist ein systematisches, empirisches Prüfverfahren, welches auf Software mit einer grafischen Benutzungsschnittstelle angewendet wird. Bei einem Usability-Test müssen repräsentative Benutzer typische Aufgaben, welche so oder in ähnlicher Form auch später zu erledigen sein müssen, mit der Software lösen. Dabei werden die Aktionen und Reaktionen der Benutzer typischerweise auf Video aufgezeichnet oder zumindest beobachtet. Ziel des Vorgehens ist es, jene Stellen der Software zu identifizieren, bei welchen der Benutzer bei Erledigung seiner Aufgaben Probleme hat oder er vom vorgesehenen Ablauf abweicht. Nach Nielsen (1993) ist eine Möglichkeit des Usability-Tests, dass der Benutzer seine Gedanken während der Benutzung der Software laut ausspricht. Bei dem Thinking Aloud genannten Verfahren ist es für die beobachtenden Personen möglich, Entscheidungen der Benutzer nachzuvollziehen und damit mögliche Schwachstellen bei der Gestaltung der Benutzungsoberfläche zu identifizieren. Aufgrund der verschiedenen technischen Möglichkeiten, die bei einem Usability-Test eingesetzt werden, wird im Zusammenhang der Durchführung oft das Usability-Lab genannt. In einem solchen Labor sind Ton- und Videoaufzeichnungen, Tracking-Software oder Blickbewegungsregistrierungssysteme installiert. Um Usability-Tests durchzuführen, ist ein solches Labor jedoch nicht zwingend notwendig. Fragebögen und Interviews Laut Nielsen (1993) können viele Usability-Aspekte am besten durch eine Befragung des Benutzers erfasst werden. Das ist besonders dann der Fall, wenn es sich um Probleme bezüglich der Zufriedenheit der Benutzer oder um Vorbehalte gegenüber bestimmter Software handelt. Fragebögen und Interviews bieten sich außerdem dann an, wenn herausge- 13

21 Grundlagen funden werden soll, welche Funktionen der Benutzer mag oder wie er die Software benutzt. Diese indirekten Prüfverfahren sind jedoch auch mit Schwierigkeiten versehen. So beschreibt Nielsen (1993) wie Benutzer gefragt worden sind, welche Befehle sie kennen. In einer weiteren offenen Frage sollten einige Befehle vom Befragten beschrieben werden. Obwohl 26 % der Befragten einen bestimmten Befehl nicht kannten, kommentierten sie denselben in der anderen Frage. Solche Effekte sind ebenfalls in allgemeiner Literatur zur Fragenbogengestaltung und Interviewführung ausführlich erklärt und beschrieben (Porst 2008). Mayhew (1999) betont, dass diese Verfahren zur Einholung von Feedback besonders nach Fertigstellung und Auslieferung der Software wichtig sind, da die Meinung der Benutzer oftmals Ideen bezüglich Verbesserungen für Folgeversionen und ähnliche Softwareprodukte liefert Bewertung des Usability Engineerings Die beschriebenen Verfahren aus dem Usability Engineering stellen einen engen Kontakt zu den Benutzern her und binden diese in sämtliche Phasen der Entwicklung ein. Mit Hinblick auf die Definition aus Kapitel 2.1 sind diese Verfahren gut geeignet, um die Eigenschaften, Ziele und Aufgaben der Benutzer und den Nutzungskontext der zu entwickelnden Software zu ermitteln. Die Verfahren bieten somit eine gute Voraussetzung, um Software mit guter Usability zu entwickeln. Das Usability Engineering beschreibt mit seinen Vorgehens- und Prozessmodellen jedoch keine vollständigen Softwareentwicklungsprozesse, sondern versteht sich als Ergänzung zu existierenden Prozessmodellen aus dem Software Engineering. Denn bei allen in Kapitel genannten Verfahren bleibt unklar, wie die funktionalen Anforderungen im Rahmen eines Softwareprojekts erhoben werden oder in welcher Weise funktionale Tests durchzuführen sind. Die Gründe für diese Tatsache sind unbekannt. So wird die Verwendung einiger der beschriebenen Verfahren zumindest in ähnlicher Weise auch in existierenden Softwareprozessmodellen vorgeschlagen. Eine Kombination aus der nichtfunktionalen und der funktionalen Sicht scheint daher durchaus möglich zu sein. 14

22 Grundlagen 2.3 Usability im Softwareentwicklungsprozess Dieses Kapitel erörtert, inwiefern Usability in bekannte Softwareentwicklungsprozesse integriert ist. Dabei stellt sich die Frage, an welchen Stellen Usability-bezogene Aktivitäten im Prozess vorkommen und ob ein solcher Prozess als Ganzes zur Entwicklung von Software mit guter Usability führt. Nach Gould (1988) sind für die Entwicklung einer Software mit guter Usability die folgenden vier Punkte ausschlaggebend: Frühzeitiger und kontinuierlicher Kontakt zu Benutzern Frühzeitiges und kontinuierliches Testen mit Benutzern Iterative Entwicklung Integrative Entwicklung, das heißt parallele Entwicklung aller Usability-bezogenen Aspekte (Erstellung von Handbuch, Übersetzung, Benutzungsoberfläche, etc. zur selben Zeit) Ob und wie existierende Softwareentwicklungsprozesse diese Punkte beachten, wird im folgenden Kapitel dargestellt. Dabei werden auch Arbeiten vorgestellt, die die Integration der von Gould (1988) genannten Punkte in existierende Softwareentwicklungsprozesse beschreiben Erweiterungen existierender Softwareentwicklungsprozesse Costabile (2001) hat das Wasserfallmodell in Bezug auf die Berücksichtigung von Usability- Aspekten untersucht. Sie stellt fest, dass Usability im Wasserfallmodell nicht behandelt wird. Dabei gibt sie Punkte an, die im Wasserfallmodell als nicht förderlich für die Usability der zu entwickelnden Software gelten. Die Software wird erst am Ende eines Durchlaufs getestet, wenn es zu spät für radikale Design-Änderungen ist, die aufgrund von Diskrepanzen zu den Anforderungen nötig wären. Anforderungen werden mit dem Kunden erarbeitet. Da der Kunde jedoch nur selten einen typischen Benutzer der Software darstellt, fehlt die Sichtweise des Benutzers, aus welcher die wichtigen Aspekte wie Eigenschaften und Aufgaben der Benutzer gewonnen werden könnten. 15

23 Grundlagen Anforderungen sind in der Regel auf funktionale Anforderungen beschränkt, so dass vor allem nichtfunktionale Anforderungen, wie die Erlernbarkeit, die Bedienbarkeit, Sicherheit etc. nicht dokumentiert werden. Als direkte Konsequenz aus den genannten Aspekten ergibt sich das Problem, dass die Usability der Software dadurch, dass sich der Softwaretest auf die dokumentierten Anforderungen bezieht, nicht explizit getestet wird. Allerdings ist anzumerken, dass sich einige der genannten Punkte nicht ausschließlich oder in besonderem Maße auf das Wasserfallmodell beziehen lassen. Sie sind jedoch typisch für verbreitete Softwareprozessmodelle beziehungsweise für die Art und Weise wie diese durchgeführt werden. Göransson, Lif & Gulliksen (2003) vergleichen die von Gould (1988) genannten Anforderungen mit dem Rational Unified Process (RUP) und prüfen dabei, welche Bedeutung Usability in diesem Softwareentwicklungsprozess besitzt und inwiefern der Prozess die Entwicklung von Software mit guter Usability unterstützt. Sie schließen mit dem Fazit, dass der RUP nicht die benötigte Unterstützung liefert, um Software mit guter Usability zu entwickeln. Unter anderem nennen Göransson, Lif & Gulliksen (2003) folgende Gründe: Der RUP ist ein Prozess, dessen Fokus auf der Erstellung guter Architektur und Use Cases liegt. Benutzer stehen daher nicht im Vordergrund. Usability-bezogene Aktivitäten kommen lediglich in der Requirements Discipline und hauptsächlich in der Elaboration Phase, also in der Anforderungsanalyse und der Prüfphase, zum Einsatz. Aus Usability-Perspektive sollten Usability-bezogene Aktivitäten allerdings über das gesamte Projekt hinweg durchgeführt werden. Es existiert keine Unterstützung für die Gestaltung von Benutzungsoberflächen. Zwar wird die Interaktion zwischen den Akteuren und den Use Cases beschrieben, bezüglich der Gestaltung von Benutzungsoberflächen, welche diese Interaktionen ermöglichen sollen, bietet der RUP jedoch nur unzureichend Unterstützung. Erschwerend kommt hinzu, dass die Unified Modeling Language (UML) nicht ausreichend zwischen Systemakteur und einem menschlichen Akteur unterscheidet, gerade diese Unterscheidung in Bezug auf die Usability der Software aber entscheidend ist. Use Cases sind nicht optimal, um mit dem Benutzer geeignet zu kommunizieren. Die Notation kann von Benutzern nur schwer verstanden werden, was in erster Linie darin begründet liegt, dass bei Use Case-Diagrammen Aufgaben abgebildet werden, die konkrete Interaktion zwischen Software und Benutzer allerdings nicht ersichtlich ist. 16

24 Grundlagen Die Art und Weise der Beschreibung der Use Cases kann Einfluss darauf haben, wie die Benutzungsoberfläche später tatsächlich gestaltet wird. So geben Göransson, Lif & Gulliksen (2003) an, bereits einige Beispiele in der Praxis gesehen zu haben, in welchen die Use Case-Beschreibung genau jene Bedienelemente definiert, die die Benutzungsoberfläche enthalten soll. Auch Sousa & Furtado (2003) identifizieren einige Aspekte, die bei der Entwicklung von interaktiver Software mit dem RUP hinderlich sind. Diese Aspekte sind: Benutzer werden im gesamten Softwareentwicklungsprozess nicht einbezogen. Dieser Punkt gleicht der Feststellung von Göransson, Lif & Gulliksen (2003). Internationale und interkulturelle Aspekte werden während der Gestaltung der Benutzungsoberfläche nicht betrachtet. Laut Nielsen (1993) sind diese Aspekte jedoch vielschichtig und nicht zu vernachlässigen. So geht es dabei nicht nur um die Übersetzung von Texten, die entsprechend in die Gestaltung der Benutzungsoberfläche passen müssen. Es muss vielmehr darauf geachtet werden, dass mögliche Sonderzeichen aus anderen Sprachen unterstützt werden. Darüber hinaus sind Herausforderungen wie unterschiedliche Interpretationen von Symbolen in verschiedenen Ländern oder Kulturen zu berücksichtigen. Es besteht keine Möglichkeit, die Entwicklung der grafischen Benutzungsschnittstelle Nutzer-zentriert zu gestalten. Die Gestaltung der Benutzungsoberfläche läuft ohne Einbeziehung der Benutzer ab, die Benutzer werden also nicht in die Prüfung und Entwicklung der Benutzungsschnittstelle eingebunden. Es finden demnach während der Entwicklung der Benutzungsschnittstelle keine von Benutzern initiierten Anpassungen statt. Ausgehend von der bereits aufgeführten Kritik am Wasserfallmodell und dem RUP werden von den genannten Autoren jedoch Vorschläge genannt, wie Usability im jeweiligen Prozessmodell besser berücksichtigt werden kann. Costabile (2001) führt Aktivitäten in das Wasserfallmodell ein, so dass Usability-bezogene Aspekte explizit berücksichtigt werden. Die hauptsächlichen Änderungen am Prozess werden im Folgenden genannt und sind in Abbildung 2 3 dargestellt. 17

25 Grundlagen Abbildung 2 3: Verändertes Wasserfallmodell (Quelle: Costabile) Einführung spezieller Usability-Techniken: In der Phase der Anforderungsanalyse werden Benutzer- und Aufgabenanalysen durchgeführt (Kästchen 1). In den zwei Design- Phasen sollen Szenarien erstellt und die Benutzungsschnittstelle spezifiziert werden (Kästchen 2). Die Design-Phasen, speziell die Erstellung der Benutzungsschnittstelle, erfolgt in Iterationen mit Hilfe von Prototypen. Die Kästchen 3 und 4 verdeutlichen diesen Sachverhalt: Die Benutzungsschnittstelle wird in Form von Prototypen entworfen, die von den Benutzern getestet und entsprechend wieder angepasst wird. Dieser Zyklus endet erst dann, wenn alle Anforderungen erfüllt sind. Es ist zu jedem Zeitpunkt möglich wieder zurück zur Anforderungsanalyse zu gehen. Dies wird durch die gepunkteten Linien in Abbildung 2 3 dargestellt. 18

26 Grundlagen Göransson, Lif & Gulliksen (2003) schlagen die Einführungen einer neuen Discipline Usability Design vor, die den RUP erweitert. Dies soll helfen, einen eher Nutzer-orientierten Ansatz zu etablieren. Die Integration der neuen Discipline in das Modell des RUPs ist in Abbildung 2 4 dargestellt. Wie zu erkennen ist, werden durch diese Discipline Usability- Aspekte im gesamten Entwicklungsprozess betrachtet. Neben der Einführung neuer Rollen (unter anderem die des Usability-Designers) und der Aufbereitung der Arbeitsaufgaben in Form eines Workflows, enthält die Discipline zwölf Best Practices, welche in den Projekten, in welchen hoher Wert auf Usability gelegt wird, angewendet werden sollen. Diese zwölf Best Practices bestehen in erster Linie aus solchen Maßnahmen wie sie auch von Gould (1988) genannt werden (siehe Kapitel 2.3). Abbildung 2 4: RUP mit Usability Design Discipline (Quelle: Göransson et al.) Sousa & Furtado (2003) erweitern in ihrer Arbeit ebenfalls den RUP. Allerdings führen sie keine neue Discipline ein, sondern ergänzen verschiedene Workflows um neue Aktivitäten. Ein Beispiel einer solchen Ergänzung ist das Assess Business Status Workflow Detail aus dem Business Modeling Workflow. Der Business Process Analyst ist typischerweise dafür verantwortlich, die Ziele, das Vokabular und die Regeln des Unternehmens zu verstehen und die entsprechenden Informationen zu dokumentieren. Sousa & Furtado (2003) ergänzen diese Aufgabe, indem sie eine zusätzliche Rolle, die des User Interface-Designers (UI-Designers), 19

27 Grundlagen integrieren. Die Aufgabe des UI-Designers ist die Modellierung des Nutzungskontexts. Gerade in diesem Aufgabengebiet können sich beide Rollen unterstützen und tragen somit gemeinsam zum neuen Dokument, in welchem der Nutzungskontext dokumentiert ist, bei. Abbildung 2 5 zeigt dieses Zusammenspiel. Abbildung 2 5: Verändertes Workflow Detail im RUP (nach Sousa & Furtado) Weitere Modifikationen finden in den Workflow Details Refine Roles and Responsibilities, Define the System, Refine the System Definition, Analyze Behaviour, Refine Architecture und Design Components statt Bewertung Usability wird in verbreiteten Softwareprozessmodellen nur unzureichend unterstützt. Dabei wird von den hier zitierten Autoren in erster Linie bemängelt, dass die Prozesse den Benutzer nicht einbinden, was für Software, die eine gute Usability haben soll, von entscheidender Bedeutung ist. Dementsprechend beziehen sich die vorgeschlagenen Verbesserungen allesamt auf den stärkeren Kontakt zum Benutzer, der über den gesamten Entwicklungsprozess bestehen soll. Zusätzlich binden die Autoren an geeigneten Stellen Verfahren aus dem Usability Engineering (siehe Kapitel 2.2.1) ein. Weitere Arbeiten, die ähnliche Änderungen oder Erweiterungen vorschlagen, sind Anderson et al. 2001, Ferré 2003 und Granollers, Lorés & Perdrix

28 Grundlagen Letztendlich unterscheiden sich die beschriebenen Vorschläge prinzipiell nicht sonderlich. Es ist außerdem nicht bekannt, ob einer der vorgeschlagenen Prozesse bereits in der Praxis evaluiert oder validiert worden ist kein Autor weist auf entsprechende Aktivitäten hin. 2.4 Stand der Praxis Die Frage nach dem Stand der Praxis, also die Frage danach, wie mit dem Thema Usability in der Industrie umgegangen wird, ist Gegenstand der vorliegenden Arbeit. Ähnliche Arbeiten mit entsprechenden empirischen Untersuchungen sind bereits durchgeführt und veröffentlicht worden. Ein klares Bild erhält man bei Betrachtung der veröffentlichten Studien jedoch nicht zu unterschiedlich sind die einzelnen Rahmenbedingungen und auch die Ergebnisse zeichnen ein unscharfes Bild Übersicht über Studien zum Stand der Praxis Ein Überblick über vier ausgewählte Studien zum Thema Usability in der Praxis gibt Tabelle 2 1. Alle Studien hatten das Ziel, die Verbreitung von Usability-bezogenen Techniken und den generellen Umgang mit Usability in den Unternehmen zu untersuchen. Autoren Zielgruppe Ort Teilnehmerzahl Rosenbaum, Rohn & Usability-Interessierte USA 134 Humburg 2000 Gulliksen et al Usability-Experten Schweden 194 Vredenburg et al Usability-Interessierte USA 103 Bygstad, Ghinea & Brevik 2008 IT-Manager Norwegen 78 Tabelle 2 1: Übersicht über ausgewählte Studien Rosenbaum, Rohn & Humburg (2000) führten ihre Studie im Rahmen der beiden Usability-Konferenzen ACM Conference on Human Factors in Computing Systems (CHI) und Usability Professionals Association (UPA) durch, indem sie ihren Fragebogen, der zehn Fragen enthält, dort veröffentlicht haben. Die Teilnehmer sind somit Personen, die Interesse am Thema Usability zeigen. Für diese Arbeit relevante Ergebnisse der Studie sind: Usability-Tests in Usability-Labs führen 65 % der Befragten durch. 70 % der Befragten setzen Heuristische Evaluation ein. Aufgabenanalysen werden von 62 % der Unternehmen durchgeführt. 21

29 Grundlagen Die von Gulliksen et al. (2004) durchgeführte Studie ist an Usability-Experten gerichtet, was bedeutet, dass die Personen entweder eine entsprechende Berufsbezeichnung tragen oder nach eigenen Aussagen im Unternehmen für die Usability einer bestimmten Software verantwortlich sind. Die Studie ist mittels eines Online-Fragebogens erhoben worden, wobei der Hinweis auf den Fragebogen über das persönliche Netzwerk der Autoren per E- Mail verbreitet worden ist. Ergebnisse der Studie sind: Prüfverfahren wie Heuristische Evaluation oder andere spezielle Usability-Techniken werden von weniger als 10 % der Befragten eingesetzt. 75 % der Befragten geben an, Benutzer in die Entwicklung einzubeziehen. Dennoch sind 62 % der Befragten der Ansicht, zu wenig Zeit mit den Benutzern zu verbringen. Vredenburg et al. (2002) führen ihre Studie über einen Online-Fragebogen durch, der sich an Usability-Interessierte richtet, wobei die Einladungen an Mitglieder von Usability- Konferenzen (CHI und UPA) gesandt worden sind. Dabei ergeben sich folgende Ergebnisse: Heuristische Evaluation setzen 14 % der Befragten ein. 63 % der Befragten geben an, dass sie iterativ entwickeln. Aufgabenanalysen machen 33 % der Befragten. Bygstad, Ghinea & Brevik (2008) richten ihre Studie an IT-Manager. Die Befragung wurde mittels eines Online-Fragebogens mit 13 Fragen durchgeführt. Ergebnisse der Studie sind: 72 % der Befragten geben an, Usability in die Anforderungen immer einzubinden. Bei 67 % der Unternehmen werden Benutzerbefragungen zur Spezifikation von Usability-Anforderungen durchgeführt. Usability-Tests mit repräsentativen Benutzern führen 40 % der Befragten durch. Hingegen geben 91 % der Befragten an, Usability-Tests durchzuführen. Bemerkenswert an den beiden letzten Aussagen zu Usability-Tests ist: Ein Usability-Test ist nur dann ein Usability-Test wenn er mit repräsentativen Benutzern durchgeführt wird. Die Unklarheiten bezüglich der Begrifflichkeiten werden also an diesen beiden Aussagen besonders deutlich. 22