Ausgewählte Themender Software-Technik

Universität Bremen, FB 3, Informatik, WS 2007/8

vonAyse Araz (aa)

Carsten Berje (cb)Bó Hú (bh)

Christian Kenfack Tenevo (ckt)Matthias Kirschner (mk)

Lothar Meyer-Lerbs (lml)Alvine Nono (an)

Stand: 2008–01–19, Revision: 107

Inhalt

1 Mensch–Computer-Interaktion –Software-Ergonomie 5

1.1 Menschliche Stärken und Schwächen 51.2 Mensch–Computer-Interaktion 61.3 Software-Ergonomie 61.4 Fazit 10

2 Einführung in GUIs 11

3 Messen von Usability 133.1 Warum Usability messen? 133.2 Wie kann Usability überhaupt gemessen

werden? 133.3 Methoden zur Usability-Datenerhebung 133.4 Metriken für Usability 163.5 Fazit: Der optimale Einsatz der Methoden

für das Usability-Engineering 18

4 Reflexionsanalyse 214.1 Begriffe 214.2 Einsatzszenarien 214.3 Reflexionsmethode 214.4 Fallstudien 244.5 Analyse-Werkzeuge 244.6 Fazit 25

5 Graphenvisualierung und Layout vonGraphen 27

6 Spezielle Graphlayouts 296.1 Beachte 296.2 Higraphs 296.3 Knotenüberlappung 296.4 UML Layout 296.5 Sonstiges 29

7 Erweiterung der Reflexionsanalyseum Software-Produktlinien 31

Anhang 33

A Abkürzungen 35

3

1 Mensch–Computer-Interaktion – Software-ErgonomieAlvine Nono – nono@tzi.de – Vortrag: 2007-11-23

Zusammenfassung – Die Entwicklung von Benut-zungsschnittstellen ist bei vielen Software-Projekten an-spruchsvoll. Das liegt daran, dass die Technologie sichschnell entwickelt. So steigen die Erwartungen der Be-nutzer. Ein Software-Produkt wird nicht nur an sei-ner Funktionalität, Robustheit, Stabilität sondern auchan seiner Benutzungsoberfläche (user interface) gemes-sen. Studien haben gezeigt, dass ergonomische Soft-ware die Kosten bei der Nutzung des Produkts senkenkann. Außerdem wurde unter Anderem in der Software-Reengineering-Vorlesung festgestellt, dass Anpassungenbzw. Änderungen in späten Projektphasen zeitaufwendigund kostensteigernd sind.

Das Referat „Software-Ergonomie – Mensch–Computer-Interaktion“ ist im Rahmen des Seminars „AusgewählteThemen der Softwaretechnik“ an der Universität Bremenentstanden. Es geht dabei, darum die Benutzbarkeit vonSoftware zu verbessern und somit die Interaktion zwi-schen Mensch und Computer zu optimieren, die oft un-terschätzt und vergessen wird. Einleitend werde ich denMensch an sich vorstellen, der hier der Mittelpunkt die-ser Interaktion ist, seine Stärken und Schwächen. Danachwerde ich definieren, was Mensch–Computer-Interaktionist. Dabei wird insbesondere betrachtet, wie die Kom-munikation zwischen Mensch und Computer verläuft.Es wird sowohl der Begriff „Software-Ergonomie“ erläu-tert als auch die Ziele, die eine ergonomische Gestaltungverfolgt. Darauf folgend werden die Schritte erklärt, diewichtig sind bei der Entwicklung neuer Software. Im letz-ten Kapitel wird anhand dieser Beschreibung ein Fazitgezogen, das auch uns helfen sollte den Verlauf unseresProjekts erfolgreich zu gestalten.

1.1 Menschliche Stärken undSchwächen

Es ist notwendig, dass beim Entwurf und bei der Gestal-tung von Benutzungsoberflächen die Stärken und Schwä-chen menschlicher Informationsverarbeitung gegenüberdenen von Maschinen bevorzugt werden (?). Benutzersind Menschen mit verschiedenen kognitiven Fähigkei-ten. Für die Aufnahme von Informationen stehen ihnenalle Sinne zur Verfügung: Sehen, Hören, Riechen, Schme-

cken, Fühlen. Für die Speicherung von Informationen hatder Mensch ein Gedächtnis, das ihm hilft sich später zuerinnern.Kurzzeitgedächtnis: Die Funktion des Kurzzeitgedächtni-

ses ist die kurzzeitige Speicherung von Informationen,die jeder Zeit abrufbar und bewusst sind. Leider ist dieKapazität des Kurzzeitgedächtnises sehr beschränkt.Die Speicherkapazität des Kurzzeitgedächtnises liegtbei etwa 3[2,4] Einheiten (?). Das entspricht etwa 7Icons oder 7 Einträgen pro Menü.

Langzeitgedächtnis: Der Langzeitgedächtnis dagegen hatdie Funktion eine große Menge von Informationen zuspeichern. Es hat eine sehr große Kapazität, ist aberrecht unzuverlässig. Die Informationen die im Lang-zeitgedächtnis gespeichert sind, können erst durch Er-innern im Kurzzeitgedächtnis verfügbar gemacht wer-den. Die Speicherkapazität des Langzeitgedächtniseslässt sich schwer bestimmen. Sie ist durch Lernen undÜbung beeinflussbar (?).

Menschliche Gestaltwahrnehmung: Der Mensch hat auchdie Eigenschaft sich gut strukturierte Sachverhaltebesser zu merken. Man spricht hier von menschli-cher Gestaltwahrnehmung. Bei der Entwicklung ei-nes Webinterface, ist es notwendig auf die visuelleGestaltwahrnehmung zu achten. Als Beispiel nehmenwir eine Telefonnummer die man sich merken soll, esist hilfreich die tatsächliche Nummer von der Vor-wahl zu trennen. Statt 04216393690, sollte man besser(04 21) 6 39 36 90 schreiben. So braucht man sich dieVorwahl nicht merken, wenn man schon weiß, dass dieBremer Vorwahl 0421 ist.

Begrenzte Konzentrationsfähigkeit: Menschen haben dieFähigkeit mehrere Sachen gleichzeitig zu machen (mul-titasking). Diese Eigenschaft soll aber nicht über-schätzt werden, weil wir uns nur für eine begrenzteZeit konzentrieren können. Bei der Gestaltung vonBenutzungsschnittstellen sollte man diese menschlicheSchwäche beachten. Dies bedeutet beispielsweise, dassein Menü bei der Gestaltung nicht zu vollgepackt wird.Der Benutzer sollte sich auf seine Aufgabe konzentrie-ren können und auf die wesentlichen Informationen dieer braucht, damit er seine Aufgabe erledigen kann –weniger ist mehr.

5

6 1 Mensch–Computer-Interaktion – Software-Ergonomie

1.2 Mensch–Computer-InteraktionDie Mensch–Computer-Interaktion (mci, englisch:Human–Computer Interaction, hci) beschäftigt sich mitder Analyse, Auswertung und Umsetzung bei der Ge-staltung von interaktiven Informationssystemen bezüg-lich einer benutzungsgerechten Gestaltung. MenschlichesVersagen ist häufig das Versagen des mci-Designs: zumBeispiel ein Flugzeugabsturz. Das Ziel der mci ist allge-mein die Lebensqualität zu verbessern. Systeme sollenpassend zum Nutzungskontext des Benutzers realisiertwerden. Das Verhältnis Mensch–Computer spielt bei derAnalyse, Gestaltung und Bewertung interaktiver Sys-teme eine wichtige Rolle.

1.2.1 Kommunikation:Mensch–Computer

Wer mit Computer interagieren will, muss sich von an-deren Dingen abwenden und dem Computer zuwenden.Dabei ist zu beachten, dass der Mensch ja eigentlich nichtan der Interaktion mit dem Computer selbst interessiertist, sondern an der Interaktion mit Informationen, bzw.der Kommunikation und Kooperation mit anderen Men-schen. Um eine Interaktion zwischen Mensch und Com-puter überhaupt zu ermöglichen wird ein Kanal benötigt,über den beide kommunizieren. Dieser Kanal wird hierKommunikationsschnittstelle gennant. Sie ist das Zen-trum der Kommunikation zwischen Mensch und Com-puter. Zu ihr gehören Eingabe- und Ausgabegeräte wieTastatur, Maus und Bildschirm. Mensch und Computerkommunizieren um Informationen auszutauschen, damitsie gemeinsam die Ziele (des Menschen) erreichen kön-nen. Die Kommunikation zwischen Mensch und Com-puter ist allerdings stark eingeschränkt. Die Verteilungvon Medien ist unsymmetrisch (siehe Abbildung 1.1) (?).Der Mensch hat nur wenige Möglchkeiten Informatio-

Abbildung 1.1: Medien in der mci

nen an den Computer zu senden: die Tastatur und dieMaus. Dagegen hat der Computer mehrere Ausdrucks-formen um Informationen an den Benutzer zu senden.Er kann mit dem Menschen per Bild, Schrift und sogarakustisch (Musik) kommunizieren. Damit die Kommu-nikation zwischen Mensch und Computer besser läuft,muss der Computer sich an menschliche Fähigkeiten an-passen und nicht der Mensch an den Computer (wie esim wirklichen Leben üblich ist) (?).

Die entsprechende Wissenschaft, die sich um eine Ver-besserung der mci bemüht, ist die Software-Ergonomie.

1.3 Software-ErgonomieDer Begriff Ergonomie kommt aus dem Griechischen: er-gon – Werk, Arbeit; nomos – Lehre, Gesetz, Regel.Ergonomie: eine Wissenschaft, die sich mit Arbeitsbedin-

gungen und deren Anpassung an Menschen befasst. Sieanalysiert wie und was man an den Arbeitsbedingun-gen verbessern kann.

