Cloudogu Logo

Hallo, wir sind Cloudogu!

Experten für Software-Lifecycle-Management und Prozess­auto­mati­sierung, Förderer von Open-Source-Soft­ware und Entwickler des Cloudogu EcoSystem.

featured image Software Prototyping – Rapid Application Development
06.12.2023 in Methods

Software Prototyping – Rapid Application Development


Daniel Huchthausen
Daniel Huchthausen

IT Consultant


Prototypen sind eine gute Möglichkeit, um Feedback zu Designideen und zur Machbarkeit technischer Lösungen zu erhalten. RAD (Rapid Application Development) ist eine Methode, bei der es darum geht, so schnell wie möglich mit der Entwicklung zu beginnen, anstatt strenge Designspezifikationen zu schreiben. Im Gegensatz zu dem verbreiteten Ratschlag, niemals einen Prototyp in der Produktion zu verwenden, tut RAD genau das. Deshalb wollen wir uns diese Methode genauer ansehen. Wenn Sie zunächst einen schnellen Überblick über Software-Prototyping benötigen, schauen Sie hier nach.

Die RAD-Methodik wurde als Alternative zur klassischen Wasserfallmethode entwickelt. Darüber hinaus gibt es auch eine spezifische Entwicklungsmethode, die RAD genannt wird. Lassen Sie sich also nicht von dem Begriff RAD verwirren. In diesem Beitrag werden wir uns auf die allgemeine Methodik beschränken.

Rapid Application Development (RAD)

Die Idee von RAD ist, dass Softwareentwicklung ein wissensintensiver Prozess ist. Während der Entwicklung einer Anwendung wird neues Wissen erworben, das zur Verbesserung des Produkts genutzt werden kann. Im Wasserfallmodell haben Sie keine Möglichkeit, dieses neu gewonnene Wissen zu nutzen, da alle Spezifikationen bereits vor Beginn der Entwicklung im Detail beschrieben wurden. RAD hingegen ermöglicht es Ihnen, die gewonnenen Erkenntnisse zu nutzen und so Ihre Softwareprodukte kontinuierlich zu verbessern, da es sich um einen iterativen Prozess handelt. Rapid Application Development Prozess

Mit RAD entwickeln Sie zunächst Prototypen, anstatt umfangreiche Designspezifikationen zu schreiben. Dann demonstrieren Sie den Prototyp, holen Feedback ein und passen ihn erneut an. Auf diese Weise entwickelt sich der Prototyp weiter und wird ab einem bestimmten Punkt zum Produkt (oder Teile davon können in das Produkt integriert werden). Das klingt sehr nach Scrum, bei dem man am Ende eines jeden Sprints ein lauffähiges System produzieren will. Jeder Sprint ist also ein evolutionärer Schritt des Prototypen, aber die Anwendung von RAD erfordert nicht die Rollen, Artefakte und Ereignisse von Scrum.

RAD eignet sich nicht für alle Projekte

In unserem ersten Beitrag über Prototyping haben wir gesagt, dass Sie Prototypen niemals in der Produktion einsetzen sollten, da sie sich auf ihren Hauptzweck konzentrieren und andere Themen vernachlässigen (oft Themen wie Sicherheit, Leistung oder nachhaltige Architektur). Wenn Sie RAD folgen und einen Prototyp zu einem Endprodukt entwickeln, müssen Sie diese Aspekte an einem bestimmten Punkt berücksichtigen, je nach Ihren Prioritäten. Generell ist die prototypische Entwicklung nicht für alle Projekte geeignet und bringt verschiedene Vor- und Nachteile mit sich.

Vorteile von Rapid Application Development

  • Risikominderung: Durch die Konzentration auf schrittweise Änderungen am System wird das Risiko eines katastrophalen Ausfalls verringert. Durch den Einsatz von RAD ist es weniger wahrscheinlich, dass eine grundlegende Neugestaltung des Produkts erforderlich ist.
  • Höhere Effizienz: Menschen sind besser im Benutzen und Reagieren als im Schreiben von Spezifikationen, die auf ihrer Vorstellung beruhen. Durch die Möglichkeit, einen Prototyp zu verwenden, erkennen Nutzende, dass sie etwas anderes wollen, oder es wird Optimierungspotenzial deutlich.
  • Hohe Qualität: Die ständige Interaktion mit den Nutzenden während der Entwicklung des Prototyps gewährleistet eine hohe Akzeptanz des Endprodukts.
  • Flexibilität: Dank der iterativen Entwicklung kann auf sich ändernde Anforderungen eingegangen werden.
  • Geringe Integrationshürde: Durch die Integration jeder einzelnen Stufe des Prototyps werden viele Integrationsprobleme gelöst.

Nachteile von Rapid Application Development

  • Schlechtes Design: Da das Design nie vollständig geplant wird und mit jeder Iteration oder jedem neuen Prototyp weiterentwickelt wird, kann das Design Schwächen aufweisen.
  • Nicht für alle Projekte (nicht zu groß): Bei großen Projekten stellt diese Methode eine besondere Herausforderung dar, insbesondere wegen des schlechten Designs, der geringen Kontrolle und der umfangreichen Benutzerinteraktion.
  • Modularisierung: Diese Methode kann nur angewandt werden, wenn das Produkt in mehrere Stufen von Prototypen modularisiert werden kann.
  • Einbeziehung von Kunden: Wie auch bei anderen inkrementellen oder iterativen Methoden ist die ständige Verfügbarkeit von Kunden eine Grundvoraussetzung, die jedoch nicht immer gegeben ist.

RAD ist agil

Wenn es sich um ein kleines Projekt handelt, das modularisiert werden kann, und Kunden/Nutzende sehr verfügbar sind, könnte es eine gute Idee sein, das Projekt mit der Entwicklung eines Prototyps zu beginnen und diesen zum Endprodukt weiterzuentwickeln. Auf diese Weise erhalten Sie viel Feedback, das Sie sofort einarbeiten können, und Sie müssen das Produkt nicht über den Prototyp hinaus entwickeln. Wie bei allen iterativen Ansätzen besteht immer die Gefahr, dass man einen Zustand entdeckt, der eine Neukonzeption des Produkts erforderlich macht. In diesem Fall ist es eine Frage der Prioritätensetzung - ist die Anforderung so wichtig, dass wir das Redesign realisieren sollten. Das klingt alles sehr nach einem agilen Ansatz, nicht wahr?