Informatik Forsch. Entw. 14: 145–153 (1999)

c© Springer-Verlag 1999

Probleme und Konzepte software-ergonomischer Beratungam Beispiel eines Informationssystems im World Wide Web (WWW)

Marc Hassenzahl1, Jochen Prumper2

1 Siemens AG, Fachzentrum User Interface Design (ZT IK 7), D-81730 Munchen (e-mail: marc.hassenzahl@mchp.siemens.de)2 FHTW – Fachhochschule fur Technik und Wirtschaft, Treskowallee 8, D-10313 Berlin (e-Mail: j.pruemper@fhtw-berlin.de)

Eingegangen am 23. November 1998 / Angenommen am 25. Marz 1999

Zusammenfassung.Die vorliegende Arbeit gibt Einblickin ein software-ergonomisches Beratungsprojekt zur Ent-wicklung eines internetbasierten Informationssystems. Siebeschreibt projektspezifische Probleme und die darauf auf-bauende Konzeption des Beratungsprojekts. Es galt, insbe-sondere drei Problembereiche zu berucksichtigen: (1) Zu-sammenarbeit von Software-Entwicklern und Ergonomen,(2) Integration von Grundprinzipien software-ergonomischerGestaltung in ein klassisches Vorgehensmodell der Software-Entwicklung (V-Modell) und (3) Wahl des Zeitpunkts furden Beginn der Beratung. Der konkrete Beratungsprozeß un-terteilte sich in drei Phasen: Analyse, Gestaltung und Bewer-tung des Informationssystems. In jeder dieser Phasen kamenverschiedene software-ergonomische Methoden (SchriftlicheBenutzerbefragung, Gebrauchstauglichkeitsstudien etc.) zumEinsatz, die an die Bedingungen des Projektes angepaßt wur-den. Der besondere Schwerpunkt lag dabei auf der Analy-sephase.

Schlusselworter: Software-Ergonomie, Benutzerorientie-rung, ISO 13407, Software-Engineering, Gebrauchstauglich-keit, Benutzungsfreundlichkeit, ISO 9241, WWW, Informa-tionssystem

Abstract. The present paper gives insight in a software er-gonomic consultation. The consultation’s aim was to supportthe development of a web-based information system by desi-gning and carrying out additional user-centred activities. Theway user-centred activities are carried out depends heavilyon the encountered project-specific problems. In the presentproject three problem areas had to be considered: (1) co-operation of software developers and usability consultants,(2) integration of basic user-centred activities into a classicalsoftware engineering approach (V-Modell), and (3) choosingthe appropriate time for the start of the consultation process.The consultation was divided into three stages: analysis, de-sign and evaluation. Each stage consisted of a bundle ofactivities (e.g. user survey, usability testing) tailored to thespecific problems and demands of the project.

Key words: Software ergonomics, user-centredness, ISO13407, software engineering, usability, ISO 9241, WWW,information system

CR Subject Classification:H5.2

1 Einleitung

Das Internet ist eine Moglichkeit, Informationen einer brei-ten Offentlichkeit zuganglich zu machen. Besonders dasWorld Wide Web (kurz: Web) spielt dabei eine wichtigeRolle. Ein Informationssystem in Form einer Web-Anwen-dung bietet neben dem hohen Grad anOffentlichkeit bzw.Erreichbarkeit den Vorteil, auf das Verteilen von Fehlerkor-rekturen und neuen Versionen verzichten zu konnen. Ebensowie bei klassischen Dialogsystemen spielt auch im Web dieGebrauchstauglichkeit [20] des Systems eine entscheidendeRolle.

Die vorliegende Arbeit soll einen Einblick in eine vonuns durchgefuhrte Software-Ergonomie-Beratung bei derEntwicklung des web-basierten ,,Informationssystems zurGesundheitsberichterstattung des Bundes (IS-GBE)“ geben.Software-Ergonomie ist – wie jede anwendungsorientierteDisziplin – in der Praxis oft mit spezifischen und proble-matischen Bedingungen konfrontiert. Die Berucksichtigungdieser Bedingungen bei der konkreten Ausgestaltung einesBeratungskonzepts ist entscheidend fur seinen Erfolg.

Unsere besondere Aufmerksamkeit gilt dabei zunachstden problematischen situativen Bedingungen (Abschnitt 2)und der Art und Weise, wie diese Bedingungen das Bera-tungskonzept beeinflußt haben. Danach stellen wir kurz dasInformationssystem vor (Abschnitt 3). Anschließend wer-den die einzelnen Phasen der Beratung dargestellt und nahererlautert (Abschnitt 4).

2 Beschreibung der Ausgangssituation

Die Tatigkeit als Berater fur Fragen der Software-Ergonomiekann schwierig sein. Die Grunde dafur finden sich in –aus Sicht der Software-Ergonomie – unzureichenden Bedin-gungen, unter denen Beratungsprojekte durchgefuhrt werdenmussen. Beispiele dafur sind fehlende Akzeptanz grundle-gender Ziele und/oder Methoden der Software-Ergonomiedurch den Auftraggeber oder ein im Verhaltnis zum ge-samten Software-Entwicklungsprojekt viel zu kleines Budget(vgl. [13]).

Im Rahmen des vorliegenden Beratungsprojekts mußteninsbesondere drei Problembereiche berucksichtigt werden,

146

die allerdings gemaß unserer Erfahrungen als typisch angese-hen werden konnen: (1) die Zusammenarbeit von Software-Entwicklern und Software-Ergonomen, (2) die Integrationvon Grundtechniken software-ergonomischer Gestaltung inein klassisches Vorgehensmodell bei der Software-Entwick-lung und (3) die Wahl des Zeitpunkts fur den Beginn derBeratung.

2.1 Zusammenarbeit von Software-Entwicklernund Ergonomen

Es gehort zum Charakter einer Software-Ergonomie-Bera-tung, daß sie von externen Experten vorgenommen wird.Eine typische Beratungssituation kann wie folgt aussehen:Ein Auftraggeber hat zur Entwicklung eines Softwaresystemsexterne Software-Entwickler beauftragt; zur Klarung soft-ware-ergonomischer Fragestellung greift der Auftraggeberallerdings zusatzlich auf einen externen Software-Ergonomenzuruck. Der Auftraggeber besetzt die Rolle eines Gesamtpro-jektleiters, Software-Entwickler und Software-Ergonomenwerden jeweils zu Teilprojektleitern. Eine solche ,,Dreiecks-konstellation“ kann zu Problemen fuhren.

