Waterfall Project Methodology
This an outdated but still the best known and oldest software development 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.
In today's world of ever changing requirements, new technologies, and budgetary issues, there is little practical use for this methodology. There is little provision in this methodology for correcting errors in early steps (for example, in the requirements), or in ever changing business needs, so the entire (expensive) engineering process may be executed to the end, resulting in websites and 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. This process is still in use in many enterprise IT groups and internal web development groups, mostly because of political and budgetary concerns.
In today's world of ever changing requirements, new technologies, and budgetary issues, there is little practical use for this methodology. There is little provision in this methodology for correcting errors in early steps (for example, in the requirements), or in ever changing business needs, so the entire (expensive) engineering process may be executed to the end, resulting in websites and 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. This process is still in use in many enterprise IT groups and internal web development groups, mostly because of political and budgetary concerns.

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 used less and less in the consulting environment because the documentation in a client SOW usually describes specific functionality for a agreed upon fee and describes scenarios where functionality may need to be revised. 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