Software Development Process: Life
Cycle Models
Aditya P. Mathur
Department of Computer Science
Purdue University, West Lafayette
Last Update: Tuesday August 19, 2003
Aug 19, 2003
BITSC461/IS341 Software Engineering
Objectives

What is a process?

What is Software Development Process (SDP) ?

How is SDP organized (life cycle models)?

How is process maturity measured?

What are the benefits of a “good” process ?
Aug 19, 2003
BITSC461/IS341 Software Engineering
2
Process
Input
Input
Output
Step
Output
Step 1
Input
Step 2
Output
Input
Sequential or linear process
Aug 19, 2003
BITSC461/IS341 Software Engineering
3
Concurrent Process
Input
Output
Step 1
Step 2
Input
Step 3
Output
Input
Output
Input
Parallel or concurrent process
Aug 19, 2003
BITSC461/IS341 Software Engineering
4
Iterative Process
Input
Output
Step 1
Step 2
Input
Step 3
Output
Input
Output
Input
Iterative process
Aug 19, 2003
BITSC461/IS341 Software Engineering
5
Features of a process

One or more steps.

Each step is well defined.


Input and output of each step is well defined and
observable.
Start and end of a step can be identified.
Aug 19, 2003
BITSC461/IS341 Software Engineering
6
Process model: Linear

An arrangement of process steps.
Input
Output
Step 1
Linear model
Aug 19, 2003
Input
Step 2
Output
Input
BITSC461/IS341 Software Engineering
7
Process model: Concurrent
Input
Output
Step 1
Step 2
Concurrent
Input
Step 3
Output
Input
Output
Input
Aug 19, 2003
BITSC461/IS341 Software Engineering
8
Process model: Iterative
Input
Output Input
Step 1
Step 2
Output
Step 3
Input
Output
Input
Iterative
Aug 19, 2003
BITSC461/IS341 Software Engineering
9
Software Development Process


Steps correspond to one or more tasks related to software
development.
Tasks:
Integration
o
Requirements gathering
o
o
Requirements analysis
o
Design
Coding
o
Test
Delivery
o
Maintenance
o
Training
o
o

Software life cycle: Software Life Cycle consists of all phases
from its inception until its retirement. These are: Inception,
elaboration, construction, transition.
Aug 19, 2003
BITSC461/IS341 Software Engineering
10
Models of Software Life Cycle

Build and fix

Waterfall (classic)

Rapid prototyping

Incremental

Spiral

Unified
Aug 19, 2003
BITSC461/IS341 Software Engineering
11
Build and fix model [1]
Idea or client request
Build first version
Modify until client satisfied
Operations mode
Development
Maintenance
Aug 19, 2003
Retirement
BITSC461/IS341 Software Engineering
12
Build and fix model [2]



Product is constructed without specifications.
There is no explicit design. However, a design will
likely evolve in the mind of the developer.
The approach might work for small programming
projects [TA 162/252].
Aug 19, 2003
BITSC461/IS341 Software Engineering
13
Build and fix model [3]



Cost of fixing an error increases as one moves away
from the phase in which the error was injected.
There is a good chance that many errors will be found
in the operations phase thereby leading to high cost of
maintenance.
Rarely used in commercial projects.
Aug 19, 2003
BITSC461/IS341 Software Engineering
14
Waterfall model [1]
Requirements phase
Specification phase
Design phase
Retirement
Verification done at
the end of each
phase.
Development
Implementation phase
Integration phase
Operations mode
Maintenance
Aug 19, 2003
BITSC461/IS341 Software Engineering
15
Waterfall model [2]




Popular in the 70’s.
Requirements are determined and verified with the
client and members of the SQA group.
Project management plan is drawn, cost and duration
estimated, and checked with the client and the SQA
group
Then the design (i.e. “How is the product going to do
what it is supposed to do.”) begins and the project
proceeds as in the figure.
Aug 19, 2003
BITSC461/IS341 Software Engineering
16
Waterfall model [3]



Each phase terminates only when the documents are
complete and approved by the SQA group.
Notice the feedback loop between the Design phase
and the Specifications phase.
Maintenance begins when the client reports an error
after having accepted the product. It could also begin
due to a change in requirements after the client has
accepted the product.
Aug 19, 2003
BITSC461/IS341 Software Engineering
17
Waterfall model: Advantages