Aus der Sicht derSoftware-Entwicklerbedeutet das Hin-zuziehen externer Software-Ergonomen meist Beschneidungdes eigenen Handlungsspielraums. Plotzlich werden Aufga-ben, die eigentlich in den eigenen Kompetenzbereich fal-len, wie z.B. die Konzeption der Benutzungsoberflache, vonanderen Personenubernommen. Des weiteren muß die Ar-beit des Ergonomen in die eigene Entwicklungsarbeit inte-griert werden, meist ohne ausreichend Zeit, die jeweiligen(oft recht unterschiedlichen) Arbeitsstile optimal aufeinan-der abzustimmen. Ein weiteres Problem fur den Software-Entwickler ist die erhohte Planungsunsicherheit. Dies seian einem Beispiel erlautert: Eine zusatzlich durchgefuhrteBenutzerbeteiligungsmaßnahme in einem Projekt, bei demBenutzer bis jetzt nicht beteiligt waren, erhoht deutlich dieWahrscheinlichkeit fur nachfolgendeAnderungswunsche desAuftraggebers. Ist das Projekt schon fortgeschritten (sieheAbschnitt 2.3), ist die Folge fur den Entwickler meist einernster terminlicher oder budgetbezogener Engpaß.

Auch aus der Sicht desSoftware-Ergonomenist die be-schriebene Konstellation nicht ohne Probleme. Er muß beiden Software-Entwicklern aktiv um Verstandnis fur seine Ar-beit werben. Seine Ziele und Methoden sind haufig noch zuwenig bekannt, um auch vom Auftraggeber voll akzeptiertzu werden [13]. Dies erfordert einigeUberzeugungsarbeitund ein ausgepragtes Durchsetzungsvermogen.

Diese Probleme konnen durch das Einrichten einerPro-jektgruppe im Sinne einer ,,benutzerzentrierten Software-Entwicklung“ [21] gemildert werden. Diese Projektgruppemuß aus zukunftigen Benutzern, Software-Entwicklern, Soft-ware-Ergonomen und Vertretern der Gesamtprojektleitung,d.h. des Auftraggebers bestehen. Die Anwesenheit des Auf-traggebers ist dabei von zentraler Bedeutung, da erst siedie Gruppe entscheidungsfahig macht und ihre Arbeit legiti-miert. Nur wenn zentrale Entscheidungstrager beteiligt wer-den, konnenuberhaupt Gestaltungsentscheidungen getroffenwerden, die fur die Software-Entwickler die Verbindlichkeiteines Auftrags haben.

Eine solche Projektgruppe wurde in dem vorliegendenProjekt eingerichtet. Besonders im Rahmen der Analyse-phase kam ihr eine wichtige Rolle zu (vgl. Abschnitt 4.1).

2.2 Die Integration von Grundprinzipiensoftware-ergonomisch orientierter Gestaltungin ein klassisches Vorgehensmodell

Obwohl im Einzelfall eine Vielzahl unterschiedlicher Metho-den der software-ergonomisch orientierten Gestaltung zumEinsatz kommen konnen, gibt es doch einen allgemeinenKonsensuber hilfreicheGrundprinzipien(vgl. [6, 21]). Diesesind Benutzerbeteiligung und Interdisziplinaritat, sowie Pro-totyping und iterative Gestaltung.

Diese Grundprinzipien lassen sich allerdings nur schwermit denen in der Praxis der Software-Entwicklung haufigvorherrschenden klassischen Vorgehensmodellen verbinden.Ein solches klassisches, relativ rigides Vorgehensmodell istdas ,,V-Modell“ [5]. Orthodox angewendet, raumt es derSoftware-Ergonomie keinen Platz ein und provoziert damitdie Entwicklung zufalliger Benutzungsoberflachen [31].

Das ,,V-Modell“ ist verbindlich fur die offentliche Handund kam auch bei der Entwicklung des vorliegenden Sy-stems zum Einsatz. Es stellte besondere Anspruche an un-sere Projektplanung, da im Projektverlauf Ansatzpunkte fursoftware-ergonomische Aktivitaten identifiziert werden muß-ten, die vom Auftraggeber bereitwillig als Erweiterung desklassischen Vorgehensmodells akzeptiert werden.

Obwohl das ,,V-Modell“ kein iteratives Gestalten vor-sieht, konnte zumindest ein teilfunktionaler Prototyp zurVerfugung gestellt werden. Dies wurde moglich, da in derEntwicklungspraxis auf Werkzeuge (Oracle CASE Designerund CASE Developer) zuruckgegriffen wurde, die ein itera-tives Vorgehen nahelegen. Dies allerdings stellt im strengenSinne schon eine Aufweichung des Vorgehensmodells dar.

Um das Manko der eingeschrankten Iterationshaufigkeitauszugleichen, wurde von uns – parallel zur eigentlichenSoftware-Entwicklung – ein iterativer Prozeß des Benut-zungsoberflachenprotopyings durchgefuhrt. Leider konntenbeide Prozesse nicht vollstandig integriert werden, so wiewir es gerne gesehen hatten.

Alles in allem kann das verwirklichte Beratungskon-zept als eine software-ergonomisch orientierte Erganzungdes klassischen Vorgehensmodells verstanden werden. Esvermeidet eine allzu harte Kollision mit den Vorgaben derSoftware-Entwickler, wodurch es allerdings eher den Cha-rakter einer isoliert durchgefuhrten Maßnahme erhalt.

Es sei betont, daß wir eine vollstandige Integrationsoftware-ergonomischer Methoden in Standard-Software-Entwicklungsprozesse als ein wichtiges, langfristiges Zielbegreifen. Ein Ansatz dazu sind Beratungsprojekte, die –ahnlich wie in dem hier vorgestellten Projekt – einen Kontaktzwischen Software-Entwicklern und software-ergonomischenGestaltungszielen und Methoden herstellen. Solche Projektesollen idealerweise im Sinne einer strukturierten ,,Organi-sationsentwicklung“ wirken [12, 25]. Ein anderer Ansatzist die Anreicherung der universitaren Ausbildung (vgl.[23]) und die Qualifizierung der bereits im beruflichen All-tag stehenden Entwickler in Form betrieblicher Weiterbil-dungsmaßnahmen (vgl. [11]).

147

2.3 Wahl des Zeitpunkts fur den Beginn der Beratung

Unter dem Begriff ,,Software-Ergonomie“ werden in derLiteratur recht unterschiedliche Betrachtungsweisen zusam-mengefaßt. So findet sich beispielsweise bei Wandmacher[31] eine Perspektive auf Software-Ergonomie, die die wahr-nehmungs- und kognitionspsychologische Optimierung be-tont. Hacker [10] erweitert diese Perspektive durch die Be-tonung arbeitsgestalterischer Maßnahmen. Mittlerweile hatsich – zumindest in Fachkreisen – ein breites Verstandnisder Software-Ergonomie durchgesetzt, das Benutzerorientie-rung und die Abhangigkeit software-ergonomischer Qualitatvom Nutzungskontext (d.h. Aufgabe, Benutzer, organisatio-nales und physisches Umfeld) hervorhebt (vgl. [4, 8, 15,30]).

