Software Life Cycle Analysis
2003
Mateusz Żochowski, Marcin Borzymek
Why Planning?





2003
Streamline project
Improve development speed
Improve quality
Improve project tracking and control
Improve client relations
Mateusz Żochowski, Marcin Borzymek
Inappropriate or Lack of
a Lifecycle Model




2003
Slow work
Repeated work
Unnecessary work
Frustration
Mateusz Żochowski, Marcin Borzymek
Lifecycle Models








2003
Pure Waterfall
Modified Waterfalls
Spiral
Code-and-Fix
Evolutionary Prototypes
Staged Delivery
Design-to Schedule
Extreme Programming Life Cycle
Mateusz Żochowski, Marcin Borzymek
Pure Waterfall



2003
Orderly sequence of steps
Review at the end of each phase
Discontinuous phases
Mateusz Żochowski, Marcin Borzymek
Waterfall
Rapid Development, 1996
2003
Mateusz Żochowski, Marcin Borzymek
Waterfall Benefits



2003
Finds errors in early stages
Minimizes planning overhead since it can be
done up front
Structure minimizes wasted effort, so it works
well for technically weak or inexperienced staff
Mateusz Żochowski, Marcin Borzymek
Waterfall Disadvantages




2003
No tangible results until the end
Inflexible
Excessive documentation
Backing up to address mistakes is difficult
Mateusz Żochowski, Marcin Borzymek
Waterfall Summary
- performs well for products with clearly
understood requirements
- it's weaknesses frequently make it inadvisable
when rapid development is needed. In those
cases, modified models may be more effective.
2003
Mateusz Żochowski, Marcin Borzymek
Modified Waterfalls


2003
Waterfall with Subprojects
Waterfall with Risk Reduction
Mateusz Żochowski, Marcin Borzymek
Waterfall With Subprojects

Subprojects
Rapid Development, 1996
2003
Mateusz Żochowski, Marcin Borzymek
Waterfall With Subprojects
Benefits


2003
Logically independent subsystems
Each subproject can proceed at own pace
Mateusz Żochowski, Marcin Borzymek
Waterfall With Subprojects
Disadvantages

2003
Unforeseen interdependencies
Mateusz Żochowski, Marcin Borzymek
Waterfall With Risk Reduction

Risk-reduction spiral at top
Rapid Development, 1996
2003
Mateusz Żochowski, Marcin Borzymek
Waterfall With Risk Reduction
Benefits



2003
Reduce risk
Best of Waterfall and Risk Reduction models
Not limited to requirements
Mateusz Żochowski, Marcin Borzymek
Spiral (Cinnamon Roll)



Risk-oriented
Miniprojects
Iterations
Determine objectives, alternatives, and constraints
 Identify and resolve risks
 Evaluate alternatives
 Develop deliverables
 Plan the next iteration
 Commit to an approach for the next iteration

2003
Mateusz Żochowski, Marcin Borzymek
Spiral (Cinnamon Roll)
Rapid Development, 1996
2003
Mateusz Żochowski, Marcin Borzymek
Spiral Benefits



2003
Management control
Early indication of fatal risks
Flexible
Mateusz Żochowski, Marcin Borzymek
Spiral Disadvantages


2003
Complicated
Requires attentive, and knowledgeable
management
Mateusz Żochowski, Marcin Borzymek
Possible Applications

High risk projects
Poorly understood requirements
 Poorly understood architecture
 Potential performance problems
 Problems in the underlying technology


Combine with other lifecycle models
Terminate with waterfall or other lifecycle
 Incorporate other lifecycle models as iterations

2003
Mateusz Żochowski, Marcin Borzymek
Spiral Summary
- it's beneficial to run a series of riskreduction iterations which can be followed by a
waterfall or other non-risk-based lifecycle
2003
Mateusz Żochowski, Marcin Borzymek
Code-and-Fix


Informal
Unstructured
Rapid Development, 1996
2003
Mateusz Żochowski, Marcin Borzymek
Code-and-Fix Benefits


2003
No overhead
Requires little expertise
Mateusz Żochowski, Marcin Borzymek
Code-and-Fix Disadvantages



2003
No means of assessing progress
No quality management
No risk management
Mateusz Żochowski, Marcin Borzymek
Possible Applications



2003
Small proof-of-concept programs
Short-lived demos
Throwaway prototypes
Mateusz Żochowski, Marcin Borzymek
Evolutionary Prototyping



2003
Develop system concept as the project
progresses
Begin with the most visible aspects
Prototype
Rapid Development, 1996
Mateusz Żochowski, Marcin Borzymek
Evolutionary Prototyping
Benefits


