Usability Engineering Methoden und Leitsätze zum Entwurf von interaktiver Software

Transkript

1 Westfälische Wilhelms-Universität Münster Ausarbeitung Usability Engineering Methoden und Leitsätze zum Entwurf von interaktiver Software im Rahmen des Informatik-Seminars Software Management Till Fabian Blesik Themensteller: Prof. Dr. Herbert Kuchen Betreuer: Susanne Gruttmann Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft

2 Westfälische Wilhelms-Universität Münster Inhaltsverzeichnis 1 Einleitung Grundlagen Usability in der DIN EN ISO Anforderungen an die Gebrauchstauglichkeit Grundsätze der Dialoggestaltung Phasenmodell Wasserfallmodell Spiralmodell Grobe Phaseneinteilung Usability Methoden und Normen in der Softwareentwicklung Problemanalyse Eigenschaften der Nutzer Die Aufgaben Aufgabendefinition Ziele definieren Dialoggestaltung Parallel Design Mitbestimmungsdesign Prototyping Überprüfung der Ergebnisse Iteratives Design Technische Realisierung Guter Programmierstil Die Kontrolle über die Anwendung Betreuung/Wartung/Einsatz Die Zuordnung im Überblick Zusammenfassung und Ausblick Literaturverzeichnis... 30

3 1 Einleitung Usability wurde in den vergangenen Jahren unterschiedlich übersetzt. Anfangs wurde der Begriff mit Benutzerfreundlich(keit) übersetzt, heute ist der Begriff Gebrauchstauglichkeit gängig. Usability betrifft alle Komponenten eines Computersystems, die ein Nutzer verwendet um mit dem System umzugehen und beschreibt, wie gut der Nutzer die Systemfunktionalität nutzen kann. Durch Usability Engineering versucht man, diese Interaktion zwischen Mensch und Maschine zu optimieren. Durch die rasante technische Entwicklung der letzten Jahre hat das Thema der Usability erheblich an Bedeutung gewonnen. In nahezu allen Lebensbereichen werden mittlerweile Computersysteme genutzt. Es ist von enormer Wichtigkeit, dass diese Systeme gut zu gebrauchen sind. Diese Verbreitung hat auch zur Folge, dass nicht mehr nur Experten, sondern praktisch jeder Mensch in seinem Alltag mit diesen Systemen umgehen muss [He05]. In den meisten Fällen dient die Usability zur Steigerung der Zufriedenheit der Kunden oder der Effektivität und Effizienz von Mitarbeitern. Bei so genannten sicherheitskritischen Systemen, wie der Überwachungssoftware eines Atomkraftwerkes, kann schlechte Usability im schlimmsten Fall Leben kosten. Es gibt viele dokumentiere Fälle von erfolgreicher Verbesserung der Usability [Ha84]. Aus unternehmerischer Sicht ist wichtig, dass in den meisten Systemen erhebliches Gewinnpotential durch eine verbesserte Bedienung steckt. Auswirkungen im Unternehmen sind sinkende Supportkosten oder steigende Mitarbeiterleistungen. Zeitlich verzögerte Resultate sind bessere Verkaufszahlen als Folge von guten Bewertungen und der damit verbundenen guten Reputation. Die Bedeutung der Usability zeigt auch, dass Grundgedanken bereits gesetzlich festgehalten sind in der DIN EN ISO Die ISO 9421 enthält jedoch nur Auflagen und Soll-Beschreibungen. In der vorliegenden Seminararbeit werden die Inhalte der ISO 9421 genauer betrachtet, außerdem werden die Aktivitäten innerhalb eines Entwicklungslebenszyklus die das Usability Engineering betreffen untersucht. Zusätzlich werden Empfehlungen gegeben, wie Usability Engineering im Management zu behandeln ist. 3

4 2 Grundlagen Usability Engineering hat als Ziel, die Mensch-Computer-Schnittstelle auf Gebrauchstauglichkeit zu optimieren. Es gibt kein Regelwerk, keine Vorschriften und keine Vorgehensweise, die beschreibt wie ein System mit guter Usability zu realisieren ist. Es existieren Grundsätze, die definieren, wie sich das fertige System verhalten sollte und Methoden, die auf dem Weg dorthin hilfreich sind. Leitsätze und Methoden müssen im Hinblick auf das zu bearbeitende Projekt interpretiert werden. Stellenweise finden sich Widersprüche, für die Kompromisse zu finden sind. Das engagieren eines Usability Experten ist zu empfehlen, um die beste Lösung für das jeweilige Projekt zu finden [Ni93]. Im folgenden werden wir die DIN EN ISO 9241 bietet in Teil Grundsätze der Dialoggestaltung und Teil 11 - Anforderungen an die Gebrauchstauglichkeit Leitsätze betrachten. Teil 11 definiert Kriterien zur Messung von Usability und liefert Grundlagen für Teil 110. Teil 110 enthält Prinzipien zur Gestaltung interaktiver Systeme. Für die Entwicklung von Software gibt es eine Vielzahl von Prozessmodellen. Eines der ersten war das Wasserfallmodell, welches sehr linear verläuft und heutigen Anforderungen nicht mehr gerecht wird. Als Standard der Software Entwicklung gelten evolutionäre und inkrementelle Modelle [Ba00]. Besonders wichtig ist, dass ein Modell iterativ ist, Phasen also mehrfach durchlaufen werden können. Das Spiralmodell entwickelt das Wasserfallmodell unter Berücksichtigung dieser Anforderung weiter. Den Phasen dieses Modells lassen sich Methoden des Usability Engineering zuordnen, die teilweise selbst iterativer Natur sind. 2.1 Usability in der DIN EN ISO 9241 Die DIN EN ISO 9241 Ergonomie der Mensch-System-Interaktion ist ein internationaler Standard und enthält Richtlinen zur Gestaltung von Mensch-Computer- Schnittstellen. Im Jahr 2006 wurde ein Framework in die Norm aufgenommen, dass die Anwendung der Norm darstellt. 4

