SE Chapter 02

Chapter 2
 Process Models
Slide Set to accompany
Software Engineering: A Practitioner’s
Approach, 7/e
by Roger S. Pressman
1
What / who / why is
Process Models?
 What: Go through a series of predictable steps--- a road map
that helps you create a timely, high-quality results.
 Who: Software engineers and their managers, clients also.
People adapt the process to their needs and follow it.
 Why: Provides stability, control, and organization to an
activity that can if left uncontrolled, become quite chaotic.
However, modern software engineering approaches must be
agile and demand ONLY those activities, controls and work
products that are appropriate.
 What Work products: Programs, documents, and data
 What are the steps: The process you adopt depends on the
software that you are building. One process might be good
for aircraft avionic system, while an entirely different
process would be used for website creation.
 How to ensure right: A number of software process
assessment mechanisms that enable us to determine the
maturity of the software process. However, the quality,
timeliness and long-term viability of the software are the 2
best indicators of the efficacy of the process you use.
Definition of Software
Process
 A framework for the activities, actions, and
tasks that are required to build high-quality
software.
 SP defines the approach that is taken as

software is engineered.
 Is not equal to software engineering, which

also encompasses technologies that populate
the process– technical methods and
automated tools.
3
 As we discussed before, a generic process framework for
software engineering defines five framework activities-
communication, planning, modeling, construction, and
deployment.
 In addition, a set of umbrella activities- project tracking
and control, risk management, quality assurance,
configuration management, technical reviews, and others
are applied throughout the process.
 Next question is: how the framework activities and the
actions and tasks that occur within each activity are
organized with respect to sequence and time? See the
process flow for answer. 4
Process Flow
 process flow—describes how the
framework activities and the actions
and tasks that occur within each
framework activity are organized with
respect to sequence and time and is
illustrated in Figure 2.2.
These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by
Roger Pressman. 5
Process Flow…..
 A linear process flow executes each of the five
framework activities in sequence, beginning with
communication and culminating with deployment (Figure
2.2a).
 An iterative process flow repeats one or more of the
activities before proceeding to the next (Figure 2.2b).
 An evolutionary process flow executes the activities in a
“circular” manner. Each circuit through the five activities
leads to a more complete version of the software (Figure
2.2c).
 A parallel process flow (Figure 2.2d) executes one or
more activities in parallel with other activities

Roger Pressman. 6
Process Flow

Roger Pressman. 7
Identifying a Task Set
 A task set defines the actual work to be done to
accomplish the objectives of a software
engineering action.
 A list of the task to be accomplished(Choose a task set that
best accommodates the needs of the project and the
characteristics of team)
 A list of the work products to be produced
 A list of the quality assurance filters to be applied
8
Process Patterns
 A process pattern
 describes a process-related problem that is
encountered during software engineering work,
 identifies the environment in which the problem has
been encountered, and
 suggests one or more proven solutions to the
problem.
 Stated in more general terms, a process pattern provides
you with a template
 a consistent method for describing problem solutions
within the context of the software process.
9
 proposed a template for describing a
process pattern:
 Pattern Name.
The pattern is given a meaningful name describing it
within the context of the software process.
 Forces.
The environment in which the pattern is encountered
and the
issues that make the problem visible and may affect
its solution.
 Type.
The pattern type is specified. There are three types:

Roger Pressman. 10
Process Pattern Types
 Stage patterns—defines a problem associated with a
framework activity for the process.
 An example of a stage pattern might be Establishing Communication. This pattern
would incorporate the task pattern Requirements Gathering and others.
 Task patterns—defines a problem associated with a

software engineering action or work task and relevant
to successful software engineering practice(e.g.,
Requirements Gathering is a task pattern).
 Phase patterns—define the sequence of framework
activities that occur with the process, even when the
overall flow of activities is iterative in nature. (An example
of a phase pattern might be Spiral Model or Prototyping)
11
Process Assessment and
Improvement
 SP cannot guarantee that software will be

delivered on time, meet the needs, or has
the desired technical characteristics.
However, the process can be assessed to
ensure that it meets a set of basic process
criteria that have been shown to be
essential for a successful software
engineering.

Roger Pressman. 12
Process Assessment and Improvement
 Standard CMMI Assessment Method for Process Improvement
(SCAMPI) — provides a five step process assessment model that incorporates
five phases: initiating, diagnosing, establishing, acting and learning.
 CMM-Based Appraisal for Internal Process Improvement (CBA IPI)
