Prototyping


Zusammenfassung
Definition - Was versteht man unter einem Modell und einem Prototypen?
Modelle
Prototypen zur Demonstration der Benutzeroberfläche
Funktionale Prototypen - Erprobung von Algorithmen
Technologische Prototypen - Erprobung von Technologien
Der richtige Zeitpunkt - Wann baut man einen Prototypen?

vgl. hierzu auch Anforderungsanalyse



Zusammenfassung

Auf dieser Seite wird das Spektrum von Modellen und Prototypen dargestellt, die im Laufe eines IT-Projekts benutzt werden können. Der Schwerpunkt liegt dabei sowohl bei Modellen, als auch bei den Ausführungen zu Prototypen bei Ansätzen, um die Benutzeroberfläche darzustellen, damit dem Anwender eine Vorstellung vom Aussehen der geplanten Anwendung vermittelt wird. Funktionale und technologische Prototypen, Pilotsysteme (die hier im Rahmen funktionsreduzierter Prototypen nebenbei behandelt und nicht als Pilotsysteme explizit bezeichnet werden) und Hinweise, wann Prototypen gebaut werden sollen, werden am Rande behandelt.

Definition - Was versteht man unter einem Modell und einem Prototypen?

Ein Modell stellt die Benutzeroberfläche einer Anwendung dar, ohne dass dabei irgendeine Funktionalität vorgesehen ist. Die verwendeten Mittel müssen nichts mit Software zu tun haben.

Ein Prototyp stellt die Benutzeroberfläche und die Abfolge der Dialoge, evtl. auch die Basisfunktionalitäten einer geplanten Anwendung mehr oder weniger genau dar und hat bzw. simuliert einige grundlegende Funktionalitäten.

Zweck eines Prototypen ist es, das Prinzip einer noch zu entwickelnden Software auf für den Fachanwender greifbare Weise zu demonstrieren. Zweck eines Prototypen ist es nicht, zu einem fertigen Produkt weiter entwickelt zu werden.

Unter einem Prototypen sollte man sich nicht zwangsläufig ein Programm mit Funktionalität vorstellen. Das Spektrum reicht von einfachen Bildschirmentwürfen, z.B. mit einem Textverarbeitungssystem oder einer Präsentationssoftware, über funktionslose Benutzeroberflächen, die die Abfolge der wesentlichen Bildschirmformulare klickbar darstellen, bis hin zu funktionsreduzierten Versionen der finalen Software.

In seiner üblichen Definition stellt ein Prototyp ein Ergebnis aus den Anforderungen dar, nicht die Anforderungen selbst. Der Prototyp ist daher nicht als kontinuierlicher Begleiter eines Anforderungsdefinitionsprozesses misszuverstehen, sondern als dessen relativer oder absoluter Abschluss. Ebenfalls sollte man nichtlineare Prozessmodelle zur Erstellung von IT-Systemen, bei denen eine Anwendung schrittweise wächst und implementiert wird, nicht mit dem Bau eines Prototypen verwechseln.

Modelle

Bleistift und Papier

In der Interaktion zwischen Analytiker bzw. Screen-Designer und Fachanwender wird eher spontan zu Bleistift und Papier gegriffen, um einen Ablauf und auch eine Benutzeroberfläche darzustellen. Von einem Modell oder gar Prototypen zu sprechen ist dabei etwas optimistisch, aber der gezeichnete Entwurf ist eine Vorstufe bzw. ein erster Schritt im Prototyping. Man sollte auch als schlechter Zeichner dem Grundsatz folgen, dass ein Bild mehr sagt als tausend Worte.

Textverarbeitungssystem - Vermittlung der Oberflächeninhalte

Ein Textverarbeitungssystem ist nicht geeignet, um detaillierte graphische Entwürfe zu bauen. Aber dies ist auch nicht notwendig. Man kann einige graphische Elemente als echte Graphiken in das Dokument einbinden, um einen für den Anwender leichter verständlichen Entwurf zu bauen. Ein Element für eine Checkbox und eines für einen Radiobutton wird es meist schon tun. Editfelder braucht man nicht, ein "__________" ist gut genug; dasselbe Element kann evtl. für Comboboxen benutzt werden.

Als Analytiker stellt man nur Funktionalitäten dar, die Optik ist dem Screen-Designer überlassen. Man sollte also als Analytiker nicht zu viel Ehrgeiz in optisch schöne Entwürfe stecken, auch, da ein Textverarbeitungssystem hierfür nicht geeignet ist.