5 Abb. 1: Framework zur DIN EN ISO 9241 [Di05] Gestützt durch die Spezifikationen zur Gestaltungsempfehlung werden aus dem Nutzungskontext die Dialoganforderungen erstellt. Auf Basis dieser Anforderungen werden Gestaltungslösungen entwickelt und auf Übereinstimmung geprüft. In diesem Teil werden die Inhalte der DIN EN ISO und genauer betrachtet. Wenn es möglich ist, werden Beispiele und Empfehlungen zur praktischen Umsetzung gegeben. Die folgenden Beschreibungen basieren auf dem Buch Software- Ergonomie von Michael Herczeg [He05].. In der DIN wird immer von Dialog und Dialogsystem gesprochen, damit sind nicht nur grafische Oberflächen, sondern alle Formen von Benutzerinteraktionsschnittstellen gemeint Anforderungen an die Gebrauchstauglichkeit Die DIN EN ISO leistet gewissermaßen Vorarbeit für die DIN EN ISO Es werden drei Eigenschaften definiert, die in der DIN EN ISO benötigt werden. Diese Eigenschaften sind: 5

6 Effektivität Die Genauigkeit und Vollständigkeit mit der Benutzer ein bestimmtes Ziel erreichen Bei der Nutzung eines Systems, ist es das wichtigste Ziel, die vorliegenden Aufgaben möglichst vollständig und korrekt zu erfüllen. Die Effektivität hängt zu großen Teilen davon ab, ob das System die nötige Funktionalität besitzt. Dennoch ist es letztendlich entscheidend, dass die Funktionalität für den Nutzer geeignet erkennbar, zugreifbar und steuerbar ist. Effizienz Der im Verhältnis zur Genauigkeit und Vollständigkeit eingesetzte Aufwand, mit dem Benutzer ein bestimmtes Ziel erreichen Ist die Effektivität eines Systems gegeben, folgt das Kriterium der Effizienz. Ein Nutzer muss die Aufgaben zuverlässig und mit möglichst wenig Aufwand lösen können. Das bedeutet, dass ein Nutzer so wenige Aktivitäten oder Artikulationen wie möglich verwenden muss, um sein Ziel zu erreichen. Dabei muss die Effizienz auf allen Ebenen optimiert werden. Dazu zählt auf der pragmatischen Ebene die Eignung des Verfahrens bis hin zu Fertigkeiten im Umgang mit Ein- und Ausgabeperipherie auf der sensomotorischen Ebene. Zufriedenheit Freiheit von Beeinträchtigungen und positive Einstellungen gegenüber der Nutzung des Produkts Die Zufriedenheit wird als subjektive Reaktion auf die Interaktion mit dem System beschrieben. Anders als Effektivität und Effizienz ist die Erfassung dieses Zustandes schwierig, da er als Folge eines komplexen psychischen Zustandes, der von vielen Umständen beeinflusst wird, entsteht. Das Kriterium der Zufriedenheit als Basis für Veränderungen von Systemen zu verwenden ist daher sehr problematisch. Fremdartigen und neuen Lösungen wird anfangs oft mit Unbehagen begegnet, im Laufe der Zeit und mit steigendem Verständnis kann sich dies jedoch ins Gegenteil umkehren. 6

7 Neben der Grundlage für Teil 110 stellen diese drei Kriterien Maße der Gebrauchstauglichkeit dar. Abb. 2: Usability Framework, vgl [Ha07] Der Nutzer möchte ein bestimmtes Ziel erreichen. In seinem Nutzungskontext verwendet er ein Produkt, um dieses Ziel zu verwirklichen. Daran wie effektiv, effizient und zufriedenstellend diese Zielerfüllung möglich ist, lässt sich Gebrauchstauglichkeit messen. Gebrauchstauglichkeit=Effektivität Effizienz Zufriedenheit [Ha07] Grundsätze der Dialoggestaltung In der DIN EN ISO sind sieben Grundsätze der Dialoggestaltung festgehalten: Aufgabenangemessenheit Dieses erste Kriterium stützt sich auf die bereits in ISO definierten Eigenschaften Effektivität und Effizienz. Effektiviät meint in diesem Kontext die 7

8 Genauigkeit und Vollständigkeit, mit der der Nutzer seine Aufgabe lösen kann. Effizienz ist als Verhältnis des eingesetzten Aufwands zur Genauigkeit und Vollständigkeit, mit der die Aufgabe vom Nutzer erledigt wird, zu verstehen [Ba02]. Ein interaktives System sollte den Nutzer unterstützen, seine Aufgabe zu erledigen. Dabei sollten alle Tätigkeiten, die nicht direkt mit dem Erreichen dieses Ziels zusammenhängen vom System erledigt werden. Der Nutzer sollte sich nur mit der Bearbeitung von sogenannten externen Aufgaben, die sich direkt aus der Arbeitsaufgabe ergeben, beschäftigen müssen [He05]. Die Erledigung seiner Aufgabe sollte mit so wenig Arbeitsschritten wie möglich realisierbar und die Oberfläche den Fertigkeiten des Nutzers angemessen gestaltet sein. Grundsatz der Merksatz ISO - Zitat Hinweise zur Umsetzung Aufgabenangemessenheit Einfach und direkt zum Ziel [Wi] Ein Dialog ist aufgabenangemessen, wenn er den Benutzer unterstützt, seine Arbeitsaufgabe effektiv und effizient zu erledigen Es werden keine Informationen ausgegeben, die nicht mit der Erledigung der Arbeitsaufgabe zusammen hängen. Wiederkehrende Tätigkeiten lassen sich automatisieren. Sinnvolle Standardwerte und Positionsmarken werden gesetzt. Pflichtfelder in Formularen werden vermieden. Zwischenergebnisse werden gespeichert und benötigte oder die ursprünglichen Daten sind abrufbar. Für erfahrene Nutzer sind Short-Cuts möglich. Beispiel Ein Formular zur Eingabe von Adressen wird so angeordnet, dass es der Adressangabe auf Briefumschlägen entspricht. Tab. 1: Aufgabenangemessenheit 8

