What is the Rapid Application Development Process?
Rapid Application Development, or RAD for short, is a methodology for fast application production using an iterative software development process. So, what is RAD in simple words?
First comes the creation of a quick and dirty basic prototype version of an application that includes all the desired functions of the end product. Then iterative changes refine these functions until the end product works as required. The process depends on functions being coded as separate interconnected modules to prevent a change to one function affecting any others. These iterative changes are driven by the results of testing and evaluating each prototype version and collecting feedback from stakeholders. Typically, these are the customer and a carefully selected set of representative users. The result after the iterations are complete is a product that both the customer and users want. Iterations are unplanned; the drivers for scheduling and scope of changes are the feedback from the previous iteration. The interactive refinement allows customer requirements to be modified or new requirements added during the development process with minimal impact.
Why was RAD needed?
RAD was born as an alternative to the traditional waterfall development methodology. The problem was that the customer would have no visibility of the code until the entire development process had finished. This approach often caused frustration and delays when the application fulfilled its requirements but didn't do what the customer wanted. Errors and ambiguities in a specification often wouldn't emerge until the customer saw the first deployed version of the application. At this point, it was too late to make a quick change, meaning customer disappointment.
When is RAD useful?
RAD was the solution for projects with unclear or evolving requirements. It takes the pressure off the customer to have a complete and unambiguous specification before a development project could begin. This process is perfect for applications where the problem needing solving isn't fully defined. The RAD process will put a makeshift application before the customer or the users and influence its evolution. It will enable the stakeholders to turn the prototype into something that people want or need. RAD is also helpful where the feasibility of the original idea is uncertain. It will enable the developers to try out a concept to see if it will work in the real world.
However, it's not suitable for all projects.
For example, an application with firm requirements that will not change will offer only a slight advantage over alternative methods such as Agile. Likewise, an application where the customer will not actively evaluate prototypes will be at a disadvantage when following the rapid application development methodology. Also, RAD is entirely unsuitable for high integrity applications. Here, software, where formal development processes supported with comprehensive verification and validation evidence, is required.
Typical examples include:
Business-critical applications (banking services)
Health-critical applications (medical monitoring applications)
Safety-critical applications (nuclear power station control applications)
Modularization - The Key Feature Behind RAD
A fundamental principle behind implementing RAD is modularization. This is the process of separating the application's functionality into independent and interchangeable modules. Each module has a defined purpose, with a specification of the interfaces between modules. Developing these modules may be performed sequentially or in parallel. The process is flexible. Each module has defined functions and interfaces. This feature allows modules to be individually developed as necessary without dependency on other modules. A RAD project based on developing an existing application can pull in all the relevant modules and focus on the differences. For example, a typical application has a core of standard functions with differences concentrated around user and data interfaces. Multiple applications can then reuse these core functions. This ability offers significant productivity advantages and cost savings.
Modularization brings many other benefits:
Each development iteration can choose which modules to refine in that cycle
Each module can be self-contained, so an error in the code in a module shouldn't impact other modules
Libraries of standard modules allow for easy reuse
Building applications from ready-made modules is quick and straightforward
Modularization supports open-source development
Rapid Application Development Phases
Developing any application begins with the scope of what the application will do. This stage starts with defining essential information, including the following:
The purpose of the application, its aims, and goals
The target markets
The target audience
Positioning in the marketplace
The customer's wish list of features
This stage encompasses the initial research steps to prepare for the design and development activities. In addition, it requires the gathering of all the information necessary to inform the design activities. See here for our guide to project scope. Successful application development requires an understanding of the needs, expectations, and demographics of the target users. Without this knowledge, the application will fail. The result of this stage is an initial set of application requirements covering its features, interfaces, and performance constraints. See here for our guide to functional and non-functional requirements. The customer may look to prioritize the requirements to aid the development process. For example, categorization into must-have and nice-to-have features can allow focusing of the prototyping process.
The development process then follows the following five phases:
These continually repeat until the development is complete. The definition of what 'complete' means is one element that needs agreement in the scoping stage. See here for our guide to user acceptance criteria.
The team will derive application requirements from the information gathered during the scoping phase on the first pass. The team will then refine the application requirements for subsequent development iterations based on feedback from the developers and testers, the customer, users, and other stakeholders.
The team will create a design from the application requirements on the first pass. The team will then refine the design for subsequent development iterations based on feedback and application requirements refinement.
The team will write and reuse code to implement the initial design on the first pass. The team will then refine the code for subsequent development iterations to resolve bugs and incorporate the refinement of the design.
The test team will conduct verification testing on each iteration to confirm that the code has no significant bugs. The aim is to check the code will execute sufficiently robustly to allow deployment. Resolution of all significant bugs will be necessary by looping back to the design or implementation stage for fixing. There is no point in giving the customer a non-working application to evaluate. Minor bugs can be recorded and resolved in the next iterative cycle.
At the end of each iteration, code is deployed to the live environment for evaluation by stakeholders. These must include the customer as well as representative users. Users can be drawn from the development team if necessary. The test team will conduct validation testing on each deployed version of the application. The aim is to check the code to see where it does not fully meet the requirements. This testing may also pick up bugs due to differences between the development environment and the live environment. The rapid development cycle then jumps back to the requirements phase to start the next iteration.
Advantages and Disadvantages of Using RAD
The rapid application development model is fantastic where its use is appropriate, and it has plenty of advantages over other development processes such as the waterfall model or Agile development. However, it does also have disadvantages. We've listed the pros and cons of the rapid application development methodology below.
Cost-effective for unstable requirements
Requirements can evolve dramatically during development iterations
Allows identification and incorporation of new requirements during development
Allows fast gathering of user feedback
Ideal for user interface development based on user interaction
Suitable for determining the feasibility of a concept early in the development lifecycle
Allows risk reduction by trying ideas to see if they work before committing to their development
Allows early error identification
Shows demonstrable progress to customers
Fast time to market for a proof of concept prototype
A modular approach compartmentalizes functionality increasing maintainability
Ideal for reusing code from previous products and changing/adding functionality
Forces a modular approach that may not be appropriate
Requires effort to define and maintain the module structure
Undocumented dependencies between modules can cause problems
Scalability constraints as larger applications exponentially increase the complexity
Requires effective and responsive stakeholder communications
Dependency on developer skill
Bug investigation is complex when multiple functional areas are simultaneously modified
Documentation may be left behind, reducing maintainability
Rapid Application Development vs. Agile
RAD is a well-established process compared to Agile, but both now have an excellent pedigree behind them. Both follow an iterative approach to development with frequent stakeholder engagement, quickly putting a functional application in front of the customer.
However, there are significant differences:
Agile focuses on formal processes and a planned, structured approach that breaks down an application into individual features.
These features are prioritized and developed in sequence using sprints to schedule development, building up the final application in a series of iterations.
Its goal is to deliver a minimum viable product as quickly as possible without compromising quality.
RAD focuses on the informal production of a rough-draft prototype that follows iterative refinement based on feedback.
This makes the process much more responsive and dynamic.
As a result, it can adapt to significant changes in requirements during development.
The following table summarizes the key differences:
Deployment of each application version does not follow a planned timetable
Deployment of each version follows a strict timetable defined by the sprint schedule
Delivers a crude prototype implementing all features that slowly refine
Delivers a few polished features in a minimum viable product (MVP) that increase in number over time
The customer can evaluate the prototype after every development iteration
The customer can evaluate the application at the end of each Agile iteration phase
Changes for each iteration are determined by feedback from the previous iteration
Planning of features for the next iteration is fixed in advance
Suitable for any application that uses modularizable software
Ideal for any application that can be incrementally implemented
Ideal for the rapid development of small projects
Ideal for the fast development of large projects
The initial user interfaces will be crude, and not all interactive features may work correctly
When available, user interfaces will represent the final implementation. However, not all features may be implemented
Suited to small, experienced, and closely integrated development teams
Can easily manage large development teams, supporting collaborative working across geographically dispersed teams
Rapid Application Development Tools
There are plenty of development tools available that are suited to RAD projects. Which one is best depends on the type of applications under development? Key questions to consider are:
What programming languages will developers use?
What platforms must accept the deployment of the application?
Does it support tracking progress, issues, dependencies?
Does it provide traceability between requirements, design, and code artifacts?
Is it intuitive to use?
Below are some of the more popular tools currently available, listed in alphabetical order. This isn't a definitive list or a recommendation, just helpful information to get you started.
Alpha Anywhere is a platform-independent data integration tool
App Press is a web-based no-code tool suited for UI heavy applications
Buddy is an effective automation tool that supports continuous integration and continuous deployment
Cloud Foundry is a code-based tool with broad compatibility, including Kubernetes integration
EachScape is a mobile application tool
EASA supports independent code applications using Excel sheets
FileMaker is a cost-effective cross-platform cloud-based tool
Kissflow enables RAD with little programming knowledge
Microsoft PowerApps is an integrated solution for developing Windows-based applications
Nintex process automation management tool that can support RAD
Oracle Application Express supports RAD for secure data analysis and monitoring applications
QuickBase has a simple interface that requires minimal programming knowledge thanks to its drag-and-drop features
Quixy is a codeless tool that uses templates to build up functionality
RapidClipse is a cross-platform tool for client-server web applications
Salesforce Lightning is an intelligent and customizable cloud-based solution
Useful Tips when Following a RAD Process
Here are a few tips based on years of experience to help get you up to speed and hopefully avoid some of the common problems that RAD teams encounter:
To prevent problems during development, focus initial development effort on modularizing the application with clearly defined functions and interfaces for all modules.
Documentation of the dependencies between modules is essential to prevent unwanted consequences to any changes.
The initial prototype version must implement sufficiently robust functionality to allow the customer and users to interact and evaluate basic concepts. Too many problems and they will give up, and you won't get helpful feedback.
If a development cycle requires a change to a module's functionality, all other modules with an identified dependency should be reviewed and updated accordingly. This will prevent unexpected behavior in previously working functions.
If a development cycle requires a change to a module's interfaces, all other affected modules must be updated accordingly. Failure to do so will result in problems when the modules interact.
The number of modules changed in each development cycle should be kept to a minimum to help post-deployment bug investigations. Too many wide-ranging changes and the investigator won't know where to start.
The process for deploying each prototype for obtaining feedback requires planning and management to prevent any delays in obtaining responses. Slow feedback will cause delays to the overall program.
In the absence of formal design and code documentation, the code should include sufficient commentary information to allow a programmer to understand and maintain the code with minimum effort. This will ensure that anyone else can understand the code if the original developer is unavailable.
At the end of the development process, ensure that each code module has adequate documentation to enable different developers' quick and easy reuse in future projects.
The Bottom Line for Using RAD
Rapid application development has always been a popular choice for delivering prototype code quickly to evaluate application concepts and feasibility and on the fly development of requirements. Its main benefits for application development are the speed and flexibility to accommodate customer changes during the development cycle cost-effectively. In addition, the modular approach to code structure also brings maintainability and reuse benefits.