Zu jedem Bildschirm sollte eine kurze Erklärung nieder geschrieben werden und auch, welche Datenkonstellationen nach dem Verlassen des Bildschirmformulars zu welchen Folgeformularen führen. Halbe Entwürfe machen keinen Sinn, es lohnt sich nicht, Eingabeformulare zu zeichnen, wenn das Folgeformular vollkommen unklar ist. Daher sollten jeweils abgeschlossene Prozesse bzw. Prozessfolgen dargestellt werden.

Präsentationssoftware oder Zeichenprogramme - Entwurf der Oberfläche

Als Analytiker wird man sich hierbei darauf beschränken, von schon vorhandener Software Screenshots einzubinden und evtl. leicht zu modifizieren (z.B. im Rahmen einer Gap Analysis, bei der Screenshots der vorhandenen Software verwendet werden können). Genauso können vorhandene graphische Bildschirmentwürfe verwendet werden. Ein Screen-Designer kann mit seinen Werkzeugen wirklichkeitsnahe Entwürfe liefern.

Diese graphischen Entwürfe müssen auf jeden Fall versioniert werden.

Beispiel aus der Praxis

Eine Webagentur lieferte zunächst graphische Entwürfe für eine Anwendung. Insgesamt waren es an die hundert Screens, die zudem nur den Geradeausflug darstellten. Es gab mehrere Durchsichten der Entwürfe, wobei grundsätzlich alle Entwürfe auf einmal geschickt wurden. Da die Webagentur trotz mehrmaliger Reklamation keine Versionierung vornahm, musste ein Mitarbeiter des IT-Teams die neue Lieferung mit der letzten alten manuell abgleichen. Dasselbe galt später auch für HTML-Templates. Dem Kunden entstanden dadurch einige Personentage Mehraufwand.

Echte graphische Entwürfe sind mit ernsthafter Arbeit verbunden. Graphische Entwürfe sind erst dann vertretbar, wenn die Inhalte der Benutzeroberfläche fixiert werden können. Als Faustregel kann man sagen, dass abgenommene Prozesse immer, und mehrfach erfolgreich durch Reviews gegangene bzw. reklamationslos durchgesehene Prozesse i.d.R. graphisch entworfen werden können. Prozesse, bei denen der Willensfindungsprozess des Fachanwenders jedoch offensichtlich noch im Gange ist, sollten auf diese Weise nicht angegangen werden, es sei denn, als Auftraggeber haben Sie zu viel Geld.

Prototypen und Prototyping zur Demonstration der Benutzeroberfläche

Oberflächenmodellierwerkzeuge der Entwicklungsumgebung - Entwurf von Oberfläche und Prozessabfolge

Prototyping bedeutet, dass zumindest die prinzipiellen Abfolgen von Dialogen auf eine Art dargestellt werden, die ein "Look and Feel" des fertigen Systems vermittelt. Dazu müssen fertiges Screens montiert und miteinander verbunden werden. Funktionalität, die echte Manipulation von Daten, ist jedoch nicht erforderlich.

Professionelle Entwicklungswerkzeuge erlauben den Entwurf von Benutzeroberflächen und auch die Verknüpfung von Dialogabfolgen. Dabei werden die Screens nach den Vorgaben des Screen-Designers lediglich zusammen geklickt, jedoch auch schon mit RessourceIDs bzw. vergleichbaren Identifikations-Tags verbunden und Folgeformulare an Pushbuttons gebunden. Der zugehörige Code wird automatisch generiert, sodass der Entwickler ein Codegerüst bzw. ein Codegerippe erhält, in das er später die eigentliche Funktionalität hinein programmieren kann. Für die Gestaltung von Weboberflächen gilt dieses Vorgehen sinngemäß, entscheidender Unterschied ist aber, dass es kein Codegerippe dazu gibt.

Man vollzieht hier den Schritt weg vom rein optischen Entwurf hin zu rudimentärer Software, in der man bereits echt herum klicken und navigieren kann. Funktionalität, z.B. das Speichern von Daten, ist dabei natürlich nicht gegeben. Spätestens bei Betrachtung eines solchen Prototypen sollten dem Anwender die letzten Lücken im konzipierten IT-System auffallen.

Normalerweise reicht es aus, einen solchen relativ unaufwendigen Prototypen zu bauen, ehe mit der Entwicklungsarbeit begonnen wird.

Demonstration der Basisfunktionalität

