Traditional Software Development
Traditional software development methodologies have predominately assumed all requirements are known upfront, they have been based on the premise that a customer can define everything they want from a piece of development, define it accurately, and then communicate it to the implementer without any ambiguity.
Traditional methods also assume that the implementer can be completely understand what is being asked for to put together a comprehensive, specification, sufficient for them to complete 100% to a deadline and budget, both so whimsical in nature that no one believes them and everyone knows that contingency and change request will be the nature of the beast for the during of the project.
This process of trying to define each stage of software development into a closed activity, where nothing in the next stage can before the current stage has been completed in its entirety. It turns software development into a production line, with an “over the fence” approach, such that a analyst can hand over a supposed complete set of requirements to a designer who works in isolation delivering an all encompassing design to developers, who eventually hand over complete software to a test team
The general assumption is that up-front planning is enough to take into account all variables that could impact the development process, and than a plan put in place weeks, months or even years before the final date can some how be accurate.
Next Steps