Was ist schnelle Anwendungsentwicklung?

Der Vorteil, Nutzen der Interaktion von Benutzern mit Prototypen während des gesamten Entwicklungszyklus von Software (SDLC) liegt in einem qualitativ hochwertigeren Endprodukt, das in kürzerer Zeit auf den Markt gebracht werden kann.

RAD ist besonders hilfreich für spezifische Anwendungsfälle, in denen Benutzeroberflächenanforderungen die Entwicklung vorantreiben müssen. Die Möglichkeit, eine Benutzeroberfläche selbst zu erleben, auch wenn sie sich noch in der Entwicklung befindet, erlaubt es den Nutzern, bereits früh im Entwicklungsprozess nützlicheres Feedback zu geben. Das hilft, katastrophale Folgen zu vermeiden, wenn Software in Produktion geht und Benutzer feststellen, dass das Produkt nicht ihren Bedürfnissen entspricht.

Dies sind die vier typischen Phasen einer RAD-Iteration, wie sie vom IT-Pionier James Martin definiert wurden. RAD geht auf die Mitte der 80er Jahre zurück und wurde von Martin bei IBM in seinem Buch Rapid Application Development von 1991 als besondere Methode formalisiert, obwohl in dieser Zeit auch andere RAD-Ansätze von anderen entwickelt wurden. Die hier vorgestellten vier Phasen wurden von Martin speziell definiert, aber RAD als allgemeiner Ansatz zur Softwareentwicklung kann nicht ausschließlich Martin zugeschrieben werden.

Das Ziel der Planungsphase ist es nicht, alle Anforderungen im Voraus zu definieren. Stattdessen versucht das Team, das zu lösende Problem, die beabsichtigten Benutzer, die Funktionen, die für die Benutzer am wichtigsten sein werden, und die wichtigsten Einschränkungen für die Entwicklung zu definieren. Solche Einschränkungen umfassen Budget, Zeitplan, Integration mit breiteren Technologiestacks und Compliance-Bedenken.

Statt umfangreicher Anforderungsdokumente liefert diese Phase Benutzerstorys, Wireframes, Funktionslisten, architektonische Entscheidungen, Projektziele und grobe Zeitpläne. Dies stellt im Vergleich zu anderen Ansätzen eine minimale Planung dar, was beabsichtigt ist. Die Planung wird bewusst schlank gehalten, damit die Entwicklung schnell mit der Prototypenerstellung beginnen kann.

RAD geht davon aus, dass sich die Anforderungen ändern, da die Benutzer oft nicht genau wissen, was sie wollen, bis sie einen Prototyp sehen. Während der Entwicklung werden Erkenntnisse in Echtzeit gesammelt, die helfen, den Plan zu konkretisieren. Diese Phase ist lediglich ein Sprungbrett.

Die Teams machen sich während der Designphase schnell an die Arbeit, um Mockups, klickbare Prototypen, frühe Abläufe in der Benutzeroberfläche und funktionale Demos zu erstellen. Diese werden verwendet, um Ideen zu validieren und Probleme mit der Benutzerfreundlichkeit aufzudecken. Während des gesamten Prozesses wird die Zustimmung der Stakeholder eingeholt. Abstrakte Anforderungen werden präzisiert, indem im Laufe des Prozesses klar wird, was wichtig ist und was nicht. Falsche Annahmen werden frühzeitig aufgedeckt und nach und nach entwickelt sich ein gemeinsames Verständnis darüber, was das Produkt leisten soll.

Es ist wichtig, dass der Prototyp nicht als etwas angesehen wird, das „nur zur Veranschaulichung dient“. Es ist eine Grundlage, auf der man aufbauen kann und die sich oft direkt zum Endprodukt weiterentwickelt.

Dies ist die Hauptentwicklungsphase. Sobald sich der Prototyp zu einer gemeinsamen Vision stabilisiert hat, entwickeln die Entwicklungsteams die Funktionalität in kleinen Iterationen und schnellen Veröffentlichungen und Integrationen. Die Entwickler arbeiten parallel in kurzen Zyklen und kooperieren intensiv über Fachgrenzen hinweg. Anstatt einen Teil eines Produkts fertigzustellen, bevor sie mit der nächsten Komponente fortfahren, arbeiten die Teams parallel.

Zum Beispiel würde bei traditionelleren Ansätzen zuerst ein Team ein Authentifizierungstool entwickeln und es dann an ein anderes Team weitergeben, um ein Berichterstellungs-Tool zu entwickeln. Im Rahmen von RAD würde dies gleichzeitig geschehen, wobei beide Teams eng zusammenarbeiten würden.

Um Zeit zu sparen, setzen RAD-Tools häufig auf Low-Code- und No-Code-Lösungen, Automatisierungen, wiederverwendbare Bibliotheken, Komponenten-Frameworks und andere vorgefertigte Vorlagen, anstatt alles von Grund auf neu zu entwickeln. Dies erhöht die Bereitstellungsgeschwindigkeit, manchmal auf Kosten einer perfekten Architektur, langfristiger Wartbarkeit und Dokumentation.

Das Modell der schnellen Anwendungsentwicklung behandelt Testen und Feedback als kontinuierlichen Teil des gesamten Workflows und nicht als eine Endphase. Produktmanager, QA-Tester, Business-Stakeholder und Endnutzer sind frühzeitig und häufig an Tests beteiligt.

