Schnelle Anwendungsentwicklung

"RAD -Tool" und "Rapid Application Development Tool" leiten hier um. Für die Entwicklung, die sich auf grafische Benutzeroberflächen konzentriert, siehe Grafischer Benutzeroberfläche Builder.

Schnelle Anwendungsentwicklung (Rad), auch genannt Schnellanwendungsgebäude (Rab), ist sowohl ein allgemeiner Begriff für adaptive Software-Entwicklung Ansätze und der Name für James Martin's Methode der schnellen Entwicklung. Im Allgemeinen legt RAD -Ansätze für die Softwareentwicklung weniger die Planung und stärker auf einen adaptiven Prozess. Prototypen werden oft zusätzlich zu oder manchmal sogar anstelle von Entwurfspezifikationen verwendet.

RAD ist besonders gut geeignet für die Entwicklung (wenn auch nicht beschränkt) Software das wird von getrieben von Benutzeroberfläche Bedarf. Grafische Benutzeroberflächenbauer werden oft als Rapid Application Development Tools bezeichnet. Andere Ansätze zur schnellen Entwicklung sind die adaptiv, agil, Spiral-, und einheitlich Modelle.

Geschichte

Schnelle Anwendungsentwicklung war eine Reaktion auf planengetrieben Wasserfall Prozesse, die in den 1970er und 1980er Jahren entwickelt wurden, wie die Strukturierte Systemanalyse- und Entwurfsmethode (SSADM). Eines der Probleme mit diesen Methoden ist, dass sie auf einem traditionellen technischen Modell basierten, das zum Entwerfen und Aufbau von Brücken und Gebäuden verwendet wurde. Software ist eine von Natur aus unterschiedliche Art von Artefakt. Software kann den gesamten Prozess, der zur Lösung eines Problems verwendet wird, radikal ändern. Infolgedessen kann das aus dem Entwicklungsprozess selbst gewonnene Wissen die Anforderungen und das Design der Lösung zurücksetzen.[1] Planungsgetriebene Ansätze versuchen, die Anforderungen, die Lösung und den Plan zur Implementierung streng zu definieren und einen Prozess zu haben, der Änderungen abhält. RAD -Ansätze dagegen erkennen, dass die Softwareentwicklung ein wissensintensiver Prozess ist, und liefern flexible Prozesse, die dazu beitragen, das während des Projekts gewonnene Wissen zur Verbesserung oder Anpassung der Lösung zu nutzen.

Die erste derartige RAD -Alternative wurde von entwickelt von Barry Boehm und war bekannt als die Spiralmodell. Boehm und andere nachfolgende rad -Ansätze betonten sich sowohl die Entwicklung von Prototypen als auch anstelle von strengen Designspezifikationen. Prototypen hatten mehrere Vorteile gegenüber traditionellen Spezifikationen:

  • Risikominderung. Ein Prototyp könnte einige der schwierigsten potenziellen Teile des Systems frühzeitig testen Lebenszyklus. Dies kann wertvolle Informationen über die Machbarkeit eines Designs liefern und das Team daran hindern, Lösungen zu verfolgen, die sich als zu komplex oder zeitaufwändig herausstellen. Dieser Vorteil des Auffindens von Problemen früher im Lebenszyklus als später war ein wesentlicher Vorteil des RAD-Ansatzes. Je früher ein Problem ist, ist der billigere, den es angehen soll.
  • Benutzer verwenden und reagieren besser als beim Erstellen von Spezifikationen. Im Wasserfallmodell war es üblich, dass ein Benutzer eine Reihe von Anforderungen anmelden, aber als er ein implementiertes System präsentiert wurde, um plötzlich zu erkennen, dass einem bestimmten Design einige kritische Merkmale oder zu komplex waren. 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 sollte.
  • Prototypen können verwendbar sein und sich zu dem vollständigen Produkt entwickeln. Ein bei einigen RAD -Methoden verwendete Ansatz bestand darin, das System als eine Reihe von Prototypen zu erstellen, die sich von der minimalen Funktionalität zu mäßig nützlich für das endgültige fertige System entwickeln. Der Vorteil davon neben den beiden oben genannten Vorteilen bestand darin, dass die Benutzer im Prozess viel früher nützliche Geschäftsfunktionen erzielen konnten.[2]

Beginnend mit den Ideen von Barry Boehm und andere, James Martin entwickelte den Rapid Application Development -Ansatz in den 1980er Jahren bei IBM und formalisierte es schließlich, indem es 1991 ein Buch veröffentlichen, Schnelle Anwendungsentwicklung. Dies hat zu einer gewissen Verwirrung über den Begriff RAD geführt, selbst unter IT -Profis. Es ist wichtig, zwischen Rad als allgemeine Alternative zum Wasserfallmodell und Rad als spezifische Methode von Martin zu unterscheiden. Die Martin -Methode war auf wissensintensive und UI -intensive Geschäftssysteme zugeschnitten.

