RAD is an adaptive software development approach where a software prototype is rapidly updated based on user feedback and iteratively delivered until it meets all client requirements.
In the RAD model, the software development team and the client (this may be an internal client) work together to define the scope of the project. The client communicates their project goals, expectations, and issues that need to be addressed by the software. The development team evaluates the requirements and finalizes an agreed set of features to be delivered.
Once the requirements are finalized, developers design modularized prototypes that can be repeatedly refined to incorporate customer feedback and change requirements until it meets all client expectations.
During the RAD process, development happens rapidly because most of the blockers and issues are usually identified at the design phase and eliminated in advance. The continuous client engagement with the development team increases customer satisfaction. Hence RAD is known to be a software development model that reduces the risk associated with the software development process and ensures the delivery of high-quality software during a short time.
RAD framework consists of four main phases.
Requirements planning: The software development team and the client define the scope of the project and finalize the requirements.
User Design: Developers design the prototype and continuously refine it to incorporate client feedback until it meets expectations.
Rapid Construction: The software developers rapidly build the designed prototype into a functional software, iteratively updating it to incorporate feedback.
Cutover: The prototype is finalized, and goes into production. Changes and improvements can still be introduced iteratively following the RAD model.
The RAD model was introduced as an alternative solution to the traditional waterfall software development life cycle (SDLC) model.
The initial solution was developed by Barry Boehm, and was known as the "spiral model". Taking inspiration from Barry's work, the RAD model was formally introduced to the software industry by James Martin through his book "Rapid Application Development" which was published in 1991 while he was working for IBM.
While the RAD model can be a highly effective agile framework, it does have some limitations.
For example, the RAD model is not recommended when customer goals and requirements are unclear, and when the design cannot be broken in a modular way.
In the RAD model, it is important to clearly and precisely identify requirements before designing the prototype. This requires team members with excellent domain knowledge, which may not always be available, particularly in smaller businesses that may be reliant on external experts.
Rapid iteration: RAD empowers developers to develop quickly and iteratively, by prototyping advanced software in a modular way. Ultimately, this means that users can get a functioning product in less time.
Reusability: This approach reduces rework by encouraging the reusability of development components.
Minimizes risk: RAD prevents software from failing entirely as the functionality of the software prototype is reviewed and tested during earlier delivery cycles.
Fewer integration issues: This approach has fewer integration issues because integration takes place from the very beginning, and the new features and improvements can be introduced to the prototype on the go.
Requires modularity: One of the main drawbacks of this model is that it can only be applied to software systems that can be modularized into small components. Typically this means that the RAD model only works with small to medium-sized projects. It tends to run into issues with bigger, more complex setups.
Requires a high skill level across the team: The success of a RAD prototype relies on the ability of designers and developers to deliver precise work at pace. This means that RAD might not be the best model for teams without the level of expertise needed to do this.
Demands continuous user involvement: The nature of the RAD model demands ongoing user feedback in order to be able to iteratively improve on prototypes. Many businesses may not be able to secure user engagement throughout each stage of the project, meaning that iterations are subject to internal bias.