The Rapid Application Development process defines a programming approach that uses a continuous development environment.
The method of Rapid Application Development (RAD) was devised in the 1980s by Alex Balchin, Barry Boehm, Brian Gallagher, and Scott Shultz and introduced an innovation in the development of new software. In the nineties, this method enjoyed increasing popularity.
RAD is still used in a variety of ways by numerous service providers in the development environment. In contrast to the previously used methods, Rapid Application Development made it possible to effectively develop comprehensive and performance-oriented software in a shorter time.
RAD envisages a prototypical procedure in which requirements for software are collected and converted into executable code as quickly as possible. This is presented to the client at a relatively early stage in order to identify misunderstandings regarding the requirements as well as additional requirements. The changes will be implemented in another version . These cycles are repeated until the client is satisfied with the software and accepts it.
The classic method
Due to the methodology used, RAD differs significantly from the cascading waterfall model used up to this point. With this classic process, each phase of the development formed an independent unit; the next step could only be tackled once such a unit had been completed. As with a waterfall, it was no longer possible to return to a previous unit.
In the first phase, for example, the software’s requirement profiles were coordinated between the client and the contractor. The actual programming could only start after these requirement profiles had been fully evaluated. It was no longer possible to add or change the requirement profiles in the running system.
Every step in this system was designed to avoid mistakes. Accordingly, the software development took place slowly and with great expenditure of time and energy. Ignored errors or incorrect requirements can quickly cause a project in the waterfall model to fail. For this reason, software development according to this model took a relatively long time.
As with the classic method, the requirements are first drawn up as a rough list of basic requirements in the first process. Instead of refining and optimizing them more and more, the basic requirements are prioritized and processed by the developers.
The aim is to develop an executable prototype of the software as quickly as possible in accordance with the client’s basic requirements. For this purpose, software kits are generally used so that a fast software prototype can be delivered.
Consistent testing, development, and expansion
This prototype will be presented to the client and released for testing. In this step, the client can now supplement, refine, and optimize the requirements so that they can then be communicated to the developers.
Thanks to short development cycles, the new requirements and wishes can now be incorporated into the software. This process is now repeated until the software with all the desired properties is accepted by the customer.