Disciplined approach
Careful checking by the Software Quality Assurance
Group at the end of each phase.

Testing in each phase.

Documentation available at the end of each phase.
Aug 19, 2003
BITSC461/IS341 Software Engineering
18
Waterfall model: Disdvantages



Documents do not always convey the entire picture.
Specification documents are detailed and difficult to
read/understand for the client.
Feedback from one phase to another might be too late
and hence expensive.
Aug 19, 2003
BITSC461/IS341 Software Engineering
19
Rapid prototyping model



A working model of the product is developed (quickly,
1-3 months). Serves to elicit requirements.
Client interacts with the prototype; specifications are
developed.
Subsequent phases, design, coding etc., follow.
Feedback loops less likely and fewer.
Should the prototype be discardded or refined ?
Aug 19, 2003
BITSC461/IS341 Software Engineering
20
Incremental model [1]
Requirements phase
Specification phase
Architectural Design
Retirement
Verification done at
the end of each
phase.
For each build:
Detailed design, coding,
Integration, test, delivery.
Development
Operations mode
Maintenance
Aug 19, 2003
BITSC461/IS341 Software Engineering
21
Incremental model [2]





Product architecture is designed. It serves as the main
driver of the development process.
Features are prioritised and increments defined.
Product is designed, implemented, and integrated as a
series of incremental builds.
A build contains code from various modules to provide
the desired functionality.
A new build integrates code from previous build and
new code.
Aug 19, 2003
BITSC461/IS341 Software Engineering
22
Incremental model [3]

Client can begin using the first build.

Facilitates early adoption by the client.

Client pays in increments; financial benefit.

Design of the initial architecture is a difficult step. Poor
architecture may lead to lots of changes in builds.
Should we construct builds in parallel?
Aug 19, 2003
BITSC461/IS341 Software Engineering
23
Unified Development Process [1]





Key features: Iterative development; OO analysis and
design.
Development organized as a series of short iterations
Each iteration produces a working, executable,
product that might not be a deliverable.
No rush to code. Aslso, not a long drwan design
process.
Lots of visual modeling aids. Unified Modeling
Language (UML) used.
Aug 19, 2003
BITSC461/IS341 Software Engineering
24
Unified Development Process [2]



Early iterations seek feedback from the customer. Risk
and value to customer is managed through early
feedback.
Customer is engaged continuously in evaluation and
requirements gathering.
Architecture is built during early iterations.
Aug 19, 2003
BITSC461/IS341 Software Engineering
25
Unified Development Process [3]
Aug 19, 2003
BITSC461/IS341 Software Engineering
26
The Unified Process

Why a Process?




Software projects are large, complex,
sophisticated
time to market is key
many facets involved in getting to the end
Common process should




Aug 19, 2003
integrate the many facets
provide guidance to the order of activities
specify what artifacts need to be developed
offer criteria for monitoring and measuring a
project
BITSC461/IS341 Software Engineering
27
The Unified Process





Component based - meaning the software system is built as a
set of software components interconnected via interfaces
Uses the Unified Modeling Language (UML)
Use case driven
This is what makes
Architecture-centric
the Unified process
Iterative and incremental
Unique
Component: A physical and replaceable part of a system that conforms to
and provides realization of a set of interfaces.
Interface: A collection of operations that are used to specify a service of a
class or a component
Aug 19, 2003
BITSC461/IS341 Software Engineering
28
The Unified Process
User’s
requirements
Aug 19, 2003
Software
Development
Process
BITSC461/IS341 Software Engineering
Software
System
29
The Unified Process

Use Case driven



A use case is a piece of functionality in the
system that gives a user a result of value
Use cases capture functional
requirements
Use case answers the question: What is
the system supposed to do for the user?
Aug 19, 2003
BITSC461/IS341 Software Engineering
30
The Unified Process

Architecture centric




similar to architecture for building a house
Embodies the most significant static and dynamic
aspects of the system
Influenced by platform, OS, DBMS etc.
Primarily serves the realization of use cases
Aug 19, 2003
BITSC461/IS341 Software Engineering
31
The Unified Process

Iterative and Incremental


commercial projects continue many months
and years
to be most effective - break the project into
iterations


