Software Life Cycle Models

2

.

S

o

f

t

w

a

r

e

L

i

f

e

C

y

c

l

e

M

o

d

e

l

s

O

v

e

r

v

i

e

w

•

Software development in theory

•

Iteration and incrementation

•

Risks and other aspects of iteration and

incrementation

•

Managing iteration and incrementation

•

Other life-cycle models

•

Comparison of life-cycle models

6

.

S

o

f

t

w

a

r

e

L

i

f

e

c

y

c

l

e

M

o

d

e

l

s

A software lifecycle model is a standardised

format for

•

planning

•

organising, and

•

running

a new development project.

Hundreds of different kinds of models are

known and used.

Many are minor variations on just a small

number of basic models. In this section we:

•

s

u

r

v

e

y

t

h

e

m

a

i

n

t

y

p

e

s

o

f

m

o

d

e

l

,

a

n

d

•

c

o

n

s

i

d

e

r

h

o

w

t

o

c

h

o

o

s

e

b

e

t

w

e

e

n

t

h

e

m

.

6

.

1

.

P

l

a

n

n

i

n

g

w

i

t

h

M

o

d

e

l

s

S

E

p

r

o

j

e

c

t

s

u

s

u

a

l

l

y

l

i

v

e

w

i

t

h

a

f

i

x

e

d

f

i

n

a

n

c

i

a

l

b

u

d

g

e

t

.

(

A

n

e

x

c

e

p

t

i

o

n

i

s

m

a

i

n

t

a

i

n

a

n

c

e

?

)

Additionally, time-to-market places a strong

t

i

m

e

c

o

n

s

t

r

a

i

n

t

.

T

h

e

r

e

w

i

l

l

b

e

o

t

h

e

r

p

r

o

j

e

c

t

c

o

n

s

t

r

a

i

n

t

s

s

u

c

h

as staff.

Project constraints

money

time

Computing

resources

staff

programmers

managers

designers

E

x

a

m

p

l

e

s

o

f

P

r

o

j

e

c

t

C

o

n

s

t

r

a

i

n

t

s

Project planning is the art of scheduling the

n

e

c

e

s

s

a

r

y

a

c

t

i

v

i

t

i

e

s

,

i

n

t

i

m

e

,

s

p

a

c

e

a

n

d

a

c

r

o

s

s

staff in order to optimise:

•

project risk [low] (see later)

•

profit [high]

•

customer satisfaction [high]

•

worker satisfaction [high]

•

long-term company goals

W

h

a

t

i

s

a

L

i

f

e

c

y

c

l

e

M

o

d

e

l

?

D

e

f

i

n

i

t

i

o

n

.

A (software/system) 

lifecycle model

 is a

description of the sequence of activities

carried out in an SE project, and the relative

order of these activities.

The term “Lifecycle” is based on the metaphor of

the life of a person:

Conception

Childhood

Application

Domain

Solution

Domain

2

.

1

S

o

f

t

w

a

r

e

D

e

v

e

l

o

p

m

e

n

t

i

n

T

h

e

o

r

y

•

Ideally, software is developed

as described in Chapter 1

•

Linear

•

Starting from scratch

S

o

f

t

w

a

r

e

D

e

v

e

l

o

p

m

e

n

t

i

n

P

r

a

c

t

i

c

e

•

In the real world, software development is

totally different

•

We make mistakes

•

The client’s requirements change while the software

product is being developed

I

t

p

r

o

v

i

d

e

s

a

f

i

x

e

d

g

e

n

e

r

i

c

f

r

a

m

e

w

o

r

k

t

h

a

t

 can be tailored to a specific project.

P

r

o

j

e

c

t

s

p

e

c

i

f

i

c

p

a

r

a

m

e

t

e

r

s

w

i

l

l

i

n

c

l

u

d

e

:

•

Size, (person-years)

•

Budget,

•

Duration.

p

r

o

j

e

c

t

p

l

a

n

=

l

i

f

e

c

y

c

l

e

m

o

d

e

l

+

p

r

o

j

e

c

t

p

a

r

a

m

e

t

e

r

s

There are hundreds of  different lifecycle models

to choose from, e.g:

•

w

a

t

e

r

f

a

l

l

,

•

c

o

d

e

-

a

n

d

-

f

i

x

•

s

