BSE 1206: Software

development principles
Software Process Models: Waterfall and Agile 1
 Lecture Plan

Module 1: Software Management Module 2: Software life cycle

• Introduction to Software Engineering • Requirements engineering
Management • Modelling
• Software Process Models: Waterfall and • Software architecture
agile development
• Software design
• Configuration management
• Software testing
• People management and team
organisation • Software maintenance
• On meeting software quality • Software tools
• Project planning and control
Waterfall and
Agile
development
Software Process Models

• A method for developing computer software that organises

the effort into a number of separate tasks and steps
• This helps make it possible to develop large software
systems using many people in an organised, manageable
and trackable way, in order to retain control of the
development.
 Fundamental Process Activities

Problem
• All software process models share four fundamental
process activities, and differ in how these are
Requirements specification
organised
• Specification:
• define requirements, functionality, constraints Specification
• Development:
• build software to meet the specification
Program
• Validation:
• validate that it does what the customer wants
• Evolution: Working program

• evolve to meet changing needs and expectations.

The 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
• Organises quality control e.g., IBM’s “ETVX” – Entry, Task,
Validation, eXit at each step.
 The waterfall model

Original Waterfall Model

Requirements Definition

Design

Implementation and unit

testing

Integration and System

testing

Operation and
Maintenance
 The waterfall Model

Iterative Waterfall Model

Requirements
• Refined to more realistic Definition

practice
Design
• Go back up waterfall to
Implementatio
revisit previous steps as n and unit
testing
necessary
Integration
• Still work on one step at a and System
testing
time, cascade to next when
Operation and
completed. Maintenance
The Waterfall Model

• Requirements Analysis and Definition

• System’s required services, constraints and goals are established with
customers/users.
• Expressed in a way understood by both users and developers
• Quality control: requirements reviews (inspection)
• System and Software Design
• Partition into subsystems or components or modules
• Establish overall system and software architecture
• Establish functional specifications for components of the architecture
• Quality control: design review (inspection)
The Waterfall Model

• Implementation and Unit Testing

• Design realised as a set of programs and program components to
implement components of the architecture
• Verify that units meet functional specifications
• Quality control: unit testing, component testing
• Integration and System Testing
• Integrate individual programs and program units into complete
system
• Validate that system meets requirements
• Quality control: integration testing, acceptance testing
The Waterfall Model

• Operation and Maintenance

• Normally longest phase of software life cycle
• 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
• Quality control: regression testing, acceptance testing
• Retirement and Decommissioning
• System is retired and replaced with a new one
• Rarely done now because of cost and risk of replacement – continuous
evolution more common
Drawbacks of Waterfall Model

• Early freezing may lead to undesirable system

• Premature freezing of requirements leads to system not doing
exactly what users want
• Premature freezing of designs leads to badly structured systems as
design problems are worked around using implementation tricks
• Inflexible partitioning leads to undesirable technical results
• Delivered systems are us
 The Prototyping Model

• Problems with requirements Requirements

gathering
• Most failures are due to inadequate
requirements understanding Quick
design
• Prototyping
Refine Build
• Extend requirements phase to include a Design prototype
sequence of prototypes
• Improve requirements and design as Customer
prototypes are refined Evaluation

• Move to real development when both

Full Scale
users and developers are satisfied Development
The Prototype Model

• Requirements Gathering and Analysis

• Much like waterfall model, but less stringent since prototype will
help expose inadequacies
• Quick Design
• Make a simple approximate initial design, refine during iteration
• Build Prototype
• Quickly get together an approximate implementation showing
noticeable/important external features
 The Prototype Model

• Customer evaluation
• Users validate prototype, report inadequacies
• Design Refinement
• Refine design in response to user feedback from prototype
• Full Scale Development
• Continue with remaining phases of traditional waterfall model
Drawbacks of the Prototyping Model

• Wasted work
• Commonly built using substandard quality controls to speed
iteration thus, they must be discarded after the prototyping phase
even if they solve significant problems
• Inadequate or incomplete prototypes
• Full prototypes are difficult thus done in parts which could miss
critical requirements at integration
• When to stop prototyping
• User can keep requesting changes each time
 Evolutionary Development

• Prototype Evolution
• Method to avoid wasting work Initial Version
Specification
by smoothly evolving the
initial prototype to the final
product. Outline Outline
Development
Intermediate
Outline
Outline
Description Description Versions
Description
• In essence, never leave
prototype iteration until
implementation is complete Validation Full Version
• Get version of the software
Concurrent activities
sooner
PAUSE

• Pause
The Spiral Model

• Refinement of waterfall model designed around continuous

documentation and evaluation of risk
The 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 of the project:

• Determine Objectives
• Specific objectives 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
• 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 minimise risk
Spiral Model

• Develop and validate

• Based on risk analysis, choose or modify development model
• E.g., 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

• Review and plan

• Review and evaluate results of the phase you are at
• Decide whether another layer of the spiral is needed
• Draw up plans for the next phase if so
Drawbacks of the Spiral Model

• Heavyweight Process
• Requires large amount of overhead – each layer requires lots of
documentation and meetings – slowing progress
• Primarily suitable for large projects with long timelines
• Not really a development model
• More of meta-model since it describes the way to carry out stages,
not what the stages are
• But focuses on identifying potential problems early at each stage –
produces high quality results
Drawbacks of Spiral Model

• Depends on risk analysis

• Needs a very experienced team to recognise and analyse risks
accurately
• High dependence on quality of people (itself a risk!)
• Not for novices
• Requires experienced people since layers of process are not
explicitly laid out
Iterative Development Model

Subset Development
• 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 for training customers, and learning for
developers
IDP

• Begin with analysis of the

problem domain and
definition of requirements
• Need initial architecture
design to begin
• Add most critical remaining
features each cycle
Drawbacks of IDP

• Needs Small team

• Process does not allow large-scale parallel development, depends
on focussing on one remaining risk at a time
• Works best with relatively small teams
• Needs early architecture
• Difficult to change later
• However has good results if architecture can be settled early
Summary

• Software development has four tasks

• Software development processes differ in how these are
interlaced
• Oldest and most common process is waterfall
• Some recent and popular processes are based on prototyping
• Spiral model organises and generalises waterfall model
• Iterative development process based on product subsets