Dies ist allerdings kein Garant dafur, daß ein solchesVerstandnis von Software-Ergonomie auch von potentiellenAuftraggebern geteilt wird. Versteht ein Auftraggeber Soft-ware-Ergonomie lediglich als eine Optimierung der Benut-zungsoberflache, wird er sie an einem fur ihn gunstigen Zeit-punkt anfordern, der eher in einem fortgeschrittenen Pro-jektstadium liegen wird. Eine ernsthafte Berucksichtigungbenutzer-, aufgaben- und organisationsbezogener Aspektebei der Gestaltung ist dann nur noch bedingt moglich.Zu viele Gestaltungsentscheidungen sind dann bereits ohneBerucksichtigung software-ergonomischer Gestaltungszielegetroffen worden.

Der Idealfall, eine bereits in der Planungsphase anset-zende Software-Ergonomie-Beratung, konnte auch im vor-liegenden Projekt nicht verwirklicht werden. Die Beratungwurde zu einem Zeitpunkt nachgefragt, an dem die Entwick-lung des ,,konzeptionellen Schemas“ bereits weitestgehendabgeschlossen war. Zudem waren nur wenige systematischeInformationenuber das Vorgehen bei der Anforderungsana-lyse vorhanden.

Diese Situation machte eine Art der software-ergonomi-schen Anforderungsanalyse zu Beginn unserer Arbeit not-wendig, deren Schwerpunkt im Sinne einer Re-Analyse aufdem Sammeln, Konkretisieren undUberprufen bereits vor-handenerAnforderungen lag. Ein solches Vorgehen kann zuerheblichen Problemen fuhren, da es aus der Sicht des Ent-wicklers einen Ruckschritt darstellt, der die in Entwicklungs-projekten vorherrschende Zeitknappheit noch verscharft.Trotz dieser Probleme ist eine Anforderungsreanalyse fureinen Software-Ergonomie-Berater, der unter Software-Ergo-nomie mehr versteht als nur die wahrnehmungs-und ko-gnitionspsychologische Optimierung einer grafischen Benut-zungsoberflache zwingend notwendig.

Nachdem nun die Ausgangssituation vorgestellt wurde,soll im weiteren kurz auf den Gegenstand der Beratung ein-gegangen werden.

3 Informationssystem zur Gesundheitsberichterstattungdes Bundes

Gegenstand der hier vorgestellten software-ergonomischenBeratung ist das beim Statistischen Bundesamt angesiedelte,offentlich geforderte Projekt ,,Informationssystem zur Ge-sundheitsberichterstattung des Bundes (IS-GBE)“ [16, 17,18]. Ein zentrales Ziel der Gesundheitsberichterstattung ist

Tabelle 1. TabellarischerUberblick der wichtigsten Funktionsbereiche desIS-GBE

Funktionsbereich BeschreibungThemenkatalog Suche in einem thematisch gegliederten Inhalts-

verzeichnis.Stichwortsuche Suche nach Stichworten; Unterstutzung des Be-

nutzers durch Thesaurus und Suche nachahnlichklingenden Stichworten.

Sammelkorb Dokumente konnen in einen Sammelkorbuber-tragen werden; der Inhalt des Sammelkorbs kanndann komplett oder in Teilen heruntergeladen wer-den. Fur registrierte Benutzer bleibt er bestehen,auch wenn die Arbeitssitzung unterbrochen oderbeendet wird.

Tabellen Registrierte Benutzer haben die Moglichkeit des,,Online Analytical Processing“ (OLAP). Dabeikonnen beispielsweise Kreuztabellen ,,online“ er-stellt und modifiziert werden (vgl. [19]).

Inhaltliche Vernetzung Dokumente sinduber Querverweise inhaltlich ver-netzt. Der Benutzer kann ausgehend von einemDokument inhaltlichahnliche, ,,verwandte“ Do-kumente explorieren.

es, gesundheitsrelevante Daten einem breiten Benutzerkreisaus Politik, Wirtschaft, Wissenschaft und der allgemeinenOffentlichkeit auf moglichst einfache Weise zuganglich zumachen. Dem IS-GBE kommt dabei die Rolle einer wich-tigen Schnittstelle zurOffentlichkeit zu. Um dieser Anfor-derung zu genugen, wurde das System als Web-Anwendungmit einer Benutzungsoberflache in der BeschreibungsspracheHTML konzipiert und realisiert.

Die Grundlage des Systems ist eine Kombination un-terschiedlicher Datenbankanwendungen, die dem Benutzerinteraktiven Zugriff auf Dokumente, Zahlen in Tabellen-form und Grafiken bietet. Tabelle 1 zeigt einenUberblickder wichtigsten Funktionsbereiche des Systems.

Das Informationssystem wird sowohl im Internet alsauch im Intranet des statistischen Bundesamts verfugbarsein. Dies macht es zu einem wichtigen Arbeitsmittel ,,ex-terner“ und ,,interner“ Fachexperten.

Das System soll nach einer Testphase ab Marz unterhttp://www.gbe-bund.de im Internet erreichbar sein (StandFebruar 1998).

4 Phasen des Beratungsprojektes ,,IS-GBE”

Die software-ergonomische Unterstutzung bei der Entwick-lung des IS-GBE begann am 1. Juli 1997 und endete MitteOktober 1998. Diese Zeitspanne unterteilte sich in drei Pha-sen:

– Analyse: orientierende psychologische Aufgabenanalyse,software-ergonomische Anforderungsreanalyse, Grob-entwurf eines ersten Prototypen, informelle Gebrauch-stauglichkeitsstudie und Benutzerbefragung

– Gestaltung: Feinentwurf auf der Basis der Daten aus derAnalysephase; Umsetzung, Verfeinerung und Korrekturdes Entwurfs

– Bewertung: formale Gebrauchstauglichkeitsstudie, Be-nutzerbefragung in Form eines Diskussionsforums

Im folgenden sollen nun Ziel und konkretes Vorgehenjeder Phase beschrieben werden.

148

Feinen

twur

f

form

ale G

ebra

uchs

taugli

chke

its-

studie mod

erier

te Gru

ppen

evalu

ation

Gestaltung

Oktober ’97 Dezember ’97

Umsetzu

ng, V

erfei

neru

ng un

d

Korre

ktur d

es F

einen

twur

fs

Juli ’98 August ’98

BewertungAnalyse

orien

tiere

nde A

ufgab

enan

alyse

n

softw

are-

ergo

nomisc

he

Anford

erun

gsre

analy

se

Grobe

ntwur

f eine

s erst

en P

rotot

ypen

infor

melle G

ebra

