software development process life cycle models l.
Download
Skip this Video
Download Presentation
Software Development Process: Life Cycle Models

Loading in 2 Seconds...

play fullscreen
1 / 59

Software Development Process: Life Cycle Models - PowerPoint PPT Presentation


  • 316 Views
  • Uploaded on

Software Development Process: Life Cycle Models. Aditya P. Mathur. Department of Computer Science. Purdue University, West Lafayette. Last Update: Tuesday August 19, 2003. Objectives. What is a process?. What is Software Development Process (SDP) ?.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Software Development Process: Life Cycle Models' - coby


Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
software development process life cycle models
Software Development Process: Life Cycle Models

Aditya P. Mathur

Department of Computer Science

Purdue University, West Lafayette

Last Update: Tuesday August 19, 2003

BITSC461/IS341 Software Engineering

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

BITSC461/IS341 Software Engineering

process

Input

Output

Output

Input

Output

Input

Input

Process

Step

Step 1

Step 2

Sequential or linear process

BITSC461/IS341 Software Engineering

concurrent process

Output

Input

Input

Step 1

Step 3

Output

Input

Step 2

Output

Input

Concurrent Process

Parallel or concurrent process

BITSC461/IS341 Software Engineering

iterative process

Output

Input

Input

Step 1

Step 3

Output

Input

Step 2

Output

Input

Iterative Process

Iterative process

BITSC461/IS341 Software Engineering

features of a 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.

BITSC461/IS341 Software Engineering

process model linear

Output

Input

Output

Input

Step 1

Step 2

Linear model

Input

Process model: Linear
  • An arrangement of process steps.

BITSC461/IS341 Software Engineering

process model concurrent

Concurrent

Output

Input

Input

Step 1

Step 3

Output

Input

Step 2

Output

Input

Process model: Concurrent

BITSC461/IS341 Software Engineering

process model iterative

Output

Input

Input

Output

Step 1

Step 3

Input

Step 2

Output

Input

Iterative

Process model: Iterative

BITSC461/IS341 Software Engineering

software development process
Software Development Process
  • Steps correspond to one or more tasks related to software development.
  • Tasks:
  • Integration
  • Requirements gathering
  • Test
  • Requirements analysis
  • Delivery
  • Design
  • Maintenance
  • Coding
  • Training
  • Software life cycle: Software Life Cycle consists of all phases from its inception until its retirement. These are: Inception, elaboration, construction, transition.

BITSC461/IS341 Software Engineering

models of software life cycle
Models of Software Life Cycle
  • Build and fix
  • Waterfall (classic)
  • Rapid prototyping
  • Incremental
  • Spiral
  • Unified

BITSC461/IS341 Software Engineering

build and fix model 1

Build first version

Modify until client satisfied

Operations mode

Development

Maintenance

Retirement

Build and fix model [1]

Idea or client request

BITSC461/IS341 Software Engineering

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

BITSC461/IS341 Software Engineering

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

BITSC461/IS341 Software Engineering

waterfall model 1

Specification phase

Design phase

Retirement

Implementation phase

Development

Maintenance

Integration phase

Operations mode

Waterfall model [1]

Requirements phase

Verification done at the end of each phase.

BITSC461/IS341 Software Engineering

waterfall model 2
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.

BITSC461/IS341 Software Engineering

waterfall model 3
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.

BITSC461/IS341 Software Engineering

waterfall model advantages
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.

BITSC461/IS341 Software Engineering

waterfall model disdvantages
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.

BITSC461/IS341 Software Engineering

rapid prototyping model
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 ?

BITSC461/IS341 Software Engineering

incremental model 1

Specification phase

Architectural Design

Retirement

For each build:

Detailed design, coding,

Integration, test, delivery.

Development

Maintenance

Operations mode

Incremental model [1]

Requirements phase

Verification done at the end of each phase.

BITSC461/IS341 Software Engineering

incremental model 2
Incremental model [2]
  • Product is designed, implemented, and integrated as a series of incremental builds.
  • Product architecture is designed. It serves as the main driver of the development process.
  • Features are prioritised and increments defined.
  • A build contains code from various modules to provide the desired functionality.
  • A new build integrates code from previous build and new code.

BITSC461/IS341 Software Engineering

incremental model 3
Incremental model [3]
  • Client pays in increments; financial benefit.
  • Client can begin using the first build.
  • Facilitates early adoption by the client.
  • 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?

BITSC461/IS341 Software Engineering

unified development process 1
Unified Development Process [1]
  • Each iteration produces a working, executable, product that might not be a deliverable.
  • Key features: Iterative development; OO analysis and design.
  • Development organized as a series of short iterations
  • No rush to code. Aslso, not a long drwan design process.
  • Lots of visual modeling aids. Unified Modeling Language (UML) used.

BITSC461/IS341 Software Engineering