Software: technische Systeme, die Menschen helfen ihreAufgaben zu lösen. Software wird auch eingesetzt, umAnwendern bei der Arbeit zu helfen.

Software-Ergonomie: technische Systeme werden anmenschliche Fähigkeiten angepasst. Hier geht es umeine Optimierung des Zusammenspiels aller Kompo-nenten,die die Arbeitssituation von Computerbenut-zern bestimmen: Mensch, Aufgabe und Technik.

1.3.1 Ziele der Software-Ergonomie

Software wird in der Regel benutzt, um Anwender bei derErledigung Ihrer Aufgaben zu unterstützen. Die Ziele derSoftware-Ergonomie sind:Anpassung an die kognitiven Fähigkeiten des Menschen.

Bei der Software-Entwicklung sollen Entwickler sichgenau Gedanken machen, was die Menschen können.Danach soll die Software an diese menschlichen Eigen-schaften angepasst werden.

Hohe Benutzerakzeptanz. Eine Software hat einen hoheBenutzerakzeptanz, wenn sie bei Fehlern nicht „ab-stürzt“, sondern dem Benutzer hilft diese Fehler zubeheben. Außerdem steiger hohe Benutzerakzeptanzdie Nachfrage nach der Software.

Gebrauchstauglichkeit: Der Begriff hat sich als Überset-zung des englischen Begriffs ‘usability’ durchgesetzt.Gebrauchstauglichkeit definiert die Norm DIN EN ISO9241 im Teil 11 als:

„Ausmaß, in dem ein Produkt durch bestimmteBenutzer/-innen in einem bestimmten Nutzungs-kontext genutzt werden kann, um bestimmte Zieleeffektiv, effizient und zufriedenstellend zu errei-chen.“

1.3 Software-Ergonomie 7

Dabei sind die Kernbegriffe effektiv, effizient und zu-friedenstellend für den Benutzer. Ein. Software ist ef-fektiv, wenn sie dem Benutzer hilft sein Ziel (irgend-wie) zu erreichen. Eine Software ist effizient, wennder Weg zum Ziel mit minimalem bzw. angemessenemAufwand erreicht wird. Zufriedenstellend ist eine Soft-ware für einen Benutzer, wenn sie oder er Spaß daranhat zu arbeiten. Der Anwender sollte sich nicht wäh-rend der Benutzung ärgern sondern freuen.

Förderung der Motivation beim Benutzer. Ein Softwaresollte bei dem Benutzer die Motivation fördern unddie Kreativität entwickeln. Dies ist nur möglich wennder Benutzer Spaß an der Arbeit mit der Software hat.

1.3.2 Folgen nicht ergonomischerSoftware

Software-Entwickler sollten bei der Gestaltung der Be-butzungsoberfächen darauf achten, dass sie benutzer-freundlich gestaltet ist. Software, die diese Eigenschaftnicht hat, kann den Benutzer stark beeinträchtigen.Meistens leidet der Benutzer darunter und wird frus-triert. Typische Folgen nicht ergonomischer Softwaresind:Psychische Belastung: Belastungen treten in der Regel

nicht einzeln auf, sondern sind eine Folge von Pro-blemen. Zirka 40 Prozent der Leute, die mit Softwarezu tun haben, klagen über Kopfschmerzen und Augen-probleme. Die Überforderung der Augen bei Blendun-gen hat die vorschnelle Ermüdung zur Folge. AndereBenutzer leiden unter Stress. Dieser entsteht beispiels-weise durch Zeitdruck: der Benutzer soll eine Aufgabelösen und für diese Lösung braucht er im Normalfallzwei Stunden. Er muss aber mit einer Software arbei-ten die nicht leicht zu bedienen ist und muss sich ir-gendwie zurecht finden, während sein Chef auf die Er-gebnisse wartet. Der Benutzer leidet unter Zeitdruckund ist gestresst. Überforderung bzw. Unterforderungsind typische Ursachen vom Stress. Stress gefährdetdie Gesundheit, und Dauerstress schadet sogar demOrganismus.

Unzufriedenheit der Benutzer: Der Benutzer bringt seineUnzufriedenheit zum Ausdruck, indem er sich über denComputer aufregt. Dieser Wut kann bis zur Beschädi-gung des Computers oder seiner Teile gehen. Häufi-gälle gibt der Benutzer sogar seine Aufgabe auf.

Geld- und Zeitverschwendung: Mögliche Gründe gegendie Berücksichtigung der Software-Ergonomie bei derGestaltung sind die Verbesserung in der nächsten Ver-sion oder die Entwickler sind konservativ und wollengenau so weitermachen wie sie es seit Jahren tun. DieseGründe sind eigentlich überflüssig, wenn der Anwen-der am Ende die Software nicht benutzt, die für ihn ge-macht ist. Kommerzielle Software, die nicht der Erwar-

tung des Benutzers entspricht, ist in der Regel nichterfolgreich. Es gibt immer die Möglichkeit, dass An-wender diese Software nicht kaufen, einfach weil sieihre Probleme nicht lösen kann. Dies führt zu Zeit- undGeldverlust. Außerdem ist die Veränderung von Soft-ware sehr aufwändig, wenn man die Ergonomie nachder Fertigstellung einbeziehen will. Man sollte sich zu-erst, wenn man selbst den Code nicht geschrieben hat,einarbeiten, damit man das Programm versteht umneue Features einzubauen.

1.3.3 Woran Entwickler sich orientierensollen

Wichtig für die erfolgreiche Gestaltung von Softwareist die Berücksichtigung von: Art und Weise mensch-licher Informationsverarbeitung wie Farbwahrnehmung,Metaphern wie zum Beispiel das Icon Schere zum Aus-schneiden in Textverarbeitungprogrammen. Metaphernwerden nicht nur eingesetzt, um die Lernprozess zu be-schleunigen. Durch die Nutzung von Symbolen, die manschon kennt, ist auch eine einfachere, verständliche Be-dienung erreichbar. Dabei sind auch Informationen überdas Kurzzeit- und Langzeitgedächtnis wichtig, insoferndass der Entwickler auch persönliche Aufgaben und Kön-nen der Benutzer einbezieht: welchen Wissensstand ver-schiedene Benutzer haben bei verschiedenen Aufgaben.Deshalb sollte der Entwickler genau wissen, bei welcherAufgabe die Software eingesetzt wird. Im Bereich derTextverarbeitung gibt es Leute, die nur Text bearbei-ten wollen und andere die etwas Anderes damit machen.Ebenso wäre es hilfreich, wenn der Entwickler die Benut-zer seiner Software genau kennt und Informationen überden Wissensstand der Benutzer hätte. Es gibt Leute dietechnisch begabt sind und sich zurechtfinden ohne dieDokumentation oder die Hilfe gelesen zu haben. Anderedagegen haben große Schwierigkeiten, was die Bedienungvon Software angeht und brauchen aus diesem Grund gutstrukturierte Benutzerhandbücher.

Physische und psychische Fähigkeiten derMenschen

Menschen sind verschieden und haben aus diesem Grundunterschiedliche Bedürfnisse. Und diese Bedürfnisse soll-ten berücksichtigt werden. So gibt es Benutzer, die far-benblind sind (rot und grün Blindheit) und daher solltees beispielsweise möglich sein die Farbeinstellungen beider Arbeit zu ändern, wenn Leute dies nötig haben. Au-ßerdem sollte es auch möglich sein die Schriftgröße zuverändern für die, die es brauchen. Informationen überder Umfeld der Benutzer ist von Bedeutung. Der Ent-wickler sollte wissen, wo und wofür die Software einge-

8 1 Mensch–Computer-Interaktion – Software-Ergonomie

setzt wird. Nur so kann der Benutzer die Sprache ein-stellen die er gerne hätte.

1.3.4 Normen nach DIN

Die folgenden sieben Grundsätze sind für die Gestaltungund Bewertung eines Dialoges als wichtig erkannt wordenund dienen als eine Zusammenstellung für die Gestaltungund Bewertung von Dialogen (?):

Aufgabenangemessenheit: Die ISO 9241-10 definierteinen Dialog als „aufgabenangemessen“, wenn er denBenutzer unterstützt, seine Arbeitsaufgabe effektivund effizient zu erledigen. (?, S. 4)

Eine Software sollte nur Informationen zeigen, dieder Benutzer braucht, um seine Aufgabe zu erledigen.Die Entwickler bieten machmal überflüssige Informa-tionen, die der Benutzer in dem Moment gar nichtbraucht. Es wäre also hilfreich, wenn die Darstellungdieser Informationen an die Aufgabe angepasst wer-den kann. Ein Dialog ist „aufgabeangemessen“, wenner dem Benutzer hilft Zeit zu sparen bei seiner Arbeit.Dementsprechend sollte der Dialog Arbeitschritte diestandard sind automatisieren.

Selbstbeschreibungsfähigkeit: „Ein Dialog ist selbstbe-schreibungsfähig, wenn jeder einzelne Dialogschrittdurch Rückmeldung des Dialogsystems unmittelbarverständlich ist oder dem Benutzer auf Anfrage erklärtwird.“ (?, S. 5)

Der Dialog einer Software sollte sicherstellen, dassder Benutzer immer über den aktuellen Dialogzu-stand informiert ist. Es könnte auch dazugehören einenÜberblick über vergangene und zukünftige Dialog-schritte anzubieten. Wenn eine Eingabe verlangt wird,sollte der Benutzer Informationen darüber bekommen.