Every iteration - identify use cases,create
a design, implement the design
Every iteration is a complete development
process
Aug 19, 2003
BITSC461/IS341 Software Engineering
32
The Unified Process

Look at the whole process





Aug 19, 2003
Life cycle
Artifacts
Workflows
Phases
Iterations
BITSC461/IS341 Software Engineering
33
The Life of the Unified Process



Unified process repeats over a
series of cycles
Each cycle concludes with a
product release
Each cycle consists of four phases:




Aug 19, 2003
inception
elaboration
construction
transition
BITSC461/IS341 Software Engineering
34
The Life of the Unified Process
Time
Inception
Iteration
1
Iteration
Elaboration Construction
Iteration
1
Iteration
Iteration
Iteration
1
Transition
Iteration
Iteration
1
Release 1
A cycle with its phases and its iterations
Aug 19, 2003
BITSC461/IS341 Software Engineering
35
Life Cycle Models: Summary [1]




Build and fix: Acceptable for short programs that do
not require maintenance.
Waterfall: Disciplined approach, document driven;
delivered product may not meet client needs.
Rapid prototyping: Ensures that delivered product
meets client needs; might become a build-and-fix
model.
Incremental: Maximizes early return on investment;
requires open architecture; may degenerate into buildand-fix.
Aug 19, 2003
BITSC461/IS341 Software Engineering
36
Life Cycle Models: Summary [2]


Spiral: Risk driven, incorporates features of the above
models; useful for very large projects
UDP: Iterative, supports OO analysis and design; may
degenerate into code-a-bit-test-a-bit.
Aug 19, 2003
BITSC461/IS341 Software Engineering
37
Objectives



Why do software projects fail/succeed?
How is process maturity measured ? Key Process
Areas?
How to do requirements analysis? What are UML, use
cases, domain model, actors ?
Aug 19, 2003
BITSC461/IS341 Software Engineering
38
Standish Report [1995]
Company categorization by revenue:

Large company: >$500M

Medium company: $200-500M

Small comp;any: $100-200M
Sample size: 365 respondants, 8380 applications.
Aug 19, 2003
BITSC461/IS341 Software Engineering
39
Standish Report: Project categorization: Success/failure

Resolution Type 1: On time, on budget, all features.
16.2%

Resolution Type 2: Completed, over time, over budget, fewer
features.
52.7%

Resolution Type 3: Cancelled during the development cycle.
31.1%
Aug 19, 2003
BITSC461/IS341 Software Engineering
40
Standish Report: Failure Statistics

Success rate: Large companies: 9%



Resolution type 2: Large: 61.5%



Medium: 16.2%
Small: 28%
Medium: 46.7%
Small: 50.4%
Resolution type 3: Medium: 37.1%,


