previous next Up Title Contents Index

3.3 Vorgehensweise


Hier soll ganz allgemein auf die Vorgehensweise bei der Entwicklung einer Hypertextanwendung eingegangen werden, bevor in den folgenden Kapiteln die einzelnen Schritte detaillierter erläutert werden. Dabei wird zunächst die relevante Literatur analysiert und anschließend die Umsetzung in dem konkreten Projekt beschrieben.
In Bezug auf die Vorgehensweise erkennt man in der neueren Literatur einen Trend zu "strukturiertem Hypertextentwurf" (Hofmann 1995, S. 95). Dies bedeutet, daß ähnlich wie im Software-Engineering nach einem festen Schema verfahren wird und daß Zwischenergebnisse in einer formalen Notation festgehalten werden (Nanard 1995, S. 50). Das Ziel ist dabei, die Effizienz zu steigern (Isakowitz 1995, S. 43) und aus der Kunst der Hypertextentwicklung ein solides Handwerk zu machen (Hofmann 1995, S. 98). Beispiele für strukturierte Design-Methoden sind HDM (Hypermedia Design Model) (Garzotto 1991), OOHDM (Object-Oriented Hypermedia Design Model) (Schwabe 1995) und RMM (Relationship Management Methodology) (Isakowitz 1995).

Die folgende Abbildung soll zeigen, was man sich unter einer "formalen Notation" vorzustellen hat.


RMM

Abbildung 3.1.2-1: RMM (Isakowitz 1995, S. 37)[12]



Minicone Die Einführung einer formalen Notation hätte sich allerdings für das QM-Handbuch nicht gelohnt. Die Struktur des QM-Handbuchs ist sehr einheitlich und kann ohne Probleme im Gedächtnis behalten werden. Es war nicht notwendig, diese mit Hilfe einer komplizierten Notation auf Papier festzuhalten, zumal ich eine solche Notation erst hätte lernen müssen. Der Aufwand hierfür wäre im Vergleich zum Nutzen viel zu groß gewesen.

Die oben erwähnte Literatur konnte jedoch herangezogen werden, um die Klärung der Frage zu erleichtern, welche Schritte in welcher Reihenfolge durchgeführt werden sollten. Dabei fiel auf, daß sich aus allen mir bekannten Ansätzen sehr ähnliche Antworten ergaben:


Die folgende Tabelle soll zeigen, daß diese Phasen im wesentlichen in allen Ansätzen, die mir vorlagen, unterschieden werden, daß es allerdings erhebliche Unterschiede in der Terminologie gibt. Es war für die praktische Arbeit nicht notwendig, diese Unterschiede herauszuarbeiten und genau zu analysieren. Es kam vielmehr darauf an, sich die einzelnen Phasen bewußt zu machen, damit kein wichtiger Entwicklungsschritt übersprungen wird. Dies gilt insbesondere für die Analyse- und die Testphase, die in der Hektik der Praxis leicht vernachlässigt werden könnten, die jedoch auf längere Sicht sehr wichtig sind.

 
Isakowitz (1995, S. 38) - RRM Schwabe (1995, S. 45) - OOHDM Nanard (1995, S. 51) Hofmann (1995, S. 102-105) McKnight (1991, S. 123-133)
Analysephase
  • feasibility
  • Information/ Navigation requirements analysis
  • Hardware selection
Domain Analysis concepts elicitation
  • Umwelt
  • Informationskorpus
System specification: understanding the users, tasks and information space
Struktur
  • E-R[13]Design
  • Entity Design
  • Navigation Design
Navigational Design Navigation Model Repräsentation The structure of the database
Benutzerschnittstelle
  • Conversion protocol design[14]
  • User-interface screen design
  • Run-time behavior design
Abstract Interface Design Abstract interface Präsentation The database front-end
Implementation Construction Implementation Implementation model    
Testphase Testing and evaluation   Testing   Testing the design

Tabelle 3.1.2-1: Design-Methoden



Diese Schrittfolge kann nur als Anhaltspunkt dienen. Hypertextentwicklung ist kein linearer Vorgang, sondern ein komplexer Prozeß, bei dem ein ganzes Netzwerk von Abhängigkeiten berücksichtigt werden muß (Hofmann 1995, S. 81, 101-105). Beispielsweise sollte bereits bei der Entwicklung der Navigationsstruktur deren Umsetzbarkeit auf der Ebene der Benutzerschnittstelle im Auge behalten werden.
Außerdem wird in der Literatur immer wieder empfohlen, nicht erst nach Abschluß der Implementierung, sondern möglichst frühzeitig Tests durchzuführen (z. B. Nielsen 1990, S. 161, Grice 1989, S. 28):

"Users are a vital source of ideas and feedback; use them throughout the development process to test your designs. Realize that you are not a good judge of your own design because you know too much. [...] Create demonstrations and prototypes early in the project; don't wait for the full technology to be ready." (Schneiderman 1989, S. 125).



