Schnelle Anwendungsentwicklung (RAD) ist eine Softwareentwicklungsmethodik, die minimale Planung für schnellen prototyping verwendet. Die "Planung" der Software entwickelt, RAD verwendend, wird mit dem Schreiben der Software selbst durchgeschossen. Der Mangel an der umfassenden Vorplanung erlaubt allgemein Software, viel schneller geschrieben zu werden, und macht es leichter, Voraussetzungen zu ändern.

Übersicht

Schnelle Anwendungsentwicklung ist eine Softwareentwicklungsmethodik, die Methoden wie wiederholende Entwicklung und Software prototyping einschließt. Gemäß Whitten (2004) ist es eine Fusion von verschiedenen strukturierten Techniken, besonders datengesteuerte Informationstechnik mit prototyping Techniken, um Softwaresystementwicklung zu beschleunigen.

In der schnellen Anwendungsentwicklung werden strukturierte Techniken und prototyping besonders verwendet, um die Voraussetzungen von Benutzern zu definieren und das Endsystem zu entwerfen. Der Entwicklungsprozess fängt mit der Entwicklung von einleitenden Datenmodellen und Geschäftsprozess-Modellen mit strukturierten Techniken an. In der folgenden Bühne werden Voraussetzungen mit prototyping nachgeprüft, um schließlich die Daten und Prozessmodelle zu raffinieren. Diese Stufen werden wiederholend wiederholt; weitere Entwicklung läuft "auf vereinigte Geschäftsvoraussetzungen und technische Designbehauptung hinaus, die zu verwenden ist, um neue Systeme zu bauen".

RAD Annäherungen können Kompromisse in der Funktionalität und Leistung als Entgelt für das Ermöglichen schnellerer Entwicklung und die Erleichterung der Anwendungswartung zur Folge haben.

Geschichte

Rapid Application Development (RAD) ist ein Begriff ursprünglich hat gepflegt, einen Softwareentwicklungsprozess zuerst entwickelt und erfolgreich aufmarschiert während der Mitte der 1970er Jahre durch das Systementwicklungszentrum von New York Telephone Co unter der Richtung von Dan Gielan zu beschreiben. Im Anschluss an eine Reihe von bemerkenswert erfolgreichen Durchführungen dieses Prozesses hat Gielan umfassend in verschiedenen Foren auf der Methodik, der Praxis und den Vorteilen dieses Prozesses gelesen.

RAD schließt wiederholende Entwicklung und den Aufbau von Prototypen ein. 1990, in seinem Buch RAD, Schnelle Anwendungsentwicklung, hat James Martin seine Interpretation der Methodik dokumentiert. Mehr kürzlich sind der Begriff und sein Akronym gekommen, um in einem breiteren, allgemeinen Sinn verwendet zu werden, der eine Vielfalt von Methoden umfasst, hat darauf gezielt, Anwendungsentwicklung wie der Gebrauch des Softwarefachwerks von verschiedenen Typen wie Webanwendungsfachwerk zu beschleunigen.

Schnelle Anwendungsentwicklung war eine Antwort auf Prozesse entwickelt in den 1970er Jahren und 1980er Jahren, wie die Strukturierte Systemanalyse- und Designmethode und anderen Wasserfall-Modelle. Ein Problem mit vorherigen Methodiken bestand darin, dass Anwendungen so lange genommen haben, um zu bauen, dass sich Voraussetzungen geändert hatten, bevor das System abgeschlossen war, auf unzulängliche oder sogar unbrauchbare Systeme hinauslaufend. Ein anderes Problem war die Annahme, dass eine methodische Bedarfsanalyse-Phase allein alle kritischen Voraussetzungen identifizieren würde. Große Beweise zeugen für die Tatsache, dass das selten der Fall sogar für Projekte mit hoch erfahrenen Fachleuten an allen Niveaus ist.