p

i

r

a

l

•

r

a

p

i

d

p

r

o

t

o

t

y

p

i

n

g

•

u

n

i

f

i

e

d

p

r

o

c

e

s

s

(

U

P

)

•

a

g

i

l

e

m

e

t

h

o

d

s

,

e

x

t

r

e

m

e

p

r

o

g

r

a

m

m

i

n

g

(

X

P

)

•

C

O

T

S

…

but many are minor variations on a smaller

number of basic models.

By changing the lifecycle model, we can

i

m

p

r

o

v

e

a

n

d

/

o

r

t

r

a

d

e

o

f

f

:

•

D

e

v

e

l

o

p

m

e

n

t

s

p

e

e

d

(

t

i

m

e

t

o

m

a

r

k

e

t

)

•

P

r

o

d

u

c

t

q

u

a

l

i

t

y

•

P

r

o

j

e

c

t

v

i

s

i

b

i

l

i

t

y

•

A

d

m

i

n

i

s

t

r

a

t

i

v

e

o

v

e

r

h

e

a

d

•

R

i

s

k

e

x

p

o

s

u

r

e

•

C

u

s

t

o

m

e

r

r

e

l

a

t

i

o

n

s

,

e

t

c

,

e

t

c

.

Normally, a lifecycle model covers the entire

l

i

f

e

t

i

m

e

o

f

a

p

r

o

d

u

c

t

.

F

r

o

m

b

i

r

t

h

o

f

a

c

o

m

m

e

r

c

i

a

l

i

d

e

a

t

o

f

i

n

a

l

d

e

-

i

n

s

t

a

l

l

a

t

i

o

n

o

f

l

a

s

t

r

e

l

e

a

s

e

i.e. The three main phases:

•

D

e

s

i

g

n

,

•

B

u

i

l

d

,

•

M

a

i

n

t

a

i

n

.

W

a

t

e

r

f

a

l

l

M

o

d

e

l

•

The linear life cycle model with

feedback loops

•

The waterfall model cannot show the

order of events

I

t

e

r

a

t

i

o

n

a

n

d

I

n

c

r

e

m

e

n

t

a

t

i

o

n

•

In real life, we cannot speak about “the analysis

phase”

•

Instead, the operations of the analysis phase are

spread out over the life cycle

•

The basic software development process is

iterative

•

Each successive version is intended to be closer to

its target than its predecessor

M

i

l

l

e

r

’

s

L

a

w

•

At any one time, we can concentrate on only

approximately seven 

chunks

 (units of

information)

•

To handle larger amounts of information, use

stepwise refinement

•

Concentrate on the aspects that are currently the

most important

•

Postpone aspects that are currently less critical

•

Every aspect is eventually handled, but in order of

current importance

•

This is an 

incremental

 process

I

t

e

r

a

t

i

o

n

a

n

d

I

n

c

r

e

m

e

n

t

a

t

i

o

n

(

c

o

n

t

d

)

Figure 2.4

I

t

e

r

a

t

i

o

n

a

n

d

I

n

c

r

e

m

e

n

t

a

t

i

o

n

(

c

o

n

t

d

)

•

Iteration and incrementation are used in conjunction with

one another

•

There is no single “requirements phase” or “design phase”

•

Instead, there are multiple instances of each phase

I

t

e

r

a

t

i

o

n

a

n

d

I

n

c

r

e

m

e

n

t

a

t

i

o

n

(

c

o

n

t

d

)

•

The number of increments will vary — it does

not have to be four

C

l

a

s

s

i

c

a

l

P

h

a

s

e

s

v

e

r

s

u

s

W

o

r

k

f

l

o

w

s

•

Sequential phases do not exist in the real world

•

Instead, the five core workflows (activities) are performed

over the entire life cycle

•

Requirements workflow

•

Analysis workflow

•

Design workflow

•

Implementation workflow

•

Test workflow

W

o

r

k

f

l

o

w

s

•

All five core workflows are performed over the entire

life cycle

•

However, at most times one workflow predominates

•

Examples:

•

At the beginning of the life cycle

•

The requirements workflow predominates

•

At the end of the life cycle

•

The implementation and test workflows predominate

•

Planning and documentation activities are

performed throughout the life cycle

I

t

e

r

a

t

i

o

n

a

n

d

I

