The waterfall cycle...

When I have some free time I tend to think and philosophize. Today is one of these days.
I'm thinking about the efficiency of software development methodologies, in particular the waterfall ones.
When you read books they seem to treat all kind of software equally. But I know there are different kinds of software... for example. games, word processors, a marketing applications, etc.
My questions are, should we develop all kinds of software using the same methodology? (<analogy> do you design bridges and houses using the same techniques? is there any differnce?<analogy>)
If we used specialised methods for each kind of software would they be better quality and developed faster and cost less?
This is how I see the waterfall cycle for business applications:
. problem/need
. gathering requirements (interview users)
. analyse requirements and create a model of situation
. design a solution (software)
. code
. test
. run on user's computers.
You guys who develop embedded software or games, do you see it the same way?

Most successful software follows that path no matter what.

1. problem/need - Every software that is going to be successful will solve a problem or need. Games solve the need to have fun, and business apps solve business needs.

2. gathering requirements (interview users) - Business apps need to get information about what is the problem. Games are almost unique in this area, but they do have some requirements gathering as to what the market wants.

3. analyse requirements and create a model of situation - I think in theory, this is really rolled in with number 2.

4. design a solution (software) - You must design a game, otherwise it won't be successful. Same holds true for a business app.

5. code - All programs need this.

6. test - All programs need this as well.

7. run on user's computers. - Only trial programs won't be ran on a computer, so this also applies to all programs.

Quote:

---

Originally posted by Mutant

You guys who develop embedded software or games, do you see it the same way?

---

Choosing a methodology depends on the type of software and duration of the project. You can not apply one methodology to all type of projects, it just wont be efficient.

A lot of the project which are designed using VB and C#/VB.net to some extent are mostly RAD project.

The waterfall model is generic enough that your analogy holds. When building a bridge or a house, in both cases you analyze the terrain where you build it, the specific requirements of what you want to build (architectural plans for the house, width, depth and content (water or nothing) of whatever you want to span for the bridge), decide on a way to build it and then build it.

The analogy between designing software and designing bridges is erroneous. It would be accurate if, while building your bridge, the number of lanes required changed, the building material changed, the span of the bridge changed, the material to be used changed, changed back, and then changed again.

You get the point.

Look into Extreme Programming, a modern approach to grapple with the challenge of software design. Esp. pay attention to the mantra: release early, release often.

IOW, be concerned with a high level of interaction with your client during the design process.

The 7 steps hellswraith pointed out are better suited for building a bridge where the requirements never change. This is usually not possible and will lead to missed deadlines in a normal software project.

Another mantra of extreme programming: requirements always change.

Extreme programming also has its downsides; driving people crazy is one of them... but it definitely has its advantages also...

Due to the incomplete science that software development seems to be, sticking to one methodology probably isn't the best solution. Even if it all seems to be taking the same general direction anyway. Actually, I've seen more projects degrade to a build-and-fix model or a hybrid build-and-fix/waterfall model more than anything else. This shift usually happens in the testing phase, when the customers start to see the software and raise issues that should've come up before. Then it becomes "Can we add this?" "Oh SURE!" Build - implements: "Well, can we add this?" "Oh SURE!" Build - implement... etc. Of course this may be a sign of bad requirements gathering, but it could also result from flaky customers. And since they hold the money... well... sometimes there's no choice. And no amount of Software engineering training can challenge flaky customers who hold $$$ over your head.

The best thing is to have a basic understanding of all the main methodologies and apply this knowledge to each project. Waterfall is pretty general to cover most projects (my employer requires management approval to deviate from it); what usually differentiates a project is risk: the need to comply with some governmental regulation or may impact health or well-being (e.g., programs tied to medical devices). But this still can usually be handled by the waterfall model.

Ed Womack
http://www.getmilked.com