Mit den Ideen von Brian Gallagher, Alex Balchin, Barry Boehm und Scott Shultz anfangend, hat James Martin die schnelle Anwendungsentwicklungsannäherung während der 1980er Jahre an IBM entwickelt und hat es schließlich formalisiert, indem er ein Buch 1991, Schnelle Anwendungsentwicklung veröffentlicht hat.

Vier Phasen von RAD

1. Voraussetzungen, Phase Planend - verbinden Elemente der Systemplanung und Systemanalyse-Phasen von System Development Life Cycle (SDLC). Benutzer, Betriebsleiter und ES besprechen Mitarbeiter und einigen sich über Geschäftsbedürfnisse, Projektspielraum, Einschränkungen und Systemanforderungen. Es endet, wenn sich die Mannschaft über die Schlüsselprobleme einigt und Verwaltungsgenehmigung erhält weiterzugehen.

1. Benutzerdesignphase - während dieser Phase wirken Benutzer mit Systemanalytikern aufeinander und entwickeln Modelle und Prototypen, die alle Systemprozesse, Eingänge und Produktionen vertreten. Die RAD Gruppen oder Untergruppen verwenden normalerweise eine Kombination von Techniken von Joint Application Development (JAD) und FALL-Werkzeugen, um Benutzerbedürfnisse in Arbeitsmodelle zu übersetzen. Benutzerdesign ist ein dauernder interaktiver Prozess, der Benutzern erlaubt, zu verstehen, zu modifizieren, und schließlich ein Arbeitsmodell des Systems zu genehmigen, das ihren Bedarf deckt.

1. Bauphase - konzentriert sich auf Programm und dem SDLC ähnliche Anwendungsentwicklungsaufgabe. In RAD, jedoch, setzen Benutzer fort teilzunehmen und können noch Änderungen oder Verbesserungen als wirkliche Schirme vorschlagen, oder Berichte werden entwickelt. Seine Aufgaben programmieren und Anwendungsentwicklung, das Codieren, die Einheitsintegration und die Systemprüfung.

1. Abgeholzte Phase - ähnelt den Endaufgaben in der SDLC Durchführungsphase, einschließlich Datenkonvertierung, Prüfung, Wechsels zum neuen System und Benutzerschulung. Im Vergleich zu traditionellen Methoden wird der komplette Prozess zusammengepresst. Infolgedessen wird das neue System gebaut, geliefert, und in die Operation viel eher gelegt. Seine Aufgaben sind Datenkonvertierung, umfassende Prüfung, Systemwechsel, Benutzerschulung.

Eine andere Version von RAD Phasen

1. Das Geschäftsmodellieren: Der Datenfluss unter Geschäftsfunktionen wird durch das Antworten auf Fragen wie definiert, welche Information den Geschäftsprozess steuert, welche Information erzeugt wird, wer es erzeugt, wo die Information tut, gehen, die es und so weiter bearbeiten.

1. Das Datenmodellieren: Die vom Geschäftsmodellieren gesammelte Information wird in eine Reihe von Datengegenständen (Entitäten) raffiniert, die erforderlich sind, um das Geschäft zu unterstützen. Die Attribute (Charakter jeder Entität) werden identifiziert, und die Beziehung zwischen diesen Datengegenständen (Entitäten) wird definiert.

1. Das Prozess-Modellieren: Die in den Daten definierten Datengegenstände, Phase modellierend, werden umgestaltet, um den Datenfluss zu erreichen, der notwendig ist, um eine Geschäftsfunktion durchzuführen. In einer Prozession gehende Beschreibungen werden für das Hinzufügen, Ändern, Löschen oder Wiederbekommen eines Datengegenstands geschaffen.

1. Anwendungsgeneration: Automatisierte Werkzeuge werden verwendet, um Aufbau der Software zu erleichtern; sogar sie verwenden die 4. GL Techniken.

1. Die Prüfung und kippt Um: Viele der Programmierbestandteile sind bereits geprüft worden, da RAD Wiedergebrauch betont. Das reduziert insgesamt prüfende Zeit. Aber neue Bestandteile müssen geprüft werden, und alle Schnittstellen müssen völlig ausgeübt werden.

