IBM proposed the Rapid Application Development Model in the 1980s. The usage of strong development tools and methodologies is a key component of this strategy. 

This model can be used to implement a software project if the project can be broken down into small modules and each module can be assigned to its own team. Finally, these modules can be joined to create the final product. 

As indicated in the picture, the development of each module incorporates several essential processes of the waterfall model, including analysing, designing, coding, and testing. 

Another notable feature of this model is the short time limit for delivery (time-box), which is typically 60-90 days.

The projects also include the usage of strong development tools such as JAVA, C++, Visual BASIC, XML, and others. 

What exactly is RAD? 

Quick application development is a software development process that prioritizes rapid prototyping over extensive planning. A prototype is a working model that functions in the same way as a product component. 

The functional modules are produced in parallel as prototypes in the RAD approach, then combined to create the whole product for faster delivery. Because little thorough planning is done ahead of time, it is easier to accommodate modifications into the development process. 

Small teams of developers, domain experts, client representatives, and other IT resources work progressively on their components or prototype in RAD projects, which follow an iterative and incremental methodology.

There are four basic phases in this model

1. Needs Planning

This includes brainstorming, task analysis, form analysis, user scenarios, FAST (Facilitated Application Development Technique), and other strategies for eliciting requirements. It also includes the whole structured plan that describes the key data, the methods for obtaining it, and the subsequent processing of the data to produce the final refined model.

2. Description of the User 

This phase entails gathering user feedback and constructing a prototype with development tools. To put it another way, it entails a re-examination and validation of the information gathered in the initial phase. In this phase, the dataset attributes are also identified and clarified. 

3. Construction

The prototype is fine-tuned and delivered at this phase. It entails converting process and data models into a final working product using strong automated tools. This phase also includes all necessary modifications and additions.

4. Cutover

All interfaces between independent modules built by different teams must be thoroughly vetted. Testing is made easier by the use of powerfully automated tools and subparts. After that, the user does acceptability testing. 

Building a quick prototype, presenting it to the customer, and receiving feedback are all part of the process. The SRS document is created and the design is completed after the customer’s approval.

Advantages 

• The use of reusable components helps to shorten the project’s cycle time. 
• Customer feedback is available during the early stages of the project. 
• Cost savings because fewer developers are required. 
• The use of strong development tools results in higher-quality goods in a shorter amount of time. 
• The project’s growth and development can be tracked at different phases. 
• Because of the small iteration time spans, it is easier to handle changing needs.

Disadvantages

• High-skilled experts are required to employ powerful and efficient tools. 
• The lack of reusable components might contribute to project failure. 
• To complete the project on time, the team leader must collaborate closely with the developers and clients. 
• This model can’t be used for systems that can’t be modularized properly. 
• Throughout the life cycle, customers must be involved. 
• It is not intended for small-scale projects because the expense of adopting automated tools and processes in such circumstances may exceed the project’s total budget.

Applications

• This paradigm is appropriate for a system with well-defined requirements and a quick development period. 
• It’s also appropriate for projects where requirements can be modularized and reusable components can be developed. 
• When current system components can be used to construct a new system with few changes, the model can be used. 
• This model is only applicable if the teams are made up of domain experts. This is due to the fact that necessary knowledge and the capacity to employ powerful approaches are required. 
• When the budget allows for the use of automated tools and procedures, this approach should be adopted.