Project Lifecycle Models: How the differ and when to use them

#spiral #software #development


Project Lifecycle Models: How They Differ and When to Use Them

Business eSolutions provides System Development Project Management services, Problem Project Diagnostic and Recovery services and Project Management Training and Facilitation courses covering strategy, project management, project estimating, business requirements, risk management and quality assurance. We can help you define a lifecycle methodology customized to your organizational strengths and development risks. Our mission is to help our clients produce quality systems on time and on budget.

Project lifecycle models are not interchangeable. To deliver a quality system, it’s critical to know the risks facing your project and to use a model that reduces those risks. The following describes standard project lifecycle models, and reviews their strengths and weaknesses. These standard models can be adapted to fit the industry issues, corporate culture, time constraints and team vulnerabilities which comprise your environment. Contact Us to help.

What model do you use? Or, more appropriately, what model should you be using? Here’s a summary to help you decide.

Pure Waterfall

This is the classical system development model. It consists of discontinuous phases:

      1. Concept
      2. Requirements
      3. Architectural design
      4. Detailed design
      5. Coding and development
      6. Testing and implementation
  • Minimizes planning overhead since it can be done up front.
  • Structure minimizes wasted effort, so it works well for technically weak or inexperienced staff.
  • Inflexible
  • Only the final phase produces a non-documentation deliverable.
  • Backing up to address mistakes is difficult.

Pure Waterfall Summary
The pure waterfall performs well for products with clearly understood requirements or when working with well understood technical tools, architectures and infrastructures. It’s weaknesses frequently make it inadvisable when rapid development is needed. In those cases, modified models may be more effective.


The spiral is a risk-reduction oriented model that breaks a software project up into mini-projects, each addressing one or more major risks. After major risks have been addressed, the spiral model terminates as a waterfall model. Spiral iterations involve six steps:

      1. Determine objectives, alternatives and constraints.
      2. Identify and resolve risks.
      3. Evaluate alternatives.
      4. Develop the deliverables for that iteration and verify that they are correct.
      5. Plan the next iteration.
      6. Commit to an approach for the next iteration.
  • Early iterations of the project are the cheapest, enabling the highest risks to be addressed at the lowest total cost. This ensures that as costs increase, risks decrease.
  • Each iteration of the spiral can be tailored to suit the needs of the project.
  • It is complicated and requires attentive and knowledgeable management to pull it off.

Spiral Summary
For projects with risky elements, it’s beneficial to run a series of risk-reduction iterations which can be followed by a waterfall or other non-risk-based lifecycle.

Modified Waterfall

The modified waterfall uses the same phases as the pure waterfall, but is not done on a discontinuous basis. This enables the phases to overlap when needed. The pure waterfall can also split into subprojects at an appropriate phase (such as after the architectural design or detailed design).

  • More flexibility than the pure waterfall model.
  • If there is personnel continuity between the phases, documentation can be substantially reduced.
  • Inplementation of easy areas do not need to wait for the hard ones.
  • Milestones are more ambiguous than for the pure waterfall.
  • Activities performed in parallel are subject to miscommunication and mistaken assumptions.
  • Unforseen interdependencies can create problems.

Modified Waterfall Summary
Risk reduction spirals can be added to the top of the waterfall to reduce risks prior to the waterfall phases. The waterfall can be further modified using options such as prototyping, JADs or CRC sessions or other methods of requirements gathering done in overlapping phases.

Evolutionary prototyping uses multiple iterations of requirements gathering and analysis, design and prototype development. After each iteration, the result is analyzed by the customer. Their response creates the next level of requirements and defines the next iteration.

Copyright JJ Kuhl 2002