n

c

r

e

m

e

n

t

a

t

i

o

n

(

c

o

n

t

d

)

•

Iteration is performed during each incrementation

Figure 2.5

I

t

e

r

a

t

i

o

n

a

n

d

I

n

c

r

e

m

e

n

t

a

t

i

o

n

(

c

o

n

t

d

)

•

Again, the number of iterations will vary—it is

not always three

M

o

r

e

o

n

I

n

c

r

e

m

e

n

t

a

t

i

o

n

(

c

o

n

t

d

)

•

Each episode corresponds to an increment

•

Not every increment includes every workflow

•

Increment B was not completed

•

Dashed lines denote maintenance

R

i

s

k

s

a

n

d

O

t

h

e

r

A

s

p

e

c

t

s

o

f

I

t

e

r

.

a

n

d

I

n

c

r

e

m

.

•

We can consider the project as a whole as a set of mini

projects (increments)

•

Each mini project extends the

•

Requirements artifacts

•

Analysis artifacts

•

Design artifacts

•

Implementation artifacts

•

Testing artifacts

•

The final set of artifacts is the complete product

R

i

s

k

s

a

n

d

O

t

h

e

r

A

s

p

e

c

t

s

o

f

I

t

e

r

.

a

n

d

I

n

c

r

e

m

.

(

c

o

n

t

d

)

•

During each mini project we

•

Extend the artifacts (incrementation);

•

Check the artifacts (test workflow); and

•

If necessary, change the relevant artifacts (iteration)

R

i

s

k

s

a

n

d

O

t

h

e

r

A

s

p

e

c

t

s

o

f

I

t

e

r

.

a

n

d

I

n

c

r

e

m

.

(

c

o

n

t

d

)

•

Each iteration can be viewed as a small but complete

waterfall life-cycle model

•

During each iteration we select a portion of the software

product

•

On that portion we perform the

•

Classical requirements phase

•

Classical analysis phase

•

Classical design phase

•

Classical implementation phase

S

t

r

e

n

g

t

h

s

o

f

t

h

e

I

t

e

r

a

t

i

v

e

-

a

n

d

-

I

n

c

r

e

m

e

n

t

a

l

M

o

d

e

l

•

There are multiple opportunities for checking

that the software product is correct

•

Every iteration incorporates the test workflow

•

Faults can be detected and corrected early

•

The robustness of the architecture can be

determined early in the life cycle

•

A

rchitecture 

— the various component modules and

how they fit together

•

Robustness 

— the property of being able to handle

extensions and changes without falling apart

S

t

r

e

n

g

t

h

s

o

f

t

h

e

I

t

e

r

a

t

i

v

e

-

a

n

d

-

I

n

c

r

e

m

e

n

t

a

l

M

o

d

e

l

(

c

o

n

t

d

)

•

We can 

mitigate

 (resolve)

risks early

•

Risks are invariably involved in software

development and maintenance

•

We have a working version of the software

product from the start

•

The client and users can experiment with this

version to determine what changes are needed

•

Variation: Deliver partial versions to smooth the

introduction of the new product in the client

organization

S

t

r

e

n

g

t

h

s

o

f

t

h

e

I

t

e

r

a

t

i

v

e

-

a

n

d

-

I

n

c

r

e

m

e

n

t

a

l

M

o

d

e

l

(

c

o

n

t

d

)

•

There is empirical evidence that the life-cycle

model works

•

The CHAOS reports of the Standish Group (see

overleaf) show that the percentage of

successful products increases

S

t

r

e

n

g

t

h

s

o

f

t

h

e

I

t

e

r

a

t

i

v

e

-

a

n

d

-

I

n

c

r

e

m

e

n

t

a

l

M

o

d

e

l

(

c

o

n

t

d

)

•

CHAOS

reports

from

1994 to

2006

Figure 2.7

S

t

r

e

n

g

t

h

s

o

f

t

h

e

I

t

e

r

a

t

i

v

e

-

a

n

d

-

I

n

c

r

e

m

e

n

t

a

l

M

o

d

e

l

(

c

o

n

t

d

)

•

Reasons given for the decrease in successful

projects in 2004 include:

•

More large projects in 2004 than in 2002

•

Use of the waterfall model

•

Lack of user involvement

•

Lack of support from senior executives

M

