The theory is that end users can create much better feedback when analyzing a live system, as opposed to working strictly with documentation. RAD-based development cycles have led to a lower level of rejection once the application is placed into production, but this success most often comes at the expense of a dramatic overruns in project costs and schedule.
The Rapid Application Development approach was made possible with significant advances in software development environments to permit rapid generation and change of displays and other user interface features. The end user is allowed to work with the displays online, as though in a manufacturing environment. This leaves little to the imagination, and a significant number of errors are caught using this process.
The down side to RAD is the propensity of the end user to force scope creep to the development effort. Since it seems so simple for the developer to generate the basic screen, it has to be just as easy to add a widget or two. In many RAD lifecycle failures, the end users and developers were caught in an unending cycle of enhancements, together with the users asking for more and more and the programmers seeking to satisfy them.
For this reason, the software development team doesn’t use a pure RAD approach, but rather combines limited prototyping in with requirements and design development during a traditional waterfall lifecycle. The prototypes developed are specifically focused on a subset of the application, and don’t provide an integrated interface. The prototypes are used to validate requirements and design components, and the development of further requirements or the addition of user interface options not readily supported by the development environment is actively discouraged.
Benefits of RAD
RAD reduces the development time and reusability of components help to speed up development.
All functions are modularized so it’s easy to work with.
For big projects RAD require highly skilled engineers in the group.
Cons of RAD
Both end customer and programmer should be committed to complete the system in a much abbreviated time frame.
If commitment is lacking RAD will fail.
RAD is based on Object Oriented approach and if it is difficult to modularize the project the RAD may not work well.