9 Selbstbeschreibungsfähigkeit Der Nutzer muss während der Arbeit mit einer Anwendung immer wissen, wo er sich befindet, wie er dort hingekommen ist und welche Möglichkeiten er hat dort weg zu kommen. Dieses Systemverständnis sollte ohne Tooltips, Vorwissen, Einführungen oder sonstige Hilfen vom System selbst erzeugt werden. Das System muss dem Nutzer jederzeit anzeigen in welchem Zustand es sich befindet. Vor allem bei komplexen Anwendungen ist es oft nicht möglich, diesen Forderungen nach zu kommen. In diesem Fall müssen verständliche, möglichst kontextabhängige und im Umfang skalierbare Hilfen angeboten werden [He05]. Grundsatz der Merksatz ISO - Zitat Hinweise zur Umsetzung Selbstbeschreibungsfähigket Wenn Intuition ausreicht [Wi] Ein Dialog ist in dem Maße selbstbeschreibungsfähig, in dem für den Benutzer zu jeder Zeit offensichtlich ist, in welchem Dialog, an welcher Stelle im Dialog sie sich befinden, welche Handlungen unternommen werden können und wie diese ausgeführt werden können." Knöpfe und Links werden so beschriftet, dass eindeutig ist was sie auslösen oder wohin der Nutzer geführt wird. Der Nutzer wird über den Systemstatus informiert. Anklickbare Elemente haben Aufforderungscharakter und sind eindeutig als anklickbar zu erkennen. Beispiel Wenn ein Datum in einer bestimmten Form angegeben werden muss, wird ein entsprechender Hinweis oder eine Vorbelegung angezeigt. Tab. 2: Selbstbeschreibungsfähigkeit Steuerbarkeit Der Nutzer muss das System kontrollieren können. Sowohl die Geschwindigkeit, als auch Richtung und Arbeitsreihenfolge muss den Wünschen des Nutzer anpassbar sein. 9

10 Um verschiedenen Nutzermerkmalen gerecht zu werden sollte es möglich sein Ein- und Ausgabe bedarfs- und kontextabhängig anzupassen. Es gibt system- und benutzergesteuerte Dialoge. Bei komplexen Systemen ist ein gewisser Grad von Nutzerführung häufig nicht zu vermeiden. Am häufigsten ist deswegen eine Mischform, bei der eine Sequenz vom Nutzer gestartet wird und diese dann in ihrem Tempo regulierbar ist [He05]. Bei sicherheitsrelevanten Systemen ist jedoch meistens eine systemgesteuerte Dialogkontrolle vorzuziehen. An dieser Stelle könnte die Norm hinsichtlich der Besonderheiten einzelner Anwendungsgebiete differenzierter sein. Grundsatz der Merksatz ISO - Zitat Hinweise zur Umsetzung Steuerbarkeit Wenn alles unter Kontrolle ist [Wi] "Ein Dialog ist steuerbar, wenn der Benutzer in der Lage ist, den Dialogablauf zu starten sowie seine Richtung und Geschwindigkeit zu beeinflussen, bis das Ziel erreicht ist." Keine zeitgesteuerten automatischen Aktionen einbinden. Animationen die nicht notwendig sind können abgebrochen werden. Akustische Ausgaben können reguliert werden. Der Nutzer kann die Darstellung und Sortierung von Daten auswählen. Änderungen können Rückgängig gemacht werden. Der Nutzer hat mehrere Möglichkeiten der Navigation. Der Nutzer kann den Systemablauf jederzeit beeinflussen. Beispiele In einem Dateibrowser lässt sich ein Ordner mit Bildern in Form von Thumbnails in verschiedenen Größen anzeigen. In einem Programm kann über das Menü oder über Kurzwahltasten navigiert werden. Ein Downloadmanager ermöglicht das Abbrechen und 10

11 spätere wiederaufnehmen von Downloads. Tab. 3: Steuerbarkeit Erwartungskonformität Durch den Umgang mit Computersystemen entstehen Erfahrungen und aus diesen Erfahrungen ergeben sich Erwartungen. Ein wichtiges Kriterium ist, wie gut ein System diese Erwartungen erfüllt. Erwartungskonforme Systeme erleichtern dem Nutzer die Bildung eines geeigneten mentalen Modells des Systems [He05]. Ein System muss in sich selbst konsistent sein und vorhandenen Konventionen folgen [Di05]. Es gibt verschiedene Stufen der Konsistenz: Innere, Äußere und Metaphorische Konsistenz. Innere Konsistenz bedeutet Konsistenz innerhalb eines Anwendungssystems. Äußere Konsistenz erstreckt sich über verschiedene Anwendungssysteme und metaphorische Konsistenz beschreibt die Konsistenz der Dialoge mit der realen Arbeitswelt. Neben dem Aussehen der Dialoge ist die Antwortzeit von Systemen ein sehr wichtiger Punkt. Wenn die Antwortzeiten mehr als 50% von der bekannten Zeit abweichen, erzeugt dies beim Nutzer Verunsicherung. Wenn Abweichungen vorhersehbar sind, muss das System den Nutzer darüber informieren [He05]. Grundsatz der Merksatz ISO - Zitat Hinweise zur Umsetzung Erwartungskonformität Wenn es zur Gewohnheit wird [Wi] "Ein Dialog ist erwartungskonform, wenn er konsistent ist und den Merkmalen des Benutzers entspricht, z.b. seinen Kenntnissen aus dem Arbeitsgebiet, seiner Ausbildung und seiner Erfahrung sowie den allgemein anerkannten Konventionen." Vorhandene Produkte, Lösungen und Konventionen finden und sich daran orientieren. Populäre Styleguides beachten. Spezialisierte Anwendungen bieten schnellstmöglich und offensichtlich ihre Funktion an. 11

12 Wörter aus der Arbeitsumgebung der Nutzer verwenden. Beispiele Auf einer Webseite sind blaue, unterstrichene Wörter immer Links. Eine Web-Suchmaschine bietet auf der Startseite ein Texteingabefeld und einen Suchen-Button. Ein Druck auf die Tabulator-Taste lässt den Cursor auf das nächste Eingabefeld springen. Tab. 4: Erwartungskonformität Fehlertoleranz "Ein Dialog ist fehlertolerant, wenn das beabsichtigte Arbeitsergebnis trotz erkennbar fehlerhafter Eingaben entweder mit keinem oder mit minimalem Korrekturaufwand seitens des Benutzers erreicht werden kann. Das System sollte den Nutzer wenn möglich vor Fehlern bewahren und es muss vermieden werden, dass ein System in einen irreversiblen Fehlerzustand geführt wird. Ist ein Fehler präventiv nicht vermeidbar, muss der Nutzer im Fehlerfall konstruktiv dabei unterstützt werden, den Fehler mit geringem Aufwand zu beheben [Di05]. Über automatische Fehlerkorrekturen muss der Nutzer in Kenntnis gesetzt werden [He05]. Ist ein Fehler nicht vom System korrigierbar oder abfangbar, müssen Fehlermeldungen ausgegeben werden. Diese Fehlermeldungen sollten so dargestellt werden, dass sie die Aufmerksamkeit des Nutzers auf sich ziehen, bei schweren Fehlern sind Farb- und Blinkeffekte zu empfehlen. Die Ausgabe von unwichtigen Fehlermeldungen und Warnungen muss der Nutzer abstellen können. Grundsatz der Merksatz ISO - Zitat Fehlertoleranz Wenn unliebsame Überraschungen ausbleiben [Wi] "Ein Dialog ist fehlertolerant, wenn das beabsichtigte Arbeitsergebnis trotz erkennbar fehlerhafter Eingaben entweder mit keinem oder mit minimalem Korrekturaufwand seitens des Benutzers erreicht werden kann. 12

