ISM 6121

1
ISM 6121

• Alternative Software Development Lifecycle
  Methodologies

2
A Silver Bullet???

• No Such Law for Software Development
• Costs are Increasing
• Projects are Falling Behind Schedule
• Projects are Failing

Whats Happening to that Project???
3
Purpose of LifeCycle Methodology

• Provide Structure
• Prescriptive in Nature
• Reduce Project Failures

4
Need for RAD?

• Why do we need RAD?
• Response to problems with Waterfall
• Changing Business Environment
• Other?

5
SoRapid Development??

• It Is
• Developing software more quickly than you
  currently do by employing a methodical,
  comprehensive strategic plan
• What about
• Reusability Maintainability
• It isnt
• A silver bullet or quick fix
• Code-like-hell
• Ignoring Structured Development
• Using the Latest Software Tool

6
Agarwal et al Findings

• Developers use RAD features to deliver SW faster
• Developers do NOT use RAD features for quality
  and maintainability
• Design and Rigorous Methodology
• Decline in Requirements Planning and Modeling
• Tools / Iterations make it easy to catch and fix
  errors down the road

7
Errors Are Costly
8
Why Rapid Development?

• Must Complete Projects Faster
• Streamline Front-End
• Delivery Windows are Shrinking
• Review of 17 major DOD software contracts (1982)
• Average 28 month schedule was missed by 20 months
  
• 1 four-year project took seven years
• No project was completed on time

9
Rapid Development
Four Pillars
10
The Balancing Act (pick any 2)
11
Fast Development

• All-Out Rapid Development
• You achieve the best possible schedule but
  substantially degrade the outcome of cost and
  product

Geometric Truth If you have to have it now,
then either the product or price will have to be
adjusted.
12
(No Transcript)
13
Oh Look at the Time!!

• Managing Perceptions
• Highlight Visibility
• Make Your Schedule More Realistic
• Get the User Involved
• Get the User Involved ?
• Managing Reality
• Move toward Efficient Or Rapid Development
• Choose a Life Cycle that Matches Goals

14
McConnel Methodologies

• Pure Waterfall
• ISM 4113, 500?
• Waterfall Tweaks
• Sashimi
• Waterfall with Subprojects
• Staged Delivery
• Design to Schedule
• Evolutionary Delivery

• Other
• Code and Fix
• Spiral
• Waterfall with Risk Reduction
• Evolutionary Prototyping
• Design-to-Tools

15
Commonalties

• Requirements Determination
• Involve End-User
• Deliver Software

16
Code Fix
DANGEROUS!!!!
17
Preliminary Investigation
Analysis
Logical Design
Physical Design
Implementation
Waterfall Life Cycle
Maintenance
18
Waterfall

• Requirements Determination
• Primary Focus
• 4/6 stages
• Document / Model Driven
• DFDs, ERDs, etc.
• End User Involvement
• Extensive early
• Minimal late
• Software Delivery
• Last step

• Pros
• Provides structure for complex systems
• Cons
• Not Flexible
• Requirements need to be completely specified
• Dependent Stages
• No Prototypes

19
Sashimi (Modified Waterfall)
Preliminary Investigation
Any Realistic Differences from Waterfall???
Requirements Analysis
Logical Design
Physical Design
Implementation
Maintenance
20
Sashimi

• Waterfall Fix
• Overlapping Stages
• New Problems
• How do you know when your at the end of a stage
• Increased management of teams working on
  different stages
• Keep communications open

• Requirements Determination
• Similar to Pure
• End-User Involvement
• Similar to Pure
• Software Delivery
• End of Life Cycle

21
Waterfall w/Subprojects
Dont Wait For Complete Signoff
22
Waterfall with Subprojects

• Waterfall Fix
• System broken down into small interdependent
  modules (OO?)
• Design work for trivial can enter Implementation
  stage earlier
• New Problems
• Unforeseen Interdependencies between modules

• Requirements Determination
• Less Emphasis then Pure
• End-User Involvement
• Similar to Pure
• Software Delivery
• Staged Delivery