—provides a diagnostic technique for assessing the relative maturity of
a software organization; uses the SEI CMM as the basis for the
assessment
 SPICE—The SPICE (ISO/IEC15504) standard defines a set of
requirements for software process assessment. The intent of the
standard is to assist organizations in developing an objective
evaluation of the efficacy of any defined software process.
 ISO 9001:2000 for Software—a generic standard that applies to any
organization that wants to improve the overall quality of the products,
systems, or services that it provides. Therefore, the standard is directly
applicable to software organizations and companies.
Software Engineering Institute Capability Maturity Model

.
13
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?
14
1. The Waterfall
Model
Co m m u nic a t io n
p ro je c t in it ia t io n Planning
re qu ire m e n t g a t he rin g estimating Mo d e lin g
scheduling
a na lys is Co n s t ru c t io n
tracking
de s ign De plo y m e nt
c ode
t es t d e liv e ry
s u pp o rt
f e e d ba c k
15
The Waterfall Model…..
 when the requirements for a problem are well understood—
when work flows from communication through deployment
in a reasonably linear fashion
 The waterfall model, sometimes called the classic life
cycle, suggests a systematic, sequential approach to
software development that begins with customer
specification of requirements and progresses through
planning, modeling, construction, and deployment,
culminating in ongoing support of the completed software .
 The waterfall model is the oldest paradigm for software
engineering. However Among the problems that are
sometimes encountered when the waterfall model is
applied are:
16
The Waterfall Model…..
1.The main drawback of the waterfall is the difficulty of accommodating change after
the process is underway.
2. Real projects rarely follow the sequential flow that the model proposes.
Although the linear model can accommodate iteration, it does so
indirectly. As a result, changes can cause confusion as the project team
proceeds.
3. It is often difficult for the customer to state all requirements explicitly.
The
waterfall model requires this and has difficulty accommodating the
natural
uncertainty that exists at the beginning of many projects.
4. The customer must have patience. A working version of the program(s)
will
not be available until late in the project time span. A major blunder, if
undetected
until the working program is reviewed, can be disastrous.
The waterfall model is mostly used for large system engineering project
where a system is developed at several sites
. 17
 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. In fact, the time spent waiting can exceed the
time spent on productive work.
 Today, software work is fast-paced and subject to a
never-ending stream of changes (to features,
functions, and information content). The waterfall
model is often inappropriate for such work.

Roger Pressman. 18
The V-Model
 A variation in the representation of the waterfall model is
called the V-model. Represented in Figure 2.4, the V-model
[Buc99] depicts the relationship of quality assurance actions
to the actions associated with communication, modeling,
and early construction activities.
 As a software team moves down the left side of the V, basic
problem requirements are refined into progressively more
detailed and technical
representations of the problem and its solution.
 Once code has been generated, the team moves up the right
side of the V, essentially performing a series of tests (quality
assurance actions) that validate each of the models created
as the team moved down the left side.
 In reality, there is no fundamental difference between the
classic life cycle and the V-model. The V-model provides a
way of visualizing how verification and validation actions are
applied to earlier engineering work.
. 19
A variation of waterfall model
depicts the relationship of
The V-Model quality assurance actions to
the actions associated with
communication, modeling and
early code construction
activates.
Team first moves down the left

side of the V to refine the
problem requirements. Once
code is generated, the team
moves up the right side of the
V, performing a series of tests
that validate each of the
models created as the team
moved down the left side.
20
2. The Incremental
Model
incre m e nt # n
Co m m u n i c a t i o n
Pla n ning
Mo de ling
a n a ly s is Co n s t ru c t i o n
d e s ig n
c ode De p l o y m e n t
t est d e l i v e ry
fe e d b a c k
d e liv e ry o f
incre m e nt # 2 n t h in cre me n t
Pla n ning
Mo d e ling
d e s ig n c ode De p l o y m e n t
fe e d b a c k
d e liv e ry o f
incre m e nt # 1 2 n d in cre me n t
Pla nnin g
Mo de ling
d e s ig n c ode
d e liv e ry o f
De p l o y m e n t
fe e d b a c k
1 st in cre me n t
projectEngineering:
These slides are designed to accompany Software calendar tAime
Roger Pressman. 21
The Incremental Model
 When initial requirements are reasonably well defined,
but the overall scope of the development effort
preclude a purely linear process. A compelling need to
expand a limited set of new functions to a later system
release.
 It combines elements of linear and parallel process