13 Hinweise zur Umsetzung Eingaben werden automatisch überprüft und fehlerhafte Eingaben abgefangen. Der Nutzer wird auf Fehler, wenn möglich mit einer kontextsensitiven Hilfestellung, hingewiesen. Beispiele In einem Formularfeld, das für Zahlen vorgesehen ist, um Tab. 5: Fehlertoleranz beispielsweise das Alter anzugeben, ist es nicht möglich Buchstaben einzugeben. Sollte es doch versucht werden erscheint ein entsprechender Hinweis. Individualisierbarkeit Nutzer von Systemen haben spezifische Aufgaben und auch individuelle Vorstellungen und Wünsche bezüglich der Gestaltung des Systems. Die nachträgliche Möglichkeit der Individualisierbarkeit ist wünschenswert, ersetzt aber keine gute Standardoberfläche. Zu vermeiden ist, dass mögliche Änderungen zu Beeinträchtigungen führen können [He05]. Es ist sinnvoll, Anwendungen so flexibel zu gestalten, dass geringe Änderungen möglich sind, ohne dafür Entwickler zu benötigen [Di05]. Es ist jedoch zu beachten, dass zu starke Individualisierung Support und Pflege komplizierter machen. Dieser Teil der Norm hat stellenweise eine recht große Ähnlichkeit zum Kriterium der Aufgabenangemessenheit. Grundsatz der Merksatz ISO - Zitat Hinweise zur Umsetzung Individualisierbarkeit Wenn jeder arbeitet, wie es ihm beliebt [Wi] Ein Dialog ist individualisierbar, wenn das Dialogsystem Anpassungen an die Erfordernisse der Arbeitsaufgabe, individuelle Vorlieben des Benutzers und Benutzerfähigkeiten zulässt. Funktionen und Fenster sind vom Nutzer zu- und abschaltbar. Außerdem kann der Nutzer die Anordnung verändern. 13

14 Es können Werkzeugleisten generiert werden. Die Bennenung von Komponenten ist veränderbar. Die Nutzung von Nutzerprofilen wird unterstützt. Hat der Nutzer Daten hinterlegt, die in einem Formular abgefragt werden, werden diese automatisch eingesetzt. Beispiele In einem Webportal kann der Nutzer sich die Oberfläche aus Miniprogrammen selbst zusammenstellen. Eine System kann die Tastenbelegung der Maus vertauschen, um von Linkshändern genutzt werden zu können. Tab. 6: Individualisierbarkeit Lernförderlichkeit Eine Anwendung soll den Nutzer beim Erlernen der Bedienung unterstützen und anleiten [Di05]. Neben dem erstmaligen Erlernen sollte das Wiederauffrischen von Gelerntem unterstüzt werden. Die die Lernförderlichkeit betreffenden Bereich sind erst ansatzweise erforscht und bisher sind Systeme meist höchstens von hoher Direktheit, was bedeutet, dass sie sehr nah am Anwendungsgebiet konzipiert sind. Dadurch ist es möglich, dass parallel zur Nutzung des Systems erworbene Kenntnis des Anwendungsgebiets durch eine isomorphe Systemstruktur das Erlernen des Anwendungssystems erleichtert [He05]. In den meisten Fällen müssen jedoch Hilfesysteme oder am besten Schulungen genutzt werden. In diesem Fall deckt sich die Lernförderlichkeit mit dem Kriterium der Selbstbeschreibungsfähigkeit. Grundsatz der Merksatz ISO - Zitat Lernförderlichkeit Wenn man schlauer wird [Wi] "Ein Dialog ist lernförderlich, wenn er den Benutzer beim Erlernen des Dialogsystems unterstützt und anleitet." 14

15 Hinweise zur Umsetzung Wichtige und am häufigsten benötigte Funktionen werden gut erkennbar angeordnet. Funktionen werden anschaulich bennant. Icons werden als symbolische Darstellung der Funktion verwendet. Wenn Funktionen auf mehreren Wegen benutzbar sind wird auf die jeweils andere Möglichkeit hingewiesen. Tutorials zur Nutzung der Anwendung werden angeboten. Beispiele Wenn für eine Funktion ein Short-Cut existiert, wird dieses Short-Cut im Menü hinter der Funktion angezeigt. Es wird auf einer Webseite eine Online-Tour angeboten, die den Nutzer durch die Webseite führt und besondere Bedienmöglichkeit aufzeigt. Eine Sitemap kann zusätzlich helfen den Aufbau zu verstehen. Tab. 7: Lernförderlichkeit 2.2 Phasenmodell Im Folgenden werden die verschiedenen Modelle der Softwareentwicklung betrachtet. Es gibt kein allgemein anerkanntes Verfahren zur Entwicklung von Software, allerdings haben sich einige Vorgehensweise und Verfahrensmodelle über die Zeit etabliert. Diese Modelle unterteilen den Prozess mehr oder weniger detailliert in Phasen auf. Während der Prozess der Softwareentwicklung früher als sehr linear angesehen wurde, hat sich immer mehr gezeigt, dass es zwischen den einzelnen Phasen und auch innerhalb der Phasen häufig Rücksprünge und Schleifen gibt. Mit diesen neuen Erkenntnissen wurden neue Modelle entwickelt, die dies berücksichtigen. Es besteht trotzdem immer noch eine grundsätzliche Übereinstimmung über grobe Phasen der Softwareentwicklung. Diese groben Phasen werden später in dieser Arbeit mit Elementen des Usability Engineering in Verbindung gebracht. Zunächst betrachten wir zwei populäre Modelle der Softwareentwicklung. 15