Diese Ideen wurden von Rad Pionieren wie James Kerr und Richard Hunter weiterentwickelt und verbessert, die gemeinsam das wegweisende Buch zu diesem Thema in RAD schrieb.[3] Dies folgte der Reise eines RAD-Projektmanagers, als er die RAD-Methodik in Echtzeit bei einem tatsächlichen RAD-Projekt fuhr und verfeinerte. Diese Praktizierenden und solche wie sie haben die Beliebtheit der RAD -Gewinne als Alternative zu traditionellen Systemprojekt -Lebenszyklusansätzen beigetragen.

Der RAD -Ansatz reifte auch im Zeitraum von Spitzeninteresse an Business Regineering. Die Idee des Umbaues des Geschäftsprozesses bestand darin, die Kerngeschäftsprozesse wie Vertrieb und Kundensupport radikal zu überdenken, unter Berücksichtigung der neuen Funktionen der Informationstechnologie. RAD war oft ein wesentlicher Bestandteil größerer Unternehmens -RE -Ingenieurprogramme. Der Rapid -Prototyping -Ansatz von RAD war ein wichtiges Tool, mit dem Benutzer und Analysten "über den Box überlegen" über innovative Möglichkeiten, wie die Technologie einen Kerngeschäftsprozess radikal neu erfinden könnte, zu helfen.[4][5] [6]

Ein Großteil von James Martins Komfort mit rad stammte aus DupontDie Abteilung für Informations -Engineering und seine Leiterin Scott Schultz und ihre jeweiligen Beziehungen zu John Underwood, der ein maßgeschneidertes RAD -Entwicklungsunternehmen leitete, das viele erfolgreiche RAD -Projekte in Australien und Hongkong leitete.

Erfolgreiche Projekte wie ANZ Bank, Lend Lease, BHP, Coca-Cola Amatil, Alcan, Hongkong Jockey Club und zahlreiche andere.

Der Erfolg, der sowohl dazu führte, dass Scott Shultz als auch James Martin in Australien Zeit mit John Underwood verbrachte, um die Methoden und Details zu verstehen, warum Australien überproportional erfolgreich erfolgreich war, um bedeutende geschäftskritische RAD -Projekte umzusetzen.

Die James Martin Rad -Methode

Phasen im James Martin -Ansatz für Rad

Der James Martin -Ansatz zur RAD unterteilt den Prozess in vier verschiedene Phasen:

  1. Anforderungen Planungsphase - kombiniert Elemente der Systemplanungs- und Systemanalysephasen der Lebenszyklus für Systementwicklung (SDLC). Benutzer, Manager und IT -Mitarbeiter diskutieren und sind sich einig Geschäftliche Bedürfnisse, Projektumfang, Einschränkungen und Systemanforderungen. Es endet, wenn das Team die wichtigsten Themen einverstanden ist und die Autorisierung des Managements erhält, um fortzufahren.
  2. Benutzerdesignphase - In dieser Phase interagieren Benutzer mit Systemanalysten und entwickeln Modelle und Prototypen das repräsentiert alle Systemprozesse, Eingänge, und Ausgänge. Die RAD -Gruppen oder Untergruppen verwenden normalerweise eine Kombination von gemeinsames Anwendungsdesign (JAD) -Techniken und Fallwerkzeuge Um Benutzerbedürfnisse in Arbeitsmodelle zu übersetzen. Benutzerdesign ist ein kontinuierlicher interaktiver Prozess, mit dem Benutzer ein Arbeitsmodell des Systems verstehen, ändern und schließlich genehmigen können, das ihren Anforderungen entspricht.
  3. Konstruktionsphase - Konzentriert sich auf Programm- und Anwendungsentwicklungsaufgaben ähnlich wie die SDLC. In RAD nehmen die Benutzer jedoch weiterhin teil und können weiterhin Änderungen oder Verbesserungen vorschlagen, wenn tatsächliche Bildschirme oder Berichte entwickelt werden. Die Aufgaben sind Programmier- und Anwendungsentwicklung, Codierung, Einheitsintegration und Systemtests.
  4. Cutoverphase - ähnelt den endgültigen Aufgaben in der SDLC -Implementierungsphase, einschließlich Datenkonvertierung, Tests, Umstellung auf das neue System und Benutzertraining. Im Vergleich zu herkömmlichen Methoden wird der gesamte Prozess komprimiert. Infolgedessen wird das neue System viel früher gebaut, geliefert und in Betrieb genommen.[7]

Vorteile

In modernen Umgebungen für Informationstechnologie werden jetzt viele Systeme unter Verwendung eines gewissen Grads der schnellen Anwendungsentwicklung entwickelt[8] (Nicht unbedingt der James Martin -Ansatz). Zusätzlich zu Martins Methode, Agile Methoden und die Rational einheitlicher Prozess werden oft für die Radentwicklung verwendet.

