Bob,

You are right on!!! As another hater of the waterfall method, I completely agree.

Waterfall depends on getting the requirements completely correct, "or else!". But I've never yet been involved in a project where the requirements didn't change during design.

My motto is "requirements change, deal with it". And waterfall quite frankly can't deal with it. Agile methods assume my statement is true and they are conditioned to deal with it. You do of course have to be careful to reign in scope creep and always maintain focus on the core goals of your development.

But in my experience if you don't treat requirements as things that can evolve, be added, or disappear, you really aren't controlling them, they're controlling you.

Of course this is where the end user interaction is so important. They are the real drivers of requirements on any project. A major flaw of waterfall is to ask them what they requirements are at the start, and write them all down, but never review the requirements with them again until testing. As many of your readers know, this is a recipe for project disasters.

To sum up Agile Rocks!

Waterfall is dead, or at least it should be. Requirements will definitely change, even before the ink is dry on the requirements that were just documented; but you need a good set of requirements to get you in the ball park. Then you need a good, no make that A GOOD, object oriented design where anything and everything that can change is encapsulated and you program to an interface, not an implementation. That way when the requirements do change you can easily adapt and incorporate those changes.

Coding is towards the bottom of the list; and I agree with Bob, get/keep good Analyst/Programmers.

The top two processes on your list are requirements and design. without requirements you don't know if you are on target with what the user wants; and without a good design you won't be able to deliver a quality product when the requirements change, and they will. The waterfall methodology is out of date and out of touch with our fast paced world, it can't keep up with the ever changing requirements; It's not unheard of for the user, or client, not to know what they want until they see it; and with out a good OOD you won't be able to change your code to address the changing requirements.

For some good resources for coming up to speed on OOA&D see the book "Head First Object Oriented Analysis & Design" and part of a good design is the use of design patterns a good reference for understanding them is also a Head First book "Head First Design Patterns"

With decent and evolving requirements; and a good design to work with you are well on your way to a high quality piece of software that can be successfully implemented. With out requirements you won't know what to test. Without a good design you can write good code but it probably won't be robust enough for ongoing changes of any magnitude, therefore it won't be of a quality nature, nor be successful over the long haul. Remember too, that the maintenance phase of the software life cycle is often the most expensive, especially without a good OOA&D.

These lessons have been learned the hard way from 20 years in the trenches with my share of death marches, pulling rabbits out of hats and cleaning projects that did not make use of flexible designs, if they even had designs.

In my opinion there are a range of suitable processes depending on the project. A test I use to identify the project type is to ask how often you expect it to change once it is complete. An evolving web site is ideally suited to an agile process whereas a mars rover is more on the academic, waterfall end. I can't say why this test works, just that in my experience there is a correlation. For completeness I should say that I normally work in low level embedded software and write web site type software as a hobby.

I'm going to answer the question and include the nasty customer bits on either end as integral to what I consider the right answer, since I think most people getting paid to do this kind of work for companies that need revenue streams. I suspect this is not the right answer to give to someone teaching theoreticals, however.

1) Analysts that will take oversight of the process from an expressed desire for a new product to end user acceptance, and have the ability and desire to at least try to understand what the customer wants to accomplish.

2) Sales people that know their job is to get the customer to express a need and a willingness to pay for someone else to solve it, and then get out of the way and let the analyst work out the potential "Hows" to the customer's "What" with users.

3) Programmers (and analysts too) that understand that a good interface and process flow is the single most important thing to the end user (and by extension the most important factor in acceptance), and they could care less what it looks like underneath or how clever a bit of code is.

4) Software architecture and methodology that adapts or scales easily, though this really isn't a direct customer concern as much as how it impacts turnaround and pricing and the purchase decision.

First you had better define what you mean by "quality".

Is it robustness (e.g., does it handle bad inputs without crashing, does it save your data when the power goes out)?

Is it features (an IDE without code completion is worthless in my book)?

Is it price/performance (a $1000 Web browser had better be blazingly fast)?

Is it (relative) lack of bugs?

Is it ease of use (now where is that "preview mode" anyway?)?

Is it decent docs?

Does it solve more problems than it causes (don't laugh, some project software is worse than chalk and a board)?

Does a decent product released months before a great product have more quality? Does time-to-market have a component?

Until you decide what "quality" means, the discussion is too broad.

And note the mistaken assumption that these processes are not interrelated and dependent upon the development model, as Bob noted.

The biggest contributor to quality? Commitment to quality. Lip service is the typical commitment. "We are all about quality" lasts until the first snag. Then it's "every man for himself", the teams all anxiously waiting for another team to blink first and take the hit for the delay.

As much as we love to castigate Microsoft for slipped schedules, would you prefer buggier software as long as they hit a date? Heck no.

I agree with Bob's assessment, but wonder if the the point that the developers should be analysts and that the development and analysis is to be one job makes it through a reality check.
Basically, I agree. Fact is, if a developer has no deep understanding of the business and the users no good can come from that. Likewise, an analyst who has no clue about developing software will not get far. But the developers are expected to be technical experts, whereas analysts are expected to be user and business experts. While the one does not exclude the other, it is often practical things such as time constraints that prevent joining these two jobs together. It is also fairly unlikely to get someone who is as good of an analyst as a developer. Splitting this job makes sense in practice and the impact on quality is minimal.

I have a book on Web site development. The author makes the case for early involvement and testing by the users (or at least people who can realistically represent users). Basically the earlier the better.

Their point was that, even though you can spend additional time on refining code in an abstracted development environment, it is a much more effective use of time and resources to let the clients get their hands on the system.

Obviously this has a somewhat limited perspective. Web sites may not encompass the full range of activities of an enterprise software developer. However I suspect that the author is correct on this matter. Let the clients get their hands dirty with the actual system, during development.

This does assume however, that you have suitable clients. They need to have the time and the interest. Such clients need to be able to cope with major bugs, significant design flaws, and a system that is changing as they use it. These are usually quite sophisticated people who like a challenge and thrive in the hothouse environment of software development.