Einen Schritt weiter im Prototyping als die reine Modellierung eines funktionslosen Prototyps zur Demonstration der Benutzeroberfläche ist der Bau eines funktionsreduzierten Prototyps. Dabei wird der Entwurf der Oberfläche, die Prozessabfolge der wichtigsten im System abgebildeten Prozesse und eine stark reduzierte Baisfunktionalität demonstriert. Normalerweise benutzt man bereits die Entwicklungsumgebung, mit der auch das Endprodukt gebaut werden soll.

Projektabhängig können drei Ziele angestrebt werden:
  1. Man demonstriert das Funktionieren einer Idee in der Praxis um eine Entscheidungsgrundlage für eine grössere Investition zu gewinnen. Dabei wird ein Teil der in der Vollversion vorgesehenen Funktionalität vollständig abgebildet. Beispiel kann ein Datawarehouse sein, das sich zunächst auf eine oder zwei Abteilungen eines Unternehmens beschränkt. Man spricht dabei häufig von einem Pilotsystem.
  2. Man demonstriert die prinzipiellen Abläufe und simuliert einige Funktionalitäten eines Systems, das noch gebaut werden muss. Dabei wird die Funktionalität stark funktionsreduziert und implementiert. Solche Prototypen werden gerne vom Marketing gefordert, um damit bei potentiellen Kunden vorstellig zu werden.
  3. Man will vor Implementierung der Vollversion einer Software prüfen, ob sie auch verstanden wird und benutzt werden kann. Typischer Anwendungsfall ist ein Test einer anonymen Software (also eines Produkts für den Massenmarkt, dessen Endanwender nicht befragt werden können) mit einer möglichst repräsentativ ausgewählten Gruppe von Testern.
Die erste Variante ist genau genommen schon eine erste Version einer Software, die im Rahmen eines iterativen Prozess-Modells gebaut wird. Dagegen ist die zweite Variante ein echter Prototyp, der weggeworfen wird, wenn sein Zweck erfüllt ist. Die dritte Variante ist am ehesten mit einem usability-Test zu vergleichen, und man sollte sich vor Festlegung des Liefertermins überlegen was man tun will, wenn die Reklamationen der Tester umfangreiche Konzeptänderungen zur Folge haben.

Beispiel aus der Praxis

Für eine Internetanwendung mit einer erwarteten mindestens fünfstelligen Anwenderzahl wurde im Projektplan die Entwicklung, der Test und die Testauswertung eines Prototypen vorgesehen, nicht jedoch Zeiten für die Nachbesserung. Das Projekt war bei Beginn der Entwicklung des Prototyps bereits hinter dem Zeitplan. Beim Test stellte sich heraus, dass die Gestaltung der Oberfläche in einigen Punkten überarbeitet werden musste, da etwa die Hälfte der Testgruppe damit nicht zurecht kam. Das Projekt verzögerte sich weiter.

Man sollte sich als Auftraggeber nicht dem Irrglauben hingeben, dass das Entwicklerteam von einem Prototypen der Variante 2 oder 3 aus einfach weiter entwickeln kann. Ein solcher Prototyp ist stets oberflächenbezogen, jede Funktionalität ist hart einkodiert und als Fundament für eine weitere Entwicklung unbrauchbar. Der Grund dafür ist, dass es bei der Erstellung eines Prototypen um Geschwindigkeit und nicht um Qualität geht. Er muss schnell fertig sein und soll möglichst wenig kosten, schließlich soll nur ein Prinzip demonstriert und keine erste Produktversion gebaut werden. Das Entwicklerteam weiß zudem nicht, ob der Prototyp vom Kunden akzeptiert wird und wie oft er noch geändert werden soll, deshalb wird so wenig wie möglich Aufwand investiert.

Beispiel für einen Prototypen

Ein Beispiel für einen Prototypen eines Projekts, in dem ich mitgearbeitet habe, finden Sie im Portfolio auf der Website des Entwicklers Peter Lorenz; es handelt sich um die "online financial simulation". Lassen Sie sich nicht täuschen, es handelt sich dabei wirklich nur um einen Prototypen.

Funktionale Prototypen - Erprobung von Algorithmen