Large: 29.5%
Small: 21.6%
Aug 19, 2003
BITSC461/IS341 Software Engineering
41
Standish Report: Cost Overruns
Cost Overruns
% of Responses
Under 20%
15.5%
21 - 50%
31.5%
51 - 100%
29.6%
101 - 200%
10.2%
201 - 400%
8.8%
Over 400%
4.4%
Aug 19, 2003
BITSC461/IS341 Software Engineering
42
Standish Report: Time Overruns
Time Overruns % of Responses
Under 20%
13.9%
21 - 50%
18.3%
51 - 100%
20.0%
101 - 200%
35.5%
201 - 400%
11.2%
Over 400%
1.1%
Aug 19, 2003
BITSC461/IS341 Software Engineering
43
Standish Report: Success Profile [1]
Project Success Factors
% of Responses
1. User Involvement
5.9%
2. Executive Management Support
13.9%
3. Clear Statement of Requirements
13.0%
4. Proper Planning
9.6%
5. Realistic Expectations
8.2%
Aug 19, 2003
BITSC461/IS341 Software Engineering
44
Standish Report: Success Profile [2]
Project Success Factors
% of Responses
6. Smaller Project Milestones
7.7%
7. Competent Staff
7.2%
8. Ownership
5.3%
9. Clear Vision & Objectives
2.9%
10. Hard-Working, Focused Staff
2.4%
11. Other
13.9%
Aug 19, 2003
BITSC461/IS341 Software Engineering
45
Standish Report: Failure stories
California DMV:
Started 1987.
Project cancelled: 1993.
Cost:$45M
American airlines:
1994
Settled lawsuit with
Hilton/Marriott/Budget-rent-a car
CONFIRM car rental project failed
Aug 19, 2003
BITSC461/IS341 Software Engineering
46
Standish Report: Success Potential
Success Criteria
Points
DMV
1. User Involvement
19
NO ( 0) NO ( 0) YES (19)
2. Management Support
16
NO ( 0) YES (16) YES (16)
YES (16)
3. Clear Requirements
15
NO ( 0) NO ( 0) YES (15)
NO ( 0)
5. Realistic Expectations 10
YES (10) YES (10) YES (10)
YES (10)
10. Hard-Working Staff
3
NO ( 0) YES ( 3) YES ( 3)
YES ( 3)
TOTAL
100
10
85
Aug 19, 2003
CON
29
HYATT
100
BITSC461/IS341 Software Engineering
ITAMARATI
YES
47
Capability Maturity Model (CMM)
Process maturity is a measure of the discipline used by an
organization during the development of a software product.
CMM assists in determining how mature a process is.
Purpose:
To assess and help improve process in software development
organizations.
Aug 19, 2003
BITSC461/IS341 Software Engineering
48
Capability Maturity Model (CMM)
Capability maturity levels:
Level 1:
Level 2:
Level 3:
Level 4:
Level 5:
Aug 19, 2003
Initial
Repeatable
Defined
Managed
Optimizing
Worst
Best
BITSC461/IS341 Software Engineering
49
CMM Levels [1]
Initial
The software process is characterized as ad hoc, and
occasionally even as chaotic. Few processed are
defined, and success depends on individual effort.
Lacks: Reasonable process.
Aug 19, 2003
BITSC461/IS341 Software Engineering
50
CMM Levels [2]
Repeatable
Basic project management processes are established to track
cost, schedule and functionality. the necessary process
discipline is in place to repeat earlier successes on projects
with similar applications.
Lacks: Complete process.
Aug 19, 2003
BITSC461/IS341 Software Engineering
51
CMM Levels [3]
Defined
The software process for both management and engineering
activities is documented, standardized and integrated into a
standard software process for the organization.
All projects use an approved, tailored version of the
organization's standard software process for developing and
maintaining software.
Lacks: Predictable outcomes.
Aug 19, 2003
BITSC461/IS341 Software Engineering
52
CMM Levels [4]
Managed
Detailed measures of the software process and product
quality are collected. Both the software process and products
are quantitatively understood and controlled.
Lacks: Mechanism for process improvement.
Aug 19, 2003
BITSC461/IS341 Software Engineering
53
CMM Levels [4]
Optimized
Continuous process improvement is enabled by quantitative
feedback from the process and from piloting innovative ideas
and technologies.
Aug 19, 2003
BITSC461/IS341 Software Engineering
54
Key Process Areas [1]
Optimizing
Defect prevention
Technology change management
Process change management
Managed:
Quantitative process management
Software quality management
Aug 19, 2003
BITSC461/IS341 Software Engineering
55
Key Process Areas [2]
Defined
Organization process focus
Training programs
Integrated software management
Peer reviews
Repeatable
Requirements management
Software project planning
Software quality assurance
Software configuration management
Aug 19, 2003
BITSC461/IS341 Software Engineering
56
Maturity and product quality [1]
Results from 34 Motorola Government Electronics
Division (GED) projects
-----------------------------------------------------------CMM Level # Projects
Relative
Faults/MEASL
Decrease in
Duration
-------------------- ----------------------------------------
-------Relative
Productivity
1
3
1
--
--
2
9
3.2
890
1.0
3
5
2.7
411
0.8
4
8
5.0
205
2.3
5
9
--------------------
7.8
126
- ----------------------------------------
- -------
2.8
- -------
MEASL: Million Equivalent Assembler Source Lines
Aug 19, 2003
BITSC461/IS341 Software Engineering
57
Maturity and product quality [2]
Raytheon:
Equipment Division moved from Level 1 to Level 3. This
resulted in a productivity gain of 2.0 and a $7.70 return on
every dollar invested.
Aug 19, 2003
BITSC461/IS341 Software Engineering
58
CMM Documents ?
http://www.sei.cmu.edu/cmm/cmms/cmms.html
Aug 19, 2003
BITSC461/IS341 Software Engineering
59