Der Trugschluß der egozentrischen Intuition

Benutzerbeteiligung bei der Softwareentwicklung

Dipl. Inform. Hinnerk W. Rümenapf


Seminar Produktionstechnik und menschliche Arbeit
Wintersemester 1994/95
9. Februar 1995


Technische Universität Braunschweig
Institut für Wirtschaftswissenschaft
Abteilung für Arbeitswissenschaft
Prof. Dr.-Ing. J.-H. Kirchner


Worterklärung

Die im Titel verwendeten Begriffe egozentrisch und Intuition sollen vorab erläutert werden:

egozentrisch

[lat. ich- oder selbstbezogen]

aus: Friedrich Dorsch (Hrsg.): Psychologisches Wörterbuch, Verlag Hans Huber, 11. Aufl. 1987.
Der große Brockhaus, 1953.

Intuition

[lat. intuitio, intueri genau hinsehen]

aus: Friedrich Dorsch (Hrsg.): Psychologisches Wörterbuch, Verlag Hans Huber, 11. Aufl. 1987.

Für den Begriff egozentrisch kann hier die Übersetzung ins Deutsche genügen. Für Intuition werden zwei Erklärungen gegeben. Offenbarungen und Eingebungen ungeklärten Ursprungs werden hier nicht betrachtet. Es wird im folgenden von Intuition im Sinn der zweiten Erklärung gesprochen als ein auf Erfahrung basierendes Erkennen und Verstehen.

Im gleichen Sinn wird die Intuition auch in [6fus] betrachtet und ausführlich erläutert.

Die angestrebte intuitive Bedienbarkeit von Programmen bedeutet also, daß die vorhandene Erfahrung des Anwenders für die Bedienung ausreichen soll.

Vorerfahrungen von Benutzern/Entwicklern

Vorhandene Erfahrungen sind die Grundlage der Intuition. Es sollen hier Vorerfahrungen anhand von Beispielen betrachtet werden. Durch die hohe Entwicklungsgeschwindigkeit sind für die Benutzer und Entwickler der Gegenwart auch Beispiele von Bedeutung, die bereits als veraltet gelten.

Minimaler Benutzerdialog

Bild: Minimaler Benutzerdialog.

Der Benutzer gibt dem Computer Anweisungen in Form von Befehlstexten. Die Anweisungen müssen Zeichen für Zeichen korrekt eingegeben werden. Hilfestellungen gibt es nur im Handbuch. Nach der Bearbeitung einer Anweisung gibt das System die Meldung READY. aus und wartet auf weitere Kommandos.

Ein Programm prog1 wurde von einem Diskettenlaufwerk geladen und gestartet. Das Programm gibt ein Fragezeichen aus um anzuzeigen, daß eine Eingabe vom Benutzer erwartet wird.

Das Beispiel bezieht sich auf einen frühen Schreibtischcomputer für Büroanwendungen [cbm].



Das erste Beispiel zeigt eine minimale Benutzerschnittstelle. Geprägt von unzureichender Rechnerleistung ist das Programm auf das absolut Notwendige reduziert.

Der Benutzer muß wissen, wie das Programm zu bedienen ist, es gibt nicht die geringste Hilfestellung. Ergonomie ist kein Thema.

Der Entwickler hat nur die Aufgabe, ein funktionierndes Programm zu erstellen. Es sind alleine die technischen Probleme zu berücksichtigen.

Auf solche Programme folgten die ersten Regeln, die die Bedienung der Programme vereinfachen sollten: jedes Programm soll zuerst eine Meldung ausgeben, die beschreibt, was es macht, vor jeder Eingabe soll kurz angegeben werden, was eingegeben werden soll.

Textorientierter Benutzerdialog

Bild: Textorientierter Benutzerdialog.

Beispiel für einen rein textorientierten Benutzerdialog. Die Darstellung orientiert sich an Karteikarten. Eingaben können verändert werden, bis mit einer Funktionstaste die gewünschte Aktion aufgerufen wird.

Am oberen Rand werden allgemeine Informationen ausgegeben, darunter befinden sich die Eingabefelder für Daten. Am unteren Rand werden die aufrufbaren Funktionen mit den zugeordneten Funktionstasten angezeigt.

Auf der Basis der Textdarstellung wurden Verbesserungen der Bedienung eingeführt. Der verfügbare Platz auf dem Monitor wird weitgehend ausgenutzt für Anzeigen und Eingabefelder.

