Ludwig-Maximilians-Universität München
Vorlesung Mensch-Maschine-Interaktion
Gehalten von Prof. Andreas Butz und Dr. Albrecht Schmidt
Wintersemester 2004/05

Hierarchical Task Analysis

Essay von Sebastian Kraiker

1. Idee und Bezug zur Informatik

Die Idee hinter der Hierarchischen Aufgaben-Analyse (Hierarchical Task Analysis, HTA) nach Lon Barfield (1993) ist es, von Menschen durchgeführte Aufgaben in Unter-Aufgaben zu untergliedern, um auf diese Weise ein abstraktes Modell zu schaffen. Anhand dessen können im Anschluss die Möglichkeiten einer Computer-Unterstützung bei der Durchführung dieser Aufgabe untersucht werden.

Tatsächlich ist es ein fundamentaler Wesenszug der Informatik, Aufgaben zu abstrahieren und so weit in präzise notierte kleine Schritte zu zerlegen, bis sie vom Computer ausgeführt werden können. Nichts anderes ist der Entwurf von Algorithmen. Insofern existiert ein inhärenter fachlicher Zusammenhang zum Thema dieses Essays. Die Hierarchische Aufgaben-Analyse ist jedoch nicht unmittelbar auf den Entwurf von Software konzentriert, sondern lässt sich ganz allgemein auf Aufgaben von Menschen innerhalb der realen Welt anwenden.

Inspiriert von Cooper/Reimann (2003) soll die HTA im Rahmen dieses Essays von der Konzentration auf "Aufgaben" (Tasks) zur Berücksichtigung von "Absichten" (Goals) erweitert werden. Dies ist insofern zulässig, als jede Aufgabe einer Absicht folgt. Die HTA erhält dadurch eine gewisse philosophische Komponente, die in der Informatik bislang kaum vorhanden ist, jedoch bei der Entwicklung komplexer und gleichzeitig benutzerfreundlicher Anwendungssoftware ein bedeutender Vorteil sein könnte.

Tatsächlich gibt es im Bereich der Software-Architektur sogenannte zielgerichtete (also Absichten-betonte) Spezifikationsverfahren wie die "KAOS"-Methode, die diesem Ansatz eine formale hierarchische Struktur geben.

Man sollte sich jedoch bewusst sein, dass sich nicht alle Arten von Aufgaben oder Absichten zur Modellierung durch eine HTA eignen. In grober Anlehnung an Barfield lassen sich zwei Typen von Aufgaben unterscheiden.

2. Arten von Aufgaben

2.1. Kreative Aufgaben

Aufgaben bzw. Absichten, die die menschliche Kreativität erfordern, lassen sich nur bis zu einem gewissen Grad in Unter-Aufgaben untergliedern. Dieser Grad reicht insbesondere nicht aus, um Aufgaben von Computern erledigen zu lassen – zumindest in diesen Tagen. Zu diesem Typ Aufgaben gehört alles, was mit Kunst im weiteren Sinn zu tun hat, mit Entwurf und zu einem Teil auch zwischenmenschlicher Kommunikation.

Ein konkretes Beispiel wäre das Schreiben eines erfolgreichen Romans. Eine mögliche Verfeinerung dieser Aufgabe wären folgende Arbeitsschritte:

- Festlegen der Prämisse (Grundaussage)
- Festlegen der Charaktere
- Skizzieren der Handlung
- Festlegen der Erzählperspektive
- Festlegen der Formulierungen
- Das eigentliche Schreiben

Sehr viel präziser kann die Arbeit nicht beschrieben werden. Könnte sie es, dann könnte auch jeder einen erfolgreichen Roman schreiben. Das kann aber nicht jeder. Insofern würde man auch von der "Kunst", einen erfolgreichen Roman zu schreiben, sprechen.

2.2. Mechanische Aufgaben

Das einzige, wobei einem der Computer in obigem Beispiel helfen kann, ist das eigentliche Niederschreiben. Dies ist nämlich keine kreative Arbeit mehr, sondern eine „mechanische“. Das heißt, es geht nicht mehr um das Schaffen neuer Produkte an sich, sondern darum bestehende Produkte zu verwalten oder darzustellen. Diese Art von Aufgaben lässt sich meist beliebig weit in Unter-Aufgaben zergliedern, und das heißt wiederum, dass sich Algorithmen und damit Programme finden lassen, die dem Benutzer bei der Ausführung Arbeit abnehmen können. In diesem Fall wäre das ein Textverarbeitungsprogramm.

3. Möglichkeiten und Grenzen der Analyse

Die Zerlegung einer Aufgabe in Unter-Aufgaben, und die Zerlegung wiederum der Unter-Aufgaben ergibt die Struktur eines Baumes im Sinne der Graphentheorie.

