|
Schon Alfred Hitchkock ein wahrer Könner des Filmgeschäftes verfolgte die Strategie des
Prototyping, indem er die Reaktionen der Zuhörer, welchen er kurze Geschichten zum Besten
gab, bewertete. Bei etwaigen Parties las er verschiedene Versionen seiner Geschichte vor
und arbeitete die Kommentare des Publikums in seine neueren Versionen ein. Das Endergebnis
testete er in kurzen Filmausschnitten an den Zuschauern. Ein berühmtes Werk, welches mit
dieser Methode entstanden ist, ist der Horrorfilm Psycho.
Die Erfahrungen mit konventionellen Methoden wie dem
>Wasserfallmodell oder dem
>Spiralmodell
waren für die Softwareentwicklung oft nicht ausreichend befriedigend. Die Gründe hierfür sind verschiedenster
Natur. Ein Problem ist beispielsweise, dass bei Modellen dieser Art eine große Menge an
Designentscheidungen getroffen werden muss, unter anderem auch für Benutzerschnittstellen
die aus mehreren tausenden Widgets bestehen, ohne die Möglichkeit, diese den am Projekt
beteiligten Kunden, Entwicklern und Managern visuell darzustellen. Dies erschwert die
Kommunikation innerhalb des Designteams, das optimalerweise aus Experten der verschiedenen
Fachbereiche (Psychologie, Ergonomie, Informatik, Visuelles Design etc.) besteht,
und auch die Kommunikation zwischen den zuvor genannten.
Nachdem Entwickler meist Probleme damit haben sich in die Abläufe
pressen zu lassen, die ihnen der konventionelle Softwarelebenszyklus vorschreibt,
hat sich Prototyping als "bottom up" Methode weit verbreitet.
In speziellen Fällen kann ein Prototyp sogar nur zum Zweck der Spezifikation erstellt werden.
Funktionsfähige Prototypen sind eindeutig am besten dazu geeignet, um über die Benutzerschnittstelle
zu diskutieren. Im Gegensatz zu jeder Sprache die eine Benutzerschnittstelle beschreiben kann, hat
der Prototyp den Vorteil intuitiv zu sein. Es ist nicht notwendig erst mit viel Aufwand die meist
komplizierte Beschreibungssprache zu erlernen. Ein Prototyp ist verständlich und ermöglicht ein
schnelles Erfassen der wichtigsten Konzepte des Projektes durch einfache Erklärung der
Darstellung.
Für die Entwickler hat Prototyping den weiteren Vorteil, daß sie mit Hilfe der Prototypen besser
abschätzen können, welchen Aufwand die Implementation der geforderten Funktionalitäten
notwendig machen wird.
Ein mentales Problem kann für Entwickler entstehen wenn ein Produkt mittels
>revolutionären Prototyping
erstellt wird, da jeder der Beteiligten viel Arbeit in die Erstellung eines Prototypen
investiert, deren Produkt nun womöglich gar nicht in die weitere Entwicklung einfließt. Auf den ersten
Blick erscheint
>evolutionäres Prototyping
daher als vorteilhafter, da der Prototyp und damit Ressourcen nicht vernichtet, sondern wiederverwendet
werden. Das ist ein schwerwiegender Grund weshalb Manager vielfach dazu tendieren, evolutionäres
Prototyping zu bevorzugen. Aber nicht alles, was glänzt, ist in allen Anwendungsfällen ideal.
Neben den bemerkenswerten Vorteilen, die Prototyping aufweist, entstehen aber auch einige Schwierigkeiten
bei der Entwicklung, die allerdings durch Anwendung großer Sorgfalt vermieden werden können.
Zunächst muß sichergestellt sein, daß alle Beteiligten mit der Vorgangsweise des Prototyping
einverstanden sind. Die Möglichkeit, einen Prototyp zu verbessern hängt vom Willen und Können
der künftigen Benutzer ab, entsprechende konstruktive Kritik zu liefern. Systementwickler
nehmen die Entwicklung von Prototypen oft nicht wirklich ernst und neigen zu Ungenauigkeiten
mit dem Argument, daß sie kein "richtiges" Produkt produzieren. Oft sind Entwickler
oder aber auch Kunden zu einer Art "Featuritis" verleitet. Auf Seiten der Entwickler entsteht dies durch
immer neue Ideen die durch das visuelle Feedback des Prototypen angeregt werden. Auf der Seite der Kunden
entsteht dies meist durch wechselnde Bedingungen im Einsatzbereich und durch den Eindruck, dass
Prototypen schon ausgereifte Produkte sind, wobei in Wirklichkeit noch jegliche Funktionalität fehlt.
Manager sehen Prototyping zum Teil als Verschwendung von Ressourcen. Die Motivation aller Beteiligten ist
also eine Grundvoraussetzung für einen erfolgreichen Prototypingprozeß.
Werden die hohen Anforderungen, die Prototyping an alle Beteiligten stellt, erfüllt so steht als Lohn der
Anstrengungen meist ein verkürzter Entwicklungsprozeß
und niedrigere Kosten im Vergleich zu konventionellen Vorgangsweisen, sowie als Ergebnis
qualitativ bessere Benutzerschnittstellen, die die Konkurrenzfähigkeit sichern können, in
Aussicht.
Auch wenn sich durch Prototyping eine Menge Vorteile ergeben, ist es doch wichtig, auf die
Risiken einzugehen, die diese Vorgehensweise beinhaltet. Diese begründen sich meist in der
erhöhten Benutzerinteraktion [Bourne 1997 S.126].
So wäre als erstes zu nennen, daß sich der
Benutzer insbesondere beim evolutionären Prototyping sehr schnell an das Arbeiten mit
Prototypen gewöhnt was zur Folge hat, daß er ungeduldig wird und nicht versteht, warum das
Projekt denn noch so lange bis zu seiner Fertigstellung benötigt. Es ist wichtig dem Benutzer
klar zu machen, welche Kompromisse man beim Entwurf des Prototypen eingegangen ist und daß es
noch viel Zeit in Anspruch nehmen kann, das System auf seine Zuverlässigkeit zu testen, es auf
Performance und Ergonomie hin zu optimieren und alle Funktionalitäten zu implementieren.
Hierbei ist es hilfreich den Anwender beim Vorstellen eines neuen Prototypen jeweils darüber
zu informieren, wieviel Prozent des Systems schon fertig sind, wie lange man noch bis zur
Vollendung benötigt und was bis dahin noch alles zu erledigen ist. Oft werden von Entwicklern
sogar künstlich die Antwortzeiten des Systems verlängert um nicht schon zu Beginn der
Entwickklunsphase im Kunden Erwartungen an das Produkt zu wecken die im Realen Einsatz dann
nicht erfüllt werden könnten.
Insbesondere das evolutionäre Prototyping birgt die Gefahr, daß der Benutzer sich zu sehr auf
die GUI fixiert. Er bekommt nämlich von Beginn an einen funktionierenden GUI-Prototypen
präsentiert, dem es aber an wahrer Funktionalität noch mangelt. Er konzentriert sich somit
auf das, was er visuell wahrnehmen kann [Bourne 1997 S.126].
|
|
D. Tudhope, P. Beynon-Davies, H. Mackay >
"Prototyping Praxis: Constructing Computer Systems and Building Belief"
, Human-Computer Interaction, Volume 15, Number 4, Issue Dec 2000
G. Pomberger, R. Weinreich, "Qualitative und quantitative Aspekte prototyping-orientierter Software-Entwicklung - Ein Erfahrungsbericht",
Informatik Spektrum 20(1): 33-37 (1997)
M. Manhartsberger, >
"Prototyping - Theorie und Praxis"
,Ergonomie und Informatik Nr. 33, S. 19-23, 1998
K. C. Bourne, "Testing Client/Server Systems", McGraw Hill, S. 126, 1997
W. Henhapl, M. Brunner, Seminar: >
"Konstruktive Qualitätssicherung"
Technische Universität Darmstadt, Fachbereich Informatik, Fachgebiet Praktische Informatik
|