EEEGEF 492'05 Process Models: Waterfall and Prototyping

1
EEE/GEF 492.05Process ModelsWaterfall and
Prototyping
Royal Military College of Canada Electrical and
Computer Engineering

• Professor Colin Wortley
• wortley_at_rmc.ca
• 613-541-6000 ext. 6493

Dr. Terry Shepard shepard_at_rmc.ca 613-541-6000
ext. 6031
2
Contents of this set of slides

• Engineering Activities In Software Development
• Process Models
• List of different approaches
• Details of
• The Waterfall Model
• Incremental Prototyping Model
• Evolutionary Prototyping Model

3
Engineering Activities In Software Development
4
Engineering Activities (partial list)

• Analysing
• Prototyping
• Designing
• Implementing
• VV
• Documenting
• Deploying

Renewing, refreshing, replacing repeat above as
needed
5
The Software Process

• Why use a software process
• To improve software quality
• To improve communication
• To manage and reduce risk

- the alternative may be chaos
6
Process Models
7
Development Process Models

• Do all the engineering activities have to be
  performed in a linear sequence?
• What are the main goals of development process
  frameworks/models?
• to identify key engineering activities and their
  inter-relationships in the development of
  software.
• to determine how best to sequence those
  engineering activities for a given project

Maintenance models are different from development
models
8
Development Process Models

• Different approaches to sequencing the
  engineering activities
• Waterfall
• Incremental/Prototyping
• Evolutionary Prototyping
• Spiral
• Rapid Application Development (RAD)
• precursor to agile methods
• Rational Unified Process (RUP)
• unification of previous models
• Agile eg. XP, Scrum, Crystal, Feature Driven,
  Adaptive

1st five are in van Vliet (Ch. 3). Last 2 are too
new.
9
Models versus Methodologies

• Development process models
• identify the key activities in the development of
  software and their relationships to one another
• Development methodologies
• prescribe specific steps and instructions for
  each of the key activities
• how to

10
Example

• a development model might state that there is an
  activity called testing which follows another
  called implementation
• a methodology would specify how the activity of
  testing is supposed to be carried out

11
A Primitive process model
Problem statement

• Two activities
• implementation
• analysis

Write code to solve problem
Code
Figure out whats wrong with the code
Fix
Whats wrong with this model?
Released code
12
The Simplest reasonable model
Problem statement

• Order should be
• analysis
• implementation

Analysis
Implement
Simple Waterfall Model (Winston Royce, 1970)
Released code
13
Scaling up

• For very small projects
• a simple waterfall is sometimes adequate
• For larger projects,
• need more than analysis and coding - eg
• system requirements elicitation and definition
• software requirements allocation
• architectural and detailed design
• VV
• maintenance/evolution

14
The Waterfall ModelRoyce 1970
15
The Waterfall model
System requirements

• Transition points
• completion of a defined work product
• formal evaluation and acceptance of the work
  product
• establishment of an official baseline

Software requirements
Analysis
Design
Coding

• If rework required
• work product appropriately updated
• revisions formally evaluated and accepted
• changes are tracked as deltas to the baseline

Integration and Testing
Maintenance
16
Waterfall Transition Points

• A transition from one activity to the next
  typically requires
• completion of a defined work product
• formal evaluation and acceptance of the work
  product
• establishment of an official baseline
• Where it is necessary to revisit earlier
  activities
• the work product must be appropriately updated
• the revisions must be formally evaluated and
  accepted
• changes are tracked as deltas to the baseline

17
Economic rationale for Waterfall

• Argument put forth by Barry Boehm
• - Software Engineering Economics, 4.3, 1981
• We have to do all these steps anyway
• for small systems, the first 4 steps can be very
  light weight
• for larger systems, putting too little effort
  into the first four steps can be very costly
• Would doing the steps in any other order cost
  more?
• next slide casts some light
• line for smaller project shows a higher relative
  cost to fix requirements faults than for larger
  projects

18
Empirical data supporting Waterfall(Boehm 1981)
Relative cost to fix or change software throughout
the life cycle
200 100 50 20 10 5 2 1
larger projects
line for smaller projects supports the case for
agile methods
smaller projects
Reqr
Design
Code
Unit Test
Acceptance Test
Operation
19
Factor-of-100 Growth in Software Cost-to-Fix
CeBASE
1000
Larger software projects
500
IBM-SSD

GTE
200
100
80

Relative cost to fix defect

• Median (TRW survey)

50
20
SAFEGUARD
20

10
Smaller software projects
5
from www.hdcc.cs.cmu.edu/january01/summary/boehm.
ppt
2
1
Requirements Design Code
Development Acceptance Operation
test test
Phase in which defect was fixed
20
Steps for Success (Royce 1970)

• Document the design
• 1500 pages of documentation (design specs) needed
  where only 30 pages would be needed for a
  hardware procurement of comparable cost.
