Rapid Application Development

This software development methodology was developed as an answer to the clumsy and slow models like the waterfall method. The problem with most application development models is that it takes so much time to deliver a working product that the requirements are often changed on the way, making the initial design useless. Another problem is the need to define all of the requirements before work begins; even if your programmers are top notch professionals.

According to the RAD methodology concept, most of the attention is given over to creating a technological process in order to create quality software quickly and efficiently.

Some basic principles of the methodology:

• All efforts and resources are targeted to minimizing the development period.
• Building a prototype in order to verify requirements with the client.
• The development cycle is based on the clients' requirements.
• Re – using built modules from prior projects.
• Project programmers cooperate and work simultaneously on several tasks in various areas.
• Project management is crucial for minimizing the development cycle.

Let's see where RAD is better than some other common methodologies:

Agile Software Development: prevents over functionality as a result of small releases in short intervals until the software is ready. The danger with this method is that if you don't distribute the functionality evenly between update sessions you might put yourself in a situation where you can't actually release at the same speed. Another problem is that agile development produces little documentation in the process and that means a lot of work after finishing the project.

Extreme Programming (XP): frequent requirement cycles minimize the cost of changes. The design is defined and refined as the project progresses, which is efficient, but creates a problem: if the design documentation is not maintained properly it will cause problems in the future. The basis for XP programming is that programmers work in pairs. This is not always possible or even viable since not all programmers get along.

Scrum: divides the whole project into simple and small tasks which are carried out by the members of the team. Such division gives the opportunity to measure daily progress and to correct requirements. The work is not centered since everyone is doing a different piece of the project so there can be difficulties in pulling the project together.