Versionsorientiertes Prototyping - bewahren statt verwerfen

Vorgehensmodelle nehmen eine Einteilung der mit der Software-Einführung verbundenen Gesamtaufgabe in Teilaufgaben vor. Das älteste Modell zur Softwareentwicklung und –einführung ist das klassische Wasserfallmodell, welches in mehreren aufeinanderfolgenden Phasen die jeweils komplette Anforderungserhebung und –dokumentation, das Softwaredesign und die Softwareentwicklung vorsieht.

Sämtliche Erfahrungen der letzten Jahrzehnte haben gezeigt, dass zu Beginn eines langen und großen Softwareprojektes noch nicht vollumfänglich die Anforderungen erhoben werden können. Daher haben sich weitere Vorgehensmodelle im Software Engineering etabliert, die eine inkrementelle, versionsorientierte oder prototypenhafte Einteilung der Aufgabe vornehmen. In jüngster Zeit werden diese Grundideen und Vorgehensmodelle in Form von „Agilen Methoden“ propagiert, auch wenn eine Methode nicht agil sein kann, sondern das Projektmanagement durch die Verwendung der Methode Agilität erreichen sollte.

Die consenso hat sich für ein versionsorientiertes Prototyping-Verfahren entschieden und ein Rapid Prototyping abgelehnt, bei dem der Prototyp nach Erstellung wieder verworfen wird.

Die consenso-Methodik und das dieser Methodik zugrundeliegende Vorgehensmodell haben verschiedene Vorteile. Erstens kann den Anwendern schnell der Prozess am System gezeigt werden, um auch umgehend Veränderungen der Software vornehmen zu können, wenn das Ergebnis nicht gefällt (und damit das Refactoring als wesentliches Postulat des eXtreme Programming als wichtiger agiler Methode zu unterstützen). Zweitens bietet das Vorgehen den Vorteil, dass die im Zuge der Anforderungserhebung und Softwareumsetzung entstandenen Aufwendungen nicht doppelt entstehen. Im Rahmen des Vorgehensmodells wird mittels vier aufeinander aufbauender Prototypen (als unterschiedliche Versionen) eine strukturierte, effiziente und jederzeit am System nachvollziehbare Weiterentwicklung vorgenommen, die für die Auftraggeber und Anwender ein hohes Maß an Transparenz durch konkrete Arbeit am System schafft. Damit werden unnötige Abstraktionen für die Anwender umgangen, die i.d.R. zu falschen Anforderungen und damit zu teuren Fehlentwicklungen führen.