uchs

taugli

chke

its-

studie

und B

enutz

erbe

fragu

ng

Juli ’97 September ’97

ImplementierungBefüllung

Funktionstest

Erster EntwurfStart der

Implementierung

November '96

abschließendeÜberarbeitung

Oktober '98

Abb. 1. Projektphasen

Abbildung 1 gibt einen grobenUberblick des zeitlichenAblaufs der einzelnen Phasen. Auf eine genaue Datierungwurde hier verzichtet, da im Projektalltag die Phasenuber-gange eher fließend waren. Die vorgestellten Projektphasenbeziehen sich ausschließlich auf die von uns durchgefuhrtenBeratungsmaßnahmen. Fruhere Phasen der software-techni-schen Entwicklung werden lediglich angedeutet. Die Be-ratung begann nach Abschluß vorgelagerter konzeptionel-ler Arbeiten. Die Analysephase und die Gestaltungsphasebenotigten jeweils ca. drei Monate, die abschließende Be-wertungsphase etwas weniger als zwei Monate. Damit ergibtsich eine aktive Auslastung von ca. acht Monaten an dergesamten Projektdauer von 24 Monaten. Die restlichen 16Monate waren bestimmt von technisch orientierten Entwick-lungstatigkeiten, dem funktionalen Testen und der Befullungdes Systems.

4.1 Analyse

Das Ziel der Analyse war es, moglichst viel Information zusammeln, um software-ergonomische Gestaltungsentschei-dungen in der zweiten Phase zu erleichtern. Die Analysezeichnet sich durch einen hohen Grad an Benutzerbeteili-gung aus.

Die ergonomische Analysephase bei der Entwicklungvon IS-GBE bestand aus folgenden Teilprozessen:

– orientierende psychologische Aufgabenanalyse– software-ergonomische Anforderungsreanalyse– Grobentwurf eines ersten Prototypen– informelle Gebrauchstauglichkeitsstudie und Benutzer-

befragung

4.1.1 Orientierende psychologische Aufgabenanalyse

Am Anfang jeder Beratung steht immer die Notwendigkeit,die zu beratende Organisation und die Aufgaben der betrof-fenen Mitarbeiter kennenzulernen. Dazu fuhrten wir orien-tierende psychologische Aufgabenanalysen(in Anlehnung andie ,,Kontrastive Aufgabenanalyse im Buro (KABA)”, siehe[7]) durch. Da das IS-GBE auch im Intranet des statisti-schen Bundesamts eingesetzt werden soll, geben die dortdurchgefuhrten Aufgabenanalysen einen ersten Einblick inden Nutzungskontext des Systems.

Diese Analysen beinhalteten Gesprache mit Vorgesetz-ten (Arbeitsorganisatoren) zur Struktur der Organisation, mit

Vertretern der EDV-Abteilung zur hardware- und software-technischen Infrastruktur und mit zukunftigen Benutzern(Mitarbeiter der Fachabteilungen) zur Arbeitsaufgabe.

Gesprache mit zukunftigen Benutzern wurden direkt anden jeweiligen Arbeitsplatzen in Form von Beobachtungsin-terviews gefuhrt. Zentrale Themen waren dabei die Strukturder Arbeitsaufgaben, der Anteil der Bildschirmarbeit an dergesamten Arbeit, bereits eingesetzte Softwaresysteme undQualifikationen im Hinblick auf Computer.

Neben der Informationsgewinnung stellte die Aufga-benanalyse auch eine Art ,,Eisbrecher“ dar. Sie bot zumeinen die Moglichkeit, Mitarbeiter der Organisationuber diesoftware-ergonomischen Maßnahmen zu informieren; zumanderen konnten so zukunftige Benutzer fur die Mitarbeitam weiteren Entwicklungsprozeß gewonnen werden.

Im Rahmen des vorliegenden Projektes haben wir funfdirekt betroffene Mitarbeiter am Arbeitsplatz aufgesucht.

4.1.2 Software-ergonomische Anforderungsreanalyse

Die software-ergonomische Anforderungsreanalyse wurdein vier Gruppensitzungenmit zukunftigen Benutzern, Ent-wicklern und dem Auftraggeber (Projektgruppe, vgl. Ab-schnitt 2.1) durchgefuhrt. Ziel dieser Sitzungen war es, be-stehende Anforderungen zu bewerten, zu erganzen und zupriorisieren. Auf diese Weise wurden eine Reihe verbindli-cher Anforderungen an das Informationssystem bestimmt,die explizite software-ergonomische und arbeitsgestalteri-scheUberlegungen beinhalteten.

Zur Analyse wurden unterschiedliche Techniken ange-wendet. Zu Beginn dominierten Gruppenarbeiten und Rol-lenspiele zur Bestimmung prototypischer, zukunftiger Be-nutzer (z.B. Fachexperte aus der Organisation, Wissenschaft-ler, Normalnutzer, Journalist), deren Aufgaben und den sichdaraus ergebenden Anforderungen. Beim Erarbeiten der An-forderungen spielte ausschließlich die Gebrauchstauglichkeitdes Systems (dies beinhaltet auch die Nutzlichkeit seinerFunktionalitat) eine Rolle und nicht die Nutzlichkeit der an-gebotenen Inhalte. Dies ist zwar ein wichtiger Aspekt, liegtaber außerhalb des hier vorgestellten Projektes.

Gegen Ende der Analyse wurden ausgewahlte proble-matische Elemente der Benutzungsoberflache (wie z.B. derFunktionsbereich Stichwortsuche) mit Hilfe von Papierpro-totypen (siehe Abbildung 2a) und HTML-Modellen konkretgestaltet und diskutiert.

Im Rahmen der Anforderungsreanalyse ist es wichtig,Diskussionsergebnisse und Grundlagen fur Gestaltungsent-scheidungen zu protokollieren. Nur so kann verhindert wer-

149

Abb. 2. Entwicklungsschritte der Benutzungsoberflache des IS-GBE am Beispiel des Funktionsbereichs Stichwortsuche: a) Papierprototyp aus der Anfor-derungsreanalyse, b) Grobentwurf, c) getesteter Prototyp, d) Feinentwurf aus der Gestaltungsphase

den, daß Anforderungen ,,schwimmen“ (d.h. von den Betei-ligten permanent verandert werden) oder sich die Analyse,,im Kreis dreht“. Letzteres passiert, wenn die Gruppe dieGrundlage einer fruheren Gestaltungsentscheidung ,,verges-sen“ hat und beispielsweise eine schon langst verworfeneAnforderung reaktiviert, ohne eine Veranderung der Situa-tion, die eine solche Reaktivierung rechtfertigt. Diese Ge-fahr besteht besonders bei großerem zeitlichen Abstand dereinzelnen Sitzungen oder sich verandernder Gruppenzusam-mensetzung.