16 2.2.1 Wasserfallmodell Das Wasserfallmodell war in den frühen Jahren der Softwareentwicklung sehr beliebt. Es sieht einen linearen Verlauf vor, bei dem das Ergebnis einer Phase als Eingabe für die nächste Phase gesehen wird. Abb. 3: Wasserfallmodell Dieses Modell enthält die wichtigen Phasen der Entwicklung, beachtet jedoch nicht den iterativen Charakter, den die Softwareentwicklung heute hat und der für ein erfolgreiches Usability Engineering nötig ist Spiralmodell Standard in der Softwareentwicklung sind momentan evolutionäre und inkrementelle Modelle. In jedem Fall muss ein Modell iterativen Charakter haben [Ba00]. Das Spiralmodell erfüllt diese Anforderungen. Der Status der Entwicklung ist im Spiralmodell nicht gut zu erkennen, da die Anzahl der Wiederholungen nur begrenzt vorhersehbar ist. Dies entspricht der Tatsache, dass nicht vorhersagebar ist, wann eine Benutzerschnittstelle eine gute Usability hat. 16

17 Abb. 4: Spiralmodell Charakteristisch für inkrementelle Modelle ist, dass das Gesamtkonzept anfangs bereits modelliert ist, die Implementierung jedoch stückweise geschieht. In jeder Iteration werden die Erkenntnisse der vorherigen Versionen genutzt, um weitere Elemente zu realisieren [Ba00]. Dieses Vorgehen entspricht dem Usability Engineering. Früh in der Entwicklung ist klar, welche Funktionen durch die Oberfläche bedient werden müssen. Es werden Prototypen erstellt, getestet und verbessert. Abb. 5: Iteratives Modell der Oberflächenentwicklung [vgl Ri07] Auf Basis der bekannten Anforderungen wird ein Prototyp erstellt, der einen kleinen Teil des Gesamtkonzeptes umsetzt. Dieser wird Usability Tests unterzogen. Aus dem Ergebnis werden neue Anforderungen generiert. Dann wird der nächste Prototyp 17

18 implementiert, der weitere Teile des Gesamtkonzepts verwirklicht und bei dem eventuell bereits vorhandene Elemente verändert werden. Wenn alle Teile des Gesamtkonzepts eingebaut sind, finden nur noch Verbesserungen statt Grobe Phaseneinteilung Die iterativen Vorgänge des Usability Engineering finden hauptsächlich innerhalb einer Phase dieser Phasenmodelle statt. Einige Aspekte sind projektübergreifend anzuwenden, was beispielsweise bedeutet, dass man aus früheren Produkten Erkenntnisse für aktuelle, neue Produkte gewinnt. Für die Zuordnung im nächsten Kapitel wird diese grobe Einteilung genutzt: 1. Problemanalyse 2. Aufgabendefinition 3. Dialoggestaltung 4. Technische Realisierung 5. Betreuung/Wartung/Einsatz Die Phase der Dialoggestaltung wird zusätzlich eingeführt. Zwischen Aufgabendefinition und Technischer Realisierung wird die Oberfläche erstellt. Die zusätzliche Phase wird genutzt, um diesen großen Block des Usability Engineering zusammen zu fassen. 18

19 3 Usability Methoden und Normen in der Softwareentwicklung Das Entwickeln von Software mit hoher Usability-Qualität benötigt viel Zeit und Aufwand. In diesem Kapitel werden die relevanten Methoden beschrieben, die in den Phasen der Softwareentwicklung genutzt werden sollten. Außerdem erfolgt eine Zuordnung, welche Kriterien der ISO-Norm wann besonders gut beeinflussbar sind. Es wird der Prozess bei einer kompletten Neuentwicklung untersucht. Bei Überarbeitungen von bestehenden Programmen fallen manche Schritte weg. 3.1 Problemanalyse Am Anfang jeder Softwareentwicklung erfolgt die Problemanalyse. In der Problemanalyse werden aus vagen Formulierungen konkrete Problembeschreibungen erstellt. Ziel ist es, Mehrdeutigkeiten und Ungenauigkeiten zu beseitigen. Es werden Anforderungen an das Produkt ermittelt und Soll-Konzepte zur Problemlösung erstellt. In dieser Phase wird der Grundstein für eine gute Usability gelegt. Die wichtigste Aufgabe, die zu erfüllen ist, lautet Kenne den Nutzer. Eine Nutzeranalyse hilft, möglichst viele Informationen über den Nutzer zu bekommen Eigenschaften der Nutzer Usability Engineering ist zu großen Teilen nutzerorientiert. Aus den Eigenschaften und der Arbeitsumgebung zukünftiger Nutzer lassen sich Rückschlüsse über Lernfähigkeit und Grenzen der Komplexität ziehen. Wichtig ist es, herauszufinden, welche Vorstellung die Nutzer von dem Anwendungsgebiet haben, in dem gearbeitet wird, und wie dort kommuniziert wird. Aus diesen Informationen lassen sich für Nutzerklassen typische Beschreibungen und Wortwahlen ableiten, welche im Programm wieder verwendet werden sollten, um das Kriterium der Selbstbeschreibungsfähigkeit möglichst gut zu erfüllen. Ähnlich zu behandeln ist die Erwartungskonformität, wobei hier von den 3 Ebenen die metaphorische Erwartungskonformität beachtet werden muss. Ein Nutzer hat aus seiner bisherigen Arbeitserfahrung und aus Anwendungsgebiet spezifischen Eigenheiten eine 19

20 Vorstellung, wie ein System sich zu verhalten hat oder wie eine Aufgabe zu erledigen ist. Ein Techniker und ein Manager können hinter dem selben Symbol etwas unterschiedliches erwarten, abhängig von der Bedeutung des Symbols in der jeweiligen Arbeitswelt. Dieses Kriterium weist große Ähnlichkeit zur Aufgabenangemessenheit auf. Im Rahmen einer Wettbewerbsanalyse können Nutzer von Konkurrenzprodukten zur Erstellung von Nutzerklassen genutzt werden. Folgende Fragen sind zu beantworten: In welcher Umgebung wird die Anwendung verwendet werden? Welche Nutzer werden die Anwendung nutzen? Mit welcher Intention wird die Anwendung genutzt werden? Was verstehen/erwarten die Anwender unter bestimmten Begrifflichkeiten? Die Aufgaben Ein System muss nicht nur an seinen Nutzer, sondern auch an die damit zu erledigenden Aufgaben angepasst werden. Man betrachtet die Aufgaben, die das neue Produkt lösen sollen und wie diese Aufgaben bisher gelöst wurden. Dabei sind nicht nur Konkurrenzprodukte oder frühere Softwareentwicklungen sondern auch analoge Systeme zu beachten. Schwächen der bisherigen Vorgehensweise müssen identifiziert werden, um Verbesserungspotenziale zu erkennen. Für die Aufgaben muss definiert werden, welche Informationen man zur Bearbeitung benötigt und welche Resultate erzeugt werden. Wenn bereits ein älteres Computersystem oder ein Konkurrenzprodukt existiert sollte probiert werden, dort besonders effektive Nutzer zu identifizieren. Anhand der Art wie diese Nutzer das System nutzen und welche Workarounds angewandt werden, ist es oft möglich gute Lösungen zu entwickeln [Ni93]. Folgende Fragen sind zu beantworten: Welche Aufgaben sollen gelöst werden? Wie wurden die Aufgaben bisher gelöst? 20