a

n

a

g

i

n

g

I

t

e

r

a

t

i

o

n

a

n

d

I

n

c

r

e

m

e

n

t

a

t

i

o

n

•

The iterative-and-incremental life-cycle model is

as regimented as the waterfall model …

•

… because the iterative-and-incremental life-

cycle model is the waterfall model, applied

successively

•

Each increment is a waterfall mini project

O

t

h

e

r

L

i

f

e

-

C

y

c

l

e

M

o

d

e

l

s

•

The following life-cycle models are presented

and compared:

•

Code-and-fix life-cycle model

•

Rapid prototyping life-cycle model

•

Open-source life-cycle model

•

Agile processes

•

Synchronize-and-stabilize life-cycle model

•

Spiral life-cycle model

C

o

d

e

-

a

n

d

-

F

i

x

•

This model starts with an informal general product idea

and just develops code until a product is ”ready” (or

money or time runs out). Work is in random order.

•

C

o

r

r

e

s

p

o

n

d

s

w

i

t

h

n

o

p

l

a

n

!

(

H

a

c

k

i

n

g

!

)

C

o

d

e

-

a

n

d

-

F

i

x

M

o

d

e

l

•

No design

•

No

specifications

•

Maintenance

nightmare

Figure 2.8

A

d

v

a

n

t

a

g

e

s

1.

No administrative overhead

2.

Signs of progress (code) early.

3.

Low expertise, anyone can use it!

4.

U

s

e

f

u

l

f

o

r

s

m

a

l

l

“

p

r

o

o

f

o

f

c

o

n

c

e

p

t

”

p

r

o

j

e

c

t

s

,

e

.

g

.

a

s

p

a

r

t

o

f

r

i

s

k

r

e

d

u

c

t

i

o

n

.

D

i

s

a

d

v

a

n

t

a

g

e

s

1.

Dangerous!

1.

No visibility/control

2.

No resource planning

3.

No deadlines

4.

Mistakes hard to detect/correct

2. 

Impossible for large projects,

communication breakdown, chaos.

T

h

e

W

a

t

e

r

f

a

l

l

M

o

d

e

l

•

The waterfall model is the classic lifecycle model – it

is 

widely

 known, understood and (commonly?) used.

•

In some respect, waterfall is the ”common

sense” approach.

•

Introduced by Royce 1970.

W

a

t

e

r

f

a

l

l

M

o

d

e

l

Figure 2.9

A

d

v

a

n

t

a

g

e

s

1.

Easy to understand and implement.

2.

Widely used and known (in theory!)

3.

Reinforces good habits:  define-before- design,

design-before-code

4.

Identifies deliverables and milestones

5.

Document driven, URD, SRD, … etc. Published

documentation standards, e.g. PSS-05.

6.

Works well on mature products and weak teams.

D

i

s

a

d

v

a

n

t

a

g

e

s

I

1.

Idealised, doesn’t match reality well.

2.

Doesn’t reflect iterative nature of exploratory

development.

3.

Unrealistic to expect accurate requirements so early in

project

4.

Software is delivered late in project, delays discovery

of serious errors.

R

a

p

i

d

P

r

o

t

o

t

y

p

i

n

g

K

e

y

i

d

e

a

:

C

u

s

t

o

m

e

r

s

a

r

e

n

o

n

-

t

e

c

h

n

i

c

a

l

a

n

d

usually don’t know what they want/can have.

Rapid prototyping emphasises requirements

analysis and validation, also called:

•

c

u

s

t

o

m

e

r

o

r

i

e

n

t

e

d

d

e

v

e

l

o

p

m

e

n

t

,

•

e

v

o

l

u

t

i

o

n

a

r

y

p

r

o

t

o

t

y

p

i

n

g

R

a

p

i

d

P

r

o

t

o

t

y

p

i

n

g

M

o

d

e

l

•

Linear

model

•

“Rapid”

Figure 2.10

A

d

v

a

n

t

a

g

e

s

1.

Reduces risk of incorrect user requirements

2.

Good where requirements are

changing/uncommitted

3.

Regular visible progress aids management

4.

Supports early product marketing

D

i

s

a

d

v

a

n

t

a

g

e

s

1.

An unstable/badly implemented prototype often

becomes the final product.

2.

Requires extensive customer collaboration

