Rapid application development (RAD) is both a general term used to refer to alternatives to the conventional waterfall model of software development. In general, RAD approaches to software development put less emphasis on planning tasks and more emphasis on development. In contrast to the waterfall model, which emphasizes rigorous specification and planning, RAD approaches emphasize the necessity of adjusting requirements in reaction to knowledge gained as the project progresses. This causes RAD to use prototypes in addition to or even sometimes in place of design specifications. RAD approaches also emphasize a flexible process that can adapt as the project evolves rather than rigorously defining specifications and plans correctly from the start. Approaches to rapid development include Agile methods and the spiral model. RAD is especially well suited (although not limited to) developing software that is driven by user interface requirements. Graphical user interface builders are often called rapid application development tools.
A little background:
Rapid application development is a response to processes developed in the 1970s and 1980s, such as the Structured Systems Analysis and Design Method and other Waterfall models. One of the problems with these methodologies is that they were based on a traditional engineering model used to design and build things like bridges and buildings. Software is an inherently different kind of artifact. Software can radically change the entire process used to solve a problem. As a result knowledge gained from the development process itself can feed back to the requirements and design of the solution. The waterfall solution to this was to try and rigidly define the requirements and the plan to implement them and have a process that discouraged changes to either. The new RAD approaches on the other hand recognized that software development was a knowledge intensive process and sought to develop flexible processes that could take advantage of knowledge gained over the life of the project and use that knowledge to reinvent the solution.
Pros and Cons:
In the modern Information Technology environment many systems are now built using some degree of Rapid Application Development.
The advantages of RAD include:
Better Quality: By having users interact with evolving prototypes the business functionality from a RAD project can often be much higher than that achieved via a waterfall model. The software can be more usable and has a better chance to focus on business problems that are critical to end users rather than technical problems of interest to developers.
Risk Control: Although much of the literature on RAD focuses on speed and user involvement a critical feature of RAD done correctly is risk mitigation. A RAD approach can focus in early on the key risk factors and adjust to them based on empirical evidence collected in the early part of the process. E.g., the complexity of prototyping some of the most complex parts of the system.
More projects completed on time and within budget: By focusing on the development of incremental units the chances for catastrophic failures that have dogged large waterfall projects is reduced. In the Waterfall model it was common to come to a realization after six months or more of analysis and development that required a radical rethinking of the entire system. With RAD this kind of information can be discovered and acted upon earlier in the process.
The disadvantages of RAD include:
The risk of a new approach: For most IT shops RAD was a new approach that required experienced professionals to rethink the way they worked. Humans are virtually always averse to change and any project undertaken with new tools or methods will be more likely to fail the first time simply due to the requirement for the team to learn.
Requires time of scarce resources: One thing virtually all approaches to RAD have in common is that there is much more interaction throughout the entire lifecycle between users and developers. In the waterfall model, users would define requirements and then mostly go away as developers created the system. In RAD users are involved from the beginning and through virtually the entire project. This requires that the business is willing to invest the time of application domain experts. The paradox is that the better the expert, the more they are familiar with their domain, the more they are required to actually run the business and it may be difficult to convince their supervisors to invest their time. Without such commitments RAD projects will not succeed.
Less control: One of the advantages of RAD is that it provides a flexible adaptable process. The ideal is to be able to adapt quickly to both problems and opportunities. There is an inevitable trade-off between flexibility and control, more of one means less of the other. If a project (e.g. life-critical software) values control more than agility RAD is not appropriate.
Poor design: The focus on prototypes can be taken too far in some cases resulting in a “hack and test” methodology where developers are constantly making minor changes to individual components and ignoring system architecture issues that could result in a better overall design. This can especially be an issue for methodologies such as Martin’s that focus so heavily on the User Interface of the system.
Very large systems: RAD typically focuses on small to medium sized project teams. The other issues cited above (less design and control) present special challenges when using a RAD approach for very large scale systems.