• Do key areas twice
• a miniature version of the entire process applied
  by a specialized team in the design phase
• Plan, control and monitor testing
• testing is the highest risk phase, at a time when
  the project has no manoeuvring room plan to do
  it right
• Involve the customer
• customer must be integrated into the process to
  avoid misunderstandings about system goals

21
An Incremental Waterfall Model
Product Design
a sequence of increments is more usual (as in
Boehm 81)
22
Comparative Staffing Curves
Waterfall vs Incremental Development
strict waterfall (Rayleigh curve)
Required personnel
incremental
Development timeline
23
Strengths of The Waterfall Model

• Encourages periodic review
• better validation and verification
• higher performance product
• more closely matches the requirements
• Each phase results in document
• helps clarify decisions
• provides an audit trail
• serves as concrete milestone
• Formal transition from each phase
• results in a progressive setting of the product
• reduces unnecessary changes

24
Strengths of The Waterfall Model

• What we have is an effective fallback position
  that tends to maximize the extent of early work
  that is salvageable and preserved.
• Royce 1970

25
Weaknesses of Waterfall Model

• inherent assumption its possible to get the
  requirements and design mostly complete and
  correct in one pass
• true for a few projects that are very similar to
  ones that have been done before or that are very
  simple
• careful validation of requirements mitigates the
  phasing problems except validation often cant
  be done
• first designs are almost always sub-optimal
• when its necessary to revisit completed phases,
  there normally is a large administrative
  overhead, since progress between phases is
  document dependent
• reduces opportunity for recursive engineering
• also reduces ability to make mid-course
  corrections when early decisions turn out to be
  inappropriate

26
Weaknesses of Waterfall Model

• I believe in this concept, but the
  implementation described above eg. slide 15 is
  risky and invites failure. The problem is
  illustrated in Figure 4 next slide. The testing
  phase which occurs at the end of the development
  cycle is the first event for which timing,
  storage, input/output transfers, etc., are
  experienced as distinguished from analyzed. These
  phenomena are not precisely analyzable. They are
  not the solutions to the standard partial
  differential equations of mathematical physics
  for instance. Yet if these phenomena fail to
  satisfy the various external constraints, then
  invariably a major redesign is required. A simple
  octal patch or redo of some isolated code will
  not fix these kinds of difficulties. The required
  design changes are likely to be so disruptive
  that the software requirements upon which the
  design is based and which provides the rationale
  for everything are violated. Either the
  requirements must be modified, or a substantial
  change in the design is required. In effect the
  development process has returned to the origin
  and one can expect up to a l00-percent overrun in
  schedule and/or costs." - Royce 1970

27
(No Transcript)
28
Development Process Models

• Different approaches to sequencing the
  engineering activities
• Waterfall
• Incremental/Prototyping
• Evolutionary Prototyping
• Spiral
• Rapid Application Development (RAD)
• precursor to agile methods
• Rational Unified Process (RUP)
• unification of previous models
• Agile eg. XP, Scrum, Crystal, Feature Driven,
  Adaptive

1st five are in van Vliet (Ch. 3). Last 2 are too
new.
29
Plan to throw one away

• In most projects, the first system built is
  barely usable. It may be too slow, too big,
  awkward in use, or all three. There is no
  alternative but to start again, smarting but
  smarter, and build a redesigned version in which
  these problems are solved. Where a new system
  concept or new technology is used, one has to
  build a system to throw away, for even the best
  planning is not so omniscient as to get it right
  the first time.
• The management question, therefore, is not
  whether to build a pilot system and throw it
  away. You will do that. The only question is
  whether to plan in advance to build a throwaway,
  or to promise to deliver the throwaway to
  customers.
• Fred Brooks, The Mythical Man-Month

30
Incremental/Prototyping

• Building in smaller steps
• increment planning is a fundamental technique,
  essentially in all processes
• Prototyping can be a basis for planning in
  increments
• Requirements
• Design
• Code
• Any throwaway work product is in effect a
  prototype

31
Prototyping (Requirements)
32
Prototyping (requirements)

• problem
• customer defines general objectives but unable to
  identify detailed input, processing, or output
  requirements
• solution

33
Requirements prototyping
System requirements
Aim by prototyping and refining the requirements
during the analysis stage, we reduce the risk of
designing from incorrect or incomplete software
requirements.
Software requirements
Analysis
Gather requirements from customer
Build prototype
Customer evaluates prototype
Analysis Quick design
Refine prototype
Design
34
Dangers of requirements prototyping

• customer sees a working system keen to use
  it!
• however, he is not aware that system
• is unlikely to be maintainable
• is almost certainly of low quality
• then asks for the delivery of the prototype (with
  minor fixes) rather having it thrown away