Unter diesem Gesichtspunkt konnen bei der Entwick-lung komplexer Systeme formale Methoden zur Protokollie-rung von Gestaltungsentscheidungen, wie z.B. die ,,designspace analysis“ [24] und ein software-gestutztes Anforde-rungsmanagement, z.B. DOORS [1] (siehe auch [33]) sehrhilfreich sein. In vorliegendem Projekt kamen solche Metho-den nur indirekt zum Einsatz. Beim Explorieren und Analy-sieren der Anforderungen wurde zwar auf das Gedankenmo-dell der ,,design space analysis“ zuruckgegriffen; auf die vonMacLean et al. [24] vorgeschlagene QOC-Notation (Que-stions, Options, Criteria) mußte allerdings aus Zeitgrundenverzichtet werden. Das Anforderungsmanagement wurde mitHilfe einfacher Anforderungslisten durchgefuhrt. Das Bear-beiten dieser Listen war fester Bestandteil jeder Gruppensit-zung: Anforderungen wurden verandert, zuruckgestellt oderaufgegeben. Auf diese Weise lag der Stand der Anforderun-gen jederzeit protokolliert und fur alle Beteiligten einseh-bar vor. Veranderungen der Anforderungen, die beispiels-weise in Gesprachen zwischen Auftraggeber und Software-Entwicklern außerhalb der Sitzungen vorgenommen wurden,kamen so zur Sprache, konnten von der Gruppe offen disku-tiert und bei der Arbeit angemessen berucksichtigt werden.

Ein letztes wichtiges Element der Reanalyse ergibt sichaus dem Ansatz, software-ergonomische Beratung als einenLern- und Veranderungsprozeßzu betrachten. Wir verste-hen Software-Ergonomie-Beratung nicht als ,,expertokrati-schen“ Prozeß, sondern als einen partizipativen Lernprozeßaller Beteiligten (auch des Beraters). Dementsprechend wa-ren auch kleinere Lerneinheiten zu Themen wie ,,Problemeder Gebrauchstauglichkeit von Frames“ [27] Teil der Grup-penarbeit.

Nach vier eintagigen Sitzungen lagen damit genug In-formationen und Vorschlage vor, um einen Grobentwurf er-stellen zu konnen.

4.1.3 Grobentwurf der Benutzungsoberflache

Es erscheint uns wenig sinnvoll, empirische (Roh-)Datenohne vorherige Transformation in einen Losungsvorschlagzu prasentieren. Nach unseren Erfahrungen herrscht in einempraxisorientierten Umfeld eine hohe Losungsorientierungvor. So sind primar die Schlußfolgerungen aus den Datender Analysenvon Interesse; die Daten selbst werden eherals sekundar verstanden. Die primare Aufgabe des Software-Ergonomie-Beraters besteht also darin, aus den gesammel-ten Daten konkrete Gestaltungsvorschlage abzuleiten, diesezu prasentieren und zu begrunden.

Auf der Basis der in der Re-Analyse gewonnenen In-formationen erstellten wir zunachst einen nicht-funktionalenHTML-Prototypen (siehe Abbildung 2b fur ein Beispiel).Dieses ,,visuelle Protokoll“ faßte wichtige Ergebnisse derProjektarbeit zusammen. Mayhew und Bias [25] betonen dieWichtigkeit einer effektiven Kommunikation fur software-

150

ergonomische Beratung. Ein grundlegender Erfolgsfaktor fureffektive Kommunikation ist nach unserer Ansicht die an-schauliche Prasentation von Arbeitsergebnissen (z.B. anhandeines Prototypen), die wir als weitaus effektiver einschatzenals das Erarbeiten umfangreicher Spezifikationen der Benut-zungsoberflache.

Auf der Basis der Ergebnisprotokolle der Sitzungenund der aktuellen Anforderungsliste konnten die Software-Entwickler nun einen funktionalen Prototypen erstellen, derin nachfolgenden Schritten bewertet und verbessert werdensollte.

4.1.4 Informelle Gebrauchstauglichkeitsstudieund Benutzerbefragung

,,Prototyping“ oder ,,Versioning“ (siehe [9]) als Unterstutz-ung der software-ergonomisch orientierten Gestaltung ist nurdann sinnvoll, wenn angemessene und systematische Metho-den zur Evaluation des Prototypen angewendet werden.

Ein Verfahren zur software-ergonomischen Evaluation istdie Gebrauchstauglichkeitsstudie(z.B. [26]), im englisch-sprachigen Raum ,,usability testing“ genannt. Diese Methodekann zwar konkrete Nutzungsprobleme aufzeigen, ist jedochin der Durchfuhrung relativ aufwendig. Daraus folgt, daß nurwenige zukunftige Benutzer an einer solchen Studie teilneh-men konnen, was immer wieder zu Fragen von Auftrag-gebern und Entwicklern bezuglich der Reprasentativitat derStichprobe fuhrt.

Eine Moglichkeit, viele reprasentative Benutzer an einerStudie zu beteiligen, ist dieBenutzerbefragungmit Hilfe ei-nes schriftlichen Fragebogens (z.B. [26]). Nachteil der Be-nutzerbefragung ist die eher indirekte Natur der erhobe-nen Daten. Im Gegensatz zu Gebrauchstauglichkeitsstudienkonnen mit Hilfe schriftlicher Fragebogen nur sehr schwerkonkrete Nutzungsprobleme mit direktem Bezug zum unter-suchten System aufgezeigt werden.

Da sich die beiden Evaluationsmethoden gut erganzen,setzen wir sie, wenn moglich, gemeinsam ein. Die Kombi-nation beider Verfahren wird im folgendenKreuzevaluationgenannt.

Eine eher informell durchgefuhrte Kreuzevaluation zumAbschluß der Analysephase fand auf dem ,,Forschungsfo-rum ’97“ (Messe Leipzig, 16.–20.9.1997) statt. Hier wurdeder Offentlichkeit ein erster funktionaler Prototyp des IS-GBE prasentiert (siehe auch Abbildung 2c fur ein Bei-spiel). Mit Hilfe eines Fragebogens wurde eineBenutzerbe-fragungdurchgefuhrt, die folgende Themen behandelte: (1)Suche mit dem Computer (Suchstrategien, logische Opera-toren), (2) Erwartungen an die Funktionalitat und (3) all-gemeines Interesse an dem zukunftigen System. Außerdemwurde die Erfahrung des Teilnehmers mit Computern (Nut-zungshaufigkeit, Anzahl der beherrschten Programme, Pro-grammiererfahrung) erhoben, um so Unterschiede zwischenunerfahrenen und erfahrenen Computeranwendern beim Sy-stementwurf berucksichtigen zu konnen. Auf dem ,,For-schungsforum ’97“ wurde der Fragebogen von insgesamt 79Personen bearbeitet (weitere 18 wurden in der Fachabteilungdes statistischen Bundesamtes ausgegeben und bearbeitet).

