1. The Rapid Application Development Paradigm
It is so RAD!
Copyright © Curt Hill

2. 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 © Curt Hill

3. 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 © Curt Hill

4. 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 © Curt Hill

5. 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 © Curt Hill

6. 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 © Curt Hill

7. 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 © Curt Hill

8. 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 © Curt Hill

9. 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 © Curt Hill

10. 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 © Curt Hill