2003
Steady, visible signs of progress
Less documentation
Mateusz Żochowski, Marcin Borzymek
Evolutionary Prototyping
Disadvantages


2003
Impossible to schedule release
Excuse to use code-and-fix development
Mateusz Żochowski, Marcin Borzymek
Possible Applications




2003
Rapidly changing requirements
Customer reluctant to commit to requirements
Do not understand application area
Strong demand for development speed
Mateusz Żochowski, Marcin Borzymek
Evolutionary Delivery



2003
Similar to Evolutionary Prototyping
Refine version based upon customer feedback
Emphasizes core of the system
Mateusz Żochowski, Marcin Borzymek
Evolutionary Delivery
Rapid Development, 1996
2003
Mateusz Żochowski, Marcin Borzymek
Evolutionary Delivery Benefits



2003
Can accommodate customer requests
Allows a degree of midtime changes
Provides visible results
Mateusz Żochowski, Marcin Borzymek
Evolutionary Delivery
Disadvantages


2003
Difficult to schedule release
May lead to Code-and-Fix development
Mateusz Żochowski, Marcin Borzymek
Design-to-Schedule


2003
Prioritize features
Unsure if final release will be reached
Rapid Development, 1996
Mateusz Żochowski, Marcin Borzymek
Design-to-Schedule Benefits


2003
Ensure product release for a particular date
Most important features completed first
Mateusz Żochowski, Marcin Borzymek
Design-to-Schedule
Disadvantages

Wasted effort specifying unfinished stages

2003
Could complete one or more stages if time was not
wasted specifying several unfinished stages
Mateusz Żochowski, Marcin Borzymek
Possible Applications


2003
Must have product by a specific date
Unconfident in scheduling abilities
Mateusz Żochowski, Marcin Borzymek
Design-to-Tools

Include functionality only if directly supported
by existing software tools
Rapid Development, 1996
2003
Mateusz Żochowski, Marcin Borzymek
Design-to-Tools Benefits


Maximum functionality vs. time
Can be combined with other lifecycle models
Initial spiral
 Throwaway prototype
 Staged delivery
 Evolutionary delivery
 Design-to-schedule

2003
Mateusz Żochowski, Marcin Borzymek
Design-to-Tools Disadvantages




2003
Less control
Unable to implement all features
Unable to implement features as intended
Dependent on commercial software producers
Mateusz Żochowski, Marcin Borzymek
Possible Applications

2003
Exceptionally time-sensitive projects
Mateusz Żochowski, Marcin Borzymek
Extreme Programming
2003
Mateusz Żochowski, Marcin Borzymek
User Stories


2003
written by the customers as things that the
system needs to do for them
in the format of about three sentences of text in
the customers terminology without technosyntax
Mateusz Żochowski, Marcin Borzymek
Release Plan



2003
create iteration plans for each individual
iteration.
estimate each user story in terms of ideal
programming weeks
estimate user stories velocity
Mateusz Żochowski, Marcin Borzymek
Spike solutions



2003
is a very simple program to explore potential
solutions
figure out answers to tough technical or design
problems
helps to estimate project velocity
Mateusz Żochowski, Marcin Borzymek
Iteration

2003
During an iteration the user stories selected
during the iteration planning meeting will be
translated into acceptance tests.
Mateusz Żochowski, Marcin Borzymek
Acceptance Tests



2003
The customer specifies scenarios to test when a
user story has been correctly implemented
No tests passed = no progress
A user story is not considered complete until it
has passed its acceptance tests
Mateusz Żochowski, Marcin Borzymek
Small Releases

2003
Small units of functionality can be released into
the customer's environment early in the project that gives valuable feedback
Mateusz Żochowski, Marcin Borzymek
Choosing An Appropriate
Lifecycle






2003
How well are requirements understood
How well is system architecture understood
How much reliability is needed
How likely are future revisions
How much risk
Need to make midcourse corrections
Mateusz Żochowski, Marcin Borzymek
Choosing An Appropriate
Lifecycle (cont.)



2003
Need to provide visible progress to customers
Need to provide visible progress to management
How sophisticated is the model
Mateusz Żochowski, Marcin Borzymek
Strengths & Weaknesses
Rapid Development, 1996
2003
Mateusz Żochowski, Marcin Borzymek
Strengths & Weaknesses (cont.)
2003
Rapid Development, 1996
Mateusz Żochowski, Marcin Borzymek
Questions?
2003
Mateusz Żochowski, Marcin Borzymek