unified development process 2
Unified Development Process [2]
  • Architecture is built during early iterations.
  • 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.

BITSC461/IS341 Software Engineering

unified development process 3
Unified Development Process [3]

BITSC461/IS341 Software Engineering

the unified process
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

BITSC461/IS341 Software Engineering

the unified process28
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
  • Architecture-centric
  • Iterative and incremental

This is what makes

the Unified process

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

BITSC461/IS341 Software Engineering

the unified process29
The Unified Process

User’s

requirements

Software

Development

Process

Software

System

BITSC461/IS341 Software Engineering

the unified process30
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?

BITSC461/IS341 Software Engineering

the unified process31
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

BITSC461/IS341 Software Engineering

the unified process32
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

BITSC461/IS341 Software Engineering

the unified process33
The Unified Process
  • Look at the whole process
    • Life cycle
    • Artifacts
    • Workflows
    • Phases
    • Iterations

BITSC461/IS341 Software Engineering

the life of the unified process
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

BITSC461/IS341 Software Engineering

the life of the unified process35
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

BITSC461/IS341 Software Engineering

life cycle models summary 1
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.

BITSC461/IS341 Software Engineering

life cycle models summary 2
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.

BITSC461/IS341 Software Engineering

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

BITSC461/IS341 Software Engineering

standish report 1995
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.

BITSC461/IS341 Software Engineering

standish report project categorization success failure
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%

BITSC461/IS341 Software Engineering

standish report failure statistics
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%

BITSC461/IS341 Software Engineering

standish report cost overruns
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%

BITSC461/IS341 Software Engineering

standish report time overruns
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%

BITSC461/IS341 Software Engineering

standish report success profile 1
Standish Report: Success Profile [1]

Project Success Factors % of Responses

User Involvement 5.9%

Executive Management Support 13.9%

Clear Statement of Requirements 13.0%

Proper Planning 9.6%

Realistic Expectations 8.2%

BITSC461/IS341 Software Engineering

standish report success profile 2
Standish Report: Success Profile [2]

Project Success Factors % of Responses

Smaller Project Milestones 7.7%

Competent Staff 7.2%

Ownership 5.3%

Clear Vision & Objectives 2.9%

Hard-Working, Focused Staff 2.4%

Other 13.9%

BITSC461/IS341 Software Engineering

standish report failure stories
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

BITSC461/IS341 Software Engineering

standish report success potential
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 1029 100 85

BITSC461/IS341 Software Engineering

capability maturity model cmm
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.

BITSC461/IS341 Software Engineering

capability maturity model cmm49
Capability Maturity Model (CMM)
  • Capability maturity levels:
  • Level 1: Initial Worst
      • Level 2: Repeatable
      • Level 3: Defined
      • Level 4: Managed
      • Level 5: Optimizing Best

BITSC461/IS341 Software Engineering

cmm levels 1
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.

BITSC461/IS341 Software Engineering

cmm levels 2
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.

BITSC461/IS341 Software Engineering

cmm levels 3
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.

BITSC461/IS341 Software Engineering

cmm levels 4
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.

BITSC461/IS341 Software Engineering

cmm levels 454
CMM Levels [4]

Optimized

Continuous process improvement is enabled by quantitative

feedback from the process and from piloting innovative ideas

and technologies.

BITSC461/IS341 Software Engineering

key process areas 1
Key Process Areas [1]

Optimizing

Defect prevention

Technology change management

Process change management

Managed:

Quantitative process management

Software quality management

BITSC461/IS341 Software Engineering

key process areas 2
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

BITSC461/IS341 Software Engineering

maturity and product quality 1

Re

s

u

lt

s

fr

om

3

4

M

o

t

o

rol

a

Go

v

e

rn

me

nt

El

e

c

t

ro

n

ic

s

D

iv

i

s

i

o

n

(

G

E

D

)

p

roj

ec

t

s

--------------------

-

----------------------------------------

-

-------

C

M

M L

e

ve

l

#

P

r

o

j

ec

ts

R

e

l

at

iv

e

F

au

lt

s

/M

EA

SL

R

e

l

at

iv

e

Dec

r

e

a

se

i

n

P

rodu

ct

iv

it

y

Du

r

a

ti

on

--------------------

-

----------------------------------------

-

-------

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

--------------------

-

----------------------------------------

-

-------

M

E

A

S

L

:

M

illi

on

E

qu

i

va

l

en

t

A

s

s

e

m

bl

e

r

S

ourc

e

Li

nes

Maturity and product quality [1]

BITSC461/IS341 Software Engineering

maturity and product quality 2
Maturity and product quality [2]

BITSC461/IS341 Software Engineering

cmm documents
CMM Documents ?

http://www.sei.cmu.edu/cmm/cmms/cmms.html

BITSC461/IS341 Software Engineering

ad