slide set to accompany web engineering: a practitioner...

These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e

(McGraw-Hill, 2009). Slides copyright 2009 by Roger Pressman. 1

Chapter 2

Process Models

Slide Set to accompany

Software Engineering: A Practitioner’s Approach, 7/e by Roger S. Pressman

Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman

For non-profit educational use only May be reproduced ONLY for student use at the university level when used in conjunction

with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is

prohibited without the express written permission of the author.

All copyright information MUST appear if these slides are posted on a website for student

use.

@Tehra

nS

hom

alE

ng

ine

ers



The Waterfall Model

Communicat ion

Planning

Modeling

Const ruct ionDeployment

analysis

designcode

t est

project init iat ion

requirement gat hering estimating

scheduling

tracking

delivery

support

f eedback

@Tehra

nS

hom

alE

ng

ine

ers



The V-Model @Tehra

nS

hom

alE

ng

ine

ers



The Waterfall Model Why does the waterfall model sometimes fail?

1) Real projects rarely follow the sequential flow that the

model proposes.

2) It is often difficult for the customer to state all requirements

explicitly.

3) The customer must have patience.

• Bradac [Bra94] found that the linear nature of the classic life

cycle leads to “blocking states” in which some project team

members must wait for other members of the team to complete

dependent tasks.

• However, it can serve as a useful process model in situations

where requirements are fixed and work is to proceed to

completion in a linear manner.

@Tehra

nS

hom

alE

ng

ine

ers



The Incremental Model

• The incremental model delivers a series of

releases, called increments, that provide

progressively more functionality for the

customer as each increment is delivered.

• When an incremental model is used, the first

increment is often a core product. That is,

basic requirements are addressed but many

supplementary features (some known, others

unknown) remain undelivered

@Tehra

nS

hom

alE

ng

ine

ers



The Incremental Model

@Tehra

nS

hom

alE

ng

ine

ers



Evolutionary Models: Prototyping

Construction of prototype

Often, a customer defines a set of general objectives for software,

but does not identify detailed requirements for functions and

features. In other cases, the developer may be unsure of

- the efficiency of an algorithm,

- the adaptability of an operating system,

- or the form that human-machine interaction should take.

Although prototyping can be used as a stand-alone process

model, it is more commonly used as a technique that can be

implemented within the context of any one of the process

models.

The prototyping paradigm assists you and other stakeholders

to better understand what is to be built when requirements

are fuzzy.

@Tehra

nS

hom

alE

ng

ine

ers





Communicat ion

Qu ick p lan

Const ruct ion

of

prot ot ype

Mo d e lin g

Qu ick d e sig n

De live ry

& Fe e dback

Deployment

communication

Quick plan

Modeling Quick design


Deployment delivery & feedback

@Tehra

nS

hom

alE

ng

ine

ers





1. Stakeholders see what appears to be a working version of the

software, unaware that the prototype is held together

haphazardly, unaware that in the rush to get it working you haven’t

considered overall software quality or long-term maintainability.

When informed that the product must be rebuilt so that high levels

of quality can be maintained, stakeholders cry foul and demand

that “a few fixes” be applied to make the prototype a working

product.

2. As a software engineer, you often make implementation

compromises in order to get a prototype working quickly. An

inappropriate operating system or programming language may be

used simply because it is available and known; an inefficient

algorithm may be implemented simply to demonstrate capability.

After a time, you may become comfortable with these choices and

forget all the reasons why they were inappropriate. The less-than-

ideal choice has now become an integral part of the system.

@Tehra

nS

hom

alE

ng

ine

ers

Rapid Application

Development (RAD) Model

Makes heavy use of reusable software components with an extremely short development cycle

@Tehra

nS

hom

alE

ng

ine

ers

RAD model Communication – to understand business problem.

Planning – multiple s/w teams works in parallel on diff. system.

Modeling –

Business modeling

Data modeling

Process modeling

Construction – it highlighting the use of pre-existing software

component.

Deployment – Deliver to customer basis for subsequent iteration.

RAD model emphasize a short development cycle.

“High speed” edition of linear sequential model.

If requirement are well understood and project scope is constrained

then it enable development team to create “ fully functional system”

within a very short time period.

@Tehra

nS

hom

alE

ng

ine

ers

If application is modularized (“Scalable Scope”), each major

function to be completed in less than three months.

Each major function can be addressed by a separate team and

then integrated to form a whole.

Drawback:

For large but scalable projects

RAD requires sufficient human resources

Projects fail if developers and customers are not committed in a much shortened time-frame

Problematic if system can not be modularized

Not appropriate when technical risks are high ( heavy use of new technology)

RAD model

@Tehra

nS

hom

alE

ng

ine

ers



Evolutionary Models: The Spiral

communication

planning

modeling

constructiondeployment

delivery

feedback

start

analysis

design

code

test

estimation

scheduling

risk analysis

@Tehra

nS

hom

alE

ng

ine

ers



Evolutionary Models: Concurrent

Under review

Baselined

Done

Under

revision

Await ing

changes

Under

development

none

Modeling act ivit y

represents the state

of a software engineering

act ivity or task

@Tehra

nS

hom

alE

ng

ine

ers



Still Other Process Models Component based development—the process to

apply when reuse is a development objective

Formal methods—emphasizes the mathematical

specification of requirements

AOSD—provides a process and methodological

approach for defining, specifying, designing, and

constructing aspects

Unified Process—a “use-case driven, architecture-

centric, iterative and incremental” software process

closely aligned with the Unified Modeling Language

(UML)

@Tehra

nS

hom

alE

ng

ine

ers



The Unified Process (UP) @Tehra

nS

hom

alE

ng

ine

ers



UP Phases

Incept ion Elaborat ion Const ruct ion Transit ion Product ion

UP Phases

Workflows

Requirements

Analysis

Design

Implementation

Test

Iterations #1 #2 #n-1 #n

Support

@Tehra

nS

hom

alE

ng

ine

ers



UP Work Products Incept ion phase

Elaborat ion phase

Const ruct ion phase

Transit ion phase

Vision document

Init ial use-case model

Init ial project glossary

Init ial business case

Init ial risk assessment .

Project plan,

phases and it erat ions.

Business model,

if necessary .

One or more prot ot ypes I n c e p t i o

n

Use-case model

Supplement ary requirement s

including non-funct ional

Analysis model

Soft ware archit ect ure

Descript ion.

Execut able archit ect ural

prot ot ype.

Preliminary design model

Rev ised risk list

Project plan including

it erat ion plan

adapt ed workf lows

milest ones

t echnical work product s

Preliminary user manual

Design model

Soft ware component s

Int egrat ed soft ware

increment

Test plan and procedure

Test cases

Support document at ion

user manuals

inst allat ion manuals

descript ion of current

increment

Delivered soft ware increment

Bet a t est report s

General user feedback

@Tehra

nS

hom

alE

ng

ine

ers

slide set to accompany web engineering: a practitioner...

Documents