Ch 2: Software Life

Ch 2: Software Life-Cycle
CSCI 4320
Ideal Software Development
Actual Software Development
• Software developers make mistakes
• Clients requirements or environment
changes while software is being
The Software Development Life-Cycle
involves many iterations (loops).
Bus Fare Machine Program
GOAL: Fare machines on bus must recognize real dollar bills.
• Episode 1: The first version is implemented
• Episode 2: A fault is found
– The product is too slow because of an implementation fault (double
precision instead of single precision used)
– Changes to the implementation are begun
• Episode 3: The requirements change
– A different/faster dollar recognition algorithm has been discovered
• Episode 4: A new design is adopted
– New design is more accurate.
- Development is complete
• Epilogue: A few years later, these problems recur
Teal Tractors Business Software
Goal : Handle sales, inventory and commissions for
• While the Teal Tractors software product is being
constructed, the requirements change
• The company is expanding into Canada
– Additional sales regions must be added
– Canadian taxes and other business aspects that are handled
– Two different currencies, US and CANADA
Moving Target Problem
• Growing companies are always going to change
• Even if the reasons for the change are good, the
software product can be adversely impacted
– Dependencies will be induced
– Potentially cause a regression fault (A fault in an
apparently unrelated part of the software)
– feature creep
• There is no solution to the moving target problem
Life-Cycle Models
Waterfall Life
Extreme Programming and Agile
• Synchronize-and-Stabilize
• Spiral
• Iteration and Incrementation
Iteration and Incrementation
The basic software development process is
– Each successive version is intended to be
closer to its target than its predecessor
An Incremental Process
– Miller’s Law : concentrate on ~ 7 chunks
– Use stepwise refinement
– handle in order of current importance
Iteration and Incrementation
• Idea:
– Project is divided into several mini projects
– Each project goes through all phases,
extending existing artifacts
• Multiple opportunities to check for faults
• Always have a working version of
• No phase is complete until documentation for that phase
is complete.
• Relying solely on written specifications may lead to
products that don’t meet client’s needs.
Code-and Fix
• Developers simply throw code together
and rework it as many times as necessary
• No Requirements written
• May work well for small programs
• Maintenance Nightmare!
Rapid Prototyping
• Build a rapid-prototype and let client
interact and experiment with it.
• Developers draw up specifications from
rapid prototype and develop true system
• Key: Speed is of the essence
• The rapid prototype is discarded but
lessons learned are retained.
Open-Source Life-Cycle
• A single individual has an idea for a program and
makes it available free of charge
• Users become co-developers
– Report and correct defects
– Add additional functionality
– Port program to new environment
• Individuals are not paid to participate
• Release new versions after minimal testing
Open Source Software
• 100,000 open-source projects at
• ½ have never attracted a team to work on the
• Majority have never been completed
• But there are cases where it has been benefical
– Operating Systems (Linux), web browsers (Firefox),
compilers (gcc), web servers(Apache)
Extreme Programming and Agile
New Approach: responsive to change, collaborate
with client
• Client picks features based on time and cost
• Build is broken down into tasks
• Pair programming
– Two programmers work on one computer
– Alternate typing every 15 or 20 minutes
– Team members change coding partners daily
• Client works with team at all times
Extreme Programming and Agile
• No individual can work overtime for 2 weeks
• No specialization: All members of team work on
analysis, design, coding
• No overall design step before the various builds
Agile Processes
• Less emphasis on analysis and design
• Goal is to deliver working software frequently
• Have short meetings often
• Successful for small-scale projects where
customer requirements are vague
Synchronized and Stabilize
Expected Features are prioritized
Work is divided into several builds
Each build is carried out by several teams
working in parallel
• At the end of the day all teams
synchronize and test
• Waterfall method with each phase
preceded by risk analysis
• Uses prototypes to mitigate risks
• Advantage: Emphasis on alternatives and
constraints supports the reuse of existing
• Problem: When do you determine if a
phase has been sufficiently tested?
Comparison of Life-Cycle Models
Figure 2.12