The Rapid Application Development Paradigm It is so RAD! Copyright © 2015-2017 Curt Hill

Introduction Like Agile methods RAD can refer to several distinct methods Often these have little to do with each other One use of RAD refers to a technique that relies heavily on components Another one is very similar to Prototyping but where the components allow for a better grade of prototype Copyright © 2015-2017 Curt Hill

Again An incremental method Uses short development cycles Enhancement of the Waterfall model using existing components With well understood requirements and constrained scope a functional system can be attained in a short amount of time Copyright © 2015-2017 Curt Hill

Phases There are five phases Business Modeling Data Modeling Process Modeling Application Generation Testing and turnover The difference from waterfall is dependence on libraries of components Copyright © 2015-2017 Curt Hill

Components Reusable objects that can be easily incorporated into another project These are typically objects in the programming sense but may also be functions or programs Before these components were available we started from scratch each time Copyright © 2015-2017 Curt Hill

Example In the 1990s we typically coded a GUI nearly from scratch We would code our own message loop Draw the image It was a terribly slow development Typical application spent more time on the GUI than the logic behind it Then the kind of GUI components we see in Dev appeared Now creating the GUI is comparatively quick These are often called RAD tools Copyright © 2015-2017 Curt Hill

Componentization This RAD approach needs libraries of components There should be components that Ease GUI design and drawing Process Regular Expressions Access SQL databases Spreadsheet access If a RAD team has to develop new capabilities they are usually determined to make it a component as well Copyright © 2015-2017 Curt Hill

RAD and Prototyping Another flavor of RAD is similar to Prototyping In minimizes the modeling phase in favor of a prototype With the availability of components this prototype will be much more likely to be: In a production language rather than a script Able to be improved into a production system Copyright © 2015-2017 Curt Hill

More Differences Since the prototype is much more likely to be stable there is typically more interaction with the users throughout the process The GUI shell may be nearly right at the outset The processing can then be swapped in and out without the users noticing This tends to reduce the risk The user gets incrementally better products with no surprises Copyright © 2015-2017 Curt Hill

Finally The problems of the waterfall model are largely alleviated by continual user interaction Does consume a fair amount of user time for evaluations Often better for small to medium projects Copyright © 2015-2017 Curt Hill