Schnelle Anwendungsentwicklung - Rapid application development

Rapid-Application-Development ( RAD ), auch Rapid-Application-Building ( RAB ) genannt, ist sowohl ein Sammelbegriff für adaptive Softwareentwicklungsansätze als auch die Bezeichnung für die Methode der schnellen Entwicklung von James Martin . Im Allgemeinen legen RAD-Ansätze für die Softwareentwicklung weniger Wert auf die Planung und mehr auf einen adaptiven Prozess. Prototypen werden oft zusätzlich zu oder manchmal sogar anstelle von Designspezifikationen verwendet.

RAD ist besonders gut geeignet für die (wenn auch nicht darauf beschränkt) die Entwicklung von Software , die von angetriebenen Benutzeroberfläche Anforderungen . Builder für grafische Benutzeroberflächen werden oft als schnelle Anwendungsentwicklungstools bezeichnet. Andere Ansätze für eine schnelle Entwicklung umfassen die adaptiven , agilen , spiralförmigen und vereinheitlichten Modelle.

Geschichte

Die schnelle Anwendungsentwicklung war eine Reaktion auf plangesteuerte Wasserfallprozesse , die in den 1970er und 1980er Jahren entwickelt wurden, wie die Structured Systems Analysis and Design Method (SSADM). Eines der Probleme bei diesen Methoden besteht darin, dass sie auf einem traditionellen Ingenieurmodell basierten, das zum Entwerfen und Bauen von Dingen wie Brücken und Gebäuden verwendet wurde. Software ist von Natur aus eine andere Art von Artefakt. Software kann den gesamten Prozess zur Lösung eines Problems radikal verändern. Dadurch können Erkenntnisse aus dem Entwicklungsprozess selbst in die Anforderungen und das Design der Lösung einfließen. Plangesteuerte Ansätze versuchen, die Anforderungen, die Lösung und den Plan zu ihrer Implementierung starr zu definieren und haben einen Prozess, der Änderungen verhindert. RAD-Ansätze hingegen erkennen an, dass Softwareentwicklung ein wissensintensiver Prozess ist und bieten flexible Prozesse, die dabei helfen, während des Projekts gewonnenes Wissen zu nutzen, um die Lösung zu verbessern oder anzupassen.

Die erste derartige RAD-Alternative wurde von Barry Boehm entwickelt und als Spiralmodell bekannt . Boehm und andere nachfolgende RAD-Ansätze betonten die Entwicklung von Prototypen sowie oder anstelle von strengen Designspezifikationen. Prototypen hatten gegenüber herkömmlichen Spezifikationen mehrere Vorteile:

  • Risikominderung. Ein Prototyp könnte einige der schwierigsten potenziellen Teile des Systems zu einem frühen Zeitpunkt im Lebenszyklus testen . Dies kann wertvolle Informationen über die Machbarkeit eines Entwurfs liefern und kann verhindern, dass das Team nach Lösungen sucht, deren Umsetzung sich als zu komplex oder zeitaufwändig herausstellt. Dieser Vorteil, Probleme eher früher als später im Lebenszyklus zu finden, war ein wesentlicher Vorteil des RAD-Ansatzes. Je früher ein Problem gefunden wird, desto günstiger ist es zu beheben.
  • Benutzer können besser verwenden und reagieren als Spezifikationen erstellen. Im Wasserfallmodell war es üblich, dass ein Benutzer eine Reihe von Anforderungen abzeichnete, aber dann, als er ein implementiertes System präsentierte, plötzlich feststellte, dass einem bestimmten Design einige kritische Funktionen fehlten oder es zu komplex war. Im Allgemeinen geben die meisten Benutzer viel nützlicheres Feedback, wenn sie einen Prototyp des laufenden Systems erleben können, anstatt abstrakt zu definieren, was dieses System sein soll.
  • Prototypen können nutzbar sein und sich zum fertigen Produkt entwickeln. Ein Ansatz, der bei einigen RAD-Methoden verwendet wurde, bestand darin, das System als eine Reihe von Prototypen zu erstellen, die sich von minimaler Funktionalität über mäßig nützlich bis zum endgültigen fertigen System entwickeln. Der Vorteil neben den beiden oben genannten Vorteilen bestand darin, dass die Benutzer viel früher im Prozess nützliche Geschäftsfunktionen erhalten konnten.

Ausgehend von den Ideen von Barry Boehm und anderen entwickelte James Martin in den 1980er Jahren bei IBM den Rapid Application Development- Ansatz und formalisierte ihn schließlich durch die Veröffentlichung eines Buches im Jahr 1991, Rapid Application Development . Dies hat selbst unter IT-Experten zu einiger Verwirrung über den Begriff RAD geführt. Es ist wichtig, zwischen RAD als allgemeine Alternative zum Wasserfallmodell und RAD als der von Martin entwickelten spezifischen Methode zu unterscheiden. Die Martin-Methode wurde auf wissensintensive und UI-intensive Geschäftssysteme zugeschnitten.