Gelegentlich ist es notwendig, das Funktionieren eines Algorithmus für ein im Sinne der Komplexitätstheorie wirklich komplexes Problem nachzuweisen oder diesen Algorithmus experimentell erst zu entwickeln. Die zu bearbeitenden Probleme sind i.d.R. np oder np-vollständig. Man bewegt sich dabei in vermintem algorithmischen Gelände, dessen betreten Profis vorenthalten ist. Anders gesagt: Sollten Sie kein IT-Experte sein und von einem solchen gesagt bekommen, dass zur Implementierung eines von Ihnen gewünschten Features ein np-Problem zu bearbeiten ist, dann halten Sie sich mit Ratschlägen zurück und machen Sie sich nicht dadurch lächerlich, dass sie von einfachen Lösungen sprechen oder Termine vorgeben.

Bei diesem funktionalen Prototyp spielt die Benutzeroberfläche keine Rolle, man betreibt eher Grundlagenforschung auf dem Gebiet der Algorithmentheorie und das Ziel ist der Aufbau von Know How. Da zunächst nur ein Algorithmus ge- bzw. erfunden werden muss, die Optimierung des Algorithmus und seine Einbettung in das Produktionsumfeld aber erst später stattfindet, kann eine andere Software zur Erprobung verwendet werden. Es gibt nicht einmal eine Bindung an die Programmiersprache.

Wenn sich ein Business Analyst mehr als nur oberflächlich mit solchen Algorithmen befassen will, muss er solide Programmierkenntnisse haben und den Algorithmus auch selbst implementieren. Auch, wenn er sich als Pair Programmer engagiert, kommt der Analytiker nicht um profunde Kenntnisse der Programmierung herum, da die Forschungsarbeit größtenteils im Code stattfindet.

Beispiele aus der Praxis

Ich sollte einmal einen automatischen Entflechter für einen allgemeinen Graphen zur Darstellung eines Datenmodells entwickeln, der ein übersichtliches Bild erarbeitet. Wie bringt man nun einem Programm übersichtlich bei? Weiterhin gab es strikte Restriktionen zur Laufzeit des Algorithmus, was bereits bei p-Problemen bei wachsenden Datenmengen kritisch sein kann. Zunächst wurde im Laufe von einigen Tagen ein Prototyp entwickelt, der lediglich in einem groben Raster und mit einer definierten Anzahl Objekte und Beziehungen das Funktionieren des Verfahrens bei akzeptabler Laufzeit nachwies. Dabei wurden zwei der finalen drei Optimierungsmethoden erfolgreich erprobt und die gröbsten Fehler, die auftreten konnten, wurden ebenfalls schon im Prototypen gemacht und konnten bei der Entwicklung der Anwendung bereits beim Design vermieden werden.

Nach Fertigstellung einer Spezifikation, die einige finanzmathematische Abläufe in Kombination mit Nullstellensuchen enthielt, setzte der Analytiker einige der Algorithmen prototypisch in C++ um. Auf diese Weise wurde dem Entwickler, der diesen und ein weiteres Dutzend ähnlicher Algorithmen in Java implementieren sollte, ein gutes Stück Arbeit abgenommen, was sich positiv auf die Entwicklungszeit und die Produktqualität auswirkte.

Im Rahmen der Analyse eines Data Dictionaries erzielten die eingesetzten Algorithmen Laufzeiten von über 24 Stunden auf einem Großrechner. Man konsultierte einen Experten, der zunächst eine etwa 30-seitige Abhandlung zum Thema erarbeitete. Der Gruppenleiter und die drei Programmierer der Projektgruppe kapitulierten etwa auf Seite fünf mangels nötiger Kenntnisse in Graphentheorie. Der Ansatz wurde zunächst prototypisch erprobt und dann technisch umgesetzt. Die Laufzeiten sanken unter 30 Minuten. Die Mitarbeiter der Fachabteilung bekamen von all dem nichts mit.

Technologische Prototypen - Erprobung von Technologien

Sofern man mit einer Technologie das erste Mal zu tun hat, sollte man zunächst ausprobieren, ob die Versprechungen des Herstellers auch gehalten werden und ob das eigene Know How ausreicht, diese Technologien handzuhaben. Typische Probleme stellen die Verwendung von neuen Bibliotheken, Entwicklungskonzepten oder die Schnittstelle zwischen zwei Systemumgebungen dar, z.B. zwischen einer Programmiersprache und einer Datenbank. Ebenfalls können Skalierbarkeit und Durchsatz eines Systems ausprobiert werden. Bei diesen Prototypen geht es nur um den Nachweis, dass der gewählte technologische Weg nicht über dünnes Eis führt, sondern für die aktuelle Aufgabenstellung tragfähig ist und effizient beschritten werden kann. Man sollte stets den komplexesten aller Fälle erproben, am Besten auf eine Art und Weise, dass er im nachfolgenden Projekt auch wiederverwendet werden kann.
Beispiel aus der Praxis