Da die HTA ihre Grenzen in der Zergliederung kreativer Arbeit findet, müssen wir an diesen Stellen "atomare" Blätter akzeptieren, die keine weiteren Äste besitzen. Dafür lassen sich mechanische Aufgaben teilweise so weit zerlegen, bis sie schließlich mit Programmiersprachen nachgebildet werden können. Dies findet allerdings seine Grenzen in der linearen Ablaufstruktur einer durch die HTA dargestellten Aufgabe. Insofern sind auf der Granularitätsebene der Programmiersprachen andere Modellierungsmethoden wie beispielsweise Aktivitätsdiagramme besser geeignet. Der Zweck einer HTA ist also die Verfeinerung von Absichten zu Abläufen und deren Verfeinerung maximal bis zu ihren kleinsten linearen Teilkomponenten.

Statt eine Aufgabe zu unterteilen, sich also weiter in den Baum hinein zu bewegen, lässt sich eine Aufgabe allerdings ebenso als Teil einer übergeordneten Aufgabe begreifen. Formuliert man diese, so kann man sich immer höher im Baum bewegen.

Anstatt isolierte Lösungen für einmal definierte, vielleicht völlig veraltete Teillösungen zu schaffen, lassen sich auf diese Weise eventuell Zusammenhänge erkennen, die einen in die Lage versetzen, elegantere und den Bedürfnissen des Nutzers angemessenere Lösungen zu entwickeln.

Je höher man jedoch in diesem Baum steigt, d.h. je allgemeinere Absichten man formuliert, desto mehr kommt man das Gebiet der Philosophie. Die letzte auftretende Frage ist nämlich immer die nach dem Sinn der menschlichen Existenz. Hier sollte dem Systementwickler wohl eine Grenze in Form einer klar umrissenen Aufgabenstellung gesetzt werden.

Diese theoretischen Überlegungen sollen nun anhand eines praktischen Beispiels dargestellt werden.

4. Beispiel

4.1. Eine hierarchische Analyse

Nehmen wir einmal folgende Aufgabe bzw. Absicht (und siedeln sie in einer Zeit vor der Verbreitung von Computern an, um im Anschluss Möglichkeiten der Computer-Unterstützung zu betrachten):

1. Ich möchte ein bestimmtes Buch aus der Bibliothek entleihen.

Eine erste Untergliederung könnte folgendermaßen aussehen:

1.1. Ich bestimme den Standort des Buches und begebe mich in die entsprechende Zweigstelle der Bibliothek.
1.2. Ich bestimme den Standort des Buches innerhalb des Gebäudes und hole das Buch
1.3. Ich entleihe es an der vorgesehenen Theke

Untergliedern wir weiter:

1.1.1. Ich schlage die Signatur des Buches im zentralen Karteikasten anhand des Autors nach.
1.1.2. Ich schreibe mir die Signatur des Buches auf.
1.1.3. Ich sehe anhand der ersten vier Ziffern der Signatur auf einem Aushang nach, welche Adresse die Bibliothek hat, in welcher sich das Buch befindet.
1.1.4. Ich sehe auf dem Stadtplan nach, wie ich dort hin komme.
1.1.5. Ich begebe mich dort hin und betrete die Bibliothek.

1.2.1. Ich sehe auf der Übersichtskarte der Bibliothek nach, in welchem Raum sich das Buch laut fachlicher Einordnung befindet.
1.2.2. In diesem Raum gehe ich an so lange an den Regalen vorbei, bis der Buchstabe der restlichen Signatur des Buches mit einem der Buchstaben am Regal überein stimmt.
1.2.3. Innerhalb des gefundenen Regals suche ich die Sektion, die mit genau dem Buchstaben der Signatur gekennzeichnet ist.
1.2.4. Innerhalb dieser Sektion suche ich auf den Buchrücken nach der restlichen Signatur-Nummer.
1.2.5. Ich entnehme das Buch.

Und so weiter. Eine grafische Darstellung des Beispiels findet sich im Anhang.

4.2. Praktische Verwendung der Analyse

Wenn wir nun als Entwickler vor die Aufgabe gestellt werden, einen solchen Prozess durch ein Computersystem zu unterstützen, d.h. für den Kunden einfacher zu gestalten, dann könnten wir an die Aufgabe heran gehen, ohne uns weiter mit dem Modell zu befassen, das die HTA ergeben hat.

Das heißt, wir könnten ein Computersystem entwickeln, das mehr oder weniger eins zu eins die Aufgabe des ehemaligen Karteikastens übernimmt. Innerhalb des beschriebenen Prozesses würden wir also diese Aufgabe:

"1.1.1. Ich schlage die Signatur des Buches im zentralen Karteikasten anhand des Autors nach."

