Title: EEEGEF 492'05 Process Models: Waterfall and Prototyping
1EEE/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
2Contents 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
3Engineering Activities In Software Development
4Engineering Activities (partial list)
- Analysing
- Prototyping
- Designing
- Implementing
- VV
- Documenting
- Deploying
Renewing, refreshing, replacing repeat above as
needed
5The Software Process
- Why use a software process
- To improve software quality
- To improve communication
- To manage and reduce risk
- the alternative may be chaos
6Process Models
7Development 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
8Development 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.
9Models 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
10Example
- 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
11A 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
12The Simplest reasonable model
Problem statement
- Order should be
- analysis
- implementation
Analysis
Implement
Simple Waterfall Model (Winston Royce, 1970)
Released code
13Scaling 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
14The Waterfall ModelRoyce 1970
15The 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
16Waterfall 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
17Economic 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
18Empirical 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
19Factor-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
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
20Steps 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
21An Incremental Waterfall Model
Product Design
a sequence of increments is more usual (as in
Boehm 81)
22Comparative Staffing Curves
Waterfall vs Incremental Development
strict waterfall (Rayleigh curve)
Required personnel
incremental
Development timeline
23Strengths 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
24Strengths 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
25Weaknesses 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
26Weaknesses 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)
28Development 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.
29Plan 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
30Incremental/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
31Prototyping (Requirements)
32Prototyping (requirements)
- problem
- customer defines general objectives but unable to
identify detailed input, processing, or output
requirements - solution
33Requirements 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
34Dangers 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
35Prototyping (Design)
36Prototyping (design)
- problem
- some aspects of the design are poorly understood
and are therefore high risk - solution
37Design 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
38The 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
39The Incremental Model and Prototyping applied at
the Code levelIterative Development
40Iterative 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
41Iterative 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
42The 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
43Observation
- 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)
44Development 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.
45Evolutionary Prototyping
46Evolutionary Prototyping
Gather requirements from customer
Build prototype
Customer evaluates prototype
Quick design
Derive design
Refine prototype
Tune system
Operate and maintain
47Evolutionary 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)
49Dangers 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
50Prototyping 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?
51Summary
- 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