Der Recherchekompass
[ home | anleitungen | recherchen | hilfe | sitemap | index | suchen ]

Usability Engineering

usable =    brauchbar, verwendbar    nach Langenscheidts    Taschenwörterbuch.

Usability Engineering ist das derzeitige Ende einer Entwicklung, die in den achtziger Jahren als Software-Ergonomie in das Blickfeld der (Informatik-)Öffentlichkeit gelangte. Während die Anforderungen an die Ergonomie von Softwareprodukten - besonders in Deutschland - in Form von Normen niedergelegt werden, hat sich das Augenmerk verstärkt auf den Prozeß zur Erstellung ergonomischer Software gerichtet. Wenn Software-Ergonomie das WAS beschreibt, so ist Usability Engineering das zugehörige WIE.

Während "Mensch-Maschine-Interaktion" oder "Software-Ergonomie" für Aussenstehende ziemlich diffuse Begriffe sind, ist Usability Engineering dabei, sich als Technologie zu etablieren. Dabei erweist sich die Normung der "Gebrauchstauglichkeit" als hilfreich, da hierdurch prüfbare Eigenschaften festgelegt werden.

Das Usability Engineering soll gewährleisten, dass die Tauglichkeit zum Gebrauch von Beginn an im Prozess der Softwareentwicklung berücksichtigt wird und über den gesamten Lebenszyklus erhalten bleibt. Auf diesem Wege sollen am Ende verwendbare Programme herauskommen, die für den Anwender einen Nutzen erzielen und vom Benutzer akzeptiert werden.

Die Entwicklung von Software erfolgt in mehreren aufeinander aufbauenden Schritten. Um dabei die Benutzungsfreundlichkeit der Software sicherzustellen, müssen Aspekte der Gebrauchstauglichkeit von Anfang an in diesen Prozess einbezogen werden. Dieses Einbeziehung in den gesamten Entwicklungsprozeß wird als Usability Engineering bezeichnet. Diese Arbeitsabschnitte werden im Folgenden kurz erläutert:

1. Analyse
   Beginn eines jede Entwicklungsprozesses muss die Analyse der Anforderungen sein. Erfolgt die Analyse zumeist aus funktionaler und datenbankorientierter Sicht, so wird beim Usability Engineering verstärkt auch auf benutzerorientierte Aspekte wie Workflow, Arbeitsumgebung und Benutzereigenschaften geachtet. Aus dieser Sichtweise ergeben sich weitere Unterphasen der benutzerorientierten Analyse:
   • Zielanalyse (Usability Goals)
     Jedes Vorhaben muss frühzeitig klären, welche Ziele zu erreichen sind. Die frühe Bestimmung von Usability Zielen und ihre ständige Überprüfung, ermöglicht es den Gesamtprozess zielgerichtet zu gebrauchstauglicher Software zu führen.
   • Benutzeranalyse
     Die Benutzeranalyse ermöglicht die Gestaltung eines Modells des künftigen bzw. potentiellen Benutzers. Dieses hilft bei der Berücksichtigung unterschiedlicher Benutzergfruppen, aber auch bei der Auswahl geeigneter Analyse- und Testpartner.
   • Aufgabenanalyse
     Um tauglich für den Gebrauch zu sein muss ein System tauglich sein die Aufgaben zu unterstützen für die es eigesetzt werden soll. Diese werden in der Taskanalyse untersucht. Dabei ist nicht nur die isolierte Aufgabe von Interesse, sondern insbesondere deren zusammenwirken mit Anderen, am selben Arbeitsplatz und auch von anderen Benutzern.
   • Kompetitive (vergleichende) Analyse
     Die Vorstellung des Benutzers wird von dem geprägt, was er kennt oder lernt. Daher sind Konkurrenzprodukte ein Quell von Ideen und Anforderungen, sie können daher als Prototypen angesehen werden, aus denen Erkenntnisse für ein besseres Produkt gewonnen werden kann.

   design =    Entwurf, Gestaltung,    Absicht, Muster,    (Konstruktions-)zeichnung    nach Langenscheidts    Taschenwörterbuch.

