Rapid Prototyping Modell
Veröffentlicht auf 16. Oktober 2009
Das Rapid Prototyping Modell ist ein Softwareentwicklungsmodell, dass besonders geeignet ist, wenn die Anforderungen zu Beginn eines Projektes unbekannt sind oder ganz neue Bereiche betreten werden.
Voraussetzung ist allerdings eine enge Einbindung des zukünftigen Anwenders.
Zu Beginn der Entwicklung einer Anwendersoftware wird ein grober Projektplan und eine erste Anforderungsspezifikation für die ersten 3 evolutionären Phasen erstellt.
Mit diesen Vorgaben wird mittels Werkzeugen ein Modell erstellt, dass die ersten Anforderungen der Anwender erfüllt.
Auf Basis dieses Modell wird dann eine Datenbank und eine grafische Oberfläche erstellt, die dem Anwender vorgestellt wird.
Wird sie akzeptiert, werden die ersten Funktionen hinzugefügt und die Software dem Anwender wieder zur Überprüfung übergeben. Ansonsten wird das Modell so lange verbessert, bis der Anwender seine Anforderungen erfüllt sieht.
Ist der Anwender mit den neuen Funktionen zufrieden, werden weitere Verbesserungsvorschläge und neue Funktionen in die nächste Evolutionsphase mitgenommen und umgesetzt.
Dies wird so lange wiederholt, bis die volle Funktionalität vom Anwender bestätigt wird.
Nun wird vom Entwickler (möglichst mittels Werkzeuge) ein einfaches Designdokument der Architektur erstellt und mögliche Optimierungsmaßnahmen werden erörtert und umgesetzt um den Prototyp auf den Einsatz vorzubereiten.
Dies kann durchaus einen größeren Arbeitsaufwand für den Entwickler mit sich bringen, wenn strenge Produktionsvorgaben für Ressourcenverbrauch oder Performance erreicht werden müssen.
Im allgemeinen gibt es keinen absolut richtigen Weg das Rapid Prototyping Modell anzuwenden.
Man kann genauso einen fast fertigen Prototyp verwerfen oder nur Teile wiederverwenden und sich auf Grund der Erfahrungen mit dieser Arbeit an eine Neuentwicklung machen.
Die Vorteile des Rapid Prototyping Modell:
* Trotz mangelnder Anforderungen kann entwickelt werden
* Enge Einbindung des Endanwenders
* Anforderungen werden stets vom Anwender selbst geprüft
* Der Entwickler wird vom Anwender in die Thematik eingelernt
* Der Anwender bekommt genau das, was er haben möchte
* Fortschritt ist stets sichtbar
* Neue Arbeitsbereiche können ergründet werden, ehe eine größere Anzahl von Ressourcen beschlagnahmt werden
Mögliche Nachteile:
* Enge Einbindung des Endanwenders
* Man neigt zu einer Quick-and-dirty Implementierung
* Die schwierigen Funktionen werden gerne zuletzt umgesetzt
* Der Anwender möchte möglicherweise Geld sparen und den Prototyp produktiv einsetzen
* Man verliert sich in immer neuen Code-and-Fix Zyklen, der Anwender möchte immer noch mehr Funktionen umgesetzt sehen
* Anwender und Entwickler haben unterschiedliche Vorstellungen von der Anzahl der Iterationen
Voraussetzung ist allerdings eine enge Einbindung des zukünftigen Anwenders.
Zu Beginn der Entwicklung einer Anwendersoftware wird ein grober Projektplan und eine erste Anforderungsspezifikation für die ersten 3 evolutionären Phasen erstellt.
Mit diesen Vorgaben wird mittels Werkzeugen ein Modell erstellt, dass die ersten Anforderungen der Anwender erfüllt.
Auf Basis dieses Modell wird dann eine Datenbank und eine grafische Oberfläche erstellt, die dem Anwender vorgestellt wird.
Wird sie akzeptiert, werden die ersten Funktionen hinzugefügt und die Software dem Anwender wieder zur Überprüfung übergeben. Ansonsten wird das Modell so lange verbessert, bis der Anwender seine Anforderungen erfüllt sieht.
Ist der Anwender mit den neuen Funktionen zufrieden, werden weitere Verbesserungsvorschläge und neue Funktionen in die nächste Evolutionsphase mitgenommen und umgesetzt.
Dies wird so lange wiederholt, bis die volle Funktionalität vom Anwender bestätigt wird.
Nun wird vom Entwickler (möglichst mittels Werkzeuge) ein einfaches Designdokument der Architektur erstellt und mögliche Optimierungsmaßnahmen werden erörtert und umgesetzt um den Prototyp auf den Einsatz vorzubereiten.
Dies kann durchaus einen größeren Arbeitsaufwand für den Entwickler mit sich bringen, wenn strenge Produktionsvorgaben für Ressourcenverbrauch oder Performance erreicht werden müssen.
Im allgemeinen gibt es keinen absolut richtigen Weg das Rapid Prototyping Modell anzuwenden.
Man kann genauso einen fast fertigen Prototyp verwerfen oder nur Teile wiederverwenden und sich auf Grund der Erfahrungen mit dieser Arbeit an eine Neuentwicklung machen.
Die Vorteile des Rapid Prototyping Modell:
* Trotz mangelnder Anforderungen kann entwickelt werden
* Enge Einbindung des Endanwenders
* Anforderungen werden stets vom Anwender selbst geprüft
* Der Entwickler wird vom Anwender in die Thematik eingelernt
* Der Anwender bekommt genau das, was er haben möchte
* Fortschritt ist stets sichtbar
* Neue Arbeitsbereiche können ergründet werden, ehe eine größere Anzahl von Ressourcen beschlagnahmt werden
Mögliche Nachteile:
* Enge Einbindung des Endanwenders
* Man neigt zu einer Quick-and-dirty Implementierung
* Die schwierigen Funktionen werden gerne zuletzt umgesetzt
* Der Anwender möchte möglicherweise Geld sparen und den Prototyp produktiv einsetzen
* Man verliert sich in immer neuen Code-and-Fix Zyklen, der Anwender möchte immer noch mehr Funktionen umgesetzt sehen
* Anwender und Entwickler haben unterschiedliche Vorstellungen von der Anzahl der Iterationen