Zu den angeblichen Vorteilen von RAD gehören:

  • Bessere Qualität. Durch die Interaktion von Benutzern kann die Geschäftsfunktionalität eines RAD -Projekts oft viel höher sein als das, das über ein Wasserfallmodell erreicht wird. Die Software kann mehr sein verwendbar und hat eine bessere Chance, sich auf Geschäftsprobleme zu konzentrieren, die für Endbenutzer von entscheidender Bedeutung sind, als auf technische Probleme, die für Entwickler von Interesse sind. Dies schließt jedoch andere Kategorien von dem aus, was normalerweise bekannt ist Nicht-funktionale Anforderungen (AKA -Einschränkungen oder Qualitätsattribute) einschließlich Sicherheit und Portabilität.
  • Risikokontrolle. Obwohl ein Großteil der Literatur zu Rad auf Geschwindigkeit und Benutzer beteiligt ist, ist eine kritische Merkmale von RAD, die korrekt durchgeführt wurde, die Risikominderung. Es ist sich daran zu erinnern, dass Boehm das Spiralmodell zunächst als risikobasiertes Ansatz charakterisierte. Ein RAD -Ansatz kann sich früh auf die wichtigsten Risikofaktoren konzentrieren und sich an sie anhand von empirischen Beweisen anpassen, die zu Beginn des Prozesses gesammelt wurden. Z. B. die Komplexität des Prototyps einiger der komplexesten Teile des Systems.
  • Weitere Projekte, die pünktlich und innerhalb des Budgets abgeschlossen sind. Durch die Konzentration auf die Entwicklung inkrementeller Einheiten wird die Chancen auf katastrophale Fehler, die große Wasserfallprojekte verzeichnet haben, verringert. Im Wasserfallmodell war es üblich, nach sechs Monaten oder mehr Analysen und Entwicklung zu einer Verwirklichung zu kommen, die ein radikales Überdenken des gesamten Systems erforderte. Mit RAD kann diese Art von Informationen früher im Prozess entdeckt und bearbeitet werden.[2][9]

Nachteile

Zu den angeblichen 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 so überdenken mussten, wie sie funktionierten. Menschen sind praktisch immer abgeneigt, und jedes Projekt, das mit neuen Tools oder Methoden durchgeführt wird, wird beim ersten Mal eher gescheitert, weil das Team lernen muss.
  • Mangelnde Betonung auf Nicht-funktionale Anforderungen, die für den Endbenutzer im normalen Betrieb oft nicht sichtbar sind.
  • Erfordert Zeit der knappen Ressourcen. Eine Sache, die praktisch alle RAD-Ansätze gemeinsam haben, ist, dass während des gesamten Lebenszyklus zwischen Benutzern und Entwicklern viel mehr Interaktion besteht. Im Wasserfallmodell definieren Benutzer Anforderungen und verschwinden dann meistens, als Entwickler das System erstellt haben. Bei Rad sind Benutzer von Anfang an und durch praktisch das gesamte Projekt beteiligt. Dies erfordert, dass das Unternehmen bereit ist, Experten für Anwendungsdomänen zu investieren. Das Paradoxon ist, je besser der Experte, desto mehr sind sie mit ihrer Domäne vertraut, desto mehr müssen sie tatsächlich das Geschäft führen, und es kann schwierig sein, ihre Vorgesetzten davon zu überzeugen, ihre Zeit zu investieren. Ohne solche Verpflichtungen werden RAD -Projekte nicht erfolgreich sein.
  • Weniger Kontrolle. Einer der Vorteile von RAD besteht darin, dass es einen flexiblen anpassbaren Prozess bietet. Das Ideal ist es, sich schnell sowohl an Probleme als auch an Chancen anzupassen. Es gibt einen unvermeidlichen Kompromiss zwischen Flexibilität und Kontrolle, mehr bedeutet weniger des anderen. Wenn ein Projekt (z. lebenskritische Software) Die Werte steuern mehr als Agility Rad ist nicht angemessen.
  • Schlechtes Design. Der Fokus auf Prototypen kann in einigen Fällen zu weit geführt werden, was zu einer "Hack- und Test" -Methodik führt, bei der Entwickler ständig geringfügige Änderungen an einzelnen Komponenten vornehmen und Probleme mit der Systemarchitektur ignorieren, die zu einem besseren Gesamtdesign führen können. Dies kann insbesondere für Methoden wie Martin ein Problem sein, die sich so stark auf die Benutzeroberfläche des Systems konzentrieren.[10]
  • Mangel an Skalierbarkeit. Rad konzentriert sich in der Regel auf kleine bis mittelgroße Projektteams. Die anderen oben genannten Themen (weniger Design und Kontrolle) stellen besondere Herausforderungen bei, wenn Sie einen RAD -Ansatz für sehr große Systeme verwenden.[11][12][13]

