CSE 403

Software Lifecycle Models

Reading:
Rapid Development Ch. 7, 25
(further reading: Ch. 21, 35, 36, 20)

These lecture slides are copyright (C) Marty Stepp, 2007, with significant content taken from slides
written by Valentin Razmov. They may not be rehosted, sold, or modified without expressed
permission from the author. All rights reserved.1
 Lecture outline
 The software lifecycle
 evaluating models

 Lifecycle models
 code-and-fix
 waterfall
 spiral
 evolutionary prototyping
 staged delivery
 design-to-schedule

2
 Ad-hoc development
 ad-hoc development: creating software without any
formal guidelines or process

 Some disadvantages of ad-hoc development:

 some important actions (testing, design) may go ignored
 not clear when to start or stop doing each task
 does not scale well to multiple people
 not easy to review or evaluate one's work

 a common observation: The later a problem is found in

software, the more costly it is to fix.

3
 The software lifecycle
 software lifecycle: series of steps / phases, through
which software is produced
 can take months or years to complete

 goals of each phase:

 mark out a clear set of steps to perform
 produce a tangible document or item
 allow for review of work
 specify actions to perform in the next phase

4
 Lifecycle phases
 standard phases
 Requirements Analysis & Specification
 High-level (Architectural) Design
 Detailed (Object-oriented) Design
 Implementation, Integration, Debugging
 Testing, Profiling, Quality Assurance
 Operation and Maintenance

 other possible phases

 risk assessment: examining what actions are critical and
performing them first (part of Spiral model)
 prototyping: building a rough/partial version of the product
and using it to guide design decisions

5
 One view of SW cycle phases

Requirements Requirements Arch. Detailed Implemen-

Testing
Elicitation Analysis Design Design tation

Implemented
Expressed in By
Structured By Realized By
Terms Of Verified
By

class...
class...
class... ?
class....?
Use Case Application Solution
Domain Subsystems Source Test
Model Domain
Objects Code Cases
Objects

6
 Some software models
 Several models for developing software have been
attempted, varying the order and frequency in which
these stages occur:
 code-and-fix: write some code, debug it, repeat until finished
 waterfall: perform the standard phases (requirements, design,
code, test) in sequence
 spiral: assess risks at each step, and do the most critical
action immediately
 evolutionary prototyping: build an initial requirement spec,
code it, then "evolve" the spec and code as needed
 staged delivery: build initial requirement specs for several
releases, then design-and-code each in sequence

7
 Model pros/cons
 value of models
 decomposing workflow
 understanding and managing the process
 as a management tool

 limitations of models
 a model is just a model
 abstracts away some aspects and highlights others
 artificial constraints
 compromises with model are often necessary
 (as with almost everything in SE)
 risk of overemphasizing the process
 the process is not the end in itself; product delivery is

8
 Evaluating models
 Criteria for evaluation of models
 Risk management
 Quality / cost control
 Predictability
 Visibility of progress
 Customer involvement and feedback

 Theme: Overall aim for good, fast, and cheap.

But you can't have all three at the same time.

9
 Code-and-fix model

code first
version

modify until
client is satisfied

operations mode

retirement

10
 Problems with code-and-fix
 benefits
 no planning whatsoever; little management overhead
 applicable for very small projects and short-lived prototypes

 What are some reasons not to use the code-and-fix

model?

 code becomes expensive to fix (bugs are not found

until late in the process)
 code didn't match user's needs (no requirements!)
 code was not planned for modification, not flexible 11
 Waterfall model

req. change
requirements

verify
design

verify
implementation

test

operations

retirement

12
Detailed waterfall view

13
 Waterfall issues
 waterfall model is perhaps the most common model for
software development
 we will use a waterfall-like model in this course
 benefits
 formal, standard; has specific phases with clear goals
 good feedback loops between adjacent phases
 What are some drawbacks to this method?

- rigid, too linear; not very adaptable to change in the product

- requires a lot of planning up front (not always easy / possible)
- assumes that requirements will be clear and well-understood
- costly to "swim upstream" by going back to a previous phase
- Nothing to show to anxious customers ("We're 90% done!")
14
 Modified waterfalls
 sashimi (waterfall with overlapping phases): phases
overlap
 team can learn insights from later cycles to aid earlier ones

 waterfall with subprojects

 can begin coding simple features while designing tough ones

 What are some problems with these models?

- harder to track progress of the overall project

- communication can be tougher
- unforeseen dependencies can occur

15
 Spiral model (Boehm)
Cumulative
cost

Progress
through
Determine steps Evaluate alternatives,
objectives, identify, resolve risks
alternatives,
constraints
(OAC) Risk
Assessment
Concrete
Specification
OAC Risk
Assessment
Abstract
Barry Boehm, USC Specifcation
OAC Risk Risk
Requirements Assessment Control
Risk
OAC Control
Risk
Commit Control
Review
partition Requirements
Concept of
Plan
Operation
Requirements
Abstract Specification Abstract
Plan Specification Concrete
Requirements Specification
Validation
Concrete Specification
Plan
Abstract Specification
Validation