Für den Benutzer entfällt die Notwendigkeit, die Bedienung komplett auswendig zu lernen oder zu notieren. Es werden zusammengehörige Informationen auch gemeinsam angezeigt und mit einer kurzen Beschreibung versehen. Die Eingabe orientiert sich an Erfahrungen des Büroalltags: dem Ausfüllen von Formularen bzw. Karteikarten. Die möglichen Aktionen werden zusammen mit der Aufrufmöglichkeit angezeigt.

Die Aufgaben des Entwicklers wurden erweitert. Ein Programm muß nicht mehr nur funktionieren. Die Eingaben müssen geordnet und sinnvoll zu Eingabemasken gruppiert werden. Die erweiteren Eingabe- und Korrekturmöglichkeiten müssen ebenfalls programmiert werden.

Eingabemasken und ähnliche Techniken sind bereits eine deutliche Verbesserung für den Benutzer. Solche Programme werden noch häufig verwendet. Die Textdarstellung setzt den Gestaltungsmöglichkeiten jedoch enge Grenzen.

Graphische Benutzeroberfläche

Bild: Texteditor [qed].

Texteditor mit graphischer Benutzeroberfläche. Alle typischen Bedienungselemente sind vertreten, z.B. Fenster, in denen hier die Texte dargestellt werden, Icons für Drucker, Papierkorb, Mülleimer, geladene Texte usw. Zusätzlich kann der Benutzer jeder Funktionstaste eine Folge von Standardfunktionen zuordnen, entsprechend den eigenen Bedürfnissen.

Der hier dargestellte Textausschnitt ist Teil eines Programms. Programme werden in dieser Darstellung entwickelt, die nicht geeignet erscheint, dem Benutzer die Möglichkeiten und Erfordernisse der Softwareentwicklung zu erläutern.

Graphische Benutzeroberflächen wurden geschaffen, damit der Benutzer weitere Alltagserfahrungen im Umgang mit dem Computer verwenden kann. So wurden Bedienungselemente Gegenständen des Arbeitsalltags nachempfunden.

Dem Benutzer zeigt sich ein völlig verändertes Bild. Es ist außerdem ein zusätzliches Eingabegerät, die Maus (oder etwas gleich leistungsfähiges), notwendig. Die Grundideen solcher Oberflächen wie z.B. point and click (Draufzeigen und Knopfdrücken) müssen dem Benutzer vermittelt werden. Die Bedienung soll alltägliche Handlungen nachahmen. Wenn z.B. ein Icon für einen Text mit der Maus auf den Papierkorb bewegt wird, gilt das als Anweisung zum Löschen des Textes.

Der Entwickler hat weitere Aufgaben zu übernehmen. Die graphischen Bedienungselemente müssen entworfen und in das Programm eingebunden werden, die Eingaben per Maus müssen berücksichtigt werden, .... Alle neuen Möglichkeiten erzeugen einen erhöhten Arbeitsaufwand. Der Entwickler hat also die Verantwortung für die Gestaltung der Benutzeroberfläche, die Auswahl der Bedienungskonzepte und die internen Programmfunktionen.

Die graphischen Möglichkeiten müssen mit Bedacht eingesetzt werden. Die Graphik darf nicht Selbstzweck sein. Auch hier gilt häufig less is more (weniger ist mehr). Wichtig ist eine klare, übersichtliche Gliederung der Oberfläche und eine eindeutige Zuordnung der Bedienungselemente. Zu jedem Rechnersystem mit graphischer Oberfläche gibt es style guides, Ratgeber für die Gestaltung. Es können nicht alle Fälle in diesen Ratgebern behandelt werden, jedoch sollten passende Ratschläge auch angenommen werden.

Entwicklungssystem

Bild: Oberfläche eines Entwicklungssystems [m2d2].

Aufgabe dieses Programms ist es, dem Entwickler eine Übersicht über das aktuelle Projekt zu geben, einen schnellen Zugriff auf die Werkzeuge zu ermöglichen und ihre Anwendung zu vereinfachen.

Am linken Rand stehen die Icons für die Entwicklungswerkzeuge. In der Mitte werden die Teile des aktuellen Projektes angezeigt. Das Programm in Bearbeitung besteht aus mehreren Modulen, jedem ist eine Zeile zugeordnet. Zu einem Modul gehören mehrere Dateien. Jeder Datei ist ein Rechteck in einer Zeile zugeordnet. Ist das Rechteck leer, ist die Datei nicht vorhanden (wird nicht benötigt).

