Re: The waterfall cycle...
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.
Re: The waterfall cycle...
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.
Re: The waterfall cycle...
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