Je früher vorhandene Fehler korrigiert werden, desto geringer ist der dazu notwendige Aufwand. Das geänderte Design sollte erneut getestet und ggf. weiter verbessert werden. Eine Vorgehensweise, die auf solchen Rückkopplungsschleifen ("experimental feedback loops", Nanard 1995, S. 51) beruht, bezeichnet man als "iterativen Entwurfs- und Entwicklungsprozeß" (Ansel Suter 1995, S. 69) bzw. "iterative user-centered design" (McKnight 1991, S. 60).
Es gibt jetzt sogar eine Norm, in der eine solche Vorgehensweise beschrieben wird: DIN EN ISO 13407 `Benutzer-orientierte Gestaltung interaktiver Systeme':

ISO 13407 beschreibt einen benutzer- und aufgabenzentrierten Entwicklungszyklus: Als erstes müssen die Anforderungen der Benutzer, ihre Aufgaben und die vorgesehene Einsatzumgebung genau erforscht werden. Aus dieser Analyse lassen sich dann die Benutzungsanweisungen ableiten und aus den Ergebnissen in einem dritten Schritt erste Produktentwürfe (Prototypen) entwickeln. Diese Produktentwürfe sind auf Übereinstimmung mit den spezifizierten Benutzungsanforderungen zu prüfen - dabei müssen auch wieder Endbenutzer einbezogen werden. Nach der Feststellung von Mängeln beginnt der Zyklus erneut, bis alle Benutzungsanforderungen erfüllt sind (Geis 1998, S. 168).


 iterative user-centered design
Abbildung 3.1.2-2: iterative user-centered design (Geis 1998, S. 169)





Minicone Bei der Entwicklung des Informationssystems für das QM-Handbuch wurde versucht, den Empfehlungen der Literatur möglichst weitgehend zu folgen: Nach der Analysephase (siehe Kapitel 3.4) und der Entwicklung von Struktur und Layout (siehe Kapitel 3.5) wurde ein erster Test im kleinen Kreis durchgeführt. Hierzu wurden die wichtigsten Navigationsseiten und eines der Dokumente fertiggestellt. Insbesondere sollten die Verständlichkeit der Icons und die Durchschaubarkeit der Struktur geprüft werden. Es ergaben sich einige kleinere Änderungen. Nun wurde eine der Rubriken des QM-Handbuchs vollständig konvertiert. Per E-Mail wurden alle Mitarbeiter gebeten, das Zwischenergebnis zu prüfen und zu kommentieren. Dabei stellte sich heraus, daß die Hintergrundgraphiken neu gestaltet werden mußten, da sie für Bildschirme mit nur 256 Farben nicht geeignet waren. Nach dieser Änderung konnte die Konvertierung des QM-Handbuchs abgeschlossen werden.[15]



Ein weiterer Punkt, der in der Literatur häufig angesprochen wird, ist die Zusammensetzung des Entwicklungsteams. Teamarbeit ist für die Hypertextentwicklung sehr vorteilhaft, da viele verschiedene Fähigkeiten zum Einsatz kommen müssen (Shneiderman 1989, S. 125, Ansel Suter 1995, S. 68, Streitz 1995, S. 70).

Minicone Beteiligt an der Entwicklung der Hypertextanwendung waren Mitarbeiter der Bereiche Qualitätsmanagement, Information und Kommunikation, Desktop Publishing, Multimedia und Systementwicklung. Allerdings verwendete niemand die volle Arbeitszeit für dieses Projekt.

[12] Knoten werden durch die größeren Rechtecke und Verweise durch die Pfeile symbolisiert. Das Dreieck deutet an, daß die Knoten „Faculty", „Courses" und „Programs" zu einer Gruppe zusammengefaßt sind und daß auf diese drei Knoten von der Homepage aus direkt zugegriffen werden kann. Den anderen dargestellten Verweisen ist jeweils ein Index und eine Bedingung zugeordnet. Zum Beispiel erkennt man auf der linken Seite zwischen den Knoten „Faculty" und „Publications" den Index „Publication Index" und die Bedingung „Publish(F,Pub)". Dies bedeutet: Befindet sich der Benutzer auf dem Knoten „Faculty" und wählt den Verweis zum Knoten „Publications", so wird ausgehend von der Liste aller Publikationen (Publication Index) eine Liste derjenigen Publikationen generiert, die von den aufgeführten Fakultäten stammen (Publish(F,Pub)); denn nur diese Publikationen sind im Zusammenhang mit dem Ausgangsknoten relevant.
[13] "Entity-relationship diagrams [...] are a diagramming approach for creating data models. A basic entity-relationship diagram links together icons represent[ing] fundamental entities (rectangles) through icons (diamonds) representing relationships among the entities. Attributes associated with entities and relationships are represented as ovals." (Jones URL 1)
[14] hier werden Regeln aufgestellt, die jedem Element der formalen Notation ein konkretes, implementierbares Element zuordnen (z. B. ein HTML-Formular)
[15] Die eigentliche Konvertierung der Word-Dateien ins HTML-Format wurde mit Hilfe eines Konvertierprogramms automatisch durchgeführt. Allerdings war eine sehr intensive Nachbearbeitung erforderlich, da zahlreiche Layout-Elemente bei der Konvertierung verloren gingen. Außerdem mußten Graphiken, Verweise und Navigationsleisten von Hand eingefügt werden.

previous next Up Title Contents Index