CSC 492
The Practice of
Software Engineering
Lecture 3
University of Mount Union
Software Life Cycle Models
Software Life Cycle Models
Every program (no matter what size) has several
distinct phases that occur in its development
Requirements (what)
Design (how)
Coding (how)
Testing
Release
Maintenance/Evolution (change)
Software Life Cycle Models
Every life cycle model is a variation on two fundamental types
Do each phase in order
Software Life Cycle Models
The software life cycle describes the sequence in which all major activities will occur
May cover from concept development to product
retirement
May include planning, reviews, documentation, and
baselines
Code and Fix Model
In other words, the lack of any SLC model
lack of formal SE process
No formal requirements, documentation, QA, testing, etc. Works okay for quick, disposable tasks
(e.g. proof of concept) - no maintenance
Works well for single person projects
Waterfall Model
One of the first models to be developed at the dawn of SE Covers all major software development activities
Based on an assembly-line mentality
Assumption is you finish phase N - 1 before proceeding to
phase N
Waterfall Model
Originated from the manufacturing and construction
industries
Highly structured physical environments in which
after-the-fact changes are prohibitively costly (if not impossible).
Since no formal software development methodologies
existed at the time, this hardware-oriented model was simply adopted for software development.
It turns out that software is different from other products
small changes are almost free (debugging and recompiling) even major changes
Properties of Waterfall Model
Works well for:
Known requirements AND known technologies Weak or inexperienced staff (lots of structure) High quality requirements (must have!)
Problems:
Very rigid if used without modification
For the majority of projects, it is nearly impossible to define
requirements adequately to make Waterfall work
Few signs of ongoing progress (easy to fall behind)
In practice, unmodified waterfall is almost never used
Waterfall With Subprojects
After Requirements and Architectural Design of project,
break out next 3 phases [Detailed Design, Coding, and Unit Testing] for several subprojects
Then integrate the whole system and do complete system
testing for a single release of the product
Pros include faster development of known tasks, and
possibly better use of resources
Cons include unforeseen dependencies between
subprojects
Waterfall With Feedback
Take the phases of a classic waterfall and add explicit
feedback loops.
Recognizes that you have to start work with incomplete
requirements, design, tests, etc.
You will have to go back and do re-work Problems:
Much more difficult to establish schedule & benchmarks When is product complete (when to stop)?
Staged Delivery
Also known as: Rapid Application Development (RAD)
Like Waterfall model for Requirements Analysis and
Architectural Design; then [Design, Code, Test, and Deliver] the product in stages
Project defined from the start and is delivered in stages,
based on feature priorities
Increases chance of getting key features into product Key idea: overlapping stages
Spiral LCM
First incremental delivery model.
Focuses on addressing major risk areas for a project
(requirements, architecture, etc.)
Each “mini-project” addresses one or more risk areas,
then start the next mini-project
Spiral LCM
Each mini-project has four steps:
1) Determine objectives, alternatives, and constraints for
this mini-project
2) Identify and resolve risks
3) develop products/deliverables and test 4) plan for next iteration
Spiral LCM
Risks: a potential problem that may affect the project, its
timing and/or its budget lawsuits
equipment failure buggy release
inadequate performance/quality
Risks may be classified during Requirements Analysis as
low, medium or high
Risk Exposure: (probability of risk) (cost of occurrence) Team should address areas of highest risk exposure first
Spiral LCM
Pros:
Handles risk very well Cons:
Very complicated
Hard to define and resolve many mini-projects Hard to stay focused on overall project goals
Evolutionary Prototyping
(aka Incremental Prototyping)
Develop visible parts of system first, then work on the rest
of the system, prioritizing requirements as you get them
Keep refining the prototype until customer accepts it as
the final product
Good for changing requirements, or a poorly understood
Evolutionary Prototyping
Very hard to plan full project from the start Risky, but has good track record
Pros:
improved progress visibility, good customer and end user input to requirements
Cons:
danger of unrealistic schedule, budget, and progress expectations possibility of bad design
low maintainability
Design-To-Schedule
The usual Requirements Analysis and Architectural
Design; then do stages of [design, code, and fully test] until time or money runs out. Then deliver product.
Good for non-critical portions of product. Put highest priority features in first stages.
Usually done when you’ve got a hard deadline Needs very good schedule estimates to succeed
Evolutionary Delivery
Cross between Evolutionary Prototyping and Staged
Delivery
Draft initial Requirements Analysis and Architectural
Design
do {
Prioritize the features
Develop the product within a fixed timeframe
Deliver it to the customer, receive feedback to modify requirements
} while ( needed );
Evolutionary Delivery
Pros:
good project visibility reduced risk
strong customer interaction with requirements definition Cons:
reduced project control
may result in feature creep or unrealistic estimates This is the way many software products are developed
Extreme Programming
A relatively new lightweight model (meaning less
documentation and fewer process controls)
Useful for small teams (up to 20 developers; 10-12 is
optimal)
Main focus: customer satisfaction Relies on:
Heavy customer involvement
Continuous Unit Testing and reviews Pair Programming
How to Choose a Life Cycle?
Questions to consider: How well known and stable are your requirements? How big is the project? (How many features?)
How well known and stable is your architecture? What are your reliability needs?
Will there be many versions of your product? How much risk do you expect?
How to Choose a Life Cycle?
Questions to consider (continued): How constrained is the schedule? (drop-dead date?) Will midcourse corrections be likely?
Does the customer need visible progress?
Does your management need visible progress?
How sophisticated is your team with respect to the life
cycle you pick?
How to Choose a Life Cycle?
See table 7.1 in section 7.11 of McConnell’s Rapid Development, 3/e (available on Safari)
Some guidelines:
High Risk, Big Budget: Spiral
Legacy system or well-defined reqs: Waterfall, or one of
the Waterfall variants
Visible Progress needed, working model needed quickly,
features can be added later: Staged Delivery
How to Choose a Life Cycle?
More guidelines: Lots of changes probable, or requirements not well
understood: Evolutionary Prototyping or Evolutionary
Delivery
My favorite (not that my opinion matters a great deal…):
Evolutionary Delivery
important consideration: skills and experience of team