Verhältniswirksamkeit

Die Verschiebung von der traditionellen Sitzungsbasierten Entwicklung des Kunden/Servers, um sessionless und zusammenarbeitende Entwicklung wie Web 2.0 zu öffnen, hat das Bedürfnis nach schnelleren Wiederholungen durch die Phasen des Softwareentwicklungsprozesses vergrößert. Das, das mit dem wachsenden Gebrauch des offenen Quellfachwerks und der Produkte in der kommerziellen Kernentwicklung für viele Entwickler verbunden ist, hat Interesse an der Entdeckung einer Silberkugel RAD Methodik wieder angezündet.

Obwohl die meisten RAD Methodiken Softwarewiedergebrauch, kleine Mannschaft-Struktur und verteilte Systementwicklung fördern, erkennen die meisten RAD Praktiker an, dass, schließlich, keine "schnelle" Methodik eine Größenordnungsverbesserung über jede andere Entwicklungsmethodik zur Verfügung stellen kann.

Alle Typen von RAD haben das Potenzial, für ein gutes Fachwerk für die schnellere Produktentwicklung mit der verbesserten Softwarequalität zur Verfügung zu stellen, aber erfolgreiche Durchführung und Vorteile hängen häufig von Projekttyp, Liste, Softwareausgabe-Zyklus und korporativer Kultur ab. Es kann auch von Interesse sein, dass einige der größten Softwareverkäufer wie Microsoft und IBM RAD in der Entwicklung ihrer Flaggschiff-Produkte und größtenteils nicht umfassend verwenden, verlassen sie sich noch in erster Linie auf traditionelle Wasserfall-Methodiken mit etwas Grad davon, schnell zu wachsen.

Dieser Tisch enthält eine Zusammenfassung auf höchster Ebene von einigen der Haupttypen von RAD und ihren Verhältniskräften und Schwächen.

Kritik

Da schnelle Anwendungsentwicklung ein wiederholender und zusätzlicher Prozess ist, kann sie zu einer Folge von Prototypen führen, die nie in einer befriedigenden Produktionsanwendung kulminieren. Solche Misserfolge können vermieden werden, wenn die Anwendungsentwicklungswerkzeuge robust, flexibel, und zum richtigen Gebrauch gestellt sind. Das wird in Methoden wie die 2080-Entwicklungsmethode oder anderen postflinken Varianten gerichtet.

Außerdem gibt es ein Phänomen hinter einer erfolglosen Folge von unbefriedigenden Prototypen: Endbenutzer intuitiv und achten in erster Linie auf Graphical User Interface (GUI) als ein erstes Maß von Softwarequalitäten. Je schneller sie etwas "sehen" arbeiten, desto "schneller" sie wahrnehmen, dass der Entwicklungszyklus ist. Das ist, weil der GUI einen starken natürlichen direkt viewable Anwesenheit hat, während anderer Problem-Bereichscode abgeleitet oder abgeleitet werden muss, größtenteils unbemerkt gehend.

Da Programmierer allgemein Softwareendbenutzer zuerst und Programmierer später sind, ist diese natürliche Schwerkraft zum "Sehen" engrained vom Anfang (z.B "Hallo Welt" ist nicht über die Daten oder das Geschäftsgebiet, aber ist über "das Sehen" von etwas auf einem Schirm). Programmierer ohne klare Ausbildung zum Verstehen dieser irreführenden Qualität der Software neigen auch dazu, ihr Maß von "schnellen" in RAD dadurch angezogen zu werden, wie schnell der GUI fortschreitet. Die Tendenz wird weiter durch die Tatsache gestärkt, dass Endbenutzer meinen, dass die Finanzbelohnungsprogrammierer suchen, sie dazu bringend, den Maß-geMeinungssetzten des Endbenutzers aber nicht einer passenden und realistischeren Alternative unwissend zu befriedigen.