21 Was ist an dem bisherigen Vorgehen verbesserbar? Welche Informationen werden benötigt und welche Resultate generiert? 3.2 Aufgabendefinition In der Phase der Aufgabendefinition wird die Struktur des Produktes entworfen. Die Anforderungen an das Produkt werden analysiert und auf ihrer Basis wird ein grobes Konzept für das Anforderungsmodell entwickelt. Der Prozess spielt sich zu großen Teilen auf dem Papier ab, was bedeutet, dass konkrete Implementierungsentscheidungen erst am Ende oder sogar in der nächsten Phase getroffen werden Ziele definieren In dieser Phase findet die Zielsetzung für die Usability statt. Es wird festgelegt, welche Kriterien zu priorisieren sind, da sich einige Kriterien nicht komplett in Einklang bringen lassen. Bei Spezialanwendungen, die nur von Experten bedient werden, ist Usability meistens unwichtig. Auf Basis dieser Ziele lassen sich Aussagen bezüglichen der Kriterien der Individualisierbarkeit und Lernförderlichkeit treffen. Je nach Art der Anwendung ist ein unterschiedlicher Grad der Individualisierbarkeit zu empfehlen. Dient die Anwendung zur Darstellung und Verarbeitung vieler Informationen in unterschiedlichen Kontexten, ist ein höherer Individualisierbarkeitsgrad zu empfehlen als bei Anwendungen, mit denen hauptsächlich weniger komplexe Aufgaben nach ähnlichen Schemata abgearbeitet werden. Wieder sind Ähnlichkeiten zum Kriterium der Aufgabenangemessenheit zu erkennen. In dieser Phase der Entwicklungen werden große Teile der Systemstruktur und Funktionsweise festgelegt. Diese Informationen sollte man, soweit es keine Betriebsgeheimnisse sind, aufbereiten und dem Nutzer zur Verfügung stellen, damit dieser ein besseres Verständnis für das Anwendungsmodell entwickeln kann. Mit diesem Schritt wird dem Kriterium der Lernförderlichkeit entsprochen. Folgende Fragen sind zu beantworten: Wie wichtig ist die Usabilty für die Anwendung? 21

22 Von welcher Art ist die Anwendung (Informationsmenge, Komplexität)? In welchem Umfang muss die Anwendung individualisierbar sein? 3.3 Dialoggestaltung Nach der groben Erstellung des Anforderungsmodells beginnen die Funktionen der Anwendung konkreter zu werden. An dieser Stelle beginnt die Entwicklung des Dialogs und damit der nächste wichtige Punkt des Usability Engineering. Diese Zwischenphase wird in dieser Arbeit eingeführt, da die dort anzuwendenden Methoden von fundamentaler Wichtigkeit für eine gute Usability der Nutzerschnittstelle sind. Nachdem in der Phase der Aufgabendefinition erarbeitet wird, was gemacht werden soll, dient die Zwischenphase dazu herauszufinden, wie es am besten gesteuert wird. Wenn für die Steuerung ein zufriedenstellendes Ergebnis gefunden wurde, wird auf Basis der Nutzerschnittstelle und des Anforderungsmodells ein Konzept auf technischer Ebene für die Datenverarbeitung entwickelt, welches in der nächsten Phase implementiert wird. Zwei Methoden zur Entwicklung von Oberflächen sind Parallel Design und Mitbestimmungsdesign. Um die Ergebnisse in Aktion betrachten zu können, existieren verschiedene Formen des Prototyping [Ni93]. Der auf den ersten Blick entstehende Mehraufwand durch die vielen Designs und Prototypen, die im folgenden beschrieben werden, ist bei genauer Betrachtung eine der besten Möglichkeiten Kosten zu sparen. Jede Dialogvariante, die früh ausgeschlossen und damit nicht erst implementiert und dann wieder verworfen wird, spart Zeit und Ressourcen Parallel Design Beim Parallel Design werden mehrere Teams gebildet, die unabhängig voneinander eine Nutzerschnittstelle konzipieren. Wichtig ist, dass kein Austausch zwischen den Gruppen stattfindet. Das Ziel ist es, möglichst viele, möglichst verschiedene Lösungsansätze zu bekommen, um jeweils die besten Lösungen zu nutzen. Wenn es Konkurrenzprodukte gibt, können diese als zusätzliche Designvariante genutzt werden [Ni93]. 22

