Waterfall Software Process Models

Michael L. Collard, Ph.D.

Department of Computer Science, The University of Akron


Slides adapted from the slides for the book “Software Engineering: The Current Practice” by Václav Rajlich © 2012 by Václav Rajlich

Contrast School to Real World Projects

Project AttributesSchoolReal World
Number of developers1 (2 - 3 at most)2 - 3, even 10s to 100s
Other developersfriends, acquaintancestotal strangers
Time spent coding8 hours2000 hours
Timespan (start to finish)2 - 3 daysYears
Lifespan2 - 3 daysMultiple years
Software Users1, 210s to 100s to billions

Role of Process

  • Small, short projects can use any process they want, and they may accidentally succeed, or nobody notices if they fail
  • Large, long time frame projects do not accidentally succeed

Studies Show


Standard Software Phases

  • Requirements
  • Analysis
  • Design
  • Implementation
  • Testing & Validation
  • Release
  • Maintenance

Why breakup into phases?

  • Phases match common development activities
  • Ensure needed tasks are completed
  • Ensure needed artifacts (documents) have been generated
  • Measure and show progress
  • Predict personnel and skillsets needed
  • Record for future use

(Some) Phases and Deliverable Artifacts

  • Requirementsrequirements specification
    • E.g., user stories, use cases, all the way to 500 page requirements documents
  • Designtechnical specification
    • E.g., Quick UML class diagram, sequence diagram, all the way to using all 16 (?) UML diagrams, plus more
  • Implementationcode (finally), e.g., code :)
  • Releaseexecutables, e.g., packages, installers
  • Testingtest report, e.g., set of test cases, testing/acceptance report

Common Process Models

  • Waterfall
  • Prototyping
  • Agile
  • Extreme Programming (XP)
  • Rational Unified Process

Characteristics of Process Models

  • Heavyweight vs. Lightweight
  • Planning vs. Doing
  • Efficiency (skillset, personnel, time to market)
  • Single Pass vs. Multiple Passes
  • Role of Maintenance
  • View of Evolution

Waterfall Model

Waterfall Model

  • Heavyweight, single pass, strong planning-based approach
  • Each phase completed and verified before another phase is started
  • “Big Bang” approach described in Head First book exhibits similar characteristics
  • Requires extreme amounts of planning to be successful

Waterfall Model Effects

  • Detailed and very formal documents required for each phase
  • Personnel become experts in individual phases

Role of Waterfall

  • Original attempt to solve software crisis
  • Very appealing, especially to those in other disciplines, appears to be common sense
  • Predominant model taught in SE for many years
  • Predominant process model for other engineering disciplines
  • Maintenance is handled very differently than initial development

Criticisms of Waterfall

  • Prescriptive rather than descriptive
  • Assumes “pure” phases
  • Maintenance may be 80% of overall costs, but handled very differently than initial development
  • Not proved to be successful
  • Note: Waterfall thinking can permeate all aspects, e.g., BDUF (Big Design Up Front)

Requirement Volatility

  • Requirements are almost always not fully known in advance, and often added during the other phases
    • E.g., 30% of requirements for Microsoft were not found during requirements gathering
  • Any design based on requirements documents must be considered temporary


  • anomaly is an important fact that directly contradicts the old paradigm”
  • Waterfall is not very successful at solving the software crisis, or produces less-than-excellent results
  • band-aid approaches were then proposed

Band-Aid Approach: Design for Change

  • Idea: Since requirements are volatile, design to allow for future changes
  • Commonsense, but does require predicting the future, which we cannot always do
  • Very useful for low-level design: named constants, good method abstraction, good class abstraction
  • Increases flexibility, but that often increases complexity
  • Increases cost of initial software

Problem: Unexpected Changes

  • Company mergers that require IT unification, e.g., Daimler Chrysler
  • Changes in the law, e.g., record keeping (or lack thereof)
  • Changes in technology, e.g., Internet, mobile applications, smartwatches

Band-Aid Approach: Prototyping

  • Idea: Difficult to determine requirements without some sort of running system, so build a prototype to get requirements, e.g., “Build one to throw away”
  • Develop first version cheaply: Very high-level languages, less features (particularly non-functional requirements of speed, robustness, quality)
  • Still necessary to gather all requirements during the prototype
  • Issue: perception of prototype as completed system

Studies Show


Why should companies care?

  • Money lost due to wasted development effort (somewhat important)
  • Money lost due to inability to use the developed software (extremely important)
  • Provide an opportunity for other companies to take over, and disruption to occur


Slides adapted from the slides for the book “Software Engineering: The Current Practice” by Václav Rajlich © 2012 by Václav Rajlich