Software Life Cycle Analysis

1
Software Life Cycle Analysis
2
Why Planning?

• Streamline project
• Improve development speed
• Improve quality
• Improve project tracking and control
• Improve client relations

3
Inappropriate or Lack of a Lifecycle Model

• Slow work
• Repeated work
• Unnecessary work
• Frustration

4
Lifecycle Models

• Pure Waterfall
• Modified Waterfalls
• Spiral
• Code-and-Fix
• Evolutionary Prototypes
• Staged Delivery
• Design-to Schedule
• Extreme Programming Life Cycle

5
Pure Waterfall

• Orderly sequence of steps
• Review at the end of each phase
• Discontinuous phases

6
Waterfall
Rapid Development, 1996
7
Waterfall Benefits

• 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

8
Waterfall Disadvantages

• No tangible results until the end
• Inflexible
• Excessive documentation
• Backing up to address mistakes is difficult

9
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.

10
Modified Waterfalls

• Waterfall with Subprojects
• Waterfall with Risk Reduction

11
Waterfall With Subprojects

• Subprojects

Rapid Development, 1996
12
Waterfall With Subprojects Benefits

• Logically independent subsystems
• Each subproject can proceed at own pace

13
Waterfall With Subprojects Disadvantages

• Unforeseen interdependencies

14
Waterfall With Risk Reduction

• Risk-reduction spiral at top

Rapid Development, 1996
15
Waterfall With Risk Reduction Benefits

• Reduce risk
• Best of Waterfall and Risk Reduction models
• Not limited to requirements

16
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

17
Spiral (Cinnamon Roll)
Rapid Development, 1996
18
Spiral Benefits

• Management control
• Early indication of fatal risks
• Flexible

19
Spiral Disadvantages

• Complicated
• Requires attentive, and knowledgeable management

20
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

21
Spiral Summary

• - it's beneficial to run a series of
  risk-reduction iterations which can be followed
  by a waterfall or other non-risk-based lifecycle
•  

22
Code-and-Fix

• Informal
• Unstructured

Rapid Development, 1996
23
Code-and-Fix Benefits

• No overhead
• Requires little expertise

24
Code-and-Fix Disadvantages

• No means of assessing progress
• No quality management
• No risk management

25
Possible Applications

• Small proof-of-concept programs
• Short-lived demos
• Throwaway prototypes

26
Evolutionary Prototyping

• Develop system concept as the project progresses
• Begin with the most visible aspects
• Prototype

Rapid Development, 1996
27
Evolutionary Prototyping Benefits

• Steady, visible signs of progress
• Less documentation

28
Evolutionary Prototyping Disadvantages

• Impossible to schedule release
• Excuse to use code-and-fix development

29
Possible Applications

• Rapidly changing requirements
• Customer reluctant to commit to requirements
• Do not understand application area
• Strong demand for development speed

30
Evolutionary Delivery

• Similar to Evolutionary Prototyping
• Refine version based upon customer feedback
• Emphasizes core of the system

31
Evolutionary Delivery
Rapid Development, 1996
32
Evolutionary Delivery Benefits

• Can accommodate customer requests
• Allows a degree of midtime changes
• Provides visible results

33
Evolutionary Delivery Disadvantages

• Difficult to schedule release
• May lead to Code-and-Fix development

34
Design-to-Schedule

• Prioritize features
• Unsure if final release will be reached

Rapid Development, 1996
35
Design-to-Schedule Benefits

• Ensure product release for a particular date
• Most important features completed first

36
Design-to-Schedule Disadvantages

• Wasted effort specifying unfinished stages
• Could complete one or more stages if time was not
  wasted specifying several unfinished stages

37
Possible Applications

• Must have product by a specific date
• Unconfident in scheduling abilities

38
Design-to-Tools

• Include functionality only if directly supported
  by existing software tools

Rapid Development, 1996
39
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

40
Design-to-Tools Disadvantages

• Less control
• Unable to implement all features
• Unable to implement features as intended
• Dependent on commercial software producers

41
Possible Applications

• Exceptionally time-sensitive projects

42
Extreme Programming
43
User Stories

• 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 techno-syntax

44
Release Plan

• create iteration plans for each individual
  iteration.
• estimate each user story in terms of ideal
  programming weeks
• estimate user stories velocity

45
Spike solutions

• is a very simple program to explore potential
  solutions
• figure out answers to tough technical or design
  problems
• helps to estimate project velocity

46
Iteration

• During an iteration the user stories selected
  during the iteration planning meeting will be
  translated into acceptance tests.

47
Acceptance Tests

• 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

48
Small Releases

• Small units of functionality can be released into
  the customer's environment early in the project -
  that gives valuable feedback

49
Choosing An Appropriate Lifecycle

• 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

50
Choosing An Appropriate Lifecycle (cont.)

• Need to provide visible progress to customers
• Need to provide visible progress to management
• How sophisticated is the model

51
Strengths Weaknesses
Rapid Development, 1996
52
Strengths Weaknesses (cont.)
Rapid Development, 1996
53
Questions?