Erwartungskonformität: „Ein Dialog ist erwartungskon-form, wenn er konsistent ist und den Merkmalen desBenutzers entspricht, z. B. seinen Kenntnissen aus demArbeitsgebiet, seiner Ausbildung und seiner Erfahrungsowie den allgemein anerkannten Konventionen.“ (?,S. 6) Ein Dialog ist erwartungskonform, wenn er denMerkmalen des Benutzers entspricht. Zum Beispiel sei-nen Kenntnissen aus dem Fachgebiet seines Studiumsoder seiner Ausbildung.

Lernförderlichkeit: „Ein Dialog ist lernförderlich, wenn erden Benutzer beim Erlernen des Dialogsystems unter-stützt und anleitet.“ (?, S. 9)

Lernen: bestimmt die Fähigkeit des Menschen, sichVerhaltensweisen anzugewönnen. Sie ist eng verbun-den mit der Merkfähigkeit. (?). Sie spielt in der mcieine Rolle, wenn ein Benutzer sich eine neue Arbeit-sumgebung aneignen soll oder diese eine neue Schnitt-stelle erhält. Der Benutzer sollte unterstützt werden,allein, während der Nutzung des Software, sein Wissen

über das System zu verbessern. Dabei helfen ihm dieMetaphern und die Hilfefunktionen.

Steuerbarkeit: „Ein Dialog ist steuerbar, wenn der Benut-zer in der Lage ist, den Dialogablauf zu starten sowieseine Richtung und Geschwindigkeit zu beeinflussen,bis das Ziel erreicht ist.“ (?, S. 6)

Das heißt, der Benutzer sollte die Kontrolle über derAblauf seiner Aufgaben haben. Und die Geschwindig-keit des Dialogs sollte dem Benutzer nicht vorgeschrie-ben werden.

Fehlertoleranz: „Ein Dialog ist fehlertolerant, wenn dasbeabsichtigte Arbeitsergebnis trotz erkennbar fehler-hafter Eingaben entweder mit keinem oder mit mi-nimalem Korrekturaufwand seitens des Benutzers er-reicht werden kann.“ (?, S. 7)

Fehler kommen häufig vor bei der alltäglichen Ar-beit mit Software. Und diese Fehler stellen zusätzli-che Arbeit für den Benutzer dar, statt dem Benutzerzu helfen seine Probleme zu lösen. Fehler sind immervom Kontext in den man sich befindet abhängig. Des-halb verfügen viele Textverarbeitungsprogramme übereine Rechtschreibkorrektur, die syntaktische Fehler be-hebt. Allerdings sollte es auch möglich sein, die auto-matische Korrektur abzuschalten. Die Fehlermeldun-gen eines Dialogs sollten möglichst verständlich sein.Außerdem wäre es sinnvoll diese Fehler Kontextbezo-gen zu formulieren und sie sollten auch sachlich undstrukturiert sein.

Individualisierbarkeit: „Ein Dialog ist individualisierbar,wenn das Dialogsystem Anpassungen an die Erforder-nisse der Arbeitsaufgabe sowie an die individuellenFähigkeiten und Vorlieben des Benutzers zulässt.“ (?,S. 8)

Die Entwickler sollten bei der Entwicklung an dieMöglichkeiten denken dem Benutzer die Wahl zu über-lassen, wie er seine graphische Oberfläche haben will.Aus diesem Grund sollte es dem Benuzter möglich sein,seine Lieblingsfarbe zu nehmen oder die Farben zu än-dern falls er rot/grün farbenblind ist sowie die Schrift-größe und nicht zuletzt die Lautstärke die er brauchtfür sein Audiosystem. Allerdings sollte diese Einstel-lung durch den Entwickler begrenzt sein, sodass derBenutzer nicht beeinträchtigt wird. Als Beispiel solltees nicht möglich sein die Farbe so einzustellen, dassder Benutzer davon Augenprobleme bekommt. Indivi-dualisierbar beudeutet auch Software-Systeme solltenan die persönlichen Fähigkeiten anpassbar sein. Wei-terhin sollten geistige, psychische und physische Eigen-schaften des Menschen beachtet werden: Wissenstand,Behinderung, Blindheit und Art und Weise wie Men-schen Informationen verarbeiten.

1.3 Software-Ergonomie 9

1.3.5 Software-Ergonomie imEntwicklungsprozess

Es ist üblich bei Projekten den Projektablauf in Pha-sen aufzuteilen. Die Ergonomie soll schon bei der Ent-wicklung berücksichtigt werden. Dies erspart unnötigenStress und Probleme, die man später haben kann. Spätentdeckte Fehler sind teure Fehler. Deswegen gibt es vor-gegebene Schritte, die man bei der Entwicklung neuerSoftware beachten muss (siehe Abbildung 1.2):

Abbildung 1.2: Benutzerzentierte Software-Entwicklung nachISO 9241

Analyse des Nutzungskontexts: Bei der Analyse des Nut-zungskontexts wird untersucht in welchem Kontext dieSoftware benutzt wird und welche technischen Detailszur Verfügung stehen, damit die Nutzer mit dem neuenSystem arbeiten können. Das Ziel ist bessere Anpas-sung an Organisation und Umgebung. Dazu gehört:welches Betriebsystem wird benutzt und die Eigen-schaften der Hardware.

Ermittlung der Benutzeranforderungen: Die Phase wirdhäufig als Anforderungsanalyse im allgemeinenSoftware-Entwicklungsprozess bezeichnet. Das Ziel istzu wissen, welche Aufgabe der Benutzer mit seinemSystem erreichen will, welche Techniken er benötigtund werlche Vorlieben er für die Erledigung seine Ar-beit hat. In der Regel sprechen Benutzer und Software-Entwickler nicht die gleiche Sprache, da jeder sein ei-genes Fachgebiet und dementsprechend seine eigenenFachwörter besitzt. Wichtig ist eine gemeinsame Kom-munikationsbasis zu schaffen. Sobald beide Parteienüber die Kommunikation zu eine Einigung kommen,soll die Entwicklung die Anforderungen des Benutzeranalysieren (?). Um die Benutzeranforderung ermit-teln zu können, hat der Entwickler verschiedene Ana-lysetechniken. Der Entwickler kann die vorhandenenDokumente auswerten oder noch das alte System, fallsvorhanden, untersuchen. Außerdem kann er Befragun-gen durchführen, es gibt zwei Möglichkeiten der Be-fragung, als erste gibt es schriftliche Fragenbögen oder

mündliche Interviews. Eine andere Art die Anforde-rungen der Benutzer zu analysieren, ist die Benutzerzu beobachten. Das Ziel dieser Beobachtung ist, denbisherigen Ablauf zu erfassen, wie die Aufgaben bis-her erledigt wurden. Vor allem sollten die Benutzer,die Experten auf ihrem Gebiet sind, Vorschläge undAnmerkungen zur Verbesserung ihrer Arbeit machen.

Entwicklung von Prototypen: Das Ziel der Prototypent-wicklung ist, so früh wie möglich die Anforderungender Benutzer mit Hilfe eines Beispiels zu überprü-fen (?). Dieser frühzeitige Beispielentwurf dient dazu,mögliche Probleme zu finden und passende Lösungs-ansätze zu geben. Es gibt verschiedene Typen von Pro-totypen: Wegwerfprototypen, zum Beispiel aus Papier.Er ist nicht benutzbar für das zukünftige Produkt. Siedienen nur als Beispiel, um die Anforderungen bes-ser zu demonstrieren. Andere Formen von Prototypensind: technische Prototypen, evolutionäre Prototypen,horizontale und vertikale Prototypen, Storyboard umdie Interaktion zu zeigen.

Usability-Tests durchführen: „Usability eines Produktesist das Ausmaß, in dem es von einem bestimmten Be-nutzer verwendet werden kann, um bestimmte Ziele ineinem bestimmten Kontext effektiv, effizient und zu-friedenstellend zu erreichen.“ (?)

Bei einem Usability-Test interagiert der Benutzermit dem Prototyp um herauszufinden, ob das zukünf-tige System seine Erwartungen erfüllt. Diese Testswerden meist in Usability-Labors durchgeführt. Dabeiwird der Benutzer beobachtet wie er reagiert, und mitwelcher Geschwindigkeit er seine Aufgaben erledigt.

Das Ziel des Usability-Tests ist, das tatsächlicheVerhalten eines Nutzers bei der Durchführung realis-tischer Aufgaben mit einem Produkt zu beobachten,um möglichst viele Probleme aufzudecken. Außerdemhat der Usability-Test auch das Ziel Schwachstellenzu erkennen um sie später beheben zu können undsomit zum Wohlbefinden des Anwenders beizutragen.Diese Tests sollten so früh wie möglich in den Entwick-lungsprozess einbezogen werden. Je eher die Benutzerin den Entwicklungsprozess einbezogen werden, um soeinfacher, schneller und kostengünstiger, können mög-liche Usability-Probleme aufgedeckt und beseitigt wer-den. Die Verbesserung der Usability an sich ist ein in-teraktiver iterativer Prozess: Eliminierung von schwe-ren und geringfügigen Usability-Problemen, Verifizie-rung, dass vorher gefundene Usability-Probleme be-seitigt wurden. Eliminierung von weiteren oder neuenUsability-Problemen.Wenn der Usability-Test nicht erfolgreich durchge-

führt wurde, sollte der ganze Entwicklungsprozess wie-der von vorne angefangen, zumindestens die Anforderun-gen neu definiert oder verbessert werden. Erst wenn derUsability-Test bestanden ist, erfüllt die Software die vor-gegebenen Anforderungen, und wird als akzeptiert ge-

10 1 Mensch–Computer-Interaktion – Software-Ergonomie

kennzeichnet. Entwickler, die diesem Entwicklungspro-zess folgen haben gute Chancen:– die Akzeptanz des Systems zu steigern– bessere Verständigung zwischen Programmierer und