Software Concrete
Plan next phases Development Plan Specification Validation Develop, verify
and Verification next-level product

16
Another view of the spiral

17
 Another view of spiral model
Risk Assessment
Req. Change
Requirements
Risk Assessment
Verify
Design
Risk Assessment
Verify
Implementation

Test
Adds a Risk Analysis
step to each phase
Operations

(phases may not be

completed in this order Retirement
any more!)
18
 Spiral details
 breaks up the project into mini-projects based on risk
 purpose: risk reduction
 example: in first phase,
 great when charting new territories (with high risks)

 steps taken at each loop of the spiral (roughly):

 determine objectives, options, constraints
 identify risks
 evaluate options to resolve the risks
 develop and verify any deliverable items
 plan the next phase
 commit to approach for next phase

19
 Spiral benefits
 benefits of spiral
 provides early indication of unforeseen problems
 as costs increase, risks decrease
 always addresses the biggest risk first
 focuses attention on reuse
 accommodates changes, growth
 eliminates errors and unattractive choices early
 limits to how much is enough (not too much design, reqs, etc)
 treats development, maintenance same way

20
 Spiral problems
 What are some drawbacks to the spiral model?

- complicated
- relies on developers to have risk-assessment expertise
- possibly more management overhead to assess risk
- need for more elaboration of project steps
(clearer milestones)
- matching to contract software
(doesn't work well when you're bound to a fixed
inflexible contract)

21
 Evolutionary prototype model

requirements

verify
arch. design

verify
for each build:
perform detailed
design, implement,
test, deliver

operations

retirement

22
 Evolutionary details
 idea: build an initial requirement spec, code it, then
"evolve" the spec and code as needed
 each repetition is an "evolution" of the code, not necessarily
bug fixes

 What is the difference between evolutionary

prototyping and evolutionary delivery?

 e. delivery is a mixing of evolutionary prototyping

and staged delivery
 focuses more on internals, parts of system unlikely
to be changed by customer feedback
 e. prototyping rushes initial release with perhaps less
focus on requirements and design
23
 Benefits of evolutionary
 benefits of evolutionary prototyping
 produces steady signs of progress
 useful when requirements are not very well known, changing
rapidly, or customer is non-committing
 allows close customer involvement
 "What do you think of this version?"
 can improve customer confidence / satisfaction
 customers must be available on a short notice to give feedback

24
 Problems with evolutionary
 What are some problems with this model?

 sometimes difficult to distinguish from code-and-fix

 assumes user's initial spec will be flexible; fails for:
 separate pieces that must then be integrated
 "information sclerosis": temporary fixes become permanent
constraints
 bridging; new software trying to gradually replace old
 unclear how many iterations will be needed to finish
 wrong order: makes lots of hard-to-change code

25
 Staged delivery
 staged delivery
 waterfall-like beginnings, then develop in short stages
 requires tight coordination with documentation, management,
and marketing
 can ship at any time during implementation
 from the outside (to customers) it looks like a successful
delivery even if it is not the final goal the team aimed for

 How does staged delivery differ from evolutionary

prototyping?

 In staged delivery, requirements are better known

ahead of time rather than discovered through customer
feedback after each release.
26
 Design-to-*
 design-to-schedule
 useful when you absolutely need to ship by a certain date
 similar to the staged delivery model
 but less flexible because of the fixed shipping date
 requires careful prioritization of features and risks to address

 design-to-tools
 a model where the project only incorporates features that are
easy to implement by using or combining existing components
 reduces development time at cost of losing control of project

27
 Which model is best?
 The choice of a model depends on the project
circumstances and requirements.
 A good choice of a model can result in a vastly more
productive environment than a bad choice.
 A cocktail of models is frequently used in practice to
get the best of all worlds.
 care must be applied; some models can't mix easily or at all

 Reminder: criteria for judging models:

 Risk management
 Quality / cost control
 Predictability
 Visibility of progress
 Customer involvement and feedback
28
 Model category matrix
 Rate each model 1-5 in each of the categories shown:
Risk Quality/ Predict- Visibility Customer
mgmt. cost ctrl. ability involvement
code-and-fix

waterfall

spiral

evolutionary
prototyping
staged delivery

design-to-
schedule

29
 Possible answer
 Rate each model 1-5 in each of the categories shown:
Risk Quality/ Predict- Visibility Customer
mgmt. cost ctrl. ability involvement
code-and-fix
1 1 1 3 2
waterfall
2 4 3 1 2
spiral
5 5 3 3 3
evolutionary
prototyping 3 3 2 5 5
staged delivery
3 5 3 3 4
design-to-
schedule 4 3 5 3 2
30