Software Process Models

Typical Software Process Models

 Waterfall Model
 Prototyping Model
 Spiral Model
 Iterative Development Model
Waterfall Model
 First explicit model, derived from other engineering processes
 Cascade of phases, carried out in order, with sign-off of each before
proceeding to the next
 Organizes quality control at each step, e.g., IBM’s “ETVX” - Entry, Task,
Validation, eXit
Waterfall Model
Requirements Original Waterfall Model
definition
(Somerville 1996)
System and
software design

Implementation and
unit testing

Integration and
system testing

Operation and
Maintenance
Waterfall Model
Requirements Iterative Waterfall Model
definition
(Somerville 1996)
System and software
design
 Refined to more realistic with
practice
Implementation and
unit testing
 Go back up waterfall to revisit
previous steps as necessary
Integration and  Still work on one step at a time,
system testing
cascade to next as completed
Operation and
Maintenance
Waterfall Model
Phase 1: Requirements Analysis and Definition
 System’s required services, constraints and goals are established by
consultation with users/customers
 Expressed in a way understood and agreed to by both users and
developers – often test cases or scenarios

SQA task: requirements reviews (inspection)

Waterfall Model
Phase 2: System and Software Design
 Partitions into hardware and software subsystems
 Establishes overall system and software architecture
 Establishes functional specifications for components of the architecture

SQA task: design reviews (inspection)

Waterfall Model
Phase 3: Implementation and Unit Testing
 Design realized as a set of programs and program components (units)
to implement components of the architecture
 Verify that units meet functional specifications

SQA task: unit testing

Waterfall Model

Phase 4: Integration and System Testing

 Integrate individual programs and program units into complete system
 Validate system that system meets requirements

SQA task: integration testing, acceptance testing

Waterfall Model

Phase 5: Operation and Maintenance

 Normally the longest phase of software lifecycle
 Install system and put into use
 Maintenance involves correcting errors discovered in practice
(“failures”) and improving system units (e.g., performance tuning) and
enhancing services in response to new requirements

SQA task: regression testing, acceptance testing

Drawbacks of Waterfall
(1) Early Freezing
In practice, frequent iterations back up the waterfall, making it difficult to identify
checkpoints and track progress.
Therefore, it is normal to freeze parts of the development, such as requirements and
design, and move on to the later stages quite early without feedback.
• Premature freezing of requirements may mean that the system won’t end up doing
exactly what the users want.
• Premature freezing of designs often leads to badly structured systems as design
problems are worked around using implementation tricks
Drawbacks of Waterfall
(2) Inflexible Partitioning
 The inflexible partitioning into distinct stages, while a management
advantage, often leads to undesirable technical results.
 Delivered systems are, sometimes, unusable, do not meet users’ real
requirements (as opposed to their original guesses)
Drawbacks of Waterfall

(3) Problems with Requirements

 The first step in the waterfall is requirements gathering and analysis.
 In practice, this is the most difficult part and experience with the
waterfall – indicates that most failures are due to inadequate
requirements understanding.
 Users often change requirements as they see what can be done.
Prototyping Model
 The prototyping model attempts to address the requirements difficulty
by introducing an iterative, by-example requirements stage
 A prototype is a partial implementation of a software system with all
external interfaces presented

 Users use the prototype and provide feedback from which real
requirements are gradually refined
 Final prototype serves as an example of intended system
Prototyping Model
Requirements
gathering

 Extend requirements phase to

Quick
include a sequence of prototypes Design
 Improve requirements and Refine Build
design as prototypes refined Design Prototype

 When users and developers both

Customer
satisfied, move on to real Evaluation
development
Full Scale
Development
Prototyping Model
Step 1: Requirements Gathering and Analysis
 Much like waterfall model, but less stringent since prototype will help expose
inadequacies
 SQA task: requirements reviews (inspection)

Step 2: Quick Design

 Make a simple approximate initial design, refine during prototype iteration
 SQA task: prototype testing

Step 3: Build Prototype

 Quickly hack together an approximate implementation showing salient external features
 SQA task: none
Prototyping Model
Step 4: Customer Evaluation
 Users validate prototype, report inadequacies
 SQA task: acceptance testing and evaluation (inspection)

Step 5: Design Refinement

 Refine design in response to user feedback from prototype
 SQA task: design reviews (inspection)

Step 6: Full Scale Development

 Remaining stages of traditional waterfall model
Drawbacks of Prototyping Model
(1) Wasted Work
 Prototypes are normally built using substandard quality controls
(“thrown together”) to speed the iteration (“quick turnaround”)
 Thus, prototypes must be discarded after the prototyping phase, even if