2. Entwurf
   Anhand der Ergebnisse aus der Analyse wird der Software-Entwurf begonnen. Dazu gehört auch die Festlegung der Funktionalität und der Prozeßabläufe, bei denen der Benutzer in seiner Arbeitstätigkeit unterstützt werden soll. Neben den Analyseergebnissen fliessen in den Entwurf vor allem die Anforderungen der Bildschirmarbeitsverordnung und die allgemeinen softwareergonomischen Erkenntnisse ein, die in der entsprechenden Fachliteratur und in Normen niedergelegt sind.
   In der Designphase wird der Gestaltung der Benutzerschnittstelle vorgenommen. Im Hinblick auf das Usability Design umfasst sie die Definition von Benutzeraktionen, Feedback, das Aussehen des Bildschirms, die Tätigkeiten des Benutzers, die Repräsentation der Systemfunktionalität sowie Reihenfolgenüberlegungen, Zugriffsmechanismen und das Design von Interaktionsobjekten und -stilen. Man unterscheidet:
   • Konzeptionelles Design
     Diese, oft auch als Grobdesign bezeichnete, Designstufe legt die Arbeitsabläufe fest und definiert Objekte und die Operationen auf den Objekten. Des weiteren werden Metaphern bestimmt und Standards, Richtlinien und Styleguides erstellt bzw. ausgewählt.
   • Detaillierter Design
     In dieser Phase werden die Vorgaben des konzeptionellen Designs auf konkrete Anwendungsteile umgesetzt. Für die Gestaltung der Benutzerschnittstelle werden zumeist sogenannte GUI-Builder eingesetzt, so dass Oberflächenprototypen generiert und ausprobiert werden können.
   Grundsätzliches Prinzip beim Design ist die Zusammenarbeit mit Endbenutzern. Die Benutzer bringen eigene Designideen ein und sind auch entscheidungsberechtigt. Korrekturen können so frühzeitig vorgenommen werden bzw. treten gar nicht erst auf.

3. Realisierung
   Wird bei der Gestaltung der Benutzerschnittstelle während des detaillierten Designs ein GUI-Builder für die intendierte Zielumgebung eingesetzt, so ist in diesem Abschnitt "nur noch" für die Anbindung der Interaktionskomponenten an die fachliche Funktionalität zu sorgen.

4. Test
   Zusätzlich zu den bekannten Teststufen bildet das Usability Testing einen Bewertungsprozeß, um die Gebrauchstauglichkeit von Produkten und Systemen zu überprüfen. (siehe hierzu Usability Testing »)

5. Betrieb
   Waren die vorherigen Phasen immer nach vorn auf die Tauglichkeit zum Gebrauch ausgerichtet, so wird erst in täglichen Gebrauch festgestellt, ob eine Produkt auch nutzbar ist. Ständige Überprüfung und Verbesserung wird die Gebrauchstauglichkeit und jetzt sogar die Nützlichkeit erhalten und stets wieder auf den neusten Stand bringen.

"Alles fliesst" sagt bereits Euklid und weil alles in stetiger Änderung begriffen ist, ist die Voraussage der Zukunft um so schwerer je weiter in die Zukunft geschaut werden soll. Die Entwicklung von Anwendungssystemen wurde - und wird auch heute noch - vielfach mit sequentiellen, phasenorientierten Vorgehensmodellen durchgeführt, mit dem Resultat, dass am Projektende das erzeugte Produkt soweit von der Realität entfernt ist, dass es niemand mehr haben will.

Bei rein technischen Entwicklungen, deren Umfeld fast statisch ist, kann ein derartiges Vorgehen noch zum Erfolg führen. In den dynamischen, soziotechnischen Umfeldern, in denen interaktive Systeme zum Einsatz kommen ist dies eher unwahrscheinlich. Im Usability Engineering wird daher darauf gesetzt, innerhalb möglichst kurzer Zeiträume zu Reaktionen der Benutzer zu kommen.

Um die Zielsetzung eines einfachen und effizient bedienbaren Programms zu erreichen, ist in allen Projektphasen notwendig Benutzerfeedback zu bekommen. Nur die rechtzeitige Einbeziehung der Benutzern in den Entwicklungsprozeß kann zu einem bedienungsfreundlichen System führen. Unter Usability Engineering ist eben vor allem die Durchführung eines benutzerzentrierten Entwicklungsprozesses in des Lebenszyklus der Produkte zu verstehen.

Dies geschieht zum einen durch den frühen Einsatz von Prototypen (») und zum anderen durch einen evolutionären Ansatz, der auch als Rapid Application Development (RAD) bekannt geworden ist. Dabei werden Zwischenstufen realisiert, die in kurzen Zeitspannen realisierbar sind. Wenn diese Zeitspannen kleiner als sechs Wochen sind, bedarf es nur selten zusätzlicher Maßnahme, solange das Prinzip der Benutzerpartizipation eingehalten wird. Werden die Zeitspannen länger, so müssen zusätzliche Maßnahmen eigeleitet werden (siehe nächsten Absatz). Länger als sechs Monate sollte solch eine Entwicklungsspanne aber nicht dauern.

Das Usability Engineering sieht zusätzlich noch einen weiteren Feedbackkreislauf von Usability Design und Usability Testing vor, bei dem bestimmte Aspekte der Schnittstelle durch ständiges Benutzerfeedback zur Reife gebracht wird. Dieses Vorgehen wird solange (ca. drei bis vier mal) wiederholt, bis ein für alle Betroffenen zufriedenstellendes Ergebnis erzielt worden ist.

