Waterfall Project Methodology
The best known and oldest software development methodology Project Methodology is the Waterfall model, where developers and project managers leverage the standard Requirements, Design, Build, QA (perhaps unit tests then system tests), Deployment, and Maintenance phases. After each step is finished, the methodology proceeds to the next step, just as builders don't revise the foundation of a house after the framing has been erected.
There is little provision in this methodology for correcting errors in early steps (for example, in the requirements), so the entire (expensive) engineering process may be executed to the end, resulting in software which needs to be immediately upgraded after the first launch.Some descriptions of the methodology include for iteration, but that part of the methodology is usually overlooked. One source of difficulty is that the number of dependencies among the artifacts (outputs) of the various steps is surprisingly high, much higher in a typical software project than in a typical building project.
There is little provision in this methodology for correcting errors in early steps (for example, in the requirements), so the entire (expensive) engineering process may be executed to the end, resulting in software which needs to be immediately upgraded after the first launch.Some descriptions of the methodology include for iteration, but that part of the methodology is usually overlooked. One source of difficulty is that the number of dependencies among the artifacts (outputs) of the various steps is surprisingly high, much higher in a typical software project than in a typical building project.

As illustrated above the process is almost forced ahead by the phased approach, except for the QA phase which naturally shares quick iterations of build to addresses bugs found in the software.
This approach is usually favored by larger corporations because it fits within the normal processes which require long approval processes. A change in functionality discovered during build, might stop a project and require an additional approval by corporate stakeholders.
The process is still used in the consulting environment because the initial documentation in a client SOW describes specific functionality for a agreed upon fee. If the client decides to alter the functionality, then a Change Order is created, which states the agreed upon changes and fees associated with the additional development.
Previous page: Software Programming Methodology
Next page: Iterative Project Methodology