Software Development Process: Life Cycle Models

Aug 19, 2003 BITSC461/IS341 Software Engineering

Software Development Process: Life Cycle Models

Last Update: Tuesday August 19, 2003

Aditya P. Mathur

Purdue University, West Lafayette

Department of Computer Science


2

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 ?


3

Process

StepInput Output

Step 1Input

Step 2Output

OutputInput

Input

Sequential or linear process


4

Concurrent Process

InputStep 3

Output

InputStep 2

Input

Output

Step 1Input

Output

Parallel or concurrent process


5

Iterative Process

InputStep 3

Output

InputStep 2

Input

Output

Step 1Input

Output

Iterative process


6

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.


7

Process model: Linear

An arrangement of process steps.

Step 1Input

Step 2Output

OutputInput

InputLinear model


8

Process model: Concurrent

InputStep 3

Output

InputStep 2

Input

Output

Step 1Input

OutputConcurrent


9

Process model: Iterative

Input

Step 3

Output

InputStep 2

InputOutput

Step 1

Input Output

Iterative


10

Software Development Process

Steps correspond to one or more tasks related to software development.

Tasks:

o Requirements gatheringo Requirements analysiso Designo Coding

o Integrationo Test

o Deliveryo Maintenanceo Training

Software life cycle: Software Life Cycle consists of all phases from its inception until its retirement. These are: Inception, elaboration, construction, transition.


11

Models of Software Life Cycle

Build and fix

Waterfall (classic)

Rapid prototyping

Incremental

Spiral

Unified


12

Build and fix model [1]

Modify until client satisfied

Operations mode

Retirement

Development

Maintenance

Idea or client request

Build first version


13


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


14


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.


15

Waterfall model [1]

Design phase

Implementation phase

Integration phaseDevelopment

Maintenance

Requirements phase

Specification phase

Operations mode

RetirementVerification done at the end of each phase.


16

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.


17

Waterfall model [3]

Each phase terminates only when the documents are complete and approved by the SQA group.

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.

Notice the feedback loop between the Design phase and the Specifications phase.


18

Waterfall model: Advantages

Disciplined approach

Testing in each phase.

Careful checking by the Software Quality Assurance Group at the end of each phase.

Documentation available at the end of each phase.


19

Waterfall model: Disdvantages

Documents do not always convey the entire picture.

Feedback from one phase to another might be too late and hence expensive.

Specification documents are detailed and difficult to read/understand for the client.


20

Rapid prototyping model

A working model of the product is developed (quickly, 1-3 months). Serves to elicit requirements.

Subsequent phases, design, coding etc., follow. Feedback loops less likely and fewer.

Client interacts with the prototype; specifications are developed.

Should the prototype be discardded or refined ?


21

Incremental model [1]

Architectural Design

For each build:Detailed design, coding,Integration, test, delivery.

Development

Maintenance

Requirements phase

Specification phase

Operations mode

RetirementVerification done at the end of each phase.


22


Product is designed, implemented, and integrated as a series of incremental builds.

A new build integrates code from previous build and new code.

A build contains code from various modules to provide the desired functionality.

Product architecture is designed. It serves as the main driver of the development process.

Features are prioritised and increments defined.


23


Client pays in increments; financial benefit.

Should we construct builds in parallel?

Design of the initial architecture is a difficult step. Poor architecture may lead to lots of changes in builds.

Client can begin using the first build.

Facilitates early adoption by the client.


24

Unified Development Process [1]

Each iteration produces a working, executable, product that might not be a deliverable.

No rush to code. Aslso, not a long drwan design process.

Key features: Iterative development; OO analysis and design.

Development organized as a series of short iterations

Lots of visual modeling aids. Unified Modeling Language (UML) used.


25


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.


26



27

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


28

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

Component: A physical and replaceable part of a system that conforms toand 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

This is what makesthe Unified processUnique


29

The Unified Process

User’s requirements

User’s requirements

SoftwareDevelopment

Process

SoftwareDevelopment

ProcessSoftwareSystem

SoftwareSystem


30

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?


31

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


32

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


33

The Unified Process Look at the whole process

Life cycle Artifacts Workflows Phases Iterations


34

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


35

The Life of the Unified Process

Elaboration Inception Construction Transition

Iteration Iteration Iteration Iteration Iteration Iteration Iteration Iteration

Release 1

1 1 1 1

Time

A cycle with its phases and its iterations


36

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.

Incremental: Maximizes early return on investment; requires open architecture; may degenerate into build-and-fix.

Rapid prototyping: Ensures that delivered product meets client needs; might become a build-and-fix model.


37

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.


38

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 ?


39

Standish Report [1995]

Large company: >$500M

Medium company: $200-500M

Small comp;any: $100-200M

Company categorization by revenue:

Sample size: 365 respondants, 8380 applications.


40

Standish Report: Project categorization: Success/failure

Resolution Type 1: On time, on budget, all features.

Resolution Type 2: Completed, over time, over budget, fewer features.

Resolution Type 3: Cancelled during the development cycle.

16.2%

52.7%

31.1%


41

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%


42

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%


43

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%


44

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%


45

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%


46

Standish Report: Failure stories

California DMV: Started 1987. Project cancelled: 1993. Cost:$45M

American airlines: 1994Settled lawsuit with Hilton/Marriott/Budget-rent-a carCONFIRM car rental project failed


47

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)

TOTAL 100 10 29 100 85

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)


48

Capability Maturity Model (CMM)

Purpose:To assess and help improve process in software development organizations.

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.


49

Capability Maturity Model (CMM)

Capability maturity levels:

Level 1: Initial WorstLevel 2: RepeatableLevel 3: DefinedLevel 4: ManagedLevel 5: Optimizing Best


50

CMM Levels [1]

Initial

The software process is characterized as ad hoc, andoccasionally even as chaotic. Few processed are defined, and success depends on individual effort.

Lacks: Reasonable process.


51

CMM Levels [2]

Repeatable

Basic project management processes are established to trackcost, schedule and functionality. the necessary processdiscipline is in place to repeat earlier successes on projects with similar applications.

Lacks: Complete process.


52

CMM Levels [3] Defined

The software process for both management and engineeringactivities is documented, standardized and integrated into astandard 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.


53

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.


54

CMM Levels [4]

Optimized

Continuous process improvement is enabled by quantitativefeedback from the process and from piloting innovative ideasand technologies.


55

Key Process Areas [1]

OptimizingDefect preventionTechnology change managementProcess change management

Managed:Quantitative process managementSoftware quality management


56

Key Process Areas [2]

DefinedOrganization process focusTraining programsIntegrated software managementPeer reviews

RepeatableRequirements managementSoftware project planningSoftware quality assuranceSoftware configuration management


57

Maturity and product quality [1]

Results from 34 Motorola Government ElectronicsDivision (GED) projects

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

-------------------- - ---------------------------------------- --------CMM Level # Projects Relative Faults/MEASL Relative

Decrease in ProductivityDuration

-------

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


58

Maturity and product quality [2]

Raytheon:

Equipment Division moved from Level 1 to Level 3. Thisresulted in a productivity gain of 2.0 and a $7.70 return onevery dollar invested.


59

CMM Documents ?

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