So-called waterfall processes and structured methods first became popular in the 1970's and dominated the industry throughout 1980's. The 1990's saw waterfall processes lose their dominance to formal use-case and object-oriented analysis and design approaches epitomized by the Unified Process framework. Then, at the turn of the century a wave of self-styled agile approaches including Scrum, eXtreme Programming (XP), and Feature-Driven Development (FDD) to software development appeared and rapidly grew in popularity.
Despite this, numerous software development organizations still follow waterfall-style processes today.
Waterfall processes are characterized by well-defined phases and quality checkpoints or gateways.
Unfortunately, waterfall processes regularly exhibit a number of problems. Defining all of the requirements precisely at the start of the project often proves considerably harder than originally envisaged. Plans are adjusted and design is reported to senior management and the customer as starting late. As a result, design is often hurried to reduce the impact on the start date of coding. Nevertheless, coding is still reported as taking signifcantly later than planned. The end result is that the time planned for testing is significantly reduced to make the new promised deploy date that is already much later than originally committed to.
The real picture is often much worse than the reported picture. Although design starts, requirements work is typically still continuing as designers immediately start to find omissions, ambiguities, and inconsistencies in the requirements documents. This problem is quite frequently compounded by requirements and designs still being reworked and refined when programmers start coding. Changes to requirements and design after coding has started cause unplanned delays and reworking of code. The end result is that coding needs to continue well into testing, further reducing the effectiveness of that testing.
Another side-effect of all this is that,
once the initial requirements are finally signed off, the project has
no opportunity to accommodate non-trivial changes to those requirements
without jeopardizing the deployment date. The project's change management process, effectively
becomes a change minimization
process. In addition, the project team have little opportunity to
significantly improve the way they do things because each major
activity is done only once and lessons learned are either forgotten or
not applicable on the next project.
While all types of software development can fall foul of these problems, they seem to be more acutely felt on enterprise software systems where business requirements are typically harder to define and subject to more frequent change than the requirements for industrial or embedded software, for example.