The Utilization of Software Engineering Development Principles

Question

Being a CS student I've had to take a course in basic software engineering. I was a little curious to find such elaborate "software development processes", like the spiral model, the waterfall model, et cetera. Some of these methodologies seem a little antiquated to me and, after speaking with several employed developers, I can't seem to find anyone who actually adheres to these models.

Does anyone here have experience working under the guidance of these models? Were they useful to you and your team during the development of your product? Or are these models just some way to communicate a sense of progression to interested parties outside of the development team?

Answer 1

I find it very hard to believe that a development team of any real size would not follow a development process model. It might not be one of the 'classic' models that you learnedin school, but right now you hear a lot about Agile software development models like SCRUM and XP a lot (or you should if you talk to anyone employed in the industry).

There are a ton of companies currently exploring how to move from the more antiquated models to the hot new contenders, but still using their old methods.

In a professional environment you must follow some process in order to predict delivery dates and ensure the quality of what you are delivering. Which method to use is a great (and hotly contested) debate.

I personally believe that the only 'best' model is one that you base on certain principles that the development and management teams can agree to, and then built iteratively over time through retrospectives on the work you have accomplished together as a team, building processes around areas where you are weak, and avoiding process in areas that work well for your team.

Answer 2

For years people have been trying to come up with a blueprint that will produce successful software products\projects. A lot of money has been made around writing books, presentations, courses, etc. on the latest blueprint, that when followed will create software faster, cheaper, and bug free. The one thing that you will realize is there is not a one size fits all for building software, no matter what a professor, manager, etc. will tell you. Each software project is going to be different than the last and may require different tools, languages, processes, and even people to deliver it successfully. This is one of the reasons this field is so different than other fields and makes it so exciting at the same time.

Answer 3

You're taking basic software engineering courses which gives you a broad overview on different techniques. When doing more advanced courses, you'll learn to understand various nuances and come to learn when the evil waterfall model is actually a good model to be used. Everything depends on the context in which you are developing. For example, waterfall is acceptable in situations where extremely similar projects have been done by the team numerous times in the past. (There is no risk of change involved, as everyone knows what to expect.)

In practice, some places use elaborate processes. Some places misuse elaborate processes. Some places use agile processes. Some places misuse agile processes. Some places don't use processes. It depends.

In any case, methodologies are a good thing as it keeps everyone working in a focused, measurable fashion. What's bad about methodologies is when you start following them blindly and don't stop to think about your context and your needs. What's even worse about methodologies is when you don't understand what you're doing, but you claim you're following one.

That said, the best tip I can say is to learn as much as you can about the different methodologies while you can and don't expect to find a golden solution to your problem by following a methodology.

Answer 4

As sad as it may sound Waterfall is still VERY much used in the industry in general. So yes they do exist.

Answer 5

I think what you're missing is that the various development processes (such as those described in Rapid Development) are abstract ideals. They each put maximum emphasis on certain aspects of the development process (ability to ship on time, customer feedback, etc.). In practice most actual development processes will comprise some mixture of these ideals, balancing the trade-offs and benefits of the ideals.