Bei meinem ersten Projekt als Selbstständiger, in dem ich damals als noch als Entwickler tätig war, sollte eine Clipper-Datenbank von einem C++-Programm aus bedient werden. Die gekaufte Klassenbibliothek wurde vom mir zunächst auf das reibungsfreie Funktionieren hin erprobt, ehe ich eine Termin- und Lieferzusage machte.

Der richtige Zeitpunkt - Wann baut man einen Prototypen?

Es gibt zwei grundlegend unterschiedliche Philosophien, wann ein Prototyp gebaut werden soll:
  1. Der Prototyp wird einmalig dann gebaut, wenn der Spezifikationsprozess vollständig oder doch so gut wie abgeschlossen ist und alle Prozesse und Daten bekannt sind.
  2. Man beginnt möglichst früh damit, Oberflächen zu modellieren und darzustellen und passt diese Oberflächen fortwährend an die sich im Fluss befindlichen Anforderungen an.
Oberflächlich beurteilt ist Variante 2 die teurere, da neben der Spezifikationsarbeit zusätzlich ein zur Spezifikation redundanter Prototyp laufend angepasst werden muss. Meine Erfahrung zeigt, dass es nicht funktioniert, die Spezifikation kontinuierlich fortzuschreiben, den Prototypen aber nur gelegentlich anzupassen, da die Fachanwender immer wieder den Prototypen gegen die Spezifikation vergleichen und Abweichungen trotz entsprechender Vereinbarungen reklamieren oder sich doch zumindest wünschen, dass der neue oder geänderte spezifizierte Prozess visualisiert wird. Die Erwartungshaltung, dass Prototyp und Anforderungsdokument Hand in Hand fortgeschrieben werden, kann somit für den Auftraggeber teuer werden. Ein Trick, dem entgegen zu wirken, besteht darin, dass der Prototyp nicht übergeben wird, sondern dass der Kunde den Prototypen lediglich beim Auftragnehmer einsehen kann.

In der üblichen Definition stellt ein Prototyp die Ergebnisse der Anforderungen dar, nicht die Anforderungen selbst. Aus diesem Blickwinkel betrachtet ist die zweite Variante ein ungewöhnlicher Ansatz, der eher als Kompromiss zu einem evolutionären Prozessmodell gesehen werden kann. Als Auftraggeber sollten Sie sehr gute Gründe anführen können, weshalb Sie sich weder für ein evolutionäres Prozessmodell, noch für einen einmaligen Prototypen nach Spezifikationsende entscheiden wollen. Ebenso sollten Sie sich über die zusätzlichen Kosten im Klaren sein. Folgende Gründe können für die Entscheidung für Variante 2 sprechen:
Sind diese Bedingungen gegeben und sogar sehr gewichtig, so kann die Variante 2 evtl. billiger als die Variante 1 sein. Man sollte sich allerdings bei einer Entscheidung für Variante 2 keinen Illusionen hingeben: Wenn Kompetenz, Interesse oder Zeit der Fachanwender nicht ausreicht, um auch ein umfangreiches Anforderungsdokument zu studieren und zu verstehen, dann stellt dies in jedem Fall ein Projektrisiko und einen vom IT-Team nicht beeinflussbaren Kostentreiber dar. Fortlaufendes Prototyping kann dieses Risiko bestenfalls abgemildern, nicht jedoch neutralisieren. Der Willensfindungsprozess findet beim Auftraggeber statt, nicht beim Analytiker oder einer Person beim Auftragnehmer, z.B. dem Screen-Designer. Wenn es lediglich am Abstraktionsvermögen scheitert, kann das Verfahren sehr nützlich sein. Falls das fehlende Abstraktionsvermögen allerdings ein Resultat mangelhafter IT-Kompetenz ist, gilt jedoch ebenfalls, dass Projektrisiken lediglich abgemildert werden können, nicht aber neutralisiert. U.U. sollte dann vor Projektbeginn über eine Schulung des Fachanwenders in Grundlagen der IT nachgedacht werden, denn ohne rudimentäre IT-Kompetenz kann er auch keine wirklich kompetenten Entscheidungen zur Entwicklung eines IT-Systems treffen.
home - top - Kontakt - letzter Update 20.5.2004 - © Karl Scharbert