Zwischen den Modulen bestehen Abhängigkeiten. Das Programm kann diese berücksichtigen und bestimmte Werkzeuge entsprechend steuern.

Die Arbeit mit einem Texteditor ist eine wesentliche Erfahrung der Entwickler. Die meiste Zeit wird mit dem Erstellen von Programmtexten verbracht. Der im Texteditor sichtbare Textausschnitt zeigt ein Beispiel in der Programmiersprache Modula-2 [m2].

Auch die Arbeit der Entwickler kann durch entsprechende Programme erleichtert werden. Der Texteditor ist zwar das am häufigsten benötigte Werkzeug, aber nicht das einzige. Ein Programm besteht (ab einer bestimmten Größe) aus mehreren Programmtexten (Modulen). Ein Entwicklungssystem soll dabei helfen, die Übersicht zu behalten.

Subjektive Sichtweise

Für den Benutzer bildet ein Programm eine Einheit mit bestimmten Eigenschaften. Mancher Benutzer sieht nicht nur ein Programm als Einheit, mitunter wird der Computer mit allen Programmen, dem Betriebssystem und der Hardware als Einheit gesehen.

Der Entwickler ist es gewohnt, Programme in Module zu zerlegen bzw. aus Modulen aufzubauen. Die Module wiederum enthalten Prozeduren, die aus Anweisungen bestehen. Aus der eigenen Erfahrung sehen Entwickler Programme (und Computer) grundsätzlich anders als Benutzer.

Bild: Subjektive Sichtweise (aus [booch]).

Wenn Zwei dasselbe betrachten, sehen sie noch lange nicht das gleiche.

Die unterschiedliche Vorerfahrung beeinflußt die Sichtweise von bestehenden Programmen und auch die Vorstellung, wie neue Programme gestaltet werden sollten. Entwickler werden Gestaltungskonzepte bevorzugen, die sie in der Vergangenheit erfolgreich angewendet haben. Als Teil der Alltagserfahrung üben die Entwicklungswerkzeuge ebenfalls einen Einfluß auf die Entwickler aus.

Für die Benutzer erscheinen Konzepte vorteilhaft, die sich in ihrem Arbeitsalltag bewährt haben. Dazu gehört die Arbeit mit und ohne Computer.


Benutzer/Entwickler-Kommunikation

Wenn ein neues Programm erstellt werden soll, werden die Entwickler ganz selbstverständlich ihrer egozentrischen Intuition folgen und an den Interessen der Benutzer (die ihre eigene, ebenfalls egozentrische Intuition haben) vorbei arbeiten. Damit das Ergebnis mehr den Vorstellungen der Benutzer entspricht, muß eine Kommunikation zwischen Benutzern und Entwicklern stattfinden [komm].

Kommunikationsmodell

Die Kommunikation ist Gegenstand von zahlreichen Untersuchungen. Es wurden in der Psychologie verschiedene Modelle entwickelt, die unterschiedliche Aspekte der Kommunikation beschreiben sollen. In der Abbildung soll ein Kommunikationsmodell vorgestellt werden.

Bild: Kommunikationsmodell nach [komm2].

Ein zu übermittelnder Inhalt wird vom jeweiligen Sender mittels eines Codes (hier: Sprache) zum Empfänger übertragen. Die Teilnehmer müssen den Code vollständig beherrschen, damit eine fehlerfreie Kommunikation möglich wird. Der Empfänger muß die empfangene Information dekodieren, um darauf reagieren zu können, sich eine Meinung zu bilden und sein Verhalten entsprechend zu steuern. Das resultiernde Verhalten kann in einer Antwort bestehen, die er (nun als Sender) kodiert und übermittelt.

Störungen können in jeder Phase auftreten. Besonders komplex (und deshalb hier nicht ausführlich zu behandeln) sind Meinungsbildung und Verhaltenssteuerung.



Dieses Modell betont die Übertragung der Information in Anlehnung an nachrichtentechnische Systeme. Modelle, die soziale und kognitive Aspekte der Kommunikation näher beschreiben, sind zu komplex, um in diesem Rahmen behandelt zu werden.

Kommunikationsstörungen

