School of Information Systems

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:

  1. Define Requirements:

The developer defines what is needed in the system.

  1. Prototyping

After all the requirements are set, developers start designing and making the prototype.

  1. 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.

  1. 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.

Wiza Teguh