flows. Each linear sequence produces deliverable
increments of the software.
 The first increment is often a core product with many
supplementary features. Users use it and evaluate it
with more modifications to better meet the needs.
 Early increments are stripped-down versions of the
final product, but they do provide capability that
serves the user and also provide platform for
evaluation by the user.

The Incremental Model
 For example, word-processing software developed using
the incremental paradigm might deliver basic file
management, editing, and document production functions
in the first increment; more sophisticated editing and
document production
 Capabilities in the second increment; spelling and grammar
checking in the third increment; and advanced page layout
capability in the fourth increment.
.

Roger Pressman. 23
3. Evolutionary Models:
Prototyping
Quick
Qu i c k p la n
Co m m u n ic a t io n plan
communication
Modeling
Mo d e lin g
Qu ic k d e s i g n
Quick design
De p loym e n t
Deployment Construction
De liv e ry
delivery
& Fe e d b a&
ck
of prototype
Co n s t ru c t io n
feedback Construction
of
ofp ro
prototype
t o t yp e

Roger Pressman. 24
Evolutionary Models
 Software system evolves over time as requirements often
change as development proceeds. Thus, a straight line to a
complete end product is not possible. However, a limited
version must be delivered to meet competitive pressure.
 Usually a set of core product or system requirements is
well understood, but the details and extension have yet to
be defined.
 You need a process model that has been explicitly designed
to accommodate a product that evolved over time.
 It is iterative that enables you to develop increasingly more
complete version of the software.
 Two types are introduced, namely Prototyping and Spiral
models. 25
Evolutionary Models:
 Prototyping
When to use: Customer defines a set of general objectives but does not
identify detailed requirements for functions and features. Or Developer
may be unsure of the efficiency of an algorithm, the form that human
computer interaction should take.
 What step: Begins with communication by meeting with stakeholders to
define the objective, identify whatever requirements are known, outline
areas where further definition is mandatory. A quick plan for prototyping
and modeling (quick design) occur. Quick design focuses on a
representation of those aspects the software that will be visible to end
users. ( interface and output). Design leads to the construction of a
prototype which will be deployed and evaluated. Stakeholder’s
comments will be used to refine requirements.
 Both stakeholders and software engineers like the prototyping
paradigm. Users get a feel for the actual system, and developers get to
build something immediately. However, engineers may make
compromises in order to get a prototype working quickly. The less-than-
26
ideal choice may be adopted forever after you get used to it.
Evolutionary Models: The
Spiral planning
estimation
scheduling
risk analysis
communication
modeling
analysis
design
start
deployment
construction
delivery code
feedback test
Roger Pressman. 27
Evolutionary Models: The

Spiral
It couples the iterative nature of prototyping with the controlled and
systematic aspects of the waterfall model and is a risk-driven process model
generator that is used to guide multi-stakeholder concurrent engineering of
software intensive systems.
 Two main distinguishing features: one is cyclic approach for incrementally
growing a system’s degree of definition and implementation while decreasing
its degree of risk. The other is a set of anchor point milestones for ensuring
stakeholder commitment to feasible and mutually satisfactory system
solutions.
 A series of evolutionary releases are delivered. During the early iterations, the
release might be a model or prototype. During later iterations, increasingly
more complete version of the engineered system are produced.
 The first circuit in the clockwise direction might result in the product
specification; subsequent passes around the spiral might be used to develop a
prototype and then progressively more sophisticated versions of the software.
Each pass results in adjustments to the project plan. Cost and schedule are
adjusted based on feedback. Also, the number of iterations will be adjusted by
project manager.
 Good to develop large-scale system as software evolves as the process
28
progresses and risk should be understood and properly reacted to. Prototyping
is used to reduce risk.
 However, it may be difficult to convince customers that it is controllable as it
demands considerable risk assessment expertise.
Evolutionary Models:
Concurrent
none
Mode ling a c t ivit y
rep res ents the s tate

Unde r o f a s o ftware eng ineering
activity o r task
de ve lopm e nt
Awa it ing
c ha nge s
Unde r re vie w
Unde r
re vis ion
Ba s e line d
Done

Roger Pressman. 29
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)