Ergänzt am 21. März 2002, von Hinnerk Rümenapf

Zu den Grundvorraussetzungen einer Kommunikation zählt die Bereitschaft, auf den Partner einzugehen und seinen Äußerungen eine Bedeutung zuzugestehen. Gegen den Willen eines Beteiligten ist keine Kommunikation möglich.

Ursachen für eine Verweigerungshaltung können sein:

Angst vor Veränderung
Es ist am einfachsten eingeschliffene Verhaltens- und Verfahrensweisen beizubehalten. Jede Änderung, egal wie notwendig sie ist, wird als Störung empfunden, weil sie eine Anpassung an neue Gegebenheiten und eine Umstellung der eigenen Gewohnheiten erfordert. Dazu kann auch die Angst kommen, die eigenen Aufgaben unter den veränderten Umständen nicht mehr zu bewältigen.

Schutz der eigenen Position
Oft wird ein Wissensvorsprung genutzt, um einen persönlichen Vorteil (Ansehen, Position in der Firma) zu erlangen oder zu erhalten. Das Extrem sind Personen, die die Dokumentation ihrer Arbeit verweigern, und bei der Ausführung auf alle (eigentlich gebotenen) Hinweise zu Aufbau und Funktion verzichten.

Eine ablehnende Haltung äußert sich oft im Ignorieren des Inhalts von Äußerungen. Mitunter wird auf begründete Argumente nur mit einem "wissenden" Grinsen oder Inhaltsleeren "Killerphrasen" wie "Das geht hier nicht", "Das will man nicht", "Das kannst Du hier nicht machen" geantwortet. Mit solchen Methoden wird eine sachlich/inhaltliche Diskussion abgewürgt.

Die "Härte" solcher Reaktionen hängt auch von den jeweiligen wirtschaftlichen Umständen ab. Je schlechter die wirtschaftliche Lage ist, um so größer ist die Wahrscheinlichkeit derartiger Verhaltensweisen. Wenn Angst um den Arbeitsplatz mit ins Spiel kommt, kann es bis zum Mobbing kommen.

Auch bei bestem Willen der Beteiligten treten Störungen der Kommunikation auf. Mögliche Ursachen dafür sind (ohne Anspruch auf Vollständigkeit):

Fachsprache
Fachbegriffe, die dem Gegenüber evtl. nicht geläufig sind, müssen erläutert werden. Zu Beginn der Gespräche sollte eine Gemeinsame Sprache gefunden werden.

Selbstverständliches
Dem Fachmann sind viele Dinge in Fleisch und Blut übergegangen, so daß sie nicht mehr erwähnt werden.

Interessenkonflikt
Der Benutzer wünscht sich eine möglichst geringe Veränderung der Arbeitsabläufe, dabei trotzdem eine Entlastung im Arbeitsalltag. Dem Entwickler ist an einer schnellen Beendigung der Entwicklungsarbeit bei möglichst geringem Aufwand gelegen.

Schutz des Selbstwertgefühls
Benutzer und Entwickler sind Fachleute auf dem eigenen Gebiet. Jeder muß dem anderen sein Fachwissen zugestehen und ihn nicht als Dummkopf stehen lassen.

Erwartungen
Zu hohe Erwartungen an das Ergebnis und das Gegenüber führen zwangsläufig zu Enttäuschungen. Die Benutzer sind nach Beendigung eines Projektes häufig enttäuscht über ihre doch geringen Einflußmöglichkeiten [komm].

Sympathie/Antipathie
Das gesamte Umfeld beeinflußt die Kommunikation. Es ist ein großer Unterschied, ob der Benutzer zum Entwickler kommt oder umgekehrt. Persönliche Vorlieben und Abneigungen können die Kommunikation gänzlich verhindern.

Methoden der Softwareentwicklung

In diesem Abschnitt werden Vorgehensweisen erläutert, die die Probleme der Erstellung benutzergerechter Software verringern sollen. Eine vollständige Lösung kann kein Verfahren bieten, aber eine Verringerung der Auswirkungen.

Gestaltungsrichtung

Bei der Entwicklung müssen Schwerpunkte gesetzt werden. Ein Programm in allen Punkten optimal zu gestalten, ist ein unrealistischer Anspruch. Die Auswahl beginnt mit der Gestaltungsrichtung.