•

Costs customers money

•

Needs committed customers

•

Difficult to finish if customer withdraws

•

May be too customer specific, no broad market

O

p

e

n

-

S

o

u

r

c

e

L

i

f

e

-

C

y

c

l

e

M

o

d

e

l

•

Two informal phases

•

First, one individual builds an initial version

•

Made available via the Internet (e.g., 

SourceForge.net

)

•

Then, if there is sufficient interest in the project

•

The initial version is widely downloaded

•

Users become co-developers

•

The product is extended

•

Key point: Individuals generally work voluntarily on an

open-source project in their spare time

T

h

e

A

c

t

i

v

i

t

i

e

s

o

f

t

h

e

S

e

c

o

n

d

I

n

f

o

r

m

a

l

P

h

a

s

e

•

Reporting and correcting defects

•

Corrective maintenance

•

Adding additional functionality

•

Perfective maintenance

•

Porting the program to a new environment

•

Adaptive maintenance

•

The second informal phase consists 

solely

 of

postdelivery maintenance

•

The word “co-developers” on the previous slide should rather

be “co-maintainers”

O

p

e

n

-

S

o

u

r

c

e

L

i

f

e

-

C

y

c

l

e

M

o

d

e

l

(

c

o

n

t

d

)

•

Postdelivery maintenance life-cycle model

O

p

e

n

-

S

o

u

r

c

e

L

i

f

e

-

C

y

c

l

e

M

o

d

e

l

(

c

o

n

t

d

)

•

Closed-source software is maintained and tested by

employees

•

Users can submit failure reports but never fault reports (the

source code is not available)

•

Open-source software is generally maintained by

unpaid volunteers

•

Users are strongly encouraged to submit defect reports, both

failure reports and fault reports

O

p

e

n

-

S

o

u

r

c

e

L

i

f

e

-

C

y

c

l

e

M

o

d

e

l

(

c

o

n

t

d

)

•

Core group

•

Small number of dedicated maintainers with the inclination, the

time, and the necessary skills to submit fault reports (“fixes”)

•

They take responsibility for managing the project

•

They have the authority to install fixes

•

Peripheral group

•

Users who choose to submit defect reports from time to time

O

p

e

n

-

S

o

u

r

c

e

L

i

f

e

-

C

y

c

l

e

M

o

d

e

l

(

c

o

n

t

d

)

•

New versions of closed-source software are typically

released roughly once a year

•

After careful testing by the  SQA group

•

The core group releases a new version of an open-

source product as soon as it is ready

•

Perhaps a month or even a day after the previous version was

released

•

The core group performs minimal testing

•

Extensive testing is performed by the members of the

peripheral group in the course of utilizing the software

•

“Release early and often”

O

p

e

n

-

S

o

u

r

c

e

L

i

f

e

-

C

y

c

l

e

M

o

d

e

l

(

c

o

n

t

d

)

•

An initial working version is produced when using

•

The rapid-prototyping model;

•

The code-and-fix model; and

•

The open-source life-cycle model

•

Then:

•

Rapid-prototyping model

•

The initial version is discarded

•

Code-and-fix model and open-source life-cycle model

•

The initial version becomes the target product

O

p

e

n

-

S

o

u

r

c

e

L

i

f

e

-

C

y

c

l

e

M

o

d

e

l

(

c

o

n

t

d

)

•

Consequently, in an open-source project, there are

generally no specifications and no design

•

How have some open-source projects been so

successful without specifications or designs?

O

p

e

n

-

S

o

u

r

c

e

L

i

f

e

-

C

y

c

l

e

M

o

d

e

l

(

c

o

n

t

d

)

•

Open-source software production has attracted some of

the world’s finest software experts

•

They can function effectively without specifications or designs

•

However, eventually a point will be reached when the

open-source product is no longer maintainable

O

p

e

n

-

S

o

u

r

c

e

L

i

f

e

-

C

y

c

l

e

M

o

d

e

l

(

c

o

n

t

d

)

•

The open-source life-cycle model is restricted in its

applicability

•

It can be extremely successful for infrastructure projects,

such as

•

Operating systems (Linux, OpenBSD, Mach, Darwin)

•

Web browsers (Firefox, Netscape)

•

Compilers (gcc)

•

Web servers (Apache)

•

Database management systems (MySQL)

