Aus guten Gründen werden große Softwareprojekte nach Vorgehensmodellen abgewickelt, die Informatiker, die gerade frisch von der Uni kommen, gern als angestaubt und konservativ bezeichnen. Dem Wasserfall- und V-Modell wollen sie gern agile Methoden, Scrum und Extreme Programming entgegensetzen.
Aber Auftraggeber von kommerziellen Großprojekten erwarten Budget- und Terminsicherheit bei gleichzeitig klar definierten funktionalen und nicht-funktionalen Anforderungen, abgesichert in eindeutigen und verbindlichen Verträgen – und diese Sicherheit erwartet man eher von einfach und linear strukturierten Prozessen als von einer ungewissen Anzahl von Iterationen mit unbekanntem Ergebnis.
Allerdings können auch noch so gut vorbereitete Projekte mit erstklassig vordefinierten Phasen und Ergebnistypen selten die ursprünglichen Termin- und Kostenvorgaben einhalten. Ausgerechnet die zielgenaue und dosierte Anwendung agiler Methoden kann hier helfen – unter dem (wieder etwas konservativ klingenden) Begriff “Prototyp”.
Es gibt zwei Arten von Prototypen: Der eine ist vor allem unter dem Begriff “Klickprototyp” bekannt: Er modelliert bestimmte Aspekte des zukünftigen Systems ohne wirklich zu “funktionieren” – z.B. die Benutzeroberfläche oder die Verhaltensweise einer Schnittstelle.
Die andere Art von Prototyp wird oft als “Durchstich” bezeichnet – dabei wird ausprobiert, ob eine konzipierte Lösung wirklich funktioniert, d.h., der Prototyp liefert “echte” Ergebnisse.
Prototypen werden in der Konzeptionsphase des Softwareentwicklungsprozesses eingesetzt um Unsicherheiten über die Erfüllbarkeit funktionaler oder nicht-funktionaler Anforderungen auszuräumen. Sie kosten selbst allerdings Zeit und Ressourcen. Deshalb wird oft darauf verzichtet, insbesondere, weil Prototypen nach ihrem Einsatz oft weggeworfen werden und nicht in die endgültige Lösung eingehen.
Wenn die Prototypen nach agilen Methoden entwickelt werden, kann man aber dafür sorgen, dass sie zum Kern der späteren Lösung werden. Einfach gesagt kommt es darauf an, dass beim Erstellen des Prototypen nicht “quick and dirty” gearbeitet wird, sondern entsprechende Programmier-, Dokumentations- und Testrichtlinien angewendet werden.
Das hilft nicht nur, Doppelentwicklungen zu vermeiden, es wird auch sicher gestellt, dass die Ergebnisse der Arbeit am Prototyp wirklich in der Entwicklung berücksichtigt werden.