Benutzer zu erreichen– schnelle und zielorientierte Bedienung– bessere Transparenz– weniger Schulungsaufwand, wegen besserer Erlernbar-

keit

1.4 FazitDamit der Computer bzw. die Software genau macht,was der Mensch will, muss der Computer menschlicheBedürfnisse befriedigen. Dies ist nur möglich wenn dieSoftware an den Benutzer angepasst wird. Diese Aufgabeist nicht nur die von Informatikern sondern auch Desi-gnern, die das System gestalten und Arbeitswissenschaft-lern, die die Bedingungen der Arbeit verbessern wollen.Psychologen, die kognintive Fähigkeiten von Menschenverstehen und Anwendern, die das tatsächliche Systembeurteilen können, weil Sie diejenigen sind, die das Sys-tem benutzen. Das Verständnis der menschlichen Fakto-ren ist wichtig für die mci-Software, denn sie ist nie freivon ergonomischen Mängeln. Aber es gibt Mängel, dieunbedingt beseitigt werden müssen. Wie zum Beispieldie fehlende Undo-Funktion in unserer jetzigen Projekt-Software Gravis.

Ergonomische Software ist für den Erfolg kommerziel-ler Software entscheidend. Nur wer versteht, was Men-schen wollen, kann beurteilen was Menschen brauchen.Also möglichst mit dem Benutzer, für den Benutzer ent-wicklen (?).

Abschließend: Entwickler sollen sich an die Normenals Gestaltungsleitlinien halten. Nur ein ergonomisch ge-staltetes Programm verhindert ineffiziente, umständli-che Arbeitsabläufe, vermeidet Ressourcenverschwendungund gesundheitliche Beeinträchtigungen der Benutzer.

2 Einführung in GUIsMatthias Kirschner – maki@informatik.uni-bremen.de – Vortrag: 2007-11-30

11

3 Messen von UsabilityCarsten Berje – cberje@informatik.uni-bremen.de – Vortrag: 2007-11-30

Zusammenfassung – Diese Arbeit befasst sich mit Me-thoden zum Messen der Usability (Gebrauchstauglich-keit) von grafischen Benutzeroberflächen. Ziel ist, es dieElemente der grafischen Benutzeroberfläche zu identifi-zieren, die Benutzern Probleme bereiten und die Erledi-gung von Aufgaben erschweren oder unmöglich machen.Außerdem sollen Methoden vermittelt werden, verschie-dene Interaktionsmöglichkeiten auf Basis der Usabilityzu bewerten und zu vergleichen.

3.1 Warum Usability messen?Usability (Gebrauchstauglichkeit) bedeutet, dass einKunde eine Anwendung mühelos einsetzen und bedienenkann. Erst wer Schwachstellen erkennt, kann sie ange-hen, beheben und etwas Besseres schaffen.

Wird Usability projektbegleitend in der Entwicklungs-und Implementierungsphase einer Web- oder Software-Anwendung eingesetzt, können Schwachstellen von An-fang an beseitigt werden, also bevor das Produkt beimAnwender ankommt. Das hat zwei große Vorteile: Her-stellungskosten, die wegen zu spät gefundener Fehler ent-stehen, werden vermieden, kostenintensive Nachbesse-rungen verringert. Zudem verkauft sich das Produkt bes-ser: Gute Qualität „spricht sich rum“, wird weiteremp-fohlen, sorgt für positive Resonanz in Zeitschriften undForen sowie ein positives Unternehmensimage und Wett-bewerbsvorteile gegenüber Konkurrenzprodukten. Usab-lity steigert also den Umsatz, bringt neue Kunden undfördert die Kundenbindung, senkt Kosten in der Projekt-entwicklung, -umsetzung und beim Support und steht füreine effizient nutzbare und anwenderfreundliche Anwen-dung.

Die Messung der Usability einer grafischen Benutzero-berfläche ist somit von besonderem Interesse für Softwa-reentwickler, um Schwachstellen in ihrem Produkt früh-zeitig zu erkennen und diese zu beseitigen und sich soeinen Wettbewerbsvorteil gegenüber der Konkurrenz zuverschaffen, da Usability als weicher Faktor in die Kauf-entscheidung für ein Produkt einfließt (wichtigster Fak-tor ist die Funktionalität). Gleichzeitig ist die Messungder Usability wichtig für Endverbraucher, Berater und

Verkäufer, die die Qualität von verschiedenen Produk-ten mit ähnlicher Funktionalität beurteilen wollen.

Durch ein frühzeitiges Messen der Gebrauchstauglich-keit werden hohe Folgekosten für die Einführung einerSoftware wie Benutzerschulungen, Support, Wartung,Zeitverlust durch komplizierte Bedienung usw. stark re-duziert (vgl. ?, S. 8).

Deshalb sollte während des gesamten Softwareentwick-lungsprozesses die Usability besondere Beachtung erhal-ten. Zudem ist Usability gesetzlich vorgeschrieben im Ar-beitsschutzgesetz, in der Bildschirmverordnung und inder Europäischen Norm din en iso 9241.

3.2 Wie kann Usability überhauptgemessen werden?

Im Prinzip lassen sich Messungen zu folgenden Katego-rien durchführen:

Effektivität: In welchem Grad und welcher Qualität wirdeine Aufgabe erfüllt?

Effizienz: Welche Ressourcen (Zeit, Arbeitsmaterial,geistige Anstrengung, . . . ) müssen für ein Ergebnis inausreichender Qualität aufgewendet werden?

Zufriedenheit: Wie groß ist die subjektive Zufriedenheitdes Benutzers (Spaßfaktor)?

Diese Punkte lassen sich auch einteilen in die vonder din en iso 9241-110 „Grundsätze der Dialoggestal-tung“ für eine Software geforderten Eigenschaften Aufga-benangemessenheit, Selbstbeschreibungsfähigkeit, Steu-erbarkeit, Erwartungskonformität, Fehlertoleranz, Indi-vidualisierbarkeit und Lernförderlichkeit.

3.3 Methoden zurUsability-Datenerhebung

3.3.1 Befragungen

Usability-Daten lassen sich durch verschiedene Verfahrenerheben. Zum einen gibt es diverse Befragungsmethoden.Dazu gehört die mündliche Befragung (Interview), beider der Endbenutzer nach der Meinung über das Soft-wareprodukt und nach Verbesserungsvorschlägen befragtwird. Diese Methode bietet sich nur an, wenn es keine

13

14 3 Messen von Usability

standardisierten Fragebögen gibt und nur sehr wenigeNutzer befragt werden müssen.

Eine andere Möglichkeit bietet die Befragung mit stan-dardisierten Fragebögen. Der Vorteil dieser Methode ist,dass eine größere Anzahl an Benutzern befragt wer-den kann und Benutzergruppen verglichen werden kön-nen. Bei vom Benutzer bemängelten Punkten sollte ihmaber auch auf jeden Fall die Möglichkeit gegeben wer-den, zu den bemängelten Punkten eine ausführliche Pro-blembeschreibung mit anzugeben. Dies erleichtert dasErkennen der Verbesserungsmöglichkeiten der Usabi-lity enorm. Es existieren mittlerweile eine Vielzahl sol-cher standardisierten Fragebögen: Das Software Usabi-lity Measurement Inventory (SUMI), Questionnaire forUser Interaction Satisfaction (QUIS), Purdue UsabilityTesting Questionnaire (PUTQ), ErgoNorm – Benutzer-fragebogen zu „Arbeit & Software“ aus dem DATech-Prüfhandbuch Gebrauchstauglichkeit sind z. B. solchestandardisierten Fragebögen. Diese Fragebögen stellenim Prinzip ähnliche Fragen. Der ErgoNorm – Benutzer-fragebogen stellt z. B. systematisch Fragen zu den Ka-tegorien Aufgabenangemessenheit, Selbstbeschreibungs-fähigkeit, Steuerbarkeit, Erwartungskonformität, Feh-lertoleranz, Individualisierbarkeit und Lernförderlichkeit(vgl. ?, S. 169ff.).

Befragungen geben immer einen subjektiven Eindruckwieder. Deshalb werden diese meist nur benutzt, um dieBenutzerzufriedenheit festzustellen. Ein Nachteil von Be-fragungen ist, dass sie sich nicht ständig wiederkehrendeinsetzen lassen und deshalb meist nur anwendbar beider Vorstellung eines Prototyps oder nach der Fertig-stellung des finalen Produkts sind.

3.3.2 Beobachtung

Eine weitere Form der Usability-Datenerhebung stellenBeobachtungen dar. Hier wird das Verhalten realer Nut-zer in ihrer natürlichen Umgebung beobachtet und ge-messen.

Mit Hilfe von Beobachtungen lassen sich objektive Da-ten sammeln, z. B. die Anzahl der Fehlversuche, die einBenutzer während der Erledigung einer Aufgabe fabri-ziert, die Zeit, die der Benutzer für eine Aufgabe benö-tigt, usw. Idealerweise werden genau die Benutzer be-obachtet, die später auch das Software-System bedienenmüssen.

3.3.3 Feldbeobachtung, Log-Files

Die einfachste Beobachtungsmethode ist die der Feldbe-obachtung. Hierbei werden ein oder mehr Benutzer anihrem Arbeitsplatz besucht und beobachtet. Um die Er-gebnisse nicht zu verfälschen, müssen die Beobachtun-gen möglichst unaufdringlich protokolliert werden. Bei

einer Webseite werden die Daten für die Beobachtungpraktisch umsonst vom Webserver in der Log-File ge-sammelt. Daher bietet sich hier eine Log-File Analysean. Auf dieser Grundlage lassen sich die bestbesuchtenSeiten, die gewählten Navigationswege und die Verweil-dauer der Nutzer feststellen. Log-Files können natürlichauch ebenso von anderen Programmen angelegt werden.Auch hier lässt sich über die Reihenfolge der aufgerufe-nen Befehle das Benutzerverhalten praktisch rekonstru-ieren und mögliche Schwachstellen in der Benutzerfüh-rung feststellen.