Softwaretechnisch birgt dieses Vorgehen allerdings das eine und andere Risko, wenn nicht entsprechend gegengesteuert wird.

• Das unkontrollierte Vorgehen nach dem Try&Error-Prinzip wie es eben beschrieben wurde, setzt die Änderungsfreundlichkeit eine Produkte von Mal zu Mal herab. Dies ist natürlich auch während des Einsatzes der Fall, aber je weniger zu Anfang korrigiert werden musste, desto mehr Verbesserungen können im Betrieb ohne "Gefahr" durchgeführt werden.
  • Abhilfe kann geschaffen werden durch ein Refactoring vor den Einführungen der Zwischenstufen.
    (Übrigens: Try&Error ist eine der effektivsten Lernstrategien!)

• Wenn erst eine Reihe von Zwischenstufen eingeführt worden sind, so werden die ersten veralten, entweder weil sich die Realität weiterentwickelt hat oder im Projekt Erkenntnisse entstanden sind, die einen Redesign erforderlich machen.
  • Im Verlaufe eines Projektes ist daher immer wieder Zeit einzuplanen, um bereits fertiggestellte Zwischenstufen zu überarbeiten.

Das fertige Programm ist die beste Spezifikation. Hieran kann der Benutzer erkennen, ob es dort eingesetzt werden kann, wofür er es benutzen will. Hieran kann der Softwareingineur erkennen, ob es so gebaut wurde, dass es stabil, effizient und wartbar ist. Leider muss man diesen Zustand erst einmal erreichen.

Für moderne Benutzerschnittstellen stellen Prototypen die bestmögliche Spezifikation dar. Graphische Aspekte und dynamische Abläufe einer Interaktionsschnittstelle können mit herkömmlichen Methoden kaum so verständlich gemacht werden. Bereits in der Analyse können "Papierprototypen" in denen das Aussehen des Bildschirms dargestellt und die Interaktionen durch das agieren an Papiersymbolen simuliert wird, wertvolle Hilfestellung bei der Ermittlung der Anforderungen geben. Die besten Prototypen ergeben sich aber bei der Kompetetiven Analyse, wenn anhand von Konkurrezprodukten die Anforderungen ermittelt werden, die das eigene Produkt erfüllen muss.

Prototyp =    1. Urbild, Muster, Inbegriff    2. erster Abdruck    3. erste Ausführung eines ...    nach Duden, Bd. 5:    Das Fremdwörterbuch.

Was ist ein nun Prototyp?
Prototypen sind Modelle welche bestimmte Eigenschaften eines Produktes verdeutlichen. In Prototypen werden (unvollständige) Teile des Gesamtsystems implementiert, um bestimmte Aspekte des Systems anschaulich zu machen. Dies ermöglicht es, bestimmte Sichtweisen auf ein Produkt bereits in frühen Stadien der Entwicklung einzunehmen und somit Designideen und -umsetzungen auszuprobieren. Prototypen müssen dabei nicht notwendigerweise als ausführbare Programme vorliegen, viele Aspekte eines Systems können auch durch "Papierprototypen" oder Präsentationsfolgen erfahrbar sein.

Setzt ein Projekt Prototyping in der Entwicklung ein, so soll dadurch ein bestimmter Aspekt für die gemeinsame Abstimmung erfahrbarer gemacht werden. Dies kann zum einen die Abstimmung zwische Auftraggeber und -nehmer betreffen, aber auch zwischen Designteams, wenn neue Realisierungswege ausprobiert und veranschaulicht werden sollen. Beim iterativen Prototyping wird ein Prototyp erstellt, welcher die ersten Designideen veranschaulichen soll. Dieser wird in einem Kreislauf von Design, Evaluation und Verbesserung des Designs immer weiter in Richtung auf das Endprodukt verbessert. Beim Usability Engineering geht es um Prototypen der Interaktionsschnittstelle, welche von den künftigen Benutzern bewertet werden. Die Problempunkte werden im nächsten Zyklus verbessert und gute Ideen werden hierdurch verstärkt.

Vorteile:

• Prototypen helfen Design und Abläufe verständlich zu machen und ermöglichen es dadurch, mit allen Beteiligten über ein Design zu diskutieren.
• Prototypen sind leicht verständlich für künftige Benutzer. Während es für die Benutzer im Allgemeinen problematisch ist, sich Designideen vorzustellen bzw. technische Dokumente und Beschreibungen zu kommentieren, erlauben Prototypen ein rasches Feedback zu bekommen.

• Prototypen werden häufig zum Produkt gemacht, ohne vor der Einführung ein Refactoring durchzuführen. Dadurch werden andere Qualitätsaspekte nicht oder nur unzureichend berücksichtigt.