O

p

e

n

-

S

o

u

r

c

e

L

i

f

e

-

C

y

c

l

e

M

o

d

e

l

(

c

o

n

t

d

)

•

There cannot be open-source development of a

software product to be used in just one commercial

organization

•

Members of both the core group and the periphery are

invariably users of the software being developed

•

The open-source life-cycle model is inapplicable unless

the target product is viewed by a wide range of users as

useful to them

O

p

e

n

-

S

o

u

r

c

e

L

i

f

e

-

C

y

c

l

e

M

o

d

e

l

(

c

o

n

t

d

)

•

About half of the open-source projects on the Web have

not attracted a team to work on the project

•

Even where work has started, the overwhelming

preponderance will never be completed

•

But when the open-source model has worked, it has

sometimes been incredibly successful

•

The open-source products previously listed have been utilized

on a regular basis by millions of users

A

g

i

l

e

P

r

o

c

e

s

s

e

s

•

Somewhat controversial new approach

•

Stories

 (features client wants)

•

Estimate duration and cost of each story

•

Select stories for next build

•

Each build is divided into tasks

•

Test cases for a task are drawn up first

•

Pair programming

•

Continuous integration of tasks

U

n

u

s

u

a

l

F

e

a

t

u

r

e

s

o

f

X

P

•

The computers are put in the center of a large room

lined with cubicles

•

A client representative is always present

•

Software professionals cannot work overtime for 2

successive weeks

•

No specialization

•

Refactoring

 (design modification)

A

g

i

l

e

P

r

o

c

e

s

s

e

s

•

Agile processes are a collection of new

paradigms characterized by

•

Less emphasis on analysis and design

•

Earlier implementation (working software is

considered more important than documentation)

•

Responsiveness to change

•

Close collaboration with the client

A

g

i

l

e

(

X

P

)

M

a

n

i

f

e

s

t

o

XP = Extreme Programming emphasises:

•

Individuals and interactions

•

O

v

e

r

p

r

o

c

e

s

s

e

s

a

n

d

t

o

o

l

s

•

Working software

•

O

v

e

r

d

o

c

u

m

e

n

t

a

t

i

o

n

•

Customer collaboration

•

O

v

e

r

c

o

n

t

r

a

c

t

n

e

g

o

t

i

a

t

i

o

n

•

Responding to change

•

O

v

e

r

f

o

l

l

o

w

i

n

g

a

p

l

a

n

A

g

i

l

e

P

r

i

n

c

i

p

l

e

s

(

S

u

m

m

a

r

y

)

•

Continuous delivery of software

•

Continuous collaboration with customer

•

Continuous update according to changes

•

Value participants and their interaction

•

Simplicity in code, satisfy the spec

X

P

P

r

a

c

t

i

c

e

s

(

S

u

m

m

a

r

y

)

•

Programming in pairs

•

Test driven development

•

Continuous planning, change , delivery

•

Shared project metaphors, coding standards and

ownership of code

•

No overtime! (Yeah right!)

E

v

a

l

u

a

t

i

n

g

A

g

i

l

e

P

r

o

c

e

s

s

e

s

•

Agile processes have had some successes with small-

scale software development

•

However, medium- and large-scale software development are

completely different

•

The key decider: the impact of agile processes on

postdelivery maintenance

•

Refactoring is an essential component of agile processes

•

Refactoring continues during maintenance

•

Will refactoring increase the cost of post-delivery maintenance, as

indicated by preliminary research?

A

d

v

a

n

t

a

g

e

s

•

Lightweight methods suit small-medium size projects

•

Produces good team cohesion

•

Emphasises final product

•

Iterative

•

Test based approach to requirements and quality

assurance

D

i

s

a

d

v

a

n

t

a

g

e

s

•

Difficult to scale up to large projects where

documentation is essential

•

Needs experience and skill if not to degenerate into

code-and-fix

•

Programming pairs is costly

•

Test case construction is a difficult and specialised skill.

E

v

a

l

u

a

t

i

n

g

A

g

i

l

e

P

r

o

c

e

s

s

e

s

(

c

o

n

t

d

)

•

In conclusion

•

Agile processes appear to be a useful approach to

building small-scale software products when the

client’s requirements are vague

•

Also, some of the proven features of agile

processes can be effectively utilized within the