Die Wahl der Gestaltungsrichtung hat einen großen Einfluß auf das Ergebnis. Zu Beginn des Projektes getroffene Entscheidungen beeinflussen alle folgenden. Einmal getroffene Grundsatzentscheidungen lassen sich später nur schwer revidieren. Getreu dem Motto Das Wichtigste zuerst kann mit der zeitlichen Abfolge der Entwicklungsschritte ein Schwerpunkt gesetzt werden.

Bild: Gestaltungsrichtung.

Schwerpunkt durch die zeitliche Abfolge der Entwicklungsschritte:

(a)
Benutzerfreundlichkeit
(b)
Effizienz, optimale Ausnutzung der Resourcen



Ein Programm muß zum einen mit dem Benutzer in Verbindung treten, zum anderen mit dem Rechnersystem, auf dem es abläuft. Dazwischen stehen die programminternen Funktionen für Ein- und Ausgabe sowie interne Berechnungen.

Die Schnittstellen sind jedoch grundverschieden. Die Systemschnittstelle ist eindeutig definiert und exakt beschrieben (Zumindest sollte es so sein). Für die Benutzerschnittstelle gibt es keine eindeutigen, unumstößlichen Regeln. Die Benutzer und die Aufgaben der Software sind zu verschieden. Hinweise und Anregungen geben die bereits erwähnten style guides und die Literatur zur Software-Ergonomie.

Phasen der Softwareentwicklung

Die Entwicklung von Software durchläuft mehrere Phasen. Im sequentiellen Phasenmodell ist Benutzerbeteiligung nur bei der Analyse und der Spezifikation vorgesehen. Implementation und Test werden von den Entwicklern alleine durchgeführt, getestet wird die Übereinstimmung des Programms mit der Spezifikation.

In der Analyse wird der ist-Zustand betrachtet, der durch neue Software verändert werden soll. Die Ergebnisse werden zur Spezifikation der Anforderungen an das Programm verwendet. Die Implementation ist das Umsetzen dieser Anforderungen in ein Programm. Der Test soll sicherstellen, daß alle gestellten Anforderungen erfüllt werden. Die erfolgreiche Integration des Programms in den Arbeitsablauf beendet das Projekt.

Bild: Phasenmodell.

(a) sequentielles Phasenmodell
Die Phasen werden als eine strenge zeitliche Abfolge betrachtet. Nach Beendigung einer Phase werden die Ergebnisse nicht mehr in Frage gestellt.

(b) Phasenmodell mit Rückkopplung
Zu jeder Phase gehört eine Bewertung der Ergebnisse. Fällt die Bewertung nicht zufriedenstellend aus, wird die Phase wiederholt. Bei Bedarf werden auch auch vorhergehende Phasen (mit Verwendung der bisherigen Ergebnisse) erneut durchlaufen.



Kommunikationsschwierigkeiten und unklare Vorstellungen der Auftraggeber führen zu einer ungenauen Spezifikation. Während der Implementation und des Tests interpretieren die Entwickler die Spezifikation aus ihrer eigenen Sicht. Die Benutzer finden dann bei der Integration des Programms ihre ursprünglichen Vorstellungen und Erwartungen nicht wieder, was zu vielfältigen (und teueren) Nachbesserungswünschen führt.

Im Phasenmodell mit Rückkopplung gehört zu jeder Phase eine Bewertung der bisherigen Ergebnisse. Geschieht die Bewertung mit Beteiligung der Benutzer, können bereits frühzeitig Korrekturen vorgenommen werden. Frühzeitige Korrekturen sind billiger als späte Nachbesserungen [heeg].

Die Phasen Analyse und Spezifikation müssen auch unter Einbeziehung der Rückkopplung sorgfältig ausgeführt werden. Je näher die erste Version am Endprodukt liegt, um so weniger Schleifendurchläufe sind notwendig, und um so günstiger und schneller wird die gesamte Entwicklung.

Prototyping

Prototypen werden in der Industrie schon lange verwendet. Bevor ein Produkt die Marktreife erreicht, werden Prototypen erstellt, um die Funktionsfähigkeit zu testen und einen Eindruck vom Produktaufbau zu erhalten. Am Prototyp erkannte Verbesserungsmöglichkeiten werden in das Endprodukt eingebracht.