they solve significant problems
Drawbacks of Prototyping Model
(2) Inadequate or Incomplete Prototypes
 Full prototypes of complex systems can be difficult/impossible to create
quickly.
 Thus prototypes are often done in parts, which may miss critical
requirements at the integration or complete system stage.

(3) When to Stop Iterating

 Easy to have users convince you to continue refining beyond the point where
requirements and design are sufficient (“creeping excellence”)
Evolutionary Development
 Evolutionary prototyping is
a method to avoid wasting Specification Initial
work and take advantage of Version
“creeping excellence” by
Intermediate
smoothly evolving the initial Outline
Development Versions
Description
prototype to the final
product Full
 In essence, never leave Validation Version

prototype iteration until

implementation is complete Concurrent activities
Spiral Model
 The Spiral Model is a refinement of the waterfall model designed
around continuous documentation and evaluation of risk.
 Based on experience applying the waterfall model to large (U.S.)
government software projects
 Now a standard used by many government agencies and software providers
Spiral Model
OBJECTIVES: RISKS:
Determine objectives, Evaluate alternatives,
alternatives, constraints identify & resolve
risks

PLAN:
Review status and DEVELOP:
plan next phase Develop and verify
Source: Boehm 1988 next level product
Spiral Model
Spiral Layers
 Roughly, each layer of the spiral corresponds to one phase of the
waterfall (although there are no fixed phases)
 For example, first layer could be the requirements phase, second layer the
design phase, etc.
Spiral Model
Four Step Cycle
 In each layer, the same four step cycle is used, consisting of:
 Determine Objectives: determine objectives, constraints, risks for next phase
 Assess and Reduce Risks: analyse and reduce identified risks
 Develop and Validate: choose development model, develop and test
 Review and Plan: review status, plan next layer
Spiral Model
For each layer (phase) of the project:
Step 1: Determine Objectives
 Specific objectives (aims) for the phase of the project are defined
 Constraints on the process and product are identified
 Alternatives for achieving the objectives are identified
 Potential risks associated with each alternative are identified

Step 2: Assess and Reduce Risks

 For each potential risk, a detailed analysis is carried out
 Steps are taken to reduce risk (e.g., create prototype to check)
 Alternatives are chosen to minimize risk
Spiral Model
Step 3: Develop and Validate
 Based on risk analysis, choose or modify development model
 For example, to implement and validate,
 if user interface risks dominate, use evolutionary prototyping;
 if safety risks are the major issue, use formal methods;
 if integration problems are the big risk, use waterfall model

Step 4: Review and Plan

 Review and evaluate results of this phase (layer)
 Decide whether another layer of the spiral is needed
 Draw up plans for next phase if so
Drawbacks of Spiral Model
(1) Heavyweight Process
 The spiral model requires a large amount of overhead – every layer requires a lot of
documentation and many meetings – progress can therefore be slow
 Primarily suitable for large projects with long timelines

(2) Not Really a Development Model

 The spiral model is really more of a “meta-model” since it describes the way to carry
out stages, not what the stages are.
 But focuses on identifying potential problems early at every stage, so very good at
producing high-quality results.
Drawbacks of Spiral Model
(3) Depends on Risk Analysis
 Needs a very experienced team to recognize and analyze risks accurately
 High dependency on quality of people (itself a risk!)

(4) Not for Novices

 Layers of process are flexible and not explicitly laid out
 Each layer’s goals and plan must be decided by team itself – requires experienced
people
Iterative Development Model
Subset Development
 The Iterative Development Process (IDP) is based on subsets.
 Begin with a subset of the requirements and develop a subset of the software
product.
 The subset should:
 satisfy immediate needs of users
 serve as a vehicle of training for customers, and learning for
developers
Iterative Development Model
Sequence of Intermediate Products

 Analysis of the subset product leads to modifications to the design and

requirements, from which we build a new (hopefully larger) subset product
 Design and requirements refined over a series of iterations to provide a system
that meets evolving customer needs with improved design based on feedback and
learning
Iterative Development Model
Domain Analysis

Requirements
Iterative Development Process
 Analysis of the problem domain and Software
Architectur
definition of requirements begins process e
as usual Iteration
Risk Assessment
 Need initial architecture design to begin
 Add most critical remaining Prototype Develop Test
features each cycle Highest Risk Suite

Integrate with
SQA task: developing test suite for new features Previous
on each iteration User
feedback
Release
Drawbacks of Iterative Dev. Model
(1) Needs Small Team
 Process does not allow for large scale parallel development, depends on focussing
on one remaining risk at a time
 Works best with relatively small teams

(2) Needs Early Architecture

 Requires early design of overall architecture, difficult to change later
 But when architecture can be settled early, has been very successful at producing
significant, very high-quality products, e.g., IBM’s OS/2 system