context of other life-cycle models

S

p

i

r

a

l

M

o

d

e

l

Since end-user requirements are hard to

obtain/define, it is natural to develop software

i

n

a

n

e

x

p

e

r

i

m

e

n

t

a

l

w

a

y

:

e

.

g

.

1.

Build some software

2.

See if it meets customer requirements

3.

If no goto 1 else stop.

S

p

i

r

a

l

M

o

d

e

l

•

Simplified

form

•

Rapid

prototyping

model plus

risk analysis

preceding

each phase

Figure 2.12

This loop approach gives rise to structured

i

t

e

r

a

t

i

v

e

l

i

f

e

c

y

c

l

e

m

o

d

e

l

s

.

In 1988 Boehm developed the spiral model as

a

n

i

t

e

r

a

t

i

v

e

m

o

d

e

l

w

h

i

c

h

i

n

c

l

u

d

e

s

r

i

s

k

a

n

a

l

y

s

i

s

a

n

d

r

i

s

k

m

a

n

a

g

e

m

e

n

t

.

K

e

y

i

d

e

a

:

o

n

e

a

c

h

i

t

e

r

a

t

i

o

n

i

d

e

n

t

i

f

y

a

n

d

s

o

l

v

e

t

h

e

s

u

b

-

p

r

o

b

l

e

m

s

w

i

t

h

t

h

e

h

i

g

h

e

s

t

r

i

s

k

.

Cumulative cost

E

v

a

l

u

a

t

e

a

l

t

e

r

n

a

t

i

v

e

s

,

I

d

e

n

t

i

f

y

&

r

e

s

o

l

v

e

r

i

s

k

s

D

e

v

e

l

o

p

&

v

e

r

i

f

y

n

e

x

t

-

l

e

v

e

l

p

r

o

d

u

c

t

P

l

a

n

n

e

x

t

p

h

a

s

e

D

e

t

e

r

m

i

n

e

o

b

j

e

c

t

i

v

e

s

,

a

l

t

e

r

n

a

t

i

v

e

s

&

c

o

n

s

t

r

a

i

n

t

s

Review &

commitment

Prototypes

P1

P2

P3

Operational

Prototype

S

t

a

r

t

E

n

d

Requirements

plan

Development

plan

Integration &

Test plan

Requirements

validation

Design,

Validation

& Verification

Detailed design

Coding

Unit & Integration

Testing

Acceptance

Testing

Concept

Of Operation

Each cycle follows a waterfall model by:

1.

Determining objectives

2.

Specifying constraints

3.

Generating alternatives

4.

Identifying risks

5.

Resolving risks

6.

Developing next-level product

7.

Planning next cycle

A

d

v

a

n

t

a

g

e

s

1.

Realism: the model accurately reflects the iterative

nature of software development on projects with

unclear requirements

2.

Flexible: incoporates the advantages of the waterfal

and rapid prototyping methods

3.

Comprehensive model decreases risk

4.

Good project visibility.

D

i

s

a

d

v

a

n

t

a

g

e

s

•

Needs technical expertise in risk analysis to really work

•

Model is poorly understood by non-technical

management, hence not so widely used

•

Complicated model, needs competent professional

management. High administrative overhead.

A

K

e

y

P

o

i

n

t

o

f

t

h

e

S

p

i

r

a

l

M

o

d

e

l

•

If all risks cannot be mitigated, the project is

immediately terminated

F

u

l

l

S

p

i

r

a

l

M

o

d

e

l

(

c

o

n

t

d

)

Figure 2.13

2

.

1

0

C

o

m

p

a

r

i

s

o

n

o

f

L

i

f

e

-

C

y

c

l

e

M

o

d

e

l

s

•

Different life-cycle models have been

presented

•

Each with its own strengths and weaknesses

•

Criteria for deciding on a model include:

•

The organization

•

Its management

•

The skills of the employees

•

The nature of the product

•

Best suggestion

•

“Mix-and-match” life-cycle model

C

o

m

p

a

r

i

s

o

n

o

f

L

i

f

e

-

C

y

c

l

e

M

o

d

e

l

s

(

c

o

n

t

d

)

T

h

a

n

k

s

s

h

e

n

g

b

i

n

@

c

s

.

s

j

t

u

.

e

d

u

.

c

n