3.3.4 Lautes Denken

Der Thinking-Aloud-Test ist eine beliebte Technik imBereich von Benutzungstests. Während des Testdurch-laufs führt der Benutzer Teile eines für seine Arbeit kenn-zeichnenden Nutzungsszenarios durch. Bei der Interak-tion mit der zu testenden Software-Anwendung soll derBenutzer seine Gedanken, Gefühle und Meinungen ver-bal äußern.

Vorbereitend wird der Benutzer in das zu testendeProdukt und in die durchzuführenden Aufgaben einge-wiesen. Bei dem Testsystem muss es sich zumindest umeinen interaktiven Prototyp handeln, der jedoch nichtgänzlich implementiert sein muss, sondern es kann dieInteraktivität auch dadurch erreicht werden, in dem einMitglied des Usability-Experten-Teams entsprechend be-malte Kartonkarten auf einen Tisch legt. Dann wird derBenutzer aufgefordert diese Aufgaben mit dem Produktdurchzuführen und zu erklären, was er bei der Benut-zung des Produkts denkt. Dabei kann es nötig sein, denBenutzer durch kurze Hinweise wie „Haben Sie diesesVerhalten erwartet?“ zum lauten Denken anzuregen. Eskönnen aber auch zwei Benutzer an einem System sitzen,sodass der Redefluss nicht so schnell versiegt.

Durch den Thinking-Aloud-Test wird offensichtlich,wie der Benutzer mit dem Produkt umgeht und welcheÜberlegungen er bei der Nutzung anstellt. So kann z. B.beobachtet werden, dass Arbeitsschritte, die von der An-wendung bei der Aufgabenerledigung vorgegeben wer-den, nicht mit den vom Benutzer erwarteten Schrittenübereinstimmen. Es wird damit sofort klar, an welchenStellen der Benutzer das im System verfolgte Konzeptfalsch interpretiert und warum diese Fehlinterpretationaufgetreten ist.

Damit ist der Hauptnutzen des Thinking-Aloud-Testsdie Erlangung eines besseren Verständnisses vom menta-len Modell des Benutzers und dessen Umgang mit demProdukt, aber auch ein besseres Verständnis der vomBenutzer gebrauchten Terminologie. Die Methode kannzudem leicht und kostengünstig ohne aufwendige Testap-paraturen zu jedem Zeitpunkt des Entwicklungsprozesseseingesetzt werden.

3.3 Methoden zur Usability-Datenerhebung 15

Als problematisch kann sich bei der „Thinking-Aloud-Methode“ erweisen, dass die Benutzer fälschlicherweiseglauben, bestimmte Erwartungen erfüllen zu müssen.Dies kann dazu führen, dass durch das „Problem der so-zialen Erwünschtheit“ deren Äußerungen verfälscht wer-den. Zudem empfinden manche Benutzer die Methodeals ungewohnt und verwirrend und haben Schwierigkei-ten bei der Artikulation ihrer Gedanken (?).

3.3.5 Critical Incident Analyse

Die Critical Incident Analyse dient zur Identifizierungvon kritischen Ereignissen. Normalerweise wird die Cri-tical Incident Analyse in frühen Entwicklungsstadien ein-gesetzt, um sowohl die besonders positiven als auch diebesonders negativen Vorfälle in der Benutzung zu iden-tifizieren. Ein Critical Incident ist ein Vorfall, der einengewichtigen Beitrag zu einer Aktivität beiträgt (vgl. ?).Der Hauptzweck dieses Verfahrens ist, sehr schnell dieHauptprobleme einer Anwendung herauszufinden.

3.3.6 Eye-Tracking

Mit Hilfe von Eye-Tracking lässt sich ermitteln, welchenBereichen der Benutzeroberfläche der Anwender beson-dere Aufmerksamkeit schenkt. Dazu wird mit einer spe-ziellen Kamera die Bewegung der Augen registriert undPositionen auf dem Bildschirm zugeordnet. So lässt sichfeststellen, in welcher Reihenfolge und wie lange der Be-nutzer sich welche Elemente auf dem Bildschirm an-schaut. Daraus lassen sich dann Rückschlüsse ziehen,wie er sich auf dem Bildschirm orientiert und ob die fürseine Aufgabe relevanten Funktionalitäten der Anwen-dung überhaupt von ihm wahrgenommen werden.

3.3.7 Inspektion

Inspektionen werden von Experten anhand standardi-sierter oder genormter Richtlinien für eine gute Usabi-lity durchgeführt. Der größte Vorteil dieser Vorgehens-weise ist, dass relativ geringe Kosten im Vergleich zu Be-nutzerbefragungen und -beobachtungen entstehen undInspektionen während des gesamten Entwicklungspro-zesses durchgängig und wesentlich billiger durchgeführtwerden können. Außerdem lassen sich in Inspektionenoft mehr und konkretere Verbesserungsvorschläge für dieUsability ableiten, da das Wissen der Experten mit inden Entwicklungsprozess einfließt (z. B. verwendete Leit-fäden für die Evaluierung).

3.3.8 Heuristische Evaluierung

Bei der von Usability-Experten durchgeführten Heuristi-schen Evaluierung wird eine Anwendung im Hinblick auf

allgemein anerkannte Normen, Standards und Gestal-tungsrichtlinien überprüft und bewertet. Abweichungenwerden notiert und Lösungsvorschläge erarbeitet. Nor-malerweise beurteilen bei dieser Methode mehrere Ex-perten, ob jedes Dialogelement der grafischen Benutze-roberfläche etablierten Prinzipien für eine gute Usabi-lity folgt. Gewöhnlich betrachtet jeder der Experten dieBenutzeroberfläche zuerst alleine für sich. Erst nachdemalle Experten ihre eigenständige Evaluierung abgeschlos-sen haben, wird über die Ergebnisse kommuniziert unddiese zusammengefasst. Nur so können unabhängige undvorurteilsfreie Ergebnisse gewonnen werden. Während ei-ner Evaluation geht der Inspekteur mehrere Male durchdie Benutzeroberfläche und inspiziert diverse Dialogele-mente und vergleicht diese mit einer Liste von anerkann-ten Normen, Standards und Gestaltungsrichtlinien, z. B.die durch die Norm din en iso 9241 spezifizierten Ge-staltungsprinzipien gegliedert in Verfügbarkeit, Aufga-benangemessenheit (Nützlichkeit und Komfort), Über-sichtlichkeit, Erwartungskonformität, Fehlerrobustheit,Erlernbarkeit, Individualisierbarkeit und Steuerbarkeit(vgl. Abbildung 3.1). Für verschiedene Anwendungsbe-reiche gibt es möglicherweise sogar spezialisierte Heuris-tiken. So gibt es z. B. für die Gestaltung von Websei-ten Heuristiken, die Rücksicht auf die unterschiedlichenverwendeten Browser nehmen und speziell auf die op-timale Gestaltung einer Webseite eingehen, so z. B. die„100 Usability Tipps“ von ?. Normalerweise werden 3bis 5 Experten für die heuristische Evaluierung benö-tigt, um den Großteil der verbesserungswürdigen Stellender Benutzeroberfläche zu finden und ein gutes Verhält-nis zwischen gefundenen Problemen und Kostenfaktor zuhaben (vgl. ?).

Abbildung 3.1: iso-Gütekriterien für die Gestaltung vonBenutzeroberflächen

Die gefundenen Probleme werden anschließend prio-risiert nach der Notwendigkeit einer Behebung derUsability-Probleme von „kosmetisches Problem“ bis

16 3 Messen von Usability

„Usability-Katastrophe“. Damit liefert die heuristischeEvaluierung konkrete Hinweise zur Verbesserung derUsability eines Softwaresystems oder eines Prototypen.

Die Vorteile der heuristischen Evaluierung sind, dassdie auf Basis von anerkannten Prinzipien der Usabilityberuht und bereits früh und während des ganzen Ent-wicklungsprozesses eingesetzt werden kann. Größere undkleinere Probleme lassen sich auf diese Weise einfach undeffektiv identifizieren. Ein großer Vorteil ist außerdemder relativ geringe Zeitanspruch für die Evaluierung.

Der Nachteil dieser Methode ist, dass keine wirkli-chen Benutzer an der Evaluierung beteiligt sind undals Folge bisher nicht spezifizierte Benutzeranforderun-gen nicht erkannt werden können. Außerdem müssen dieverwendeten Heuristiken auf ihre Richtigkeit hinterfragtwerden. So sind laut DATech Prüfhandbuch Usability-Engineering-Prozess die von Jakob Nielsen beschriebe-nen ‘Ten recommended Heuristics’ (?) unzureichend,weil diese z. B. den Aspekt der Aufgabenangemessenheitund somit den Aufgabenkontext komplett vernachlässi-gen (vgl. ?, S. 121).

3.3.9 Cognitive Walkthrough

Cognitive Walkthroughs können zu beinahe jedemSoftwareentwicklungsstand angewandt werden auf derGrundlage eines Prototyps, eines konzeptionellen DesignDokuments oder des finalen Produktes. Der CognitiveWalkthrough nutzt kognitive Erkenntnisse.

Basierend auf der Zielvorgabe einer Aufgabe einesBenutzers vollführen mehrere Experten die einzelnenSchritte zur Erfüllung der Aufgabe und evaluieren beijedem Schritt, wie schwer es für den Benutzer ist, die fürdas aktuelle Zwischenziel relevanten Bedienelemente derBenutzeroberfläche zu identifizieren und diese zu benut-zen. Die Experten protokollieren außerdem, in welcherKlarheit das System eine Rückmeldung zu der durchge-führten Aktion liefert. Cognitive Walkthroughs beachtendie Denk- und Entscheidungsprozesse des Benutzers, wiez. B. die Beanspruchung des Erinnerungsvermögens unddie Fähigkeiten der Wahrnehmung.

