Two of the methods that you've cited are standard design methodologies.
The Rapid Application Design (RAD) methodology is actually a family of design methodologies. To some folks, RAD is a fancy name for the "coding cowboy" approach, the idea of "throw code at it until it works, don't bother with planning" which gives RAD an undeserved bad name. To most of the developers that use RAD, it means heavily involving the user in the design and testing of the application.
The SSADM methodology has been bureaucratized to the point that I find it unusable. It is the official standard methodology for the EU, but even the EU officials don't agree on what is required for a project to comply with the methodology. A methodology that has no formal definition, that leads to micro-management, and is administered by a government seems to be a recipe for disaster to me!
The Soft Systems method escapes me. I knew of something that was called that many years ago near Washington, DC that was named for a software development group based in that area, but I'm not familiar with it as a name for a methodology.
A consultant should use some formal methodology for any significant project. Without some kind of framework to plan the project around, there isn't any way to make meaningful estimates of what the project will cost, how long it will take, or how closely the result will match the requirements. Even if a consultant doesn't formally adhere to any particular methodology, they have to use something (even if they don't realize it!).
For More Information
- Dozens more answers to tough database design questions from Pat Phelan
- The Best Database Design Web Links: tips, tutorials, scripts, and more
- Have an Oracle or SQL tip to offer your fellow DBAs and developers? The best tips submitted will receive a cool prize. Submit your tip today!
- Ask your database design questions -- or help out your peers by answering them -- in our live discussion forums.
- Ask the Experts yourself: Our SQL, database design, Oracle, SQL Server, DB2, metadata, object-oriented and data warehousing gurus are waiting to answer your toughest questions.
This was first published in September 2002