23
Staged Delivery
Families of Features
...
24
Waterfall with Staged Delivery

• Waterfall Fix
• Deliver Software in Stages to User (rather than
  at the end)
• New Problem
• Discover that Stage 2 needs component from Stage
  2 n

• Requirements Determination
• Less Emphasis then Pure
• End-User Involvement
• Similar to Pure
• Software Delivery
• Staged Delivery

25
Design to Schedule
26
Design to Schedule

• Similar to Staged Delivery
• May never Deliver Latter Stages
• Critical Issues of this Methodology
• Prioritizing Stages
• New Problem
• Inefficient Methodology
• Time Spent in Specifying Later Stages that never
  get produced

• Requirements Determination
• Less Emphasis then Pure
• End-User Involvement
• Similar to Pure
• Software Delivery
• Staged Delivery

27
Evolutionary Delivery
Deliver final version
28
Evolutionary Delivery

• Waterfall Fix
• Produce Prototypes
• Earlier software delivery to end-user
• More Flexibility
• New Problem
• How much end-user feedback do you accept

• Requirements Determination
• Less Emphasis then Pure
• End-User Involvement
• More and Earlier then Pure
• Software Delivery
• Multiple Versions
• Earlier in the Process

29
Spiral Model
30
Spiral Model

• On each iteration
• Develop objectives, alternatives, and constraints
• Identify and resolve risks
• Evaluate alternatives
• Develop the variables for that iteration, and
  verify that they are correct
• Plan the next iteration
• Commit to an approach for the next iteration

Each Phase Refines and Defines
31
Evolutionary Prototyping
Refine prototype until acceptable
Design and implement initial prototype
Initial concept
Complete and release prototype
32
Risk of these Alternatives

• We all followed the process
• it should workRight
• This reminds me of a story

33
Apollo 1
- May 25, 1961
...I believe that this nation should commit
itself to achieving the goal, before this decade
is out, of landing a man on the Moon and
returning him safely to the Earth. ...We propose
to accelerate the development of the appropriate
lunar space craft. We propose to develop
alternate liquid and solid fuel boosters, much
larger than any now being developed, until
certain which is superior.
34
Apollo 1

• Kennedys mandate required a massive effort from
  NASA if it was to have a chance of succeeding.
• Structured development techniques were
  immediately decided upon and made formal.
• The only way to accomplish the goal was to adopt
  a sub-system parallel development approach.
• define bounded sub-systems within the defined
  system boundary
• develop simultaneously using a formal methodology

35
Apollo 1 Parallel Development
Primary Methodology SDLC
Primary Methodology SDLC
Primary Methodology SDLC
Enviromental Bio-Medical
Electrical/ CapComm
Escape Systems
Minimum 90 second procedure
Pure O2 Atmosphere in Capsule
Hi-efficiency Gold Contacts
Hi-tensile plastic insulators
Manually actuated ratchet-type release for latches
Sealed Biomedical Atmosphere in Spacesuit
Assumed N O2 Atmosphere
January 27, 1967
36
January 27, 1967 - 100pm
- Grissom, Chaffee, White enter the capsule. -
Grissom reports a strange odor in his spacesuit
O2 loop. - High O2 indicator triggers master
alarm - Environmental Control determines the
high indication was a result of astronaut
movement. - Intermittent communications became
regular between Grissom and the control room
at 540pm. - At 631pm both Chaffee and White
announce Fire in the cockpit.
What caused this system failure to occur?
- Autopsy showed death by CO asphyxia - 27 others
were treated for smoke inhalation - Investigation
revealed that fire started in a wire bundle -
White had been able to make part of one full turn
of the ratchet-style latch release system
before being overcome.
37
Mis-specified System Boundaries
38
Final Thoughts

• This is the risk faced by several of these
  techniques
• Iterative Prototyping
• Evolutionary Delivery
• Waterfall w/Subprojects
• Waterfall still seems to dominate
• Must allow flexibility
• RequiredNot Desired