ersetzen durch:

"1.1.1.* Ich schlage die Signatur des Buches im Computer anhand Titel und Autor nach."

Das hätte sicher einige Vorteile, z.B. dass man auch von zu Hause aus nach Büchern recherchieren könnte, und dass man auch anhand anderer Kriterien als dem Namen des Autors suchen könnte. Außerdem könnte es eine Zeitersparnis darstellen.

Doch würden wir die Möglichkeiten nutzen, die uns das Modell bietet, so kämen wir (von den Kosten der Implementierung einmal abgesehen) vielleicht auf eine andere Lösung:

Zweck des Schrittes 1.1.1. ist das Herausfinden der Signatur des Buches. Bewegen wir uns jedoch innerhalb des Baumes aufwärts, so erkennen wir, dass es bei der übergeordneten Absicht 1.1. in keiner Weise um die Signatur geht. Vielmehr ist die Absicht 1.1. das Bestimmen des physikalischen Standortes des Buches. Die Signatur ist lediglich das traditionelle Hilfsmittel. Statt also diese Schritte durchzuführen:

"1.1.1.* Ich schlage die Signatur des Buches im Computer anhand Titel und Autor nach.
1.1.2. Ich schreibe mir die Signatur des Buches auf.
1.1.3. Ich sehe anhand der ersten vier Ziffern der Signatur auf einem Aushang nach, welche Adresse die Bibliothek hat, in welcher sich das Buch befindet.
1.1.4. Ich sehe auf dem Stadtplan nach, wie ich dort hin komme."

-- könnte das System einem gleich eine Wegbeschreibung anhand eines Stadtplans geben. Ebenso könnte es einem den genauen Standort des Buches anhand eines Lageplans der Bibliothek anzeigen. Der Nutzer könnte sich so den Umweg über Signatur, Aushänge, Stadtpläne, Lagepläne und Regal-Abklappern sparen.

Einer solche Lösung stünde von technischer Seite aus nichts im Wege.

Bewegen wir uns noch eine Stufe höher in der Hierarchie, so kommen wir zur Aufgabe

"1. Ich möchte ein bestimmtes Buch aus der Bibliothek entleihen."

Hier eine direkte Umsetzung zu finden, würde bedeuten, ein Computersystem zu entwickeln, das einem das Buch gleich nach der Eingabe ausspuckt. Technisch schon problematischer.

Gehen wir jedoch noch eine Stufe höher, und jetzt müssen wir den Baum nach oben erweitern, so kämen wir wohl auf die übergeordnete Absicht: Das Buch lesen. Zu diesem Zweck könnte das System das Buch auf dem Bildschirm darstellen oder sogar ausdrucken. Dieser Ansatz ist schon realistischer als der vorhergehende und wird teilweise schon verfolgt, v.a. im Bereich Zeitschriften, bei denen die Texte kürzer sind.

4.3. Philosophische Anwendung der Analyse

Würden wir noch höher in der Aufgaben-Hierarchie steigen, so kämen wir zu folgenden Fragen:

Warum möchte ich das Buch lesen? Um eine interessante Arbeit zu schreiben.
Warum möchte ich diese Arbeit schreiben? Um einen Schein an der Uni zu erhalten.
Warum möchte ich diesen Schein machen? Um das Studium erfolgreich abzuschließen.
Warum möchte ich das Studium erfolgreich abschließen? Um einen spannenden Beruf auszuüben.
Warum möchte ich einen spannenden Beruf ausüben? Um ein glückliches Leben zu führen.
Warum möchte ich ein glückliches Leben führen?

Da es an dieser Stelle keine Antwort mehr geben kann, folgt ein pragmatisches

5. Fazit

Der Entwurf einer nutzergerechten Lösung setzt das tiefere Verständnis der Aufgaben und Absichten des Nutzers voraus. Die HTA kann einen Überblick über die Struktur dieser Aufgaben und Absichten geben und somit zu innovativen und anwendungsfreundlichen Lösungen beitragen.

Literatur

Lon Barfield (1993): The User Interface – Concepts & Design. Addison-Wesley, Great Britain.

Alan Cooper, Robert M. Raimann (2003): About Face 2.0 - The Essentials of Interaction Design. John Wiley & Sons Inc.
URL: http://media.wiley.com/product_data/excerpt/13/07645264/0764526413.pdf

Martin Wirsing, Harald Störrle, Nora Koch (2004): Folien zur Vorlesung „Methoden des Software-Engineering“, Einheit A.3. München.
URL: http://www.pst.ifi.lmu.de/lehre/WS0405/mse/folien/A3-REZielorientiert2p.pdf

Anhang

Bibliotheks-Beispiel