Zum Beispiel kann das Aufrufen einer Webseite in ver-schiedene Aufgaben unterteilt werden: Als erstes erfor-dert es die Fähigkeit, einen Browser zu öffnen, sich dieurl zu merken und diese anschließend in die Adresszeiledes Browsers einzutippen. Oder, wenn man sich nicht andie url erinnert, muss man die Seite einer Suchmaschineaufrufen, einen Suchausdruck ausdenken, die Resultateanschauen und durchscrollen und dann auf einen Linkklicken.

Dieser Ansatz wird vor allem genutzt, um die Usa-bility eines Systems für Erstbenutzer und unregelmä-ßige Benutzer, d. h. Benutzer, die in einem erforschendenLernmodus mit der Software umgehen, zu ermitteln. So

lassen sich vor allem Aussagen über die Erlernbarkeitund Selbstbeschreibungsfähigkeit der Software ermitteln(vgl. ?).

3.4 Metriken für UsabilityDamit aus den durch oben beschriebenen Methoden ob-jektive Daten zur Beurteilung der Usablity gewonnenwerden können, müssen wir einige Metriken einführen,die Rückschlüsse auf die Effektivität, die Effizienz unddie Benutzerzufriedenheit zulassen. Metriken sind uner-lässlich, wenn es darum geht, aus verschiedenen alterna-tiven Ansätzen für Bedienelemente einen Ansatz auszu-wählen.

3.4.1 Metriken für die Effektivität

Die Effektivität einer Anwendung bedeutet im wesent-lichen die Frage: „Wie korrekt und vollständig könnendie Ziele des Benutzers mit Hilfe des Softwareproduktserreicht werden?“.

Die „MUSiC Performance Measurement Method“ (?)definiert Metriken zur Effektivität basierend auf der Be-obachtung von Nutzern:

3.4.2 Quantität =Anteil erfüllter Aufgaben

Der Anteil an erfüllten Aufgaben ist zunächst die Anzahlder mit der Software in ausreichender Qualität erfüllba-ren Aufgaben im Verhältnis zur Gesamtanzahl der Auf-gaben, die der Benutzer lösen muss. Die Quantität dererfüllten Aufgaben lässt sich also in Prozent angeben.Die einzelnen Aufgaben können dabei natürlich gewich-tet werden.

Ein Beispiel für die Quantität: Ein Benutzer möchtemit einer Textverarbeitung einen Serienbrief an 100 Ge-schäftspartner in einer gewissen Region schreiben. SeineAufgaben umfassen also Eingabe des Textes, dessen For-matierung, das Einfügen der Adressen der Geschäftspart-ner in jeden einzelnen Brief und das Ausdrucken derBriefe. Unterstützt die Textverarbeitung nicht die Er-stellung von Serienbriefen, so wird eine Teilaufgabe nichterfüllt.

3.4.3 Qualität =Erfüllungsgrad der Aufgaben

Die Qualität ist der Grad in Prozent, in dem die Aus-gabe einer Aufgabe mit der gewünschten Ausgabe über-einstimmt.

Beispiel: Ein Student soll eine Seminararbeit schrei-ben und soll dafür ein vorgegebenes Layout verwenden.

3.4 Metriken für Usability 17

Seine Textverarbeitung erfüllt die Aufgaben, die notwen-dig sind, die Arbeit zu schreiben, unterstützt aber viel-leicht nicht alle Formatierungen, die im Layout vorge-geben sind, z. B. sind vielleicht nicht alle erforderlichenSchriftarten auf seinem System vorhanden.

Die Quantität und Qualität der Zielerreichung einerAufgabe zu messen kann unter Umständen einen gewis-sen Grad von subjektiver Beurteilung enthalten. Deshalbsollten die Beurteilungskriterien vor der Analyse von indie Aufgabe involvierten Personen festgelegt werden.

3.4.4 Effektivität = Quantität×Qualität

Eine Gesamtaussage über die Effizienz lässt sich danndurch das Produkt von Quantität und Qualität machen.Auch die Effektivität kann so in Prozent angegeben wer-den.

3.4.5 Erfolgsrate

Die Erfolgsrate (engl. success rate) bezeichnet den pro-zentualen Anteil der von einem Testbenutzer erfolgreichbeendeten Testaufgaben. Eine Zeitvorgabe gibt es hier-bei nicht. Ausschlaggebend ist allein, ob ein Benutzer inder Lage war, die ihm gestellte Aufgabe zu erfüllen. Umdiese Metrik zu berechnen, kann jede Aufgabe mit einerbestimmten Punktzahl verbunden werden. Bei der an-schließenden Auswertung werden die Punktzahlen einesNutzers oder wahlweise auch die Punktzahlen aller Pro-banden einer Testaufgabe zu einer Gesamtpunktmengeaddiert und mit der Menge der maximal erreichbarenPunkte verglichen.

3.4.6 Metriken für die Effizienz

Der Begriff „Effizienz“ wird oft verstanden als das Ver-hältnis von nützlichen Ausgaben zu erforderlichen Ein-gaben.

Effizienz =AusgabenEingaben

(3.1)

Für ein System, dass mit Menschen interagiert, ist dieEffektivität ein Maß dafür, wie erfolgreich Mensch undComputer gemeinsam eine Aufgabe gelöst haben. Daherlässt sich die Effektivität als ein Maß für die Ausgabennehmen.

Die Eingaben mögen aber aus unterschiedlichen Sich-ten anders bewertet werden. So hat ein Benutzer einesSystems wahrscheinlich den physischen oder zeitlichenAufwand im Sinn, den er betreiben muss, ein Unterneh-men wird die Effizienz eher auf der Grundlage vom Ver-hältnis der Ausgaben zu den totalen Kosten bewerten.So ergeben sich daraus auch mehrere Metriken für dieEffizienz:

3.4.7 Benutzereffizienz

Die Benutzereffizienz (engl. user efficiency)lässt sich mes-sen als die erreichte Effektivität pro investierter Zeit.

Benutzereffizienz =Effektivität

Zeit(3.2)

3.4.8 Menschliche Effizienz

Die Menschliche Effizienz (engl. human efficiency) be-rücksichtigt hingegen den investierten mentalen oderphysischen Aufwand um eine Aufgabe zu lösen.

Menschliche Effizienz =Effektivität

Anstrengung(3.3)

Dadurch wird insbesondere berücksichtigt, dass es Tä-tigkeiten gibt, die sich ohne große Anstrengung durch-führen lassen, und dass ein Mensch einfache Tätigkeitenüber einen längeren Zeitraum ohne zu ermüden als eineanstrengende Tätigkeit ausführen kann.

3.4.9 Kosteneffizienz

Aus dem Blickwinkel eines Unternehmens, das einenSoftware-Benutzer beschäftigt, ist die Eingabe für dasSoftwaresystem die Kosten des Unternehmens, die derBenutzer für die Erledigung seiner Aufgabe aufwendet.Dazu gehören die Arbeitskosten der Zeit des Benutzers,die Kosten der Ressourcen und der benötigten Arbeits-mittel, die Kosten für die Schulung des Benutzers. DieKosteneffizienz (engl. corporate efficiency) lässt sich alsowie folgt darstellen:

Kosteneffizienz =Effektivität

Totale Kosten(3.4)

3.4.10 Produktiv und unproduktivverbrachte Zeit

Die Effizienz kann auch auf Grundlage der produktiv undunproduktiv verbrachten Zeit beurteilt werden:

Aktionen sind produktiv, wenn sie entweder Dingeproduzieren, die im Resultat zu sehen sind – z. B. dasEinfügen einer Linie in eine Zeichnung –, notwendig sindum solche Dinge zu produzieren – z. B. das Auswählendes Linienwerkzeugs – oder dem Benutzer Informationenliefern, die dem Benutzer helfen, die gewünschte Ausgabezu produzieren – z. B. das Abfragen der aktuellen Lini-enstärke für die Ausgabe. Auch wenn der Benutzer nichtden optimalen Weg gewählt hat, seine Aufgabe zu erledi-gen, werden Aktionen als produktiv angesehen, wenn siezum Ergebnis beitragen. Nicht optimale Methoden wer-den sich nämlich in der Effizienz Metrik niederschlagen.

Unproduktiv verbrachte Zeit lässt sich dagegen ein-facher erkennen: Zur unproduktiven Zeit gehören alle

18 3 Messen von Usability

Aktionen, die der Benutzer auf der Suche nach Hilfeverbringt, z. B. das Lesen der Online-Hilfe oder der Be-dienungsanleitung, das Befragen eines Fachmanns, dasAnrufen eines Experten per Telefon. Dazu gehören auchalle Suchaktionen, in denen der Benutzer die Strukturdes Programms erforscht, d. h. Menüs betrachtet ohneeinen Eintrag zu aktivieren, Dialoge anzeigt und dieseabbricht ohne Änderungen vorzunehmen. Obwohl Hilfe-und Suchaktionen dem Benutzer indirekt bei der Erledi-gung seiner Aufgabe helfen, indem sie ihm wichtige In-formationen über das System geben, sind diese dennochunproduktiv, weil sie keinen Effekt auf das Ergebnis derAufgabe haben. Zu den unproduktiven Aktionen gehö-ren auch die Aktionen, die bereits durchgeführte produk-tive Aktionen rückgängig machen, z. B. das Tippen vonBuchstaben und anschließende Löschen per Backspace,das Ausführen einer Aktion und anschließendes Rück-gängigmachen durch das Ausführen der Aktion „Rück-gängig“, ein Systemzusammensturz und anschließendenAktionen um Daten zu retten, das Eingeben von Kom-mandos, auf die das System nicht reagiert.