Siehe auch

Praktische Konzepte zur Implementierung von RAD:

Andere ähnliche Konzepte:

Verweise

  1. ^ Brooks, Fred (1986). Kugler, H. J. (Hrsg.). Keine Silberkugel -Essenz und Unfälle der Software -Engineering (PDF). Informationsverarbeitung '86. Elsevier Science Publishers B.V (North-Holland). ISBN 0-444-70077-3. Abgerufen 2. Juli 2014.
  2. ^ a b Boehm, Barry (Mai 1988). "Ein Spiralmodell der Softwareentwicklung" (PDF). IEEE -Computer. doi:10.1109/2.59. S2CID 1781829. Archiviert von das Original (PDF) am 29. März 2018. Abgerufen 1. Juli 2014.
  3. ^ Kerr, James M.; Hunter, Richard (1993). Inside RAD: So bauen Sie ein voll funktionsfähiges System in 90 Tagen oder weniger auf. McGraw-Hill. ISBN0-07-034223-7.
  4. ^ Drucker, Peter (3. November 2009). Postkapitalistische Gesellschaft. Harper Collins E-Books. ISBN 978-0887306204.
  5. ^ Martin, James (1991). Schnelle Anwendungsentwicklung. Macmillan. ISBN 0-02-376775-8.
  6. ^ https://www.technobuzz.tech/2020/10/android.html
  7. ^ Martin, James (1991). Schnelle Anwendungsentwicklung.Macmillan.pp.81–90. ISBN 0-02-376775-8.
  8. ^ "Der Zerfall der Anzeige: Sie wieder zusammenzusetzen" (PDF). gartner.com.br. Abgerufen 13. April 2010.
  9. ^ Beck, Kent (2000). Extreme Programmierung erklärt. Addison Wesley. pp.3–7. ISBN 0201616416.
  10. ^ Gerber, Aurona; Van der Merwe, Alta; Alberts, Ronell (16. bis 18. November 2007). "Praktische Implikationen schneller Entwicklungsmethoden". Verfahren der Konferenz zur Bildung von Informatik und Informationstechnologie, CSITE-2007. Konferenz für Informatik und IT -Bildung. Mauritius. S. 233–245. Citeseerx 10.1.1.100.645. ISBN 978-99903-87-47-6.
  11. ^ Andrew Begel, Nachiappan Nagappan (September 2007). "Nutzung und Wahrnehmung der agilen Softwareentwicklung in einem industriellen Kontext: Eine explorative Studie" (PDF). Erstes internationales Symposium für empirische Software -Engineering und -messung (Esem 2007). S. 255–264. doi:10.1109/esem.2007.12. ISBN 978-0-7695-2886-1. S2CID 1941370.
  12. ^ Maximilien, E.M.; Williams, L. (2003). "Bewertung der Testentwicklung bei IBM". 25. Internationale Konferenz für Software Engineering, 2003. Proceedings. S. 564–569. doi:10.1109/ICSE.2003.1201238. ISBN 0-7695-1877-x. S2CID 16919353.
  13. ^ Stephens, Matt; Rosenberg, Doug (2003). Extreme Programmierung neu gestaltet: Der Fall gegen XP. doi:10.1007/978-1-4302-0810-5. ISBN 978-1-59059-096-6. S2CID 29042153.

Weitere Lektüre

  • Steve McConnell (1996). Schnelle Entwicklung: Zähmung wilder Softwarepläne, Microsoft Press Books, ISBN978-1-55615-900-8
  • Kerr, James M.; Hunter, Richard (1993). Inside RAD: So bauen Sie ein voll funktionsfähiges System in 90 Tagen oder weniger auf. McGraw-Hill. ISBN 0-07-034223-7.
  • Ellen Gottesdiener (1995). "Rad Realitäten: Über den Hype hinaus, wie Rad wirklich funktioniert"Anwendungsentwicklungstrends
  • Ken Schwaber (1996). Agile Projektmanagement mit Scrum, Microsoft Press Books, ISBN978-0-7356-1993-7
  • Steve McConnell (2003). Professionelle Softwareentwicklung: kürzere Zeitpläne, Produkte von höherer Qualität, erfolgreichere Projekte, verbesserte Karrieren, Addison-Wesley, ISBN978-0-321-19367-4
  • Dean Leffingwell (2007). Skalierungssoftware Agilität: Best Practices für große Unternehmen, Addison-Wesley Professional, ISBN978-0-321-45819-3
  • Scott Stiner (2016). Forbes -Liste: "Rapid Application Development (RAD): Ein intelligenter, schneller und wertvoller Prozess für Softwareentwickler"