Ein Software-Prototyp soll Teile des Verhaltens eines möglichen Endproduktes verdeutlichen, insbesondere die Benutzeroberfläche. Andere Qualitätsmerkmale, die nicht mit dem Prototyp überprüft werden sollen, werden außer acht gelassen (korrekte Funktion, Effizienz, Dokumentation, Fehlersicherheit, ...).

Prototyping unterstüzt die Entwicklung nach dem Phasenmodell mit Rückkopplung. Nicht alle Arten des Prototyping sehen nach jeder Phase eine Bewertung vor:

schnelles Prototyping (rapid prototyping)
Ein Prototyp wird möglichst schnell und billig erstellt, bewertet, verbessert und weggeworfen. Danach wird mit der Entwicklung des eigentlichen Programms begonnen, der Prototyp dient nur als Vorlage.

inkrementelles Prototyping
Zuerst werden einfache Funktionen und der Rahmen der Benutzeroberfläche fertig entwickelt. Die restlichen Funktionen werden nacheinander fertiggestellt und in das Programm integriert. Man könnte auch schrittweise Lieferung dazu sagen.

evolutionäres Prototyping
Im ersten Schritt werden einfache Grundfunktionen und die Grundzüge der Benutzerschnittstelle erstellt. In den folgenden Schritten werden die vorhandenen Funktionen verbessert und neue Funktionen, jeweils in einfacher Form, hinzugefügt.

Allen Arten gemeinsam ist die Idee, durch ein konkretes Anschauungsobjekt (den Prototyp) die Bewertung des Entwicklungsstandes für Benutzer zu vereinfachen, oder sogar erst möglich zu machen.

Das schnelle Prototyping ist eine Verbesserung der Spezifikationsphase. Implementation und Test entsprechen dem sequentiellen Phasenmodell. Im inkrementellen Prototyping wird die Gesamtentwicklung in mehrere aufeinanderfolgende Einzelentwicklungen zerlegt. Bei diesen Einzelentwicklungen wird nach dem sequentiellen Phasenmodell vorgegangen. Im evolutionären Prototyping findet ein ständiger Wechsel der Phasen statt. Auf jede Bewertung folgt eine weitere Spezifikation, eine teilweise Implementation, deren Ergebnis als neuer Prototyp getestet und bewertet wird. Die sequentielle Struktur wird hier weitgehend verlassen.

Die genannten Arten schließen sich nicht gegenseitig aus, es sind verschiedene Kombinationen denkbar.

Ausblick

Technische Entwicklung

Die Verbesserung der Benutzerfreundlichkeit bedeutet einen Mehraufwand für die Entwickler. In den Beispielen hat jede Verbesserung mehr Entwicklungsarbeit gefordert. Prototyping, besonders das evolutionäre Prototyping, erfordert eine enorme Flexibilität der Entwickler. Benutzerbeteiligung verliert den Sinn, wenn die technischen Gegebenheiten fehlen, die Vorstellungen der Benutzer auch umzusetzen.

Die Entwickler müssen an anderer Stelle entlastet werden, um mehr auf die Benutzer eingehen zu können. Durch bessere Entwicklungswerkzeuge kann die Programmierung vereinfacht werden. Bereits bestehende Werkzeuge (vgl. Abb. qed, m2d2, orcs) werden erweitert. Die Programmierung soll sich von dem Arbeiten mit einer Textdarstellung zu einem graphischen Entwurf entwickeln. Mit graphischen Dialogeditoren sollen außer dem Aussehen der Dialoge auch die Beziehungen der Bedienungselemente untereinander und zu Programmfunktionen modelliert werden [smalltalk].

Bild: Dialogeditor [orcs].

Ein Programm zum Erstellen und und Verändern von Dialogboxen. Standardelemente können zu Dialogen kombiniert werden. Das Aussehen des Dialogs kann graphisch gestaltet werden.

Die Standardbedienungselemente zeigen ein Standardverhalten, das mit erhöhtem Programmieraufwand verändert werden kann. Die Beziehungen zwischen den Bedienungselementen können in diesem System nur sehr eingeschränkt beschrieben werden.

Auch die Programmiersprachen werden weiterentwickelt. Konzepte, die seit Jahren wenig Beachtung fanden, werden aufgegriffen und weiterentwickelt. So hat die objekt-orientierte Programmierung einen enormen Aufschwung erlebt.