Roger Pressman. 30
The Unified Process (UP)
elaboration
Ela b o ra t io n
Inc e p t io n
inception
c o ns t ruc t io n
Releas e
t ra ns it io n
s oft ware inc rem ent
p ro d uc t io n
Roger Pressman. 31
UP
Phases
UP Phases
Ince pt ion Elaborat ion Const ruct ion Transit ion Product ion
Workflows
Requirements
Analysis
Design
Implementation
Test
Support
Iterations #1 #2 #n-1 #n

Roger Pressman. 32
UP Work Products
Ince pt ion phase
Elaborat ion phase

Visio n d o cu me n t
In it ial u se -case mo d e l
In it ial p ro je ct g lo ssary
Const ruct ion phase
Use -case mo d e l
In it ial b u sin e ss case Su p p le me n t ary re q u ire me n t s
In it ial risk asse ssme n t . in clu d in g n o n -fu n ct io n al De sig n mo d e l
Transit ion phase
Pro je ct p lan , An aly sis mo d e l So ft ware co mp o n e n t s
p h ase s an d it e rat io n s. So ft ware arch it e ct u re De liv e re d so ft ware in cre me n t
In t e g rat e d so ft ware
Bu sin e ss mo d e l, De scrip t io n . in cre me n t Be t a t e st re p o rt s
if n e ce ssary . Exe cu t ab le arch it e ct u ral Ge n e ral u se r fe e d b ack
Te st p lan an d p ro ce d u re
On e o r mo re p ro t o t y p e s p ro t o t y p e .
In c e p t i o
Te st case s
n Pre limin ary d e sig n mo d e l Su p p o rt d o cu me n t at io n
Re v ise d risk list u se r man u als
Pro je ct p lan in clu d in g in st allat io n man u als
it e rat io n p lan d e scrip t io n o f cu rre n t
ad ap t e d wo rkflo ws in cre me n t
mile st o n e s
t e ch n ical wo rk p ro d u ct s
Pre limin ary u se r man u al

Roger Pressman. 33
Personal Software Process
(PSP)
 Planning. This activity isolates requirements and develops both size and
resource estimates. In addition, a defect estimate (the number of defects
projected for the work) is made. All metrics are recorded on worksheets or
templates. Finally, development tasks are identified and a project schedule is
created.
 High-level design. External specifications for each component to be constructed
are developed and a component design is created. Prototypes are built when
uncertainty exists. All issues are recorded and tracked.
 High-level design review. Formal verification methods (Chapter 21) are applied
to uncover errors in the design. Metrics are maintained for all important tasks
and work results.
 Development. The component level design is refined and reviewed. Code is
generated, reviewed, compiled, and tested. Metrics are maintained for all
important tasks and work results.
 Postmortem. Using the measures and metrics collected (this is a substantial
amount of data that should be analyzed statistically), the effectiveness of the
process is determined. Measures and metrics should provide guidance for
modifying the process to improve its effectiveness.

Roger Pressman. 34
Team Software Process
(TSP)
 Build self-directed teams that plan and track their work,
establish goals, and own their processes and plans.
These can be pure software teams or integrated product
teams (IPT) of three to about 20 engineers.
 Show managers how to coach and motivate their teams
and how to help them sustain peak performance.
 Accelerate software process improvement by making
CMM Level 5 behavior normal and expected.
 The Capability Maturity Model (CMM), a measure of the
effectiveness of a software process, is discussed in Chapter 30.
 Provide improvement guidance to high-maturity
organizations.
 Facilitate university teaching of industrial-grade team
skills.
Roger Pressman. 35

SE Chapter 02

Uploaded by

Document Information

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

SE Chapter 02

Uploaded by

Copyright:

Available Formats

Chapter 2

 SP defines the approach that is taken as

 Is not equal to software engineering, which

These slides are designed to accompany Software Engineering: A

These slides are designed to accompany Software Engineering: A

These slides are designed to accompany Software Engineering: A

These slides are designed to accompany Software Engineering: A

 Task patterns—defines a problem associated with a

 SP cannot guarantee that software will be

These slides are designed to accompany Software Engineering: A

Software Engineering Institute Capability Maturity Model

These slides are designed to accompany Software Engineering: A

Team first moves down the left

These slides are designed to accompany Software Engineering: A

These slides are designed to accompany Software Engineering: A

Mode ling a c t ivit y

rep res ents the s tate

These slides are designed to accompany Software Engineering: A

These slides are designed to accompany Software Engineering: A

These slides are designed to accompany Software Engineering: A

Elaborat ion phase

These slides are designed to accompany Software Engineering: A

These slides are designed to accompany Software Engineering: A

You might also like