Forget about waterfall ! let's do Rapid Application Development

What is RAD (Rapid Application Development)

At KDS, we do take on client product development projects, mostly software development projects. And to have a fast turn-around time with product prototypes for initial and POC (Proof-Of-Concept) demonstrations, we swear by the methodologies of RAD and SCRUM to make our lives (well, only the work life) easier and more manageable.

Rapid application development is a form of Agile software development methodology. Unlike Waterfall methods, RAD emphasizes working software and user feedback over strict planning and requirements recording.

The key benefit of a RAD approach is fast project turnaround, making it an attractive choice for developers working in a fast-paced environment like software development. This rapid pace is made possible by RAD’s focus on minimizing the planning stage and maximizing prototype development.

In other words, RAD is less talk, more action. and lots and lots of testing, plus gathering user feedbacks to improve the overall functionality and usability.

Comparing to the good old (may be not so good anymore) Waterfall model,


where each of the development phase is dependent of each other. RAD emphasizes on the following methodology:

1. Figure out the requirements
• Every piece of software or app is built for a reason. RAD starts with figuring out what your project is supposed to accomplish.
• Get your users, developers, and designers into a room (or on a conference call) to discuss the purpose of the system you’re about to build and test. Once you’ve figured out the system requirements, you should also come up with an estimated project timeline. And, of course, you’ll need to figure out how you can create a system within the confines of your budget.
2. Build prototypes, on the double!
• RAD stands for rapid application development, so it shouldn’t be surprising that your team will start working on building functional models right away. Once you’ve got the requirements, deadline, and budget figured out, your engineers and designers will create and improve upon working prototypes until you’re ready to unveil your finished product.
3. Get user feedback
• With RAD, your users should already be familiar with most, if not all, parts of your finished product before you announce your project’s completion. Like most Agile methodologies, RAD calls for ongoing collaboration between your team and users in order to create a high-quality system. Your users will be the ones providing feedback so that you can tweak and improve your prototypes, creating the best possible finished product.
4. Do it again!
• You’ll repeat steps two and three until you feel like your project is done or until you have all working parts assembled together to meet a client’s requirements.
5. Test, test, test
• You’re not ready to pronounce a project complete until you’ve made sure that it works the way it’s supposed to. Run your system through different scenarios and make sure all of the moving parts work together to accomplish the system’s goal.
• In addition to your engineers testing and retesting your code, this will involve more user testing before you take your system live.
6. Go present your system!
• Once you’ve got a working system, pat yourself on the back! That’s not an official part of RAD, but your team has worked hard to get your project done rapidly. They deserve the congratulations. Now you’re finished… until the next update is required, of course.

During development planning, product managers, key stakeholders, and developers can use the following steps to better plan out the RAD cycle before developing the product:

1. Requirements planning phase – combines elements of the system planning and systems analysis phases of the Systems Development Life Cycle (SDLC). Users, managers, and IT staff members discuss and agree on business needs, project scope, constraints, and system requirements. It ends when the team agrees on the key issues and obtains management authorization to continue.
2. User design phase – during this phase, users interact with systems analysts and develop models and prototypes that represent all system processes, inputs, and outputs. The RAD groups or subgroups typically use a combination of Joint Application Development (JAD) techniques and CASE tools to translate user needs into working models. User Design is a continuous interactive process that allows users to understand, modify, and eventually approve a working model of the system that meets their needs.
3. Construction phase – focuses on program and application development task similar to the SDLC. In RAD, however, users continue to participate and can still suggest changes or improvements as actual screens or reports are developed. Its tasks are programming and application development, coding, unit-integration and system testing.
4. Cutover phase – resembles the final tasks in the SDLC implementation phase, including data conversion, testing, changeover to the new system, and user training. Compared with traditional methods, the entire process is compressed. As a result, the new system is built, delivered, and placed in operation much soone

For those who are the masters of SCRUM methodology domain, you will see that RAD does not interfere with SCRUM. matter of fact, SCRUM can be a great complement and guideline to RAD.



To summarize, by reducing planning time and emphasizing prototype iterations, RAD allows project managers and stakeholders to accurately measure progress and communicate in real time on evolving issues or changes. This results in greater efficiency, faster development, and effective communication.