Diese Ideen wurden von RAD-Pionieren wie James Kerr und Richard Hunter weiterentwickelt und verbessert, die zusammen das bahnbrechende Buch zu diesem Thema, Inside RAD, geschrieben haben, das der Reise eines RAD-Projektmanagers folgte, als er die RAD-Methodik in der Praxis vorantrieb und verfeinerte -time für ein aktuelles RAD-Projekt. Diese und ähnliche Praktiker haben dazu beigetragen, dass RAD als Alternative zu herkömmlichen Ansätzen für den Lebenszyklus von Systemprojekten an Popularität gewann.

Der RAD-Ansatz reifte auch während der Zeit des höchsten Interesses an Business Reengineering . Die Idee des Business Process Reengineering bestand darin, Kerngeschäftsprozesse wie Vertrieb und Kundensupport mit Blick auf die neuen Möglichkeiten der Informationstechnologie radikal zu überdenken. RAD war oft ein wesentlicher Bestandteil größerer Business Re-Engineering-Programme. Der Rapid-Prototyping-Ansatz von RAD war ein wichtiges Werkzeug, um Benutzern und Analysten dabei zu helfen, "out of the box" über innovative Wege zu denken, mit denen Technologie einen Kerngeschäftsprozess radikal neu erfinden könnte.

Ein Großteil von James Martins Komfort bei RAD stammte von Duponts Abteilung für Informationstechnik und ihrem Leiter Scott Schultz und ihren jeweiligen Beziehungen zu John Underwood, der eine maßgeschneiderte RAD-Entwicklungsfirma leitete, die viele erfolgreiche RAD-Projekte in Australien und Hongkong voranbrachte.

Erfolgreiche Projekte, darunter ANZ Bank, Lend Lease, BHP, Coca-Cola Amatil, Alcan, Hong Kong Jockey Club und zahlreiche andere.

Ein Erfolg, der dazu führte, dass sowohl Scott Shultz als auch James Martin Zeit in Australien mit John Underwood verbrachten, um die Methoden und Details zu verstehen, warum Australien bei der Umsetzung wichtiger geschäftskritischer RAD-Projekte überproportional erfolgreich war.

Die James Martin RAD-Methode

Phasen des James-Martin-Ansatzes für RAD

Der Ansatz von James Martin für RAD unterteilt den Prozess in vier verschiedene Phasen:

  1. Anforderungsplanungsphase – kombiniert Elemente der Systemplanungs- und Systemanalysephase des Systems Development Life Cycle (SDLC). Benutzer, Manager und IT-Mitarbeiter diskutieren und vereinbaren Geschäftsanforderungen, Projektumfang, Einschränkungen und Systemanforderungen. Es endet, wenn sich das Team in den wichtigsten Fragen einig ist und die Genehmigung des Managements zur Fortsetzung eingeholt wird.
  2. Benutzerdesignphase – Während dieser Phase interagieren Benutzer mit Systemanalysten und entwickeln Modelle und Prototypen, die alle Systemprozesse, Eingaben und Ausgaben darstellen. Die RAD-Gruppen oder -Untergruppen verwenden normalerweise eine Kombination aus Techniken der gemeinsamen Anwendungsentwicklung (JAD) und CASE-Tools , um Benutzeranforderungen in Arbeitsmodelle zu übersetzen. Benutzerdesign ist ein kontinuierlicher interaktiver Prozess, der es Benutzern ermöglicht, ein Arbeitsmodell des Systems zu verstehen, zu ändern und schließlich zu genehmigen, das ihren Anforderungen entspricht.
  3. Konstruktionsphase – konzentriert sich auf die Programm- und Anwendungsentwicklungsaufgabe ähnlich dem SDLC. In RAD nehmen die Benutzer jedoch weiterhin teil und können weiterhin Änderungen oder Verbesserungen vorschlagen, während tatsächliche Bildschirme oder Berichte entwickelt werden. Seine Aufgaben sind Programmierung und Anwendungsentwicklung, Codierung, Unit-Integration und Systemtest.
  4. Umstellungsphase – ähnelt den letzten Aufgaben in der SDLC-Implementierungsphase, einschließlich Datenkonvertierung, Tests, Umstellung auf das neue System und Benutzerschulung. Im Vergleich zu herkömmlichen Methoden wird der gesamte Prozess komprimiert. Dadurch wird das neue System viel früher gebaut, geliefert und in Betrieb genommen.

Vor- und Nachteile einer schnellen Anwendungsentwicklung

In modernen IT-Umgebungen werden heute viele Systeme mit einem gewissen Grad an Rapid Application Development erstellt (nicht unbedingt nach dem Ansatz von James Martin). Neben Martins Methode werden häufig Agile Methoden und der Rational Unified Process für die RAD-Entwicklung verwendet.