Im Rahmen derGebrauchstauglichkeitsstudiewurde dieMethode des ,,lauten Denkens“ in Kombination mit einer

teilnehmenden Beobachtung angewendet. Jedes identifizierteProblem der testenden Benutzer mit dem System weist aufeine potentielle software-ergonomische Schwachstelle hin.Abschließend wurde mit jedem der Teilnehmer ein kurzesInterview gefuhrt. Fur diese Art der Evaluation konnten 29Personen gewonnen werden. Eine detailliertere Darstellungder Vorgehensweise und einiger Ergebnisse finden sich beiHassenzahl, Prumper und Schulz [14].

Die Kreuzevaluation stellte den Abschluß der Analyse-phase dar. Es lagen nun genug Informationen vor, um ineiner Gestaltungsphase einen Feinentwurf zu erarbeiten.

4.2 Gestaltung

Das Ziel der Gestaltungsphase war es, die Informationenaus der Analysephase zu bundeln und in den Entwurf desSystems einfließen zu lassen. Dabei ging es hauptsachlichum software-ergonomische Detailarbeit, die in enger Zusam-menarbeit mit Auftraggebern und Software-Entwicklern ge-leistet werden mußte. Dementsprechend zeichnete sich dieGestaltungsphase durch einen eher niedrigen Grad an Be-nutzerbeteiligung aus. Vielmehr haben wir unseren Kontaktzu den Entwicklern intensiviert, um einerseits verstarkt dieWeiterentwicklung des Systems voranzutreiben und ihnenandererseits eine ,,Atempause“ zum Aufarbeiten der in derAnalysephase gewonnenen Einsichten zu verschaffen.

Die Gestaltungsphase bei der Entwicklung des IS-GBEbestand aus zwei Teilprozessen:

– Erarbeitung eines ergonomischen Feinentwurfs auf derBasis der Ergebnisse aus der Analysephase

– Umsetzung, Verfeinerung und Korrektur des Feinent-wurfs

4.2.1 Ergonomischer Feinentwurf

Ausgehend von den Daten der Analysephase erstellten wir zuBeginn der Gestaltungsphase wiederum zuerst einen nicht-funktionalen Feinentwurf (als HTML-Prototyp, siehe auchAbbildung 2d fur ein Beispiel). Dieser Entwurf berucksich-tigte insbesondere die im Rahmen der Kreuzevaluation ge-wonnenen Daten und Informationen. In diesem Sinne stellter eineUberarbeitung des Grobentwurfs dar. Wieder wurdeein ,,visuelles Protokoll“ erstellt, um die Ergebnisse der Ana-lysephase zu veranschaulichen.

4.2.2 Umsetzung, Verfeinerungund Korrektur des Feinentwurfes

Im Rahmen des iterativen Ansatzes fuhrten wir weiterhinregelmaßig Sitzungen mit Entwicklern und Auftraggebernzur Verfeinerung und Korrektur des Entwurfs durch.

Die Umsetzung des Entwurfs ist Aufgabe der Software-Entwickler. Der Software-Ergonom muß hier zurucktretenund dem Entwickler die Fuhrunguberlassen. Nur durch ge-genseitiges Anerkennen der Kompetenzen des Partners wirdeine konfliktfreie Zusammenarbeit moglich. Im konkretenProjekt wurden vor allem unterschiedliche Detail-Vorschlageund Anfragen der Entwickler diskutiert.

151

Da es in dieser Phase nicht mehr um das Erarbeitengrundlegender Anforderungen ging, konnte auf einen ho-hen Grad an Benutzerpartizipation verzichtet werden. Trotz-dem mussen die vorher beteiligten Benutzeruber den Standder Entwicklung weiterhin informiert werden, was sich ameinfachsten durch das Hinzuziehen eines Benutzervertretersrealisieren ließ.

Den Abschluß der Gestaltungsphase bildete die Fertig-stellung des Softwaresystems, der funktionale Test und dieanschließende Befullung mit Daten.

4.3 Bewertung

DasZiel der abschließenden Bewertungsphase war ein zwei-faches: Zum einen sollte die Bewertung Hinweise auf nochbestehende Nutzungsprobleme geben, zum anderen ermog-lichte sie die Evaluation des hier vorgestellten Beratungs-konzeptes.

Auf eine abschließende Bewertung des Softwaresystemskann nicht verzichtet werden, da durch Umgestaltung nichtimmer nur Nutzungsprobleme aus dem Weg geraumt wer-den, sondern durchaus auch neue entstehen konnen [2]. DieBewertung muß zu einem Zeitpunkt durchgefuhrt werden,an dem noch eine weitere, wenn auch begrenzte Umge-staltung des Softwaresystems moglich ist. Solche ergonomi-schen ,,Bugfixes“ sollten – ebenso wie das Beheben funk-tionaler Probleme (Fehler) – selbstverstandlich sein.

Die Bewertungsphase bestand aus einer formalen Ge-brauchstauglichkeitsstudie und einer Benutzerbefragung inForm eines Diskussionsforums. Dies entspricht wieder demvon uns favorisierten Prinzip der Kreuzevaluation.

Da im vorliegenden Projekt die Bewertungsphase als er-neute Analysephase konzipiert war, d.h. mit weiteren Itera-tionen im Entwicklungsprozeß gerechnet werden kann, sollhier nur ihre Konzeption kurz dargestellt werden. Entspre-chende Ergebnisse werden Inhalt weiterer Arbeiten zur Eva-luation der vorgestellten Beratungsmaßnahme sein.

4.3.1 Kreuzevaluation des funktionalen Systems

Im Rahmen der formalenGebrauchstauglichkeitsstudiewur-den quantitative Maße derEffizienz(z.B. Anteil der Fehler-bewaltigungszeit an der Aufgabenbearbeitungszeit), derEf-fektivitat (z.B. Prozentsatz erfolgreich abgeschlossener Auf-gaben) und der subjektivenZufriedenheit (mit Hilfe desISONORM 9241/10 Fragebogens, z.B. [29]) erfaßt [20].Außerdem wurden mit Fehleranalysen in Anlehnung an die,,handlungsorientierte Fehlertaxonomie“ (z.B. [34]) qualita-tive Daten in Form konkreter Nutzungsprobleme erhoben(vgl. [22]).

Erganzt wurde dies durch eine besondere Form derBenutzerbefragung: die moderierte Gruppenevaluation. ImRahmen dieser Evaluation wurde eine Gruppe Interessier-ter zu einem eintagigen Workshop eingeladen. Ziel diesesWorkshops war das gemeinsame Testen des Informations-systems in Kleingruppen. So wurden Probleme identifiziert,diskutiert und potentielle Losungsvorschlage erarbeitet.

