Prototyping-Modell

Das Prototyping-Modell begegnet einem Problem, an dem klassische, rein lineare Modelle wie das Wasserfallmodell häufig scheitern: Zu Beginn eines Projekts lassen sich Anforderungen selten vollständig und korrekt aufschreiben, vor allem wenn Nutzerinnen und Nutzer sich unter einer Beschreibung noch wenig vorstellen können. Statt Anforderungen ausschließlich in Dokumenten festzuhalten, durchläuft das Prototyping-Modell zunächst einen Zyklus aus Entwurf, Prototyp und Bewertung, bis die Anforderungen ausreichend klar sind, und mündet dann in dieselbe Linie: reguläre Fertigstellung, Test und Wartung, als eigene, abschließende Phasen desselben Modells, nicht als Übergabe an ein fremdes Vorgehen.

Herkunft

Das Prototyping-Modell hat, anders als das Spiralmodell mit Boehm, keinen einzelnen benennbaren Ursprung. Es entstand Ende der 1970er- und in den 1980er-Jahren als praktische Gegenbewegung zur Erwartung, dass sich Software vollständig durchplanen lässt, bevor die erste Zeile Code entsteht. Als frühes, häufig zitiertes Systematisierungswerk gilt Bernard Boars Buch „Application Prototyping“ von 1984, das Prototyping erstmals als eigenständiges, strukturiertes Vorgehen statt als bloßen Werkzeugtrick beschrieb.

Ablauf

Nach der Analyse, der ersten, meist noch groben Anforderungsaufnahme, entsteht ein knapper Entwurf, auf dessen Grundlage ein Prototyp gebaut wird. Nutzerinnen, Nutzer oder Fachbereich bewerten diesen Prototyp anschließend: Sind sie nicht zufrieden, fließt das Feedback zurück in Entwurf und Prototyp, der Zyklus wiederholt sich. Erst wenn der Prototyp die Anforderungen ausreichend abbildet, geht das Modell in reguläre Entwicklung, Test, Bereitstellung und Wartung über, dieselben SDLC-Phasen, die auch jedes andere Modell durchläuft. Diese letzten Phasen sind kein Bruch mit einem anderen Vorgehen, sondern der reguläre Abschluss desselben Zyklus.

Wegwerf- oder evolutionärer Prototyp

In der Praxis haben sich zwei grundverschiedene Spielarten etabliert, die in manchen Quellen sogar als eigenständige, benannte Modelle geführt werden:

• Wegwerfprototyp (throwaway prototyping): Der Prototyp dient ausschließlich der Klärung, etwa von Bedienkonzept oder technischer Machbarkeit, und wird danach verworfen. Die eigentliche Umsetzung beginnt anschließend neu, jetzt mit deutlich klareren Anforderungen.
• Evolutionärer Prototyp: Der Prototyp wird schrittweise verfeinert und wächst direkt zum fertigen Produkt heran, statt am Ende verworfen zu werden.

Eine zweite, unabhängige Unterscheidung betrifft die Tiefe: Ein horizontaler Prototyp deckt viele Funktionen oberflächlich ab, etwa als reine Bildschirmoberfläche ohne echte Logik dahinter, während ein vertikaler Prototyp eine einzelne Funktion vollständig bis in die technische Tiefe umsetzt, um deren Machbarkeit zu belegen.

Wann das Prototyping-Modell passt

• Unklare oder sich entwickelnde Anforderungen: Wenn Beteiligte erst am konkreten Ergebnis erkennen, was sie eigentlich brauchen.
• Neue, wenig erprobte Produktideen: Wenn Nutzungsverhalten oder Marktbedarf noch unsicher sind.
• Hohes Risiko in der Bedienoberfläche: Wenn früher Nutzerfeedback wichtiger ist als frühe technische Vollständigkeit.
• Klärung technischer Machbarkeit: Wenn einzelne, riskante technische Fragen vor einer größeren Investition beantwortet werden müssen.

Grenzen

Der größte praktische Fallstrick ist, dass ein eigentlich als Wegwerfprototyp gedachtes Ergebnis am Ende doch als Produktionscode weiterlebt, unter Zeitdruck oder weil er „doch schon ziemlich gut funktioniert“. Was als schnelle Klärung gedacht war, trägt dann unbemerkt technische Schulden in die eigentliche Umsetzung. Ohne klare Abbruchkriterien für den Bewertungszyklus besteht außerdem die Gefahr endloser Verfeinerungsschleifen, ohne dass sich das Projekt tatsächlich der Fertigstellung annähert. Das Modell liefert zudem weniger Vorhersagbarkeit bei Zeit- und Budgetplanung als rein lineare Modelle, weil die Anzahl nötiger Iterationen vorab kaum feststeht.

Verwandte Modelle

Das Spiralmodell nutzt Prototyping als eine seiner Techniken zur Risikoauflösung, ohne selbst ein reines Prototyping-Modell zu sein. Als eigenständige Technik, losgelöst vom gesamten Projektzyklus und meist auf einen einzelnen Anwendungsfall wie eine Bedienoberfläche begrenzt, findet sich Prototyping auch als methode-Eintrag, etwa im Umfeld von Wireframes.