Is the Waterfall software development methodology still viable?

Question

In my experience, it seems as though the Waterfall model has proven to be too inflexible and non-responsive to requirements changes to be considered a viable method in the modern world of software development. The growth and proven track record of more agile, iterative methods seems to indicate that there is no reason why anyone should be following a process of rigid blocks that assumes little to no changes from project inception to product delivery.

Is is the waterfall development methodology still viable for delivering software systems, with respect to time, cost, and quality?

Answer 1

The waterfall model that you are referring to was never intended to be a process model used on a real project. Instead, it is a strawman. It identifies the key phases and activities that exist in software projects and the most basic flow between them. This oversimplification of how to develop software is a flawed one, and it was even presented that way.

From the Wikipedia article:

The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce, though Royce did not use the term "waterfall" in this article. Royce presented this model as an example of a flawed, non-working model.

The paper discussed is titled Managing the Developement of Large Software Systems. In it, Royce does present that model on the second page. However, the text immediately below the pictoral representation goes on to read:

I believe in this concept, but the implementation described above is risky and invites failure.

He follows this with a discussion of the problems with testing following the "completion" of the development phase, and how failures here can lead to major redesigns and code changes, and how these can lead to major overruns in cost and schedule. Throughout the paper, he refines the original model to one that is indeed viable on a project. In the end, he ends up with a model that introduces prototyping, customer interaction, and refinement of artifacts - ideas that would eventually end up being critical to the agile movement that began in the late 1990s and early 2000s.

To answer your question: The Waterfall that you are asking about is not, and never was, a viable method to deliver software projects with a reasonable amount of quality on time and budget. However, there are other plan-driven methodologies that lie opposite of agile that can and do work on projects.

Answer 2

People don't use the text-book waterfall model and probably never have.

It is an idealized, theoretical construct whose purpose is to get you to think about the steps in systems development. It's main point is that you want the bigger changes to happen as early as possible, because you'll never have the time or money to make a big change once there's a lot of code built.

Despite the fact that it is more of a way of thinking than a process, it is still very much the way that many - probably most organizations go about building software (or houses, or submarines, or whatever else...).

In the real world, you don't have totally strict cut-offs between phases, and you sometimes loop back to prior phases for small sub-projects. What the methodology tells you is not that "these things are not allowed". What it tells you is "these things cost you money and/or time" - so try to avoid that in the future.

It's all well and good for Agile Snobs(TM) to look down their noses at "old fashioned" developers and their quaint, unworkable waterfall methodology, but the fact of the matter is that Agile is no panacea either. Some projects can't be built using Agile and a lot of teams that think they're Agile are actually just sloppy and unorganized.

The methodology is not the point. The point is to think about what you're doing and why you're doing it that way - and to get the most value to the customer in the shortest reasonable time.

Answer 3

The mythical waterfall process that is most often compared against agile never existed and therefore can not be considered dead. Real waterfall processes are still alive and well, and excelling at delivering on time on budget software that meets user expectations.

Answer 4

Perhaps a better way of asking what you're getting at is, "when is less iterative and more formal better?"

There are situations where this is the case:

• When the requirements won't change.

• When meeting new requirements is less important than hitting 100% of the original ones.

• When all the technology components are mature and well understood.

In a sense you can take the opposite of what might drive you to be agile.

Very few techniques are applicable everywhere. Very few have no use.

Answer 5

Yes it is very much alive, though today it's the more common "V model" that is used.

In either case, the problem that Agile has is that the solution almost never ends, the customer can continue to request changes and the development will continue to iteratively resolve them. For a project that is based on time and materials costing, this works very well. For a project that has a fixed cost, it doesn't.

For these fixed-cost projects, the customer almost always expects pre-defined milestones to demonstrate progress, however, these are more of the formal written variety rather than working code. For customers like this, the written specifications become the project, one where the software development is a secondary consideration (as they assume, if you have a well-defined project, the software should be easy to develop). These companies are also the ones that make heavy use of cheap, outsourced development resources.

So, if you have a fixed pot of money or time, do not expect the requirements to change or are not allowed to change any requirements, and are expected to supply a strong set of written documentation, then the waterfall models are the only ones that make sense.

Agile can be introduced in the middle of these projects to do the development, but you still have a ramp-up phase where the specifications are created from requirements, and a ramp down phase where the software is installed and tested in situ. Agile doesn't respond well to these cases.

Answer 6

To who? Most of the managers I have dealt with still use the Waterfall Software Dev Process for scheduling, and up levels seem to like it for easy of scheduling.

Practically, very few developers I know believe it works or is even valid.