Folglich konzentrieren sich viele Softwareentwicklungswerkzeuge stark und in erster Linie auf die Anwendung GUI ebenso.

Diese Tendenz, "schnell" mittels des GUI zu messen, wird weiter von Programmierern gestärkt, die (der Reihe nach) RAD Werkzeug-Erzeuger werden. Sie haben auch ein starkes Finanzinteresse und befriedigen die Softwareentwicklungsgemeinschaft GUI-zentrisches Modell. Schließlich offenbart eine anekdotische Rezension von RAD Werkzeugen den starken GUI-Fokus, wo "Hallo GUI-zentrische andere und" Weltbeispiele im Überfluss sind und ein Mangel an Daten oder Geschäftsproblem-Bereichsbeispiele bestehen.

Schließlich, die Triade von Spielern (z.B Endbenutzer, Programmierer, Werkzeug-Entwickler), konzentriert sich jeder mit einem starken und verlegtem auf die GUI Aspekte von Softwareanwendungen führt zu einem kulturellen underemphasis des Hauptteils dessen, worüber der Softwaretext wirklich ist: Das Geschäft und die Datenproblem-Gebiete. Außerdem wirft die Kultur von RAD (und tatsächlich der Software im Allgemeinen), mit der GUI Hauptbetonung, ein vielseitiges Problem für Ingenieure auf, die das Problem anerkennen und sich bemühen, eine entgegengesetzte Umgebung (Endbenutzer, Entwickler und Werkzeuge) zu überwinden und zu erzeugen.

Erstens gibt es den Mangel an schnellen Anwendungsentwicklungswerkzeugen, die das passende Problem-Gebiet betonen. Dann passend haben erzogene Ingenieure die Aufgabe der Ausbildung und Endbenutzer dazu erziehend, die gegenintuitiven Daten und den Geschäftscode als das passende Maß dessen zu sehen, wie gut oder schnell ein Softwareprodukt entwickelt wird. Schließlich gibt es einen Mangel an Projektingenieuren, die das verlegte Problem-Gebiet verstehen und trainable und fähig zur Aufgabe des Neuorientierens von sich zum gegenintuitiven Gesichtspunkt sind.

Praktische Implikationen

Wenn Organisationen schnelle Entwicklungsmethodiken annehmen, muss Sorge genommen werden, um Rolle und Verantwortungsverwirrung und Nachrichtendepression innerhalb einer Entwicklungsmannschaft, und zwischen Mannschaft und Kunden zu vermeiden. Außerdem besonders in Fällen, wo der Kunde fehlt oder nicht fähig, mit der Autorität am Entwicklungsprozess teilzunehmen, sollte der Systemanalytiker mit dieser Autorität im Auftrag des Kunden ausgestattet sein, zu sichern

verwenden Sie prioritisation von nichtfunktionellen Voraussetzungen. Außerdem sollte keine Zunahme des Systems ohne eine gründliche und formell dokumentierte Designphase entwickelt werden.

Weiterführende Literatur

• Steve McConnell (1996). Schnelle Entwicklung: Wilde Softwarelisten, Microsoft Press Books, internationale Standardbuchnummer 978-1-55615-900-8 zähmend
• Ellen Gottesdiener (1995). "RAD Realien: Außer dem Trick dazu, wie RAD wirklich" Anwendungsentwicklungstendenzen arbeitet
• Ken Schwaber (1996). Flinkes Projektmanagement mit dem Gedränge, Microsoft Press Books, internationale Standardbuchnummer 978-0-7356-1993-7
• Steve McConnell (2003). Berufssoftwareentwicklung: Kürzere Listen, Höhere Qualitätsprodukte, Erfolgreichere Projekte, Erhöhte Karrieren, Microsoft Prese s Bücher, internationale Standardbuchnummer 978-0-321-19367-4
• Dean Leffingwell (2007). Schuppen der Softwarebehändigkeit: Beste Methoden für Große Unternehmen, Addison-Wesley Professional, internationale Standardbuchnummer 978-0-321-45819-3