Zu den angeblichen Vorteilen von RAD gehören:

  • Bessere Qualität. Indem Benutzer mit sich entwickelnden Prototypen interagieren, kann die Geschäftsfunktionalität eines RAD-Projekts oft viel höher sein als die, die über ein Wasserfallmodell erreicht wird. Die Software kann benutzerfreundlicher sein und hat eine bessere Chance, sich auf geschäftliche Probleme zu konzentrieren, die für Endbenutzer kritisch sind, anstatt auf technische Probleme, die für Entwickler von Interesse sind. Dies schließt jedoch andere Kategorien der normalerweise als nicht-funktionalen Anforderungen (AKA-Einschränkungen oder Qualitätsattribute) bekannten Kategorien aus, einschließlich Sicherheit und Portabilität.
  • Risikokontrolle. Obwohl sich ein Großteil der RAD-Literatur auf Geschwindigkeit und Benutzerbeteiligung konzentriert, ist ein kritisches Merkmal von RAD, das richtig durchgeführt wird, die Risikominderung. Es sei daran erinnert, dass Boehm das Spiralmodell ursprünglich als risikobasierten Ansatz charakterisierte. Ein RAD-Ansatz kann sich frühzeitig auf die wichtigsten Risikofaktoren konzentrieren und sich basierend auf empirischen Erkenntnissen, die in der frühen Phase des Prozesses gesammelt wurden, darauf einstellen. ZB die Komplexität des Prototypings einiger der komplexesten Teile des Systems.
  • Mehr Projekte termin- und budgetgerecht abgeschlossen. Durch die Konzentration auf die Entwicklung inkrementeller Einheiten wird die Wahrscheinlichkeit katastrophaler Ausfälle, die große Wasserfallprojekte hartnäckig gemacht haben, reduziert. Im Waterfall-Modell war es üblich, nach sechs oder mehr Monaten Analyse und Entwicklung zu einer Erkenntnis zu kommen, die ein radikales Umdenken des Gesamtsystems erforderte. Mit RAD können diese Art von Informationen früher im Prozess entdeckt und darauf reagiert werden.

Zu den Nachteilen von RAD gehören:

  • Das Risiko eines neuen Ansatzes. Für die meisten IT-Shops war RAD ein neuer Ansatz, bei dem erfahrene Fachleute ihre Arbeitsweise überdenken mussten. Menschen sind praktisch immer abgeneigt gegen Veränderungen und jedes Projekt, das mit neuen Werkzeugen oder Methoden durchgeführt wird, wird beim ersten Mal eher scheitern, einfach weil das Team lernen muss.
  • Mangelnde Betonung nicht-funktionaler Anforderungen , die für den Endbenutzer im Normalbetrieb oft nicht sichtbar sind.
  • Benötigt Zeit knapper Ressourcen. Eines haben praktisch alle Ansätze von RAD gemeinsam, dass es während des gesamten Lebenszyklus viel mehr Interaktion zwischen Benutzern und Entwicklern gibt. Im Wasserfallmodell würden die Benutzer Anforderungen definieren und dann meistens verschwinden, wenn die Entwickler das System erstellt haben. In RAD werden Benutzer von Anfang an und praktisch während des gesamten Projekts eingebunden. Dies erfordert, dass das Unternehmen bereit ist, die Zeit von Experten für Anwendungsdomänen zu investieren. Das Paradoxe ist, dass je besser der Experte, je besser er mit seinem Gebiet vertraut ist, desto mehr muss er das Geschäft tatsächlich führen und es kann schwierig sein, seine Vorgesetzten davon zu überzeugen, ihre Zeit zu investieren. Ohne solche Zusagen werden RAD-Projekte nicht erfolgreich sein.
  • Weniger Kontrolle. Einer der Vorteile von RAD besteht darin, dass es einen flexibel anpassbaren Prozess bietet. Das Ideal ist, sich schnell auf Probleme und Chancen einstellen zu können. Es gibt einen unvermeidlichen Kompromiss zwischen Flexibilität und Kontrolle, mehr vom einen bedeutet weniger vom anderen. Wenn ein Projekt (zB lebenskritische Software ) Werte mehr als Agilität kontrolliert, ist RAD nicht geeignet.
  • Schlechtes Design. Der Fokus auf Prototypen kann in einigen Fällen zu weit gehen, was zu einer "Hack-and-Test"-Methodik führt, bei der Entwickler ständig kleinere Änderungen an einzelnen Komponenten vornehmen und Systemarchitekturprobleme ignorieren, die zu einem besseren Gesamtdesign führen könnten. Dies kann insbesondere bei Methoden wie der von Martin ein Problem darstellen, die sich so stark auf die Benutzeroberfläche des Systems konzentrieren.
  • Mangelnde Skalierbarkeit. RAD konzentriert sich in der Regel auf kleine bis mittelgroße Projektteams. Die anderen oben genannten Probleme (weniger Design und Steuerung) stellen besondere Herausforderungen dar, wenn ein RAD-Ansatz für sehr große Systeme verwendet wird.

Siehe auch

Verweise

Weiterlesen