Varsys - Software and Web Development
Chasing the Waterfall May Lead to Project Downfall

In some software development projects the requirements supporting the business objectives are easily defined, while in other projects they are more difficult to determine at the start of the project. IT leaders should avoid a "one-size-fits-all" project development methodology and tailor their strategy to maximize project quality and efficiency.

Software Development Methodologies

Waterfall and Agile software development methodologies are conceptual frameworks for undertaking software engineering projects. They both follow Software Development Lifecycle (SDLC) best practice concepts for software development projects describing each stage of development from feasibility to maintenance.

Waterfall Development

Waterfall development is an approach to software development that breaks a project into finite phases. Each phase is performed in order, and each depends on the completion of preceding phases.

The central idea behind the Waterfall model is that the time spent early on, making sure that requirements and design are correct, can lead to greater economy later in the software lifecycle. For example, a bug found in the early stages of the production lifecycle (such as requirements specification or design) is more economical (in terms of money, effort, and time) to fix than the same bug found later on in the process.

Figure 1. The Waterfall Development Approach

 Waterfall Model

Analysis of the Waterfall Development Approach

Promises
  • The Waterfall methodology is the most predicative of development methodologies, stepping through requirements capture, analysis, design, coding, and testing in a strict, pre-planned sequence.
  • Provides a disciplined and structured approach which makes it easy to keep projects under control.
  • Limits the amount of cross-team interaction needed during development.
  • Allows for greater ease in project management since plans aren't constantly being revised.
Realities
  • While the Waterfall methodology is easy on the manager, it can be grueling for developers. Testing comes at the end of the development phase; subsystem testing can reveal problems with the code that must be rectified quickly. Oversights and flawed design work can seriously affect the budgeted costs and final launch date.
  • Debugging can be complicated since developers are often working on other projects at the end of development, and the needed changes can cut into their productivity and work quality.
  • Leaves no room for feedback anywhere in the process, except at the end of a phase. There is no room for changes once development has begun. It fails to be open to change due to external factors and requirement modifications.
  • When applied to the wrong situations the methodology can give the false expectation of predictability and the reality of cost and date overruns.
  • The deliverable (ideas into working software) is a one time deal, typically several months to several years after start date.

In spite of the negative reality, a Waterfall methodology can be suited to software projects which are stable (such as with "shrink wrap" software) and where it is possible and likely that designers will be able to fully predict problem areas of the system and produce a correct design before implementation is started.

Agile Development

The Agile development method is characterized as being able to adapt quickly to changing realities. It incorporates planning, requirements analysis, and design, coding, testing, and documenting tasks to release mini-increments of new functionality.

Figure 2: The Agile Development Method

Agile Model

Analysis of the Agile Development Method

Promises
  • Allows for adaptive planning.
  • Project risk is minimized by developing software in short iterations where each iteration is a small project on its own.
  • Allows for just-in-time requirements and the ability to adapt to constantly changing requirements.
  • Less time is wasted on written documentation. The emphasis is on real-time communication, preferably face-to-face, over written documents.
  • Progress is measured by producing crude and executable systems presented to stakeholders and continually improving them.
  • There is continuous client communication – the project is very close to the user and relies heavily on client interaction to build the best system that meets the user's needs.
  • Deliverables are short-win, business-focused releases, released typically every couple of weeks or months until the entire project is completed.
Realities
  • Can result in cowboy coding; that is the absence of a defined development method and team members have the freedom to do whatever they feel is right.
  • There is often insufficient structure and the necessary documentation to maintain and enhance the application on a going-forward basis.
  • Only works well with senior-level, highly experienced developers.
  • Often incorporates insufficient software architecture and design for complex applications.
  • Business partners are often nervous and confused about what they will receive as a final package. They resist iterative requirements work and are not prepared for iterative testing.
  • Output may be surprising. Due to the incremental nature of adaptive planning, the overall result may differ substantially from the original intent. This may be a better result but perceived as a chaotic process.
  • Requires a lot of cultural change for an organization to adopt (if this doesn't already exist).
  • Many tools for development (e.g. project management, requirements management, development tools) were based on the Waterfall approach and require extra work to be effective in an Agile methodology.

An Agile methodology is best suited for development projects that are evolving and continuously facing changing conditions.

Well known Agile software development methods include:

  • Extreme Programming (XP)
  • Scrum
  • Adaptive Software Development (ASD)
  • Crystal Clear and Other Crystal Methodologies
  • Dynamic Systems Development Method (DSDM)
  • Lean Software Development
  • Rational Unified Process (RUP)
  • Dialogue-Driven Development (d3)

Bottom Line

IT leaders have an important decision to make when deciding on a Waterfall or Agile methodology for a software development project. One size does not fit all.

Back to Knowledge Center