Auf dieser Grundlage lässt sich dann als Metrik derAnteil der Produktiv verbrachten Zeit im Verhältnis zurGesamtzeit berechnen.

Produktive Periode =Produktive Zeit

Gesamtzeit(3.5)

3.4.11 Darstellung der Metriken

Die Metriken lassen sich für einen Vergleich zweier Sys-teme am besten in einem Diagramm darstellen, dasdie im Test ermittelten Werte Minimum, Durchschnittund Maximum nebeneinander für jede durchgeführteAufgabe darstellt. Abbildung 3.2 zeigt ein solches Dia-gramm.

Abbildung 3.2: Darstellung und Vergleich von Metriken (?)

3.4.12 Weitere Kennzahlen

Insbesondere für Webanwendungen gibt es noch eineReihe weiterer Metriken. Dazu gehört das Traffic/ Netz-aufkommen, die Besucherzahl (Visitor Count), die Ver-kaufsrate (die Anzahl verkaufter Artikel), Anzahl an Be-suchern, die vom Kauf eines Produktes überzeugt werdenkönnen (Conversion Rate), das Verhältnis von potentiel-len Käufern zu tatsächlichen Käufern.

3.4.13 Metriken für dieBenutzerzufriedenheit

Die Benutzerzufriedenheit (Spaßfaktor) lässt sich quan-titiv nur sehr schwer erfassen. Sie erfasst die subjektivenEindrücke des Testnutzers während eines durchgeführtenUsability-Tests.

Für die Selbstbeschreibungsfähigkeit und Erlernbar-keit der Software kann man die Benutzereffizienz einesnur kurz eingewiesenen Benutzers mit der Benutzereffi-zienz eines Experten vergleichen. Das Ergebnis ist dierelative Benutzereffizienz zwischen nur kurz eingewiese-nen Benutzern und Experten.

BenutzereffizienzExperten Benutzereffizienz

(3.6)

3.4.14 Metriken für gesengte Kosten

Eine mögliche Metrik hierfür ist laut (?) die Anzahlder Hotlineanrufe. Die Anzahl protokollierter Hotline-Anrufe ist eine besonders geeignete Metrik, um die posi-tiven Effekte von Usability-Engineering-Methoden zu be-legen. Dahinter steht die Überlegung, dass Anwendungenmit schlechter oder unausgereifter Benutzerschnittstelleauch in vielen Fällen zu Bedienproblemen führen, diewiederum Unsicherheiten und Angst im Umgang mit derAnwendung zur Folge haben. Dementsprechend kommtes häufig zu Situationen, in denen Nutzer auf die Unter-stützung des Support-Teams angewiesen sind. Der (oftkostenpflichtige und kostenintensive) Support-Anruf ver-bleibt dann in vielen Fällen als einziger Ausweg. Gleichesgilt für die Anzahl der Supportanfragen per Email.

Eine Methode für die Berechnung der Kosteneffizienzwurde weiter oben bereits vorgestellt.

3.5 Fazit: Der optimale Einsatzder Methoden für dasUsability-Engineering

Methoden, die Usability sicherstellen, sollten frühestmöglich in den Entwicklungsprozess von Software inte-griert werden. Es bietet sich ein Mix aus den hier vorge-stellten Methoden an, weil jede Methode ihre Stärken

3.5 Fazit: Der optimale Einsatz der Methoden für das Usability-Engineering 19

und Schwächen hat. Während des gesamten Entwick-lungsprozesses sollten qualitative Analysen wie heuris-tische Analysen und Cognitive Walkthroughs eingesetztwerden, damit benutzerfreundliche Ansätze für die Be-nutzeroberfläche möglichst früh zum Tragen kommen.Gerade die qualitativen Methoden bringen schnell Ver-besserungsvorschläge ein. Es bietet sich außerdem einPrototyp an, der ausgiebig von realen Benutzern getestetwerden soll um frühzeitig eventuelle Probleme zu erken-nen, die die qualitativen Analysen nicht berücksichtigthaben, oder um die qualitativen Analysen zu validieren.Die Behebung von Problemen im Nachhinein ist nämlichdeutlich teurer (Faktor > 6). Herstellungskosten, die we-gen zu spät gefundener Fehler entstehen, werden vermie-den, kostenintensive Nachbesserungen verringert. Zudemverkauft sich das Produkt besser und führt zu einem gu-ten Unternehmensimage und zufriedeneren Kunden.

4 ReflexionsanalyseAyse Araz – ser@informatik.uni-bremen.de – Vortrag: 2007-12-14

Zusammenfassung – Die Software-Architektur ist einwesentliches Merkmal für die Qualität einer Software,da sie das Grundgerüst dieser darstellt. Die Definitioneiner Architektur dient meist als Orientierung für Ent-wickler. Die Erfahrung zeigt aber, daß ohne gezielte Kon-trolle, die vorgegebene Architektur selten eingehaltenwird, oder die Architektur rückt dabei in den Hinter-grund, da die Funktionsfähigkeit der Software nach derFertigstellung meist im Mittelpunkt steht. Dies führtdazu, daß die Softwarearchitektur und Implementierungauseinanderdriften. Die Idee der Reflexionsanalyse liegtdarin, diese Unterschiede aufzudecken. Ziel dieser Aus-arbeitung ist es, die Reflexionsanalyse im Rahmen derSoftware-Entwicklung darzustellen.

Im Folgenden werden zunächst die grundlegende Be-griffe und die Einsatzszenarien der Reflexionsanalyse ein-geführt. Anschließend werden die Grundlagen der Refle-xionsmethode von Murhpy et al. und die Erweiterungder Methode erläutert und an Beispielen veranschaulicht.Abschließend werden einige Werkzeuge untersucht, dieFunktionalitäten zum Erstellen eines Reflexionsmodellsbieten.

4.1 BegriffeEinleitend sollen die Reflexionsanalyse genauer erläutertwerden, dazu werden die folgende Begriffe eingeführt.

Soll-Architektur: Soll-Architektur stellt die geplante Ar-chitektur des Systems mit gewissen Systemkomponen-ten und gewissen Beziehungen zwischen den Kompo-nenten dar.

Ist-Archtitektur: Ist-Architektur ist die tatsächliche Ar-chitektur des Systems, die aus dem Quellcode gewon-nen wird.

Reflexionsanalyse: Die Reflexionsanalyse ist eine Me-thode zur Identifikation von Unterschieden und Ver-letzungen der Softwarearchitektur und der Implemen-tierung.

4.2 EinsatzszenarienIm Zuge der Software-Entwicklung treten verschiedeneSituationen auf, die eine Reflexionsanalyse notwendigmachen:Vorgabe von Wunscharchitekturen: Beobachten und kon-

trollieren der Ist-Architektur einer Software entspre-chend vorgegebener Ziel-Architektur.

Programmverstehen: Rekonstruktion einer abstraktenArchitektur aus den vorhandenen Programmtexten,die meist schwach dokumentiert oder gar unkommen-tiert sind.

Projektbezogener Architekturvergleich: KontinuierlicheQualitätsprüfung im Projektverlauf im Hinblick dar-auf, ob die Architekturvorgaben eingehalten wordensind.

Analyse der Systemevolution: Überprüfung der Auswir-kungen einer Veränderung im Zusammenhang mit derRestrukturierung eines Software-Systems.

4.3 Reflexionsmethode? haben eine Methode vorgestellt, die es einem Ana-lyst ermöglicht, ein Ist-Architektur gegen einem Soll-Architektur zu vergleichen, um die Konsistenz dieser Do-kumente untereinander zu untersuchen.

Die Methode benötigt folgenden Eingaben:– Ein Ist-Architektur, die aus dem Quelltext mittels ei-

nes Extraktionswerkzeug gewonnen wird. Diese stelltdie im Quelltext definierte Artefakte und Relationenzwischen den Artefakten dar (z.B. Module, Klassen,Funktionen, Methodenaufrufe, Vererbung etc.).

– Ein Soll-Architektur, diese stellt ein abstraktes Modelldes zu analysierenden Systems in Form von erwartetenEntitäten und deren Beziehungen untereinander.

– Eine Abbildung zwischen den Elementen der Soll-Architektur und den Elementen der Ist-Architektur.

Die Methode liefert dem Analyst ein Reflexionsmodellals Ausgabe, indem er kontinuierlich die Unterschiede inden Relationen zwischen den Elementen des abstraktenModells und den Elementen des Quellcodes analysiertund integriert.

Abbildung 4.1 veranschaulicht die Methode, die ausfolgenden Schritten besteht:Erstellen ein abstrakten Modells: Der Entwickler erstellt

das abstrakte Modell des Systems. Dabei stehen ihm

21

22 4 Reflexionsanalyse

Abbildung 4.1: Vorgehensweise im Reflexionsmodell

nur sehr informelle Gesichtpunkte, wie Dokumenta-tion, System-, Fachgebietwissen und seinen Erwartun-gen zur Verfügung.

Erstellen eines Quelltextmodells: Ein lexikalisches Ex-traktionswerkzeug analysiert den Quelltext und ex-trahiert darin vorkommende relevante Informationenüber das System. Der Entwickler erstellt daraus dasQuelltextmodell.

Definieren einer Abbildungsvorschrift: Anschließend de-finiert der Entwickler eine Abbildung zwischen den imabstrakten Modell enthaltenen Subsystemen und denElementen des Quelltextmodells.

