Is rapid application devolpmt similar with software development method?

Rapid Application Development (RAD) is generally something you'd use for creating a demo or prototype. You'd want a user-friendly interface, probably with GUI capabilities so you can produce a working model quickly with low development cost.

By contrast, the software development cycle goes through a more stringent quality control and testing phase. You want your end product to be error and bug free. And while there is usually a deadline of some kind for completion, the ultimate goal is a functioning product rather than one thrown together ASAP.

RAD(rapid application devolpmt ) is not the next step in evolution beyond Software developement. RAD is not stupid and lazy compared to Softtware developement. They both have their place. Here鈥檚 how to decide which you need to favor in your roll-your-own process:

1. Do you have a clear vision within your team for what the product will be?
2. Is there a very solid understanding of the problem domain, within your team?
3. Do you have stakeholders and/or investors outside the core team who demand to control the design of the product?
4. How much overlap is there between the software people and the domain expert people in your extended team?

RAD works really well if the answers to 1-2 are 鈥渘o鈥? 3 is 鈥測es鈥? and 4 is 鈥渘ot a lot鈥? It helps a lot to build something that you don鈥檛 fully understand if you have some realistic prototypes to let domain experts and stakeholders fiddle with as you build it.

The disadvantage of RAD can be that the amount of rewriting effort is high. That may be unavoidable but it might be better to do high-fidelity page schematics (basically, a large number of comps) or even an HTML mockup instead of wireframes, rather than actually trying to make it all work before your stakeholders and domain experts have had a few iterations to poke and prod at.

Software dev. works well if you have a pretty darn good idea of what you want and you have the talent within the team to make decisions about the stuff that hasn鈥檛 occurred to you yet. At some point you absolutely have to make decisions about the lowest level functional and UI details that you鈥檇 rather not have to deal with, but computers can鈥檛 fill in the gaps in your high level design. The point of S/w dev. is to have all those conversations and design sessions in the cheapest medium possible, which is usually some words in a word processor about what it will do, and some annotated low fidelity pictures that describe how it will look and feel.

The disadvantage of S/w development is that you can get pretty far down the wrong path with no feedback. Stakeholders get impatient when they see that you鈥檙e producing a bunch of requirements gibberish instead of writing code. Wireframes and comps can help somewhat but that depends largely on the level of imagination that the stakeholders have, and their trust in your good judgement about design, and their experience with software applications that you consider to be well designed. Non-software people who just hired you aren鈥檛 going to have much patience for a 4 month design phase on their nickel, especially if you keep emailing them 150 page .doc files full of use cases that they鈥檙e supposed to review.

In my case the answers to the 4 questions above are 鈥測es鈥? 鈥測es鈥? 鈥渘o鈥? and 鈥渁 lot鈥? Those are the opposite of the answers that point to RAD as the right choice, so I鈥檓 using Software dev. this time.

hope this helps
Cheers:)