The Use for Rapid Application Development (RAD)

ATAK Interactive, Inc is a big fan of RAD development (rapid application development) or rapid prototyping. We use this method a lot here at ATAK Interactive because there are many time we just need to build web applications where we know exactly what we want, we know how to do it, and we know what is expected from the business or program

So let me explain: The Rapid Application Development methodology was developed to respond to the need to deliver systems very fast. The RAD approach is not appropriate to all projects - an air traffic control system (or something really complex) based on RAD would not instill much confidence. Project scope, size, and circumstances all determine the success of a RAD approach.

A suitable development project for RAD would be a focused scope project where the business objectives are well defined and narrow; decisions can be made by a small number of people who are available and preferably co-located. The project team is smaller in size and the applications and architecture is well defined. Unsuitable for RAD - A broad scope project where the business objectives are obscure or broad, complex, and an extensive amount of data must be analyzed, designed, and created within the scope of the project. Many people must be involved in the decisions on the project and the decision makers are not available on a timely basis or they are geographically dispersed.

According to gantthead.com: The RAD method has a task list and a work breakdown structure that is designed for speed. However, the major difference in RAD is a set of management techniques that are optimized for speed. Among the most important are:

- Prototyping - an approach based on creating a demonstrable result as early as possible and refining that result. The refinement is based on feedback from the business, the eventual users of the system. Prototyping requires an open approach to development; it also requires an emphasis on relationship management and change management. There are dangers involved in starting prototype development too early and in starting it too late.

- Iteration - is a commitment to incremental development based on refinement. Prototyping and iteration go hand in hand.

- Time boxing - is a management technique that focuses attention on delivery above all else. Under a time box, scope can change but delivery cannot.

RAD processes are most useful in the requirements gathering phase of a project by giving users something to react to, rather than asking users to conceptualize their needs. ATAK often uses RAD to 'buy requirements' from the user but the prototypes themselves rarely make it to production (unless it's a trivial app) but are mostly used to document what the user wants and in the forms they would like. Once the analysis is complete and signed off, the designers can then design a product-worthy system that will closely meet the user's acceptance when ready for testing.

RAD is becoming more powerful both as a technology "proof of concept" tool, but also as a marketing swing to show the business how something could work, and let them "touch" the product before the true effort goes in to building it. It is amazing how the true requirements come out when the end users get to see what the development team "thinks" they want.

Skip this step, and you are building your application without a blueprint. Interesting to see what actually is delivered.

Reference: http://www.gantthead.com/process/processMain.cfm?ID=2-19516-2