Extreme Programming
Dynamic Systems Development
Crystal Methods
Feature Driven
Lean Development
Joint Application Development
Information Technology Infrastructure Library
Agile Software Development
Rational Unified Process
Rapid Application Development
PRINCE2
Scrum
Adaptive Project Framework
Waterfall
Spiral

Rapid Application Development

Rapid Application Development (RAD) is a development methodology that focuses on building software applications very quickly, accepting compromises in usability in return for on time delivery.

Here is brief discussion of each of the key components of RAD.

Prototyping

A prototype is a mocked up simulacrum of the product created using any technology that gets something useable as quickly as possible. Prototyping methods usually trade off efficiency and cost against production time.

The purpose of a prototype is to form meeting point between the non technical customer and the domain ignorant developer. It is a form of communication which produces an almost perfect meeting of minds.

In reality the prototype usually exposes and resolves differences not only between customer and developer but internally within the customer and developer organizations.

With a signed off prototype it is felt that the project can rocket ahead confident that it is going in the right direction.

Iterative Development

It may seem contradictory that having developed a prototype development should now proceeded in cautious steps but the reality is that a prototype can not represent all the requirements of a design. Assumptions about performance and levels of finishing often cause problems at the end of a project unless caught early.

Also there is lots of scope for implementation problems even with a prefect prototype and producing intermediate versions avoids the problem of large sub systems being developed separately and then not working when brought together at the end.

Time Boxing

This means delivering an iteration on time regardless of how much has to be 'shaved' to do it.

This has the advantage of stripping the fat from the feature set and focussing developers minds on the letter of the specification rather than taking off on some elegant fancy.

It also ensures their full participation when each iteration is being planned because they are in no doubt that the deadline is solid and their failure to deliver will be all to apparent.

Team Members

RAD requires small teams of experienced and fully engaged members with many skills. The team must include representatives from the customer/sponsor so that feedback is built into the day to day process. The team should also include managers. Management is not an external function of a RAD team it is built into its makeup.