23 Eine Variante des Parallel Design ist das Diversified Design, dabei werden unterschiedlichen Teams verschiedene Vorgaben gemacht. Ein Team entwickelt zum Beispiel eine Schnittstelle, die für taube Menschen gedacht ist, und ein anderes Team entwickelt eine für mobile Endgeräte Mitbestimmungsdesign Beim Mitbestimmungsdesign werden Nutzer in den Design Prozess eingebunden. Die Nutzer werden dabei gebeten, konkrete Versionen zu beurteilen. Für dieses zeigen von konkreten Versionen wird das Prototyping gebraucht, welches im nächsten Punkt beschrieben wird. Bei großen Projekten macht es Sinn, die Nutzer, die am Design teilnehmen, manchmal auszutauschen. Durch die Mitarbeit werden sie nach einer gewissen Zeit zu sehr in die Thematik involviert und repräsentieren nicht mehr den normalen Nutzer Prototyping Das Prototyping wird benötigt, da es in der Entwicklungsphase ökonomisch nicht sinnvoll, ist alle Funktionen der Oberfläche komplett zu implementieren. Es werden Oberflächen entwickelt, ohne alle Funktionen zu implementieren. Beim horizontalen Prototyping werden alle Elemente der Oberfläche ohne Funktion dargestellt. Das vertikale Prototyping implementiert eine kleine Auswahl der Elemente mit Funktion. Weitere Möglichkeiten, den Aufwand für die Prototypen gering zu halten, sind, einen Entwickler, der sich gut mit dem System auskennt die Rolle des Computers übernehmen zu lassen, ausgedachte Daten zu verwenden oder Paper Mockups zu nutzen. Bei Paper Mockups werden Oberflächen auf Papier gezeichnet oder gedruckt und der Nutzer handelt auf diesen Papieren. Wenn ein Knopf gedrückt wird, sucht der Entwickler die Oberflächenzeichnung, die als nächstes erscheinen würde, heraus und legt sie vor. Es existieren Tools, die digitale Mockups erzeugen. Paper Mockups haben jedoch eine andere Wirkung als digitale Mockups. Durch ihre Skizzenhaftigkeit animieren sie auch Grundsätzliches zu hinterfragen und zu diskutieren [Ri07]. 23

24 3.3.4 Überprüfung der Ergebnisse Die Ergebnisse müssen anschließend geprüft werden. Es gibt die Möglichkeit, diese Prüfung mit Nutzern oder nur mit Usability Experten durchzuführen. Es ist immer zu Empfehlen mit Nutzern zu testen, manchmal ist es aber nicht möglich. Beim Testen bekommen Nutzer Aufgaben, die mit der Anwendung zu lösen sind. Dabei werden sie beobachtet und am besten auch Daten vom Programm gespeichert. Sind keine Nutzer vorhanden, kann man die Oberfläche von Usability Experten bewerten lassen, dabei reicht es oft ihnen Spezifikationen oder Prototypen zukommen zu lassen. Als Ergebnis sollte eine Liste mit Problemen entstehen. Da es selten möglich ist alle Probleme zu lösen, lässt man die Probleme auf dieser Liste priorisieren. Es ist wichtig, dass man mehrere unabhängige Experten bewerten lässt. Die Wahrscheinlichkeit, eine Bewertung zu bekommen, die maximal um 0,5 Punkte von der tatsächlichen Bewertung abweicht liegt mit nur einem Experten bei 55%, mit vier Experten bei 95% [Ni93]. Die Probleme werden dann entsprechend dem Rating abgearbeitet und es beginnt der Prozess des Iterativen Design. Empfehlung: Die Ergebnisse möglichst mit Nutzern überprüfen, andernfalls von mehrere unabhängigen Experten prüfen lassen! Iteratives Design Es ist zu empfehlen, die Probleme, die im letzten Schritt gefunden wurden, direkt abzuarbeiten. Die entstehenden neuen Versionen der Oberfläche müssen dann wieder getestet werden. Möglicherweise treten durch das Beheben von Problemen neue Probleme zu Tage die vorher überdeckt wurden. Wenn es nicht möglich ist, beide Probleme zu lösen, muss abgewogen werden, welches Problem schwerwiegender ist. Bei jeder Änderung muss hinterfragt werden, warum etwas so implementiert wurde, damit nicht bei der Korrektur kleiner Probleme das Gesamtbild aus dem Auge verloren und gegen prinzipiellen Konzepte verstoßen wird. 24

25 Dieser Prozess wird so lange wiederholt, bis das Endergebnis den Anforderungen an die Usability genügt. Die Oberfläche wird in der nächsten Phase mit allen Funktionen implementiert. 3.4 Technische Realisierung In dieser Phase wird die komplette Anwendung erstellt. Alle Vorarbeiten der vorherigen Phasen werden verarbeitet und in Code umgesetzt. Versäumnisse aus früheren Phasen wirken sich ab jetzt besonders schlimm aus, da Änderungen an fertigen Konzepten und Code wesentlich mehr Aufwand bedeuten. Bei der Implementierung werden keine weiteren Usability Methoden verwendet, die Normen der Erwartungskonformität, Fehlertoleranz und Steuerbarkeit sind jedoch noch beeinflussbar Guter Programmierstil Die metaphorische Erwartungskonformität wurde bereits in einer früheren Phase abgehandelt. Während der technischen Realisierung ist die innere und äußere Erwartungskonformität von Bedeutung. Dies ist das klarste und am einfachsten zu befolgende Kriterium. Es ist darauf zu achten, dass Dialoge mit ähnlichen Inhalten ähnlich aussehen. Stellt die Anwendung nur einen Teil einer Produktfamilie dar, ist darauf zu achten, dass die einzelnen Produkte in Aussehen und Bedienung möglichst ähnlich sind. Eine Sache der Selbstverständlichkeit und des guten Programmierstils ist die Fehlertoleranz. Nutzereingaben müssen auf Korrektheit des Typs geprüft werden. Es muss beispielsweise abgefangen werden, dass ein numerisches Feld alphanumerischen Inhalt hat. Weniger offensichtliche Fehler, wie der Versuch einen Prozess zu starten, wenn es nicht vorgesehen ist, sollten ebenfalls abgefangen werden. Der Nutzer muss davor geschützt werden, seine Arbeit durch fehlerhafte Bedienung zu verlieren. Ein häufiger Fehler ist es, Warnungen zu verwenden, wenn eine Undo Funktion sinnvoller wäre [Ra07]. Wie bereits vorher angesprochen, ist der Nutzer auf die Art des Fehlers und mögliche Lösungen hinzuweisen, um im Sinne der Lernförderlichkeit das Anwendungsmodell des Nutzers zu verbessern. Empfehlungen: 25

