Process

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 Output
Step

Output
Input Input Output
Step 1 Step 2

Input

Sequential or linear process


Concurrent Process

Output
Input Input Output
Step 1 Step 3

Input
Step 2
Output
Input

Parallel or concurrent process


Iterative Process

Output
Input Input Output
Step 1 Step 3

Input
Step 2
Output
Input

Iterative process


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.


Process model: Linear
 An arrangement of process steps.

Output
Input Input Output
Step 1 Step 2

Linear model Input


Process model: Concurrent

Concurrent
Output
Input Input Output
Step 1 Step 3

Input
Step 2
Output
Input


Process model: Iterative

Input Output Input Output
Step 1 Step 3
Input
Step 2
Output
Input

Iterative


Software Development Process
 Steps correspond to one or more tasks related to software
development.
 Tasks:

o Requirements gathering o Integration
o Requirements analysis o Test
o Design
o Delivery
o Coding o Maintenance
o Training
 Software life cycle: Software Life Cycle consists of all
phases from its inception until its retirement. These are:
Inception, elaboration, construction, transition.

Models of Software Life Cycle
 Build and fix
 Waterfall (classic)
 Rapid prototyping
 Incremental
 Spiral
 Unified


Build and fix model [1]
Idea or client request

Build first version

Modify until client satisfied

Operations mode

Development
Retirement
Maintenance


 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].


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


Waterfall model [1]
Requirements phase

Specification phase

Design phase

Retirement
Verification done at Implementation phase
the end of each
phase.
Integration phase
Development

Maintenance Operations mode

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.

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.

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.


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.


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 ?


Incremental model [1]
Requirements phase

Specification phase

Architectural Design

Retirement
Verification done at For each build:
the end of each Detailed design, coding,
phase. Integration, test, delivery.
Development

Maintenance Operations mode

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


 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?

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.


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


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
 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

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

The Unified Process

Software
User’s Software
Development
requirements System
Process


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?


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


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


The Unified Process
 Look at the whole process
 Life cycle
 Artifacts
 Workflows
 Phases
 Iterations


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:
 inception
 elaboration
 construction
 transition


The Life of the Unified Process
Time

Inception Elaboration Construction Transition

Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration
1 1 1 1

Release 1
A cycle with its phases and its iterations

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 build-
and-fix.

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.


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 ?


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.


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%


Standish Report: Failure Statistics

 Success rate: Large companies: 9%
 Medium: 16.2%
 Small: 28%

 Resolution type 2: Large: 61.5%
 Medium: 46.7%
 Small: 50.4%

 Resolution type 3: Medium: 37.1%,
 Large: 29.5%
 Small: 21.6%


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%


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%


Standish Report: Success Profile [1]

Project Success Factors % of Responses

3. User Involvement 5.9%

5. Executive Management Support 13.9%

7. Clear Statement of Requirements 13.0%

9. Proper Planning 9.6%

11. Realistic Expectations 8.2%


Standish Report: Success Profile [2]

Project Success Factors % of Responses
3. Smaller Project Milestones 7.7%

5. Competent Staff 7.2%

7. Ownership 5.3%

9. Clear Vision & Objectives 2.9%

11. Hard-Working, Focused Staff 2.4%

13. Other 13.9%


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


Standish Report: Success Potential

Success Criteria Points DMV CON HYATT ITAMARATI

1. User Involvement 19 NO ( 0) NO ( 0) YES (19) 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 29 100 85

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.


Capability Maturity Model (CMM)

Capability maturity levels:

Level 1: Initial Worst
Level 2: Repeatable
Level 3: Defined
Level 4: Managed
Level 5: Optimizing Best


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.


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.


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.


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.


CMM Levels [4]

Optimized

Continuous process improvement is enabled by quantitative
feedback from the process and from piloting innovative ideas
and technologies.


Key Process Areas [1]
Optimizing
Defect prevention
Technology change management
Process change management

Managed:
Quantitative process management
Software quality management


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


Maturity and product quality [1]
Results from 34 Motorola Government Electronics
Division (GED) projects
-------------------- - ---------------------------------------- --------
CMM L evel # Projects Relative Faults/MEA SL Relative
Dec rease in Produ ctivity
Du ration
-------------------- - ---------------------------------------- - -------

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


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.


CMM Documents ?
http://www.sei.cmu.edu/cmm/cmms/cmms.html


Process

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Process

Ähnlich wie Process (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Process