Neben dem Auffinden noch bestehender, nicht akzep-tabler Nutzungsprobleme kann die abschließende Bewer-

tung auch als erneute Analysephase fur nachfolgende, wei-tere Gestaltungsphasen verstanden werden. Dies wird sogarnotwendig, wenn man Software-Ergonomie als kontinuier-lichen Prozeß bzw. als einen Teil der Wartung eines Soft-waresystems ([28] S. 172ff) betrachtet.

5 Schlußfolgerung und Ausblick

Das Ziel der vorliegenden Arbeit ist die Beschreibung ei-nes software-ergonomischen Beratungskonzeptes anhand ei-nes konkreten Fallbeispiels. Sie zeigt zum einen Problemeauf, mit denen in der Praxis zu rechnen ist, zum anderendokumentiert sie Konzepte zur Losung – oder zumindestMilderung – der Probleme.

Folgende Punkte sollten bei der Durchfuhrung einer Soft-ware-Ergonomie-Beratung berucksichtigt werden:

– Einrichten einer Projektgruppe zur angemessenen Be-teiligung zukunftiger Benutzer, zur Erleichterung derKommunikation zwischen den Beteiligten (Auftragge-ber, Software-Entwickler, Software-Ergonom, zukunfti-ger Benutzer) und zur Unterstutzung von Entscheidungs-prozessen.

– Durchfuhren einer Anforderungsreanalyse bei Entwick-lungsprojekten im fortgeschrittenen Projektstadium, so-fern vorher kein Software-Ergonom beteiligt war. Beidieser Analyse muß besonders auf ein effektives Anfor-derungsmanagement und mogliche Konflikte mit Soft-ware-Entwicklern geachtet werden.

– Prasentation der Analyseergebnisse in Form konkreterGestaltungsvorschlage.

– Moglichst haufiges Bewerten der Gestaltungsvorschlageunter Einbeziehung potentieller zukunftiger Benutzer undmoglichst unterschiedlicher Methoden.

– Einplanen von ,,Atempausen” fur die Umsetzung der Ge-staltungsvorschlage durch die Software-Entwickler.

Langfristig muß die Software-Ergonomie mit ihren Zielenund Methoden in den Alltag der Software-Entwicklung in-tegriert werden. Daß dies noch nicht der Fall ist, zeigt dieNachfrage nach software-ergonomischer Qualitatssicherungin Form von Beratung durch externe Experten. Noch im-mer fehlt Software-Entwicklern haufig das methodische Wis-sen oder die benutzerorientierte Einstellung zur effektivenBerucksichtigung software-ergonomischer Qualitatssicher-ung im Entwicklungsprozeß.

Kurzfristig sind Beratungsprojekte eine Moglichkeit,Wissen und Methoden der Software-Ergonomie in die Pra-xis der Software-Entwicklung zu transferieren. Auch in derPraxis der Beratung mussen beschrankte Moglichkeiten undungunstige Bedingungen kompensiert werden. Das verlangtnach einem flexiblen Einsatz software-ergonomischer Me-thoden. Das vorgestellte Projekt soll beispielhaft verdeutli-chen, wie Software-Ergonomie in der gangigen Praxis derSoftware-Entwicklung berucksichtigt werden kann.

Zukunftige Arbeiten sollten sich verstarkt mit der syste-matischen Beschreibung ungunstiger Bedingungen, den dar-aus entstehenden Problemen und moglicher Losungs- bzw.Beratungskonzepte beschaftigen. Nur so kann der Transfersoftware-ergonomischen Wissens und Methoden in die Pra-xis der Software-Entwicklung erfolgreich bewaltigt werden.

152

Naturlich darf auf die Evaluation und die damit verbun-dene kontinuierliche Verbesserung solcher Beratungskon-zepte nicht verzichtet werden. Diesubersteigt allerdings denRahmen der vorliegenden Arbeit, soll aber – zumindest bei-spielhaft – an andere Stelle nachgeholt werden.

Danksagung.Wir danken Dr. Gunter Bruckner (Statistisches Bundesamt),Dr. Gunther Himmelmann (Universitat Marburg), Prof. Dr. Reinhard Op-permann (GMD), Dipl.-Psych. Uta Sailer und Dipl.-Psych. Edmund Buch-binder fur die kritische Durchsicht des Manuskripts und die vielen wichtigenund anregenden Kommentare.

Literatur

