Rapid Application Development: Introduction
In this article, I will share something about Rapid Application Development (RAD). This article will be divided into 2 parts.
In the 1980s, Barry Boehm, James Martin and others recognized this obvious point: software was not a raw mineral resource. They saw software for what it was: infinitely malleable. Boehm and Martin took advantage of software’s inherent pliability when designing their development models: The Spiral Model and the James Martin RAD model, respectively. Since then, RAD has evolved to take on other forms and acted as a precursor to agile.
Rapid application development is an adaptive software development approach that focuses more on ongoing software projects and user feedback and less on following a strict plan. The phases are generally the same with the traditional waterfall approach, but in RAD, it is summarized into 4 phases. Here are the phases of RAD:
- Define Requirements:
The developer defines what is needed in the system.
- Prototyping
After all the requirements are set, developers start designing and making the prototype.
- Absorb Feedback
Developers will show the prototype to the client and will ask for feedbacks. If it satisfied the client, then it’s time to finalize the product.
- Finalize Product
Developers in this phase will focus on improving stability and maintainability.
Here are some advantages of using RAD:
| Advantage | Description |
| Speed | With the waterfall approach, after the final delivery, client usually request changing, which may lengthen the project’s completion. With RAD, before finalizing the product, developers will have to ask for the feedback from client, to avoid any changes in the end. |
| Cost | In rapid application development, developers build the exact systems the client requires, and nothing more. In waterfall, IT risks building and fleshing out complex feature sets that the client may choose to gut from the final product. |
| Developer Satisfaction | In the traditional waterfall approach, developers work in silos devoid of feedback and positive affirmation for a product well-made. And when they finally get the opportunity to present their work to the client, the client may not roll out the red carpet for them. Regardless of how proud developers are of their work, if the client isn’t satisfied, developers don’t receive the accolades they so desperately seek. In RAD, the client is there every step of the way and the developer has the opportunity to present their work frequently. This gives them the confidence that when the final product is delivered, their work receives appreciation. |
Information about RAD will be continued on the next part of the article.
