Beitrag von DSDM, RUP und XP zur Gestaltung von RAD-Projekten

Inhaltsangabe:Einleitung: 
Wie eine Studie über den Stand der Softwareentwicklung in Deutschland, die vom Bun-desforschungsministerium Ende 2000 in Auftrag gegeben wurde, zeigt, erfolgt nur bei rund 50% aller Software entwickelnden deutschen Unternehmen die Entwicklung nach einem Vorgehensmodell. Auffällig ist, dass speziell bei kleinen und jungen Unternehmen (vor allem Start-up's der New Economy) die Softwareentwicklung in aller Regel eher chaotisch stattfindet, und dass das schnelle Anbieten neuer Funktionalität Priorität vor Qualitätsaspekten hat. Gerade diesen, in einem turbulenten Umfeld operierenden Unternehmen kann mit Vorgehensmodellen, die speziell an deren besondere Bedürfnisse angepasst sind, geholfen werden. Solche Vorgehensmodelle werden oft unter dem Oberbegriff Rapid Application Development zusammengefasst. 
In der Praxis – vor allem in Unternehmensberatungen – ist zu beobachten, dass oftmals verschiedene Modelle als das RAD-Modell propagiert und verkauft werden. Im Allgemeinen lässt sich jedoch feststellen, dass allen diesen Modellen ein gemeinsamer Bezugsrahmen fehlt, der sie vergleichbar macht. Ohne einen solchen Bezugsrahmen ist es für Organisationen sehr viel schwerer, eine rationale Entscheidung für oder wider den Einsatz eines Vorgehensmodells treffen zu können. Das Fehlen eines speziellen Bezugsrahmens zeigt auch, dass oft unklar ist, was mit einem RAD-Vorgehensmodell eigentlich gemeint ist. Zu den Vorgehensmodellen, die in Theorie und Praxis dem RAD-Bereich zugerechnet werden, gehören z.B. die Dynamic Systems Development Method, die sich selbst als holistischer Ansatz für Softwareentwicklung in einer RAD-Projektumgebung versteht, und das Extreme Programming, das zu den „agilen“ (ehemals „leichtgewichtigen“) Methoden im RAD-Spektrum gehört. Ein weiterer Ansatz, der zwar nicht explizit für eine RAD-Vorgehensweise geschaffen wurde, jedoch viele Eigenheiten von RAD zu inkorporieren scheint, ist der Unified Software Development Process bzw. seine kommerzialisierte Version Rational Unified Process. Daneben können auch weitere Methoden aufgezählt werden, z.B. Scrum oder Feature-Driven Development,die sich in der Praxis jedoch nur minderer Beliebtheit erfreuen. 
Zur Zeit existiert kein allgemein akzeptierter strukturierter RAD-Standard, anhand dessen die Eignung dieser Modelle für eine Vorgehensweise nach RAD-Gesichtspunkten überprüft werden könnte. Ebenso unklar ist, wie RAD-Projekte konkret zu gestalten sind und inwiefern die oben […]