What is Rapid Application Development (RAD)?
Rapid Application Development is an agile framework focused primarily on rapid prototyping of software products, frequently iterating based on feedback, and continuously releasing updated versions of those products to the market.
The RAD model is comprised of four phases:
- Phase 1: Requirements planning
- Phase 2: User design
- Phase 3: Rapid construction
- Phase 4: Cutover
What is the History of Rapid Application Development?
The Rapid Application Development method was designed as a direct response to the then-dominant waterfall approach to software development. The waterfall methodology was built on planning and sequential design processes. The RAD concept was officially introduced to the public in 1991 with the book Rapid Application Development by James Martin.
What are the Strengths and Weakness of RAD?
RAD’s strengths include:
- Takes advantage of the nature of software, which allows for rapid and low-cost iteration, to allows organizations to quickly and continuously improve their products
- Allows teams to break down large projects into smaller, discrete, actionable tasks
- Users can receive working products in less time
RAD’s weaknesses include:
- Requires highly skilled development team and product designers
- Requires user involvement throughout each stage of the project
- Does not work as well with large-scale projects
Should You Use Rapid Application Development?
The RAD approach offers strong benefits to a team that is both familiar with the agile philosophy, has a relatively small project to roll out, and has customers or users willing to commit to being a part of the entire development project.
But, there are several situations in which RAD may not be the best framework. For example, if your company needs to roll out a large-scale software development project, if you do not have enough skilled developers and designers on staff, or if you aren’t sure you can secure a commitment for deep involvement from your users to provide you feedback for the iterative process. In either of these situations, RAD may not be right for your team.