• solutions
• ensure customer understands reason for prototype
  and buys into the process before beginning
• build the prototype using technologies (hardware,
  OS, programming language, etc.) that make it
  obviously unsuitable for delivery

35
Prototyping (Design)
36
Prototyping (design)

• problem
• some aspects of the design are poorly understood
  and are therefore high risk
• solution

37
Design Prototyping
System requirements
Aim by prototyping and refining the the design
until it meets the key design criteria, we reduce
the risk that we will implement an inadequate or
flawed design.
Software requirements
Analysis
Design
Identify critical design criteria
Build prototype
Review critical design criteria
Quick design
Refine prototype
Coding
38
The danger of design prototyping

• to get a prototype working quickly developers
  make implementation compromises
• programming language, library, algorithms,
  database, user-interface toolkit, etc. are chosen
  that are inappropriate for later implementation
• can be hard to make the transition
• timing can be too soon or too late
• even worse try to use choices appropriate for
  prototyping in the actual system implementation
• safeguards
• document compromises as they are made
• insist on full review of the choices made in the
  prototype when prototype usefulness is complete,
  explicitly guarding against inappropriate
  carry-over from the prototype

39
The Incremental Model and Prototyping applied at
the Code levelIterative Development
40
Iterative Development

• problem
• the customer asks for too much, the difficulty in
  estimating complexity of a feature, long
  development time-frames
• solution

Identify critical design criteria
Build prototype
Review critical design criteria
Quick design
Refine prototype
41
Iterative Development
System requirements
Aim by implementing a selected set of key
features in each iteration, we reduce the risks
that secondary features will be given priority
and that more will be attempted than can be done
in a given time
Software requirements
Analysis
Design
Coding
42
The Dangers of Iterative Development

• customer may want more features than can be done
  in a cycle
• refactoring may be needed as part of the cycle
• initial operational capability may require a more
  traditional approach
• solutions
• strict adherence to a time-box
• customer and developer must work together

- starting to look agile more later
43
Observation

• For some applications, a prototype may be
  sufficient to meet end users needs. These
  applications are characterized by
• low technical risk
• immediate requirement
• possibility of close user involvement
• availability of a development environment
• in which developers can work fast enough to
  support prototyping
• but which is small/efficient/robust enough to be
  suitable for the deployment environment
• may be able to make use of fourth-generation
  languages (4GLs) or executable models (eg.
  Rose/RT)

44
Development Process Models

• Different approaches to sequencing the
  engineering activities
• Waterfall
• Incremental/Prototyping
• Evolutionary Prototyping
• Spiral
• Rapid Application Development (RAD)
• precursor to agile methods
• Rational Unified Process (RUP)
• unification of previous models
• Agile eg. XP, Scrum, Crystal, Feature Driven,
  Adaptive

1st five are in van Vliet (Ch. 3). Last 2 are too
new.
45
Evolutionary Prototyping
46
Evolutionary Prototyping
Gather requirements from customer
Build prototype
Customer evaluates prototype
Quick design
Derive design
Refine prototype
Tune system
Operate and maintain
47
Evolutionary Prototyping

• Next slide shows the EPRAM (Evolutionary
  Prototyping with Risk Analysis and Mitigation)
  model
• Evolving Beyond Requirements Creep A Risk-Based
  Evolutionary Prototyping Model, Ryan A. Carter,
  Annie I. Antón, Aldo Dagnino and Laurie Williams.
  IEEE 5th International Symposium on Requirements
  Engineering (RE'01), Toronto, Canada, pp. 94-101,
  27-31 August 2001
• Based on CMM
• EPRAM represents one of many versions of
  evolutionary prototyping

48
(No Transcript)
49
Dangers of Evolutionary Prototyping

• missing comprehensive design phase conceptual
  integrity may suffer
• ensure developers are aware of the necessity for
  conceptual integrity during development
• attempt to clarify or refactor the design during
  the derive design phase
• may be impossible to adequately tune performance
  once system is complete
• management will be tempted to skip design
  derivation and tuning phases
• without strong management control, possible to
  iterate endlessly difficult to schedule

50
Prototyping approaches

• The key feature of prototyping approaches is to
  rapidly develop simple models of the system to
  either
• get rapid customer feedback and clarify
  requirements, or
• reduce uncertainty about design aspects that are
  poorly understood
• A key question that must be asked for the
  effective application of prototyping
• What do you prototype first?

51
Summary

• both the waterfall prototyping models are aimed
  a reducing risk and improving communication
• the waterfall reduces risk of requirements/design
  thrashing by insisting they are finalized and
  signed off early
• the prototyping model reduces risk of
  misunderstanding user needs by giving user
  constant feedback (as prototypes) while system
  evolves
• relative risks vary by project, change through
  project life span
• so, develop software lifecycle model that
  explicitly recognizes risk and communications as
  key drivers next