26 Einheitliche Look&Feels für Produktfamilien erstellen. Vorhandenen Code wiederverwenden Die Kontrolle über die Anwendung Durch die Art der Implementierung legt der Entwickler fest, wie die Kontrolle und Abläufe des Systems aussehen, an dieser Stelle ist auf das Kriterium der Steuerbarkeit zu achten. Der Nutzer sollte meistens die absolute Kontrolle über das System haben. Ausnahmen wurden mit Bezug auf kritische Systeme und die Aufgabenangemessenheit bereits angesprochen. 3.5 Betreuung/Wartung/Einsatz Die Zeit der Entwicklung ist zu diesem Zeitpunkt abgeschlossen. Die Anwendung wird in der realen (Arbeits-)Welt genutzt. Es ist nicht mehr möglich auf die Nutzerschnittstelle großen Einfluss zu nehmen. Die wichtigste Aufgabe ist es jetzt, Daten zu sammeln, aus denen für die nächste Anwendung oder das nächste Release der Anwendung gelernt werden kann. Diese Folgestudien sind besonders wertvoll, da sie Ergebnisse aus einer echten Anwendungssituation liefern. Kein Test ist so repräsentativ wie die Realität! Mit der Zeit entwickeln sich Experten für die Anwendung, die wieder gute Ideen und wertvolle Kritik äußern können. Leiter von Schulungen für das Produkt wissen, welche Probleme die Nutzer im Normalfall haben, und wie damit umgegangen wird. Empfehlung: Die Nutzung des Systems in der realen Arbeitswelt untersuchen. 3.6 Die Zuordnung im Überblick In der folgenden Tabelle sind die Zuordnungen der Methoden und Normen auf die Phasen zusammengefasst. Die Zuordnungen waren nicht immer eindeutig, weswegen Mehrfachnennungen vorhanden sind. Die Methoden, die hier in den einzelnen Phasen genannt sind, finden häufig vor, am Ende oder im Übergang der Phasen statt, besonders zwischen der Phase der Aufgabendefinition und der Technischen Realisierung. Dort wurde deshalb die Oberflächenphase eingeführt. 26

27 Phase der Softwareentwicklung Problemanalyse Aufgabendefinition Nutzerschnittstellenphase Technische Realisierung Betreuung/Wartung/Einsatz Gut beeinflussbare ISO-Norm Kriterien Aufgabenangemessenheit Selbstbeschreibungsfähigkeit Erwartungskonformität Individualisierbarkeit Lernförderlichkeit Erwartungskonformität Steuerbarkeit Fehlertoleranz Usability Methoden / Aufgaben Nutzeranalyse Wettbewerbsanalyse Zielsetzung Parallel Design Prototyping Mitbestimm ungsdesign Empirisches Testen Iteratives Design Folgestudien Tabelle 8: Zuordnung von Normen und Aufgaben zu den Phasen 27

28 4 Zusammenfassung und Ausblick Ziel dieser Arbeit war es, Leitsätze und Methoden des Usability Engineering zu identifizieren und den Phasen der Softwareentwicklung zuzuordnen. Eine eindeutige Zuordnung ist nicht immer möglich. Grundsätzlich gilt, dass es leider kein festes Regelwerk gibt um, nach Usability Kriterien, hochwertige Softwareprodukte zu entwickeln. Bei Anwendung der existierenden Methoden und Leitsätze ist gute Usability sehr wahrscheinlich. Voraussetzung ist, dass eine vernünftige Interpretation der Leitsätze und Modifikation der Methoden im Kontext des Projektes vorgenommen wird. Usability begann in dem Bereich, in dem Schwächen besonders deutlich und folgenschwer waren, den Computersystemen. Dort wurden in kurzer Zeit gewaltige Systeme entwickelt, welche sich nicht, wie andere Werkzeuge, über viele hundert oder tausend Jahre entwickeln und anpassen konnten. Die gewonnenen Erkenntnisse werden mittlerweile auch auf andere Gebiete übertragen, es entstehen Normen und das Feld der Usability wird immer größer. Die Normen sind oft zu allgemein formuliert, eine Differenzierung für unterschiedliche Anwendungsarten, Nutzergruppen und Nutzungsmedien wäre wünschenswert. Anderseits sind die Ausführungen teilweise zu speziell. Die Norm spricht immer von Dialogen, aber auch Command-Line-Interfaces oder Sprachsteuerungen und ähnliches sollten nach Kriterien der Usability gestaltet werden. Alle Leitsätze der DIN EN ISO scheinen nicht nur auf den Begriffen der DIN EN ISO aufzubauen, sondern ein Großteil ist mehr oder weniger mit dem Kriterium der Aufgabenangemessenheit verknüpft. Dazu ist die Maxime Kenne den Nutzer von enormer Wichtigkeit und unterstreicht den nutzerorientierten Charakter des Usability Engineerung. Internetanwendungen sind schon lange im Focus vieler Usability Experten und Kongresse. Durch die Schnelllebigkeit dieses Mediums entstehen immer wieder neue Probleme und Lösungen. Auf diesem Gebiet wird noch lange Zeit gearbeitet werden. Immer mehr Produkte und Anwendungen haben als gemeinsamen Punkt die Verbindung über das Internet. 28

29 Das Interesse der Fachwelt gilt der Gestaltung von kollaborativen Anwendungen und Programmen zur Nutzung verteilter Informationen sowie der Möglichkeiten des Verkaufes im Internet über Onlineshops. Die Zahl der mobilen Endgeräte wird immer größer und in Zukunft wird es wichtig sein, dass Anwendungen mobil bedient werden können. Anwendungen oder Informationen müssen jederzeit und überall abrufbar sein. Waren die Endgeräte in der Vergangenheit häufig Desktop Computer mit großen Bildschirmen und Tastaturen, gilt es nun Oberflächen für kleine Anzeigegeräte mit beschränkten Eingabemöglichkeiten zu optimieren. 29

30 Literaturverzeichnis Literaturverzeichnis [Ba00] [Ha07] Helmut Balzert, Lehrbuch der Software-Technik, 2. Auflage, Spektrum, Akad. Verl., 2000 Dr. Ronald Hartwig: Ergonomie interaktiver Lernmedien, Oldenburg Wissenschaftsverlag, [He05] Michael Herczeg: Software-Ergonomie, 2. Auflage, Oldenburg Wissenschaftsverlag, [Ni93] Jakob Nielsen: Usability Engineering, Academic Press, [Ri07] [Ze92] Michael Richter, Markus Flückiger: Usability Engineering kompakt, Spektrum Akademischer Verlag, Alfred Zeidler, Rudolf Zellner: Software-Ergonomie, Oldenburg Verlag, [Bo02] Silvana Borsutzky, Website: Stand: August 2002 [Di05] Diverse, Website: Stand: Februar 2005 [Ha84] [Ra07] Douglas H. Harris, HUMAN FACTORS SUCCES STORIES, Anacapa Sciences, 1984.Website: Stand: Aza Raskin, Never Use a Warning When you Mean Undo, Information Architecture, Website: Stand: [Wi] Dr. Thomas Wirth, Die EN ISO , Website: 30