Berechnen des Reflexionsmodells: Ein Reflexionswerk-zeug errechnet aus dem Quelltextmodell, dem abstrak-ten Modell und der Abbildung das Reflexionsmodell.Das Werkzeug stellt die Unstimmigkeiten zwischen ab-straktem und Quelltext-Modell in einem so genanntenReflexionsmodell dar. Das Reflexionsmodell wird gra-phisch präsentiert und besteht aus Knoten und Kan-ten. Die Knoten sind die Komponenten des Systemsund Kanten repräsentieren die vorhandenen oder nichtvorhandenen Relationen zwischen den Komponenten.Dabei können drei Fälle eintreten die durch drei Artenvon Kanten dargestellt und in Abbildung 4.4 erkenn-bar sind.Convergence: Eine im abstrakten Modell geplante Ab-

hängigkeit tritt tatsächlich im Quelltext auf.Divergence: Eine Abhängigkeit tritt im Quelltext auf,

die im abstrakten Modell nicht spezifiziert wurde.Absence: Eine im abstrakten Modell spezifizierte Ab-

hängigkeit ist im Quelltext nicht vorhanden.Interpretieren des Reflexionsmodells: Der Entwickler in-

terpretiert das resultierende Reflexionsmodell. Die Un-stimmigkeiten werden durch eine tiefergehende Ana-lyse der Software weiter untersucht.

Verfeinern/verbessern: Der Entwickler verfeinert das ab-strakte Modell und/oder die Abbildung, falls die ihmdurch das Reflexionsmodell zur Verfügung stehendenInformationen noch nicht seinen Ansprüchen genügt.

4.3.1 Ein Beispiel des Reflexionsmodells

Die Abbildungen 4.2 – 4.4 stellen das Erstellen eines Re-flexionsmodells dar, die drei Module A, B und C ent-halten. Das Architektur-Modell in der Abbildung 4.2 isteine grobe Beschreibung über die Struktur des Software-Systems.

Das Modell Abbildung 4.3 zeigt die tatsächliche Struk-tur des Software-Systems über Quelltext. Und das dritteModell in der Abbildung 4.4 zeigt das berechnete Re-flexionsmodell. Der rote Pfeil bezeichnet dabei eine Di-vergenz, der gelbe Pfeil eine Abwesenheit und der grünePfeil eine Konvergenz.

4.3.2 Erweiterung des Reflexionsmodells

Da das ursprüngliche Reflexionsmodell, das von ? vorge-schlagen wurde, keine hierarchischen Architekturen un-terstützt, wurde später von ? weiterentwickelt, um hier-archishen Architekturen analysieren zu können. Um dieIdeen des Reflexionsmodells auf ein hierarchisches Refle-xionsmodell übertragen zu können, wurde die Semantikdes ursprünglichem Reflexionsmodells (Definitionen vonDivergence, Convergence und Absence etc.) folgender-maßen angepasst:– Die oberen Relationen überschreiben die unteren Re-

lationen.– Die unteren Relationen sind überflüßig, da die von den

oberen abgedeckt sind.

4.3 Reflexionsmethode 23

Abbildung 4.2: Bildung eines Architektur-Modells

Abbildung 4.3: Bildung eines Quelltext-Modells

Abbildung 4.4: Bildung eines Reflexionsmodells

Abbildung 4.5: Bildung eines Architektur-Modells

Abbildung 4.6: Bildung eines Quelltext-Modells

Abbildung 4.7: Bildung eines Reflexionsmodells

24 4 Reflexionsanalyse

Die Abbildungen 4.5 – 4.7 stellen das Erstellen eines hier-archischen Reflexionsmodells dar, wobei die Module inSubmodule weiter verfeinert und die Abhängigkeiten ge-nauer spezifiziert sind. Es wird eine transitive Relationdefiniert, die es erlaubt, eine Relation im Quelltext-Modell beliebig nach oben aufzuheben, bis eine Kanteim Abstrakten Modell diese Relation bestätigt. Wenneine Bestätigunskante auf der Architekturebene tatsäch-lich existiert, dies ist der gewünschte Fall, diese Relatio-nen werden als Konvergenzen bezeichnet und als grünePfeile dargestellt. Relationen, die im Modell des Quell-codes vorhanden sind, aber für die im abstrakten Modellkeine Bestätigungskante existieren, werden als Abwei-hungen bezeichnet und als rote Pfeile dargestellt. Sindumgekehrt im abstrakten Modell Relationen enthalten,für die im Quellcode keine aufgehobene Kante existie-ren, werden als Abwesenheiten bezeichnet und als gelbePfeile dargestellt.

4.4 FallstudienDie Technik der Reflexionsmodelle wurde bereits in ver-schiedenen Fallstudien angewandt. So benutzte ein Ent-wickler mit 10 Jahren Microsoft Entwicklungserfahrungim Rahmen einer experimentellen Reengineeringarbeitan Microsoft Excel Reflexionsmodelle, um die verschie-denen Bestandteile aus dem Quelltext zu identifizierenund sie anschließend zu extrahieren. Innerhalb eines Ta-ges ermittelte er ein erstes Reflexionsmodell von Excel,das er in den folgenden 4 Wochen ständig verfeinerte.Das Modell enthält 15 Komponenten mit 19 Verbindun-gen zwischen ihnen. Er schätzte, daß er ohne die Methodeca. 2 Jahre gebraucht hätte, um dasselbe Verständnis fürden Quellcode zu entwickeln (?). Die Modellierung desSpeichersystems von NetBSD und gnu C Compiler cc1sind weitere Anwendungsbeispiele von Reflexionsmodel-len.

NetBSD: Die virtuelle Speicherverwaltung von NetBSD(das komplette System besteht aus 250 000 Zeilen C-Code, das Teilsystem enthält 15 000 Beziehungen zwi-schen 3000 Elementen) (?)

cc1: ein Teilsystem des gnu C Compilers (?)Excel: Microsoft Excel (1 200 000 Zeilen Code) (?)

4.5 Analyse-WerkzeugeFür die Berechnung von Reflexionsmodellen können un-ter anderem die Werkzeuge verwendet werden, die imFolgenden dargestellt sind.

4.5.1 Bauhaus

Das Bauhaus-Projekt (?) ermöglicht das Programmver-stehen eines Softwaresystem durch Entwicklung geeigne-ter Werkzeuge sowohl auf sehr hoher Abstraktionsebenezu betrachten wie auch bis auf Codeebene hinunter zuzoomen. Zur Visualisierung und Manipulation der Ar-chitekturinformationen steht der Grapheneditor Graviszur Verfügung (Abbildung 4.8).

Abbildung 4.8: Grapheneditor Gravis

4.5.2 RMTool

Für die Berechnung von Reflexionsmodellen kann auchder Werkzeug RMTool verwendet werden. Den Down-load des Werkzeug-RMTools bietet die von der Auto-rin G. C. Murphy unterhaltene Web-Seite an (?) (Abbil-dung 4.9).

Abbildung 4.9: RMTool von G. Murphy

4.6 Fazit 25

4.5.3 Sotoarc, Lattix, SonarJ

Die kommerzielle Werkzeuge Sotoarc (?), Lattix (?) undSonarJ (?) können ebenfalls Analysen anhand von Re-flexionsmodellen durchführen.

4.6 FazitEin Reflexionsmodell liefert eine genügend abstrakteSichtweise auf ein Softwaresystem, so daß dieses Modellein sehr genaues Abbild des Quellcodes ist, das ein besse-res Verständnis vermitteln soll. Reflexionsmodelle geheneinen anderen Weg, um das Systemverständnis zu er-mitteln. Diese Reflexionsmodelle sind zum einen genauerals eventuell vorhandene Architekturdokumente, weil sieständig mit dem Quelltext korrespondieren. Sie sind an-dererseits viel abstrakter als Quelltext selbst, so daß esleichter fällt, einen überblick zu gewinnen. Kurzgesagt,stellt ein Reflexionsmodell eine Zusammenfassung der ineinem Quellcode bestehenden Komponenten und Bezie-hungen zwischen den Komponenten von einem höherenSicht dar und vergleicht diese mit einer vorliegenden ab-strakten Beschreibung.

5 Graphenvisualierung und Layout von GraphenChristian Kenfack Tenevo – kenfackc@informatik.uni-bremen.de – Vortrag: 2007-12-21

27

6 Spezielle GraphlayoutsLothar Meyer-Lerbs – TeXSatz@uni-bremen.de – Vortrag: 2007-12-21

6.1 BeachteGestaltgesetze (?).

Die wichtigste ästhetische Qualität betrifft Kreuzun-gen der Kanten in Graphen (?).

Einführung in das Graphlayout-Thema, mit vielen Re-ferenzen, steht im Büchlein von ?.

Vergleich (?). Übersicht (?).Mental map (???).Dynamik mit Radial Layout (?).

6.2 Higraphs? führte higraphs ein. ? (?)

6.3 KnotenüberlappungVergleich verschiedener Verfahren (?).

force-transfer (siehe ?).edge-node intersections (?).

6.4 UML LayoutSugiyama verbessert: (?).

Unified Modeling Language (uml), state of the art inlayout techniques (?).

(?)jarinspector (?)

6.5 Sonstigescase (?).

6.5.1 Constrained Graph Layout

Für interaktive Systeme (?).

6.5.2 Multiscale

6.5.3 Energy models

(?)

6.5.4 Modular Decomposition

(?) (?)

29

7 Erweiterung der Reflexionsanalyseum Software-ProduktlinienBó Hú – docallan@informatik.uni-bremen.de – Vortrag: 2008-01-11

31

Anhang

33

A Abkürzungen

Abkürzung Bedeutung

case Computer-Aided Software Engineeringhci Human–Computer Interactionmci Mensch–Computer-Interaktionuml Unified Modeling Language

35