Im Gegensatz zu traditionellen Ansätzen finden alle Arten von Tests (funktional, Benutzerfreundlichkeit, Workflow, Leistung) während der Entwicklung statt, nicht danach. Ziel dieses iterativen Prozesses ist es, die Entwicklung eines Softwareprodukts zu vermeiden, das zwar technisch funktioniert, aber das falsche Problem löst. Durch die kontinuierliche Validierung erhalten die Entwickler ein besseres Verständnis dafür, inwieweit ihre Lösungen die Bedürfnisse der Nutzer und die Anforderungen des Unternehmens erfüllen.

Die fertiggestellte, getestete Anwendung wird in eine Live-Produktionsumgebung eingeleitet. Dies beinhaltet in der Regel die Migration von Daten, Benutzerschulungen und die Behebung von Fehlern in letzter Minute. Aufgrund der kontinuierlichen Tests in früheren Phasen verläuft der Übergang in der Regel reibungsloser und schneller als bei traditionellen Methoden.

RAD ermöglicht es Unternehmen oft, mehr Produkte fristgerecht und innerhalb des Budgets fertigzustellen. Doch der Ansatz hat auch seine Nachteile.

Die größte Herausforderung besteht wohl darin, die vielen Berührungspunkte zwischen Nutzern und Entwicklern zu managen. RAD wurde als Antwort auf das Wasserfallmodell entwickelt, einen älteren Ansatz im Softwareentwicklungszyklus, der durch sequentielle Phasen definiert ist, die abgeschlossen sein müssen, bevor die nächste beginnt. Das Wasserfallmodell entstand aus der traditionellen Planung physischer Infrastrukturen wie Brücken und Gebäuden. Aber Software verhält sich anders als reale Systeme. Sie ist flexibler und kann sich im Laufe der Entwicklung aufgrund des Feedbacks der Benutzer ändern.

Im Wasserfallmodell definieren die Benutzer typischerweise die Anforderungen und verschwinden dann, während die Entwickler die Lösung erstellen. Der RAD-Ansatz bezieht die Benutzer während des gesamten Projekts mit ein. Das bedeutet, dass das Unternehmen diese Stakeholder für Tests und Feedback zur Verfügung stellen muss. Oft sind diejenigen, die am besten geeignet wären, gutes Feedback zu geben, beruflich sehr eingespannt, aber ohne ihre Beteiligung könnte das Projekt scheitern. Das schafft eine DevOps-Herausforderung, die eine kluge Aufsicht durch Projektmanager erfordert.

Die Flexibilität, die den RAD-Prozess so nützlich macht, geht oft auf Kosten der Kontrolle. Während das Wasserfallmodell starre Phasen aufweist, kann das RAD-Modell etwas chaotisch sein. Daher ist es möglicherweise nicht ideal für kritische Software, bei der ein Ausfall zum Tod oder zu anderen Katastrophen führen könnte, oder für große Systeme mit vielen Komponenten.

Auch die schleichende Ausweitung des Umfangs ist ein häufiger Nachteil von RAD. Die Benutzer fragen ständig nach „Nice-to-have“-Funktionen, was zu erweiterten Zeitplänen und aufgeblähten Budgets führt. Es ist wichtig, dass Benutzeranfragen so bearbeitet werden, dass die Kernfunktionen Vorrang haben.

RAD ist schnell, und Entwickler priorisieren die Dokumentation, um die Geschwindigkeit beizubehalten. Der Nachteil dabei ist, dass die langfristige Wartung schwierig werden kann, was mit der Zeit Risiken birgt, da es immer schwieriger wird, neue Entwickler ins Team zu integrieren.

Rapid Prototyping bedeutet oft, dass man so schnell vorgeht und so viele kleine, inkrementelle Anpassungen als Reaktion auf das Feedback der Nutzer vornimmt, dass die Ingenieure die größeren architektonischen Belange aus den Augen verlieren. Ohne eine solide Softwareentwicklungsdisziplin kann das Systemdesign inkonsistent werden, die Integration unübersichtlich, Modelle driften ab und Softwareprojekte insgesamt entkoppeln sich davon, wie sie in größere Systeme passen. Skalierbarkeit ist beim RAD-Modell ein Problem, da umfangreiche Systeme in der Regel eine sorgfältige Architektur, Planung und formale Prozesse erfordern.

Der Fokus von RAD auf Geschwindigkeit kann Teams unbeabsichtigt zu sofortigen Anfragen, schnellen Fixes und einer kurzfristigen Orientierung führen, was mit der Zeit problematischer wird.

RAD und flexible Entwicklung überschneiden sich, indem sie lange, starre Entwicklungszyklen ablehnen und die Iteration betonen. Während RAD primär auf die Geschwindigkeit der Anwendungsbereitstellung optimiert, optimiert der flexible Ansatz typischerweise auf adaptive und nachhaltige Softwareentwicklung. Mit seinem Scrum-Framework, das auf einen vorhersehbaren Lieferrhythmus und Sprints setzt, betont der flexible Ansatz die strukturierte, nachhaltige Lieferung mit geplanten Iterationen, definierten Zielen, Rollen und Prozessen für einen langfristig guten technischen Zustand.