Chapter 3 Prescriptive Process Models

Software Engineering: A Practitioner’s Approach, 6/e
Chapter 3
Prescriptive Process Models
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.
For University Use Only

May be reproduced ONLY for student use at the university level
when used in conjunction with Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and
are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005 1
Prescriptive Models
 Prescriptive process models advocate an orderly approach to
software engineering
That leads to a few questions …
 If prescriptive process models strive for structure and order, are
they inappropriate for a software world that thrives on change?
 Yet, if we reject traditional process models (and the order they
imply) and replace them with something less structured, do we
make it impossible to achieve coordination and coherence in
software work?
Waterfall
Communication
project initiation Planning
Model
requirement gathering estimating Modeling
scheduling
analysis Construction
tracking
design Deployment
code
test delivery
support
f eedback
 A.k.a.: Classic Life Cycle
 Useful for problems that are well understood
 Real problems are more complex than that; changes = confusion
 Customer must state all requirements upfront
 Customer must have patience
 Lack of feedback to the customer makes blunders disastrous
Incremental
Model
increment #n
Communic at ion
Planning
Modeling
analys is C o n s t ru c t i o n
des ign
c ode De p l o y m e n t
t es t d e l i v e ry
fe e db ac k
delivery of
nt h increment
increment # 2
Communic at ion
Pl a n ni ng
Modeling
des ign c ode De p l o y m e n t
fe e dba c k
delivery of
increment # 1 2nd increment
Communic at ion
Planning
Modeling
des ign c ode
delivery of
De p l o y m e n t
fe e db a c k
1st increment
project calendar time
Incremental
Model
 Applies elements of the waterfall model in incremental fashion
 First increment is often a core product
 Subsequent elements offer expanded functionality
 Subsequent features (some known, some unknown) are created,
while the core product may undergo evaluation
 If a customer requires deadlines that are impossible to meet,
a sequence of releases may solve the problem
 Permits for staffing of a team to fluctuate
RAD Model
Team # n
Mo d e lin g
business modeling
data modeling
process modeling
C o n st ru ct io n
component reuse
Team # 2 automatic code
Communication generation
testing
Modeling
business modeling
dat a modeling
process modeling
Planning
Construction Deployment
Team # 1 component reuse int egrat ion
aut omat ic code
generat ion delivery
Modeling t est ing feedback
business modeling
dat a modeling
process modeling
Construction
component reuse
aut omat ic code
generat ion
t est ing
60 - 90 days
RAD
 Model
Emphasizes short development cycle
 If requirements are well understood and project scope is
constrained, it may allow rapid creation of S/W systems
 For large projects may require vast human resources (for
many RAD teams)
 Developers and customers must be able to cope with fast
action
 For systems that are not highly modularized the RAD
approach may not work
 If systems require mutual tuning of various components, the
RAD approach may not work
 RAD may not be appropriate with technical risks high (new
technology)
Evolutionary Models:
Prototyping
Quick
Quick plan
Communication plan
communication
Modeling
Modeling
Quick design
Quick design
Deployment
Deployment
Delivery
delivery & Construction
& Feedback
feedback Construction
of
of prototype
prototype
Evolutionary Models:
Prototyping
 Useful when the customer has a legitimate need but is clueless
about the details
 First prototype may be barely useful: too slow, too big, too
unfriendly, etc.
DANGERS:
 The customer may “LOVE” the prototype which is held
together with “chewing gum”. When informed that it is a
prototype which has to be rebuilt, he may want “few fixes”
only
 The developer may be tempted to deliver the raw prototype
as a final product, sacrificing quality for a quick buck
Evolutionary Models: The
Spiral planning
estimation
scheduling
risk analysis
communication
modeling
analysis
design
start
deployment
construction
delivery code
feedback test
Evolutionary Models: The
Spiral
 Combines iterative prototyping with systematic aspects of the
waterfall model
 Can be used throughout the S/W life cycle:
from conceptualization to maintenance
 Anchor point milestones are used for each evolutionary pass
 Anchor point milestones:
 Work products
 Required conditions to be attained
 Realistic to the development of largescale systems
 Iteratively reduces risk
 Allows repeated use of the prototyping approach
 PROBLEM: Customers may not like it, fearing lack of control
Evolutionary Models: Concurrent
none
Modeling activity
represents the state

Under of a software engineering
activity or task
development
Awaiting
changes
Under review
Under
revision
Baselined
Done
Evolutionary Models: Concurrent
 The former image depicted only the modeling activity
 Indeed, concurrent engineering is a set of framework activities
such as Communication, Modeling, etc.
 Each of these activities is in one of its states…
 A state is some externally observable mode of behaviour
PROBLEMS:
 Prototyping (and other evolutionary processes) pose problems
to project planning (too much uncertainty)
 Evolutionary speed may not be optimal: too slow affects
productivity, too fast leads to chaos
 Sometimes software processes should focus on flexibility and
extensibility, rather than on quality delivery delays may
make us miss the market niche and window of opportunity
Still Other Process
Models—the process to apply
 Component based development
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 like security, fault tolerance,
adherence to business rules, systemic: DB mirroring,
memory management, concurrency
 Unified Process—a “usecase driven, architecture
centric, iterative and incremental” software process
closely aligned with the Unified Modeling Language
(UML)
The Unified Process (UP)
elaboration
Elaboration
inception
Inception
inception
construction
Release
transition
software increment
production
UP Phases
UP Phases
Inception Elaboration Construction Transition Production
Workflows
Requirements
Analysis
Design
Implementation
Test
Support
Iterations #1 #2 #n-1 #n
Inception phase
UP Work Products
Elaboration phase
Vision document
Init ial use-case model
Init ial project glossary Construction phase
Use-case model
Init ial business case Supplement ary requirements
Init ial risk assessment . including non-funct ional Transition phase
Design model
Project plan, Analysis model Soft ware component s
phases and it erat ions. Soft ware archit ect ure Int egrated soft ware Delivered soft ware increment
Business model, Descript ion. increment Beta t est report s
if necessary. Execut able archit ect ural Test plan and procedure General user feedback
One or more prot ot ypes prot ot ype.
I nc ept i o Test cases
n Preliminary design model Support document at ion
Revised risk list user manuals
Project plan including installat ion manuals
it erat ion plan descript ion of current
adapt ed workflows increment
milest ones
t echnical work product s
Preliminary user manual

Chapter 3 Prescriptive Process Models

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 3 Prescriptive Process Models

Uploaded by

Copyright:

Available Formats

Software Engineering: A Practitioner’s Approach, 6/e

For University Use Only

project calendar time

represents the state

You might also like