Chapter 2

Process Models

1
A Generic Process Model

2
Process Flow

3
 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
•A list of the work products to be
produced
•A list of the quality assurance filters
to be applied

4
 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 [Amb98]—a
consistent method for describing problem
solutions within the context of the software
process.
5
 Process Pattern Types
•Stage patterns—defines a problem associated
with a framework activity for the process.
•Task patterns—defines a problem associated
with a software engineering action or work
task and relevant to successful software
engineering practice
•Phase patterns—define the sequence of
framework activities that occur with the
process, even when the overall flow of
activities is iterative in nature.

6
 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
[Dun01]
• 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. [ISO08]
• 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. [Ant06]

7
 Assessment and Improvement
Software Process

identifies is examined by identifies capabilities

modifications to and risk of

Software Process
Assessment

leads to leads to Capability

Software Process Determination
Improvement
motivates

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 8
 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?
9
 Waterfall Model
(Diagram)
Communication
Project initiation
Requirements
gathering & Analysis
Planning
Estimating
Scheduling
Tracking Modeling
Analysis
Design Construction
Code
Test Deployment
Delivery
Support
Feedback
10
 Waterfall Model
(Description)
• Oldest software lifecycle model and best
understood by upper management
• Used when requirements are well
understood and risk is low
• Work flow is in a linear (i.e., sequential)
fashion
• Used often with well-defined adaptations
or enhancements to current software
11
 Waterfall Model
(Problems)
• Doesn't support iteration, so changes can
cause confusion
• Difficult for customers to state all
requirements explicitly and up front
• Requires customer patience because a
working version of the program doesn't
occur until the final phase
• Problems can be somewhat alleviated in the
model through the addition of feedback
loops (see the next slide) 12
The V-Model

14
W MODEL

15
 Incremental Model (Diagram)

Increment #1
Communication
Planning
Modeling
Construction
Deployment

Increment #2
Communication
Planning
Modeling
Construction
Deployment

Increment #3

Communication
Planning
Modeling
Construction
Deployment

16
 Incremental Model (Description)
• Used when requirements are well understood
• Multiple independent deliveries are identified
• Work flow is in a linear (i.e., sequential) fashion
within an increment and is staggered between
increments
• Iterative in nature; focuses on an operational
product with each increment
• Provides a needed set of functionality sooner
while delivering optional components later
• Useful also when staffing is too short for a full-
scale development 17
Evolutionary Models: Prototyping

Q u i ck p l an
Quick
Co m m u n icat io n plan
communication
Mo d e l i n g
Modeling
Q u i ck d e si g n
Quick design

Deployment
Deployment
D e live r y
Construction
of prototype
delivery
& Fe e d b& ack Co n st r u ct io n
oConstruction
f
feedback pof
r oprototype
t o t yp e

18
 Prototyping Model
(Description)
• Follows an evolutionary and iterative
approach
• Used when requirements are not well
understood
• Serves as a mechanism for identifying
software requirements
• Focuses on those aspects of the software
that are visible to the customer/user
• Feedback is used to refine the prototype 20
Prototyping Model(Potential Problems)
• The customer sees a "working version" of the software,
wants to stop all development and then buy the prototype
after a "few fixes" are made
• Developers often make implementation compromises to
get the software running quickly (e.g., language choice,
user interface, operating system choice, inefficient
algorithms)
• Lesson learned
– Define the rules up front on the final disposition of the
prototype before it is built
– In most circumstances, plan to discard the prototype
and engineer the actual production software with a
goal toward quality
21
 Evolutionary Models: The Spiral
planning
estimation
scheduling
risk analysis

communication

modeling
analysis
design
start

deployment
construction
delivery code
feedback test 23
 Spiral Model (Description)
• Invented by Dr. Barry Boehm in 1988 while working at
TRW
• Follows an evolutionary approach
• Used when requirements are not well understood and risks
are high
• Inner spirals focus on identifying software requirements and
project risks; may also incorporate prototyping
• Outer spirals take on a classical waterfall approach after
requirements have been defined, but permit iterative growth
of the software
• Operates as a risk-driven model…a go/no-go decision occurs
after each complete spiral in order to react to risk
determinations
• Requires considerable expertise in risk assessment
• Serves as a realistic model for large-scale software 24

development
 General Weaknesses of
Evolutionary Process Models
1) Prototyping poses a problem to project planning because of
the uncertain number of iterations required to construct the
product
2) Evolutionary software processes do not establish the
maximum speed of the evolution
• If too fast, the process will fall into chaos
• If too slow, productivity could be affected
3) Software processes should focus first on flexibility and
extensibility, and second on high quality
• We should prioritize the speed of the development over
zero defects
• Extending the development in order to reach higher quality
could result in late delivery
25
Evolutionary Models: Concurrent

26
Specialized Process Models
 Component-based Development Model
• Consists of the following process steps
– Available component-based products are researched
and evaluated for the application domain in
question
– Component integration issues are considered
– A software architecture is designed to accommodate
the components
– Components are integrated into the architecture
– Comprehensive testing is conducted to ensure
proper functionality
• Relies on a robust component library
• Capitalizes on software reuse, which leads to
documented savings in project cost and time
28
 Aspect-oriented software development
(AOSD)
• Aspect-oriented software development (AOSD) is
a software design solution that helps address the
modularity issues that are not properly resolved
by other software approaches, like procedural,
structured and object-oriented programming
(OOP). AOSD complements, rather than replaces,
these other types of software approaches.
• AOSD is also known as aspect-oriented
programming (AOP).