Dem Entwickler werden mehr und mächtigere Funktionen zur Verfügung gestellt, von vorgefertigten Standard-Dialogen zur Auswahl von Dateien oder Zeichensätzen bis hin zu kompletten Datenbanksystemen.

Alle diese Ansätze sind mit einem enormen Aufwand bei der Erstellung von Entwicklungssystemen verbunden. Spezialisierte Entwickler müssen viel Zeit darauf verwenden, anderen Entwicklern die Arbeit zu vereinfachen. Entsprechend kostspielig werden diese Entwicklungssysteme sein.

Eine weitere Vereinfachung ist durch die Verlagerung der Entwicklungsschwerpunkte zu erreichen. Die Mehrarbeit für die Benutzerschnittstelle wird (wenigstens teilweise) an anderer Stelle eingespart. Meistens geht das zu Lasten der Geschwindigkeit und des Speicherbedarfs im Vertrauen auf neue, leistungsfähigere Rechner.

Methoden

Bisher war nur von Benutzern und Entwicklern die Rede. Weder Benutzer noch Entwickler sind jedoch (im allgemeinen) Spezialisten für Graphik-Design. Gerade graphische Benutzeroberflächen können durch die Mitwirkung von Graphik-Designern stark verbessert werden [design].

Vorstellbar wäre eine Arbeitsgruppe von Benutzern, Entwicklern, Designern und Psychologen, die gemeinsam ein Programm gestalten. Nach Art des schnellen Prototyping könnten mehrere Prototypen entworfen werden (wie es in der Industrie nicht unüblich ist). Nach einer vergleichenden Bewertung der Prototypen würde die Spezifikation für das Programm entworfen. Sie kann Elemente verschiedener Prototypen enthalten. Für die weitere Entwicklung bietet sich das evolutionäre Prototyping an.

Wichtig ist vor allem die Bereitschaft aller Beteiligten zur Kommunikation und Zusammenarbeit.


Literaturverzeichnis

[komm]
Beate Klutmann:
Benutzer-Entwickler-Kommunikation in den frühen Phasen der Softwareentwicklung,
Dissertation, TU Berlin 1989

[komm2]
H. Crott:
Soziale Interaktion und Gruppenprozesse,
Kohlhammer, 1979

[koch]
Manfred Koch, Harald Reiterer, A Min Tjoa:
Software-Ergonomie, Gestaltung von EDV-Systemen -- Kriterien, Methoden und Werkzeuge,
Springer-Verlag, 1991

[design]
Peter Schweizer, Dr. Kai-M. Pinnow:
Menü für Zwei, Dialog zwischen Programmierer und Grafiker,
c't Februar 1995, S. 244 ff.

[6fus]
Hubert L. Dreyfus, Stuart E. Dreyfus:
Künstliche Intelligenz, von den Grenzen der Denkmaschine und dem Wert der Intuition,
Rowohlt, 1987

[heeg]
Franz-Josef Heeg, Rita Neuser:
Nutzergerechte Ausgestaltung von Software durch Prototyping -- Grundlagen, Vorgehensweise, Wirtschaftlichkeitsaspekte,
VDI-Verlag, 1988

[vonk]
Roland Vonk:
Prototyping, the effective use of CASE technology,
Prentice Hall, 1990

[m2]
Niklaus Wirth:
Programming in Modula-2,
Springer-Verlag, 3. Auflage 1985

[smalltalk]
Christian Kratzer:
PARTisanen, Objektorientierte Programmierung mit Visual Smalltalk,
c't März 1995, S. 78 f.

[booch]
Grady Booch:
Object Oriented Design with Applications,
Benjamin/Cummings Publishing Company, 1991

[ince]
Darrel Ince:
Object-Oriented Software Engineering with C++,
McGraw-Hill, 1991

[cbm]
Commodore Büromaschinen GmbH:
Handbuch zum CBM 8032 Bürocomputer, ca. 1982

[qed]
Thomas Quellenberg:
qed, shareware-Texteditor, mit einem Handbuch von Mick Schmidt, 1992

[m2d2]
Thomas Birke:
M2D2, die andere Shell für Modula-2/ST (unveröffentlicht), 1993

[orcs]
Thorsten Otto:
ORCS, shareware-Editor für Teile einer graphischen Benutzeroberfläche (Resource-Construction-Set), 1991


Letzte Änderung 1997/03/25 hr, © Layout Jochen Duckeck, © Inhalt Hinnerk Rümenapf.