1. Anon.: DOORS, requirement management tool. QSS(http://www.qssinc.com) 1997

2. Bailey, G.: Iterative methodology and designer training in human-computer interface design. Proceedings of ACM CHI’88 Conference1988, pp. 198–205

3. Bevan, N., Macleod, M.: Usability measurement in context. Behaviour& Information Technology13 (1&2), 132–145 (1994)

4. Beyer, H., Holtzblatt, K.: Contextual Design. Defining Customer-Centered Systems. San Francisco 1998

5. Brohl, A.-P., Droschel, W.: Das V-Modell. Munchen: Oldenbourg 19936. Carroll, J. M.: Human-computer interaction: psychology as a science

of design. Int J Human-Computer Studies46, 501–522 (1997)7. Dunckel, H., Volpert, W., Zolch, M., Kreutner, U., Pleiss, C., Hennes,

K.: Kontrastive Aufgabenanalyse im Buro – Der KABA-Leitfaden,Arbeitsblatter. Stuttgart: B.G. Teubner 1993

8. Eberleh, E., Oberquelle, H., Oppermann, R.: Einfuhrung in die Soft-ware-Ergonomie. Gestaltung graphisch-interaktiver Systeme: Prinzi-pien, Werkzeuge, Losungen. 2., vollig neu bearbeitete Auflage. Berlin:de Gruyter 1994

9. Frese, M., Prumper, J., Solzbacher, F.: Eine Fallstudie zu Benutzerbe-teiligung und Prototyping. In: Brodbeck, F. C., Frese, M. (Hrsg.), Pro-duktivitat und Qualitat in Software-Projekten. Psychologische Analyseund Optimierung von Arbeitsprozessen in der Software-Entwicklung,S. 135–143. Munchen: Oldenbourg 1994

10. Hacker, W.: Software-Ergonomie: Gestalten rechnergestutzter geisti-ger Arbeit?! In: Schonpflug, W., Wittstock, M. (Hrsg.), Software-Ergonomie ’87: Nutzen Informationssysteme dem Benutzer?, S. 31–54.Stuttgart: B.G. Teubner 1987

11. Hassenzahl, M., Buchbinder, E., Prumper, J.: Software-Ergonomie-Schulung in der betrieblichen Praxis – das SEE-Konzept. Ergonomieund Informatik34, 5–11 (1999)

12. Hassenzahl, M., Prumper, J., Buchbinder, E.: Software-ergonomischeBeratung in der Praxis – ein Beitrag zur Organisationsentwicklung.In: Clermont, A., Schmeisser, W. (Hrsg.), Betriebliche Personal- undSozialpolitik. Munchen: Vahlen 1999

13. Hassenzahl, M., Prumper, J., Buchbinder, E.: Software ergonomics inpractice: the importance of acceptance-related issues. In: Sikorski, M.,Rauterberg, M. (Hrsg.), Transferring usability engineering to industry.International workshop proceedings, S. 9–13. Gdansk: Technical Uni-versity of Gdansk 1998

14. Hassenzahl, M., Prumper, J., Schulz, J.: Die software-ergonomischeGestaltung von WorldWideWeb-Seiten: Benutzerbefragungen und

“Usability”-Tests. In: Himmelmann, G. W. (Hrsg.), Oracle in Theorieund Praxis: Vortragsband zur 10. Jahrestagung der DOAG-Konferenz,Fellbach 1997, S. 309–323. Stuttgart: Deutsche Oracle AnwenderGruppe, e.V. 1997

15. Herczeg, M.: Software-Ergonomie. Grundlagen der Mensch-Computer-Kommunikation. Bonn: Addison-Wesley 1994

16. Himmelmann, G. W., Prumper, J., Hassenzahl, M., Schulz, J., Eber-hardt, W., Bruckner, G., Dubrow, M.: A General Health InformationSystem in the Web: What is its Impact? – The German Federal HealthInformation System IS-GBE as a Sociocybernetic Experience. WorldCongress of Sociology, Montreal, July 26th–August 1st 1998

17. Hoffmann, U.: Zum Aufbau einer nationalen Gesundheitsberichterstat-tung. Wirtschaft und Statistik1, 33ff (1993)

18. Hoffmann, U., Bohm, K.: Fortschritte beim Aufbau der Gesundheitsbe-richterstattung des Bundes. Wirtschaft und Statistik2, 113–125 (1995)

19. Inmon, W. H.: Building the Data Warehouse. New York: John Wiley/ QED Publications 1993

20. ISO 9241: Ergonomische Anforderungen an die Burotatigkeit mit Bild-schirmgeraten. Teil 11: Anforderungen an die Gebrauchstauglichkeit –Leitsatze, 1996a

21. ISO CD 13407: Human-centred design, commitee draft, 1996b22. Kensik, A., Prumper, J., Frese, M.: Ergonomische Gestaltung von Soft-

ware auf Grundlage handlungsorientierter Fehleranalysen. In: Bocker,H. D. (Hrsg.), Software-Ergonomie ’95 – Anwendungsbereiche lernenvoneinander, S. 217–232. Stuttgart: B.G. Teubner 1995

23. Maaß, S., Ackermann, D., Dzida, W., Gorny, P., Oberquelle,H., Rodiger, K.H., Rupietta, W., Streitz, N.: Software-Ergonomie-Ausbildung in Informatik-Studiengangen bundesdeutscher Univer-sitaten. Informatik-Spektrum16, 25–30 (1993)

24. MacLean, A., Young, R. M., Bellotti, V. M. E., Moran, T. P.: Questi-ons, options, criteria: elements of design space analysis. Human Com-puter Interaction6, 201–250 (1991)

25. Mayhew, D., Bias, R.G.: Organizational Inhibitors and Facilitators. In:Bias, R. G., Mayhew, D. (Hrsg.), Cost-Justifying Usability, S. 287–318. Boston, MA: Academic Press 1994

26. Nielsen, J.: Usability Engineering. Boston, San Diego: Academic Press1993

27. Nielsen, J.: Why Frames Suck (Most of the Time). Jakob Nielsen’sAlertbox (http://www.useit.com/alertbox/9612.html) 1996

28. Pomberger, G., Blaschek, G.: Software Engineering. Prototypen undobjekt-orientierte Software-Entwicklung, 2. Auflage. Munchen, Wien:Hanser 1996

29. Prumper, J.: Der Benutzungsfragebogen ISONORM 9241/10: Ergeb-nisse zur Reliabilitat und Validitat. In: Liskowsky, R., Velichkovsky,B. M., Wunschmann, W. (Hrsg.), Software-Ergonomie ’97. UsabilityEngineering: Integration von Mensch-Computer-Interaktion und Soft-ware-Entwicklung, S. 253–262. Stuttgart: B.G. Teubner 1997

30. Shneiderman, B.: Designing the User Interface. Strategies for EffectiveHuman-Computer Interaction (3rd edn) Reading, MA: Addison-Wesley1998

31. Schoeffel, R.: Usability Engineering am Beispiel des Home ElectronicSystem von Siemens und Bosch. In: Liskowsky, R., Velichkovsky,B. M., Wunschmann, W. (Hrsg.), Software-Ergonomie ’97. UsabilityEngineering: Integration von Mensch-Computer-Interaktion und Soft-ware-Entwicklung, S. 37–53. Stuttgart: B.G. Teubner 1997

32. Wandmacher, J.: Software-Ergonomie. Berlin: de Gruyter 199333. Yourdon, E.: Death March. Upper Saddle River, NJ: Prentice-Hall 199734. Zapf, D., Brodbeck, F. C., Prumper, J.: Handlungsorientierte Fehlerta-

xonomie in der Mensch-Computer Interaktion. Zeitschrift fur Arbeits-und Organisationspsychologie33, 178–187 (1989)

153

Marc Hassenzahl,Jahrgang 1969, stu-dierte Psychologie und Informatik (imNebenfach) an der Technischen Univer-sitat Darmstadt. Seit Herbst 1998 ister als Software-Ergonomie-Berater imFachzentrum ,,User Interface Design”des Siemens-Konzerns tatig. Schwer-punkte seiner Forschungstatigkeit sinddie ergonomische Gestaltung von Such-funktionen im Internet und die Verbin-dung von Anforderungen der Ergono-mie mit Anforderungen des Produkt-Designs.

Jochen Prumper, Jahrgang 1958, stu-dierte Psychologie an den UniversitatenUtrecht/NL, Landau und Munchen. Erpromovierte an der Universitat Gießenund war anschließend einige Jahre ineinem EDV-Unternehmen tatig. Seit1995 ist er Inhaber der Professur furWirtschaftspsychologie im FachbereichWirtschaftswissenschaften an der Fach-hochschule fur Technik und Wirtschaftin Berlin. Schwerpunkte seiner For-schungstatigkeit im Bereich Informatiksind Arbeits- und Organisationsanaly-sen, Fehler in der Mensch-Computer In-teraktion, Software-Evaluation und Bild-schirmarbeitsplatzanalysen.