Process Models

Software Engineering: A Practitioners Approach, 7/e

by Roger S. Pressman

A Generic Process Model

Process Flow

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

Process Assessment and Improvement

Standard CMMI Assessment Method for Process Improvement

(SCAMPI)

CMM-Based Appraisal for Internal Process Improvement (CBA IPI)

SPICE - (ISO/IEC15504)

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.

Process Models

Waterfall Model
Communication
Project initiation
Requirements gathering

Real projects rarely follow the

sequential flow.

Planning
Estimating
Scheduling and tracking

Customers usually cant state

all requirements explicitly.

A working version will

Modeling

not be available until

late in the project
time-span.

Analysis and design

Construction
Code and test

Deployment
Delivery
Support and feedback

V-Model

Incremental Model
Communication

Increment #n

Software Functionality and Features

Planning

Delivery of
nth increment

Modeling
Construction
Deployment

Increment #2

Increment #1

Delivery of
2nd increment

Delivery of
1st increment

More features
and functionality
Core product

Project Calendar Time

Incremental Process Models

The Rapid Application Development (RAD) Model
Team #n
Communication

Modeling
business modeling
data modeling
process modeling

Require sufficient
human resources.

Planning

Require commitment to
the rapid-fire activities from
both developers and
customers.
If a system cannot be
properly modularized, RAD
may not work.

RAD is not
appropriate when
technical risks are
high.

Team #1
Modeling
business modeling
data modeling
process modeling

Construction
component reuse
automatic code
generation
testing

Construction
component reuse
automatic code
generation
testing

Deployment
integration
delivery
feedback

Evolutionary Process Models: Prototyping

Quick Plan
Communication
Modeling
Quick design

Deployment
Delivery
& Feedback

Construction
of prototype

Evolutionary Models: The Spiral

planning
estimation
scheduling
risk analysis

communication
modeling
analysis
design
start

deployment
delivery
feedback

construction
code
test
12

Evolutionary Models: Spiral Model

Cumulative cost

Progress through steps

Determine
objectives,
alternatives,
constrains

Review

Commitment
Partition

Risk
analysis

Risk
analysis
Risk
analy- Prototype 1
sis
Requirements
plan, life-cycle
plan
Development plan
Integration
and
test plan

Evaluate alternatives,
identify, resolve risks

Prototype 2

Risk
analysis

Prototype 3

Operational
prototype

Simulations, models, benchmarks

Concept of
operation

Software
requirements

Requirements
validation

Implementation

Software
product
design
Unit
test

Design validation and

verification

Plan next phases

Detailed
design

Acceptance
test

Code

Integration
and test
Develop, verify nextlevel product

Evolutionary Models: Concurrent

none
Modeling act ivit y

represent s t he st at e
of a sof t ware engineering
act ivit y or t ask

Under
development

A wait ing
changes

Under review
Under
revision
Baselined

Done

14

Other Process Models

Component based developmentthe process to

apply when reuse is a development objective.

Formal methodsemphasizes the mathematical

specification of requirements.

Unified Processa use-case driven, architecturecentric, iterative and incremental software process
closely aligned with the Unified Modeling Language
(UML).
15

The Unified Process (UP)

A use-case driven, architecture-centric, iterative and incremental software

process closely aligned with the Unified Modeling Language (UML)

Elaboration
Inception

Release

Construction

Software increment

Transition
Production

UP Phases
UP Phase s
Incept ion

Elaborat ion

Const ruct ion

Transit ion

Product ion

Wor kflows
Requirements
Analysis
Design

Implementation
Test
Support
Iterations

#1

#2

#n-1

#n

17

Agile Model

18

Agility
Effective (rapid and adaptive) response to change (team members, new

technology, requirements)
Effective communication in structure and attitudes among all team

members, technological and business people, software engineers and

managers.
Drawing the customer into the team.
Organizing a team so that it is in control of the work performed.
Eliminate all but the most essential work products and keep them lean.
Emphasize an incremental delivery strategy as opposed to intermediate

products that gets working software to the customer as rapidly as feasible.

Principles of Agile method

Agility Principles - I
1. Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
2. Welcome changing requirements, even late in development.
3. Deliver working software frequently, from a couple of weeks to a couple of months,
with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support
they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is facetoface conversation.
21

Agility Principles - II
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and
users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity.
11. The best architectures, requirements, and designs emerge from selforganizing
teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes
and adjusts its behavior accordingly.

22

Human Factors
the process molds to the needs of the people and team not the other way around
key traits must exist among the people on an agile team and the team itself:
Competence. ( talent, skills, knowledge)
Common focus. ( deliver a working software increment )

Collaboration. ( stakeholders)
Decision-making ability. ( freedom to control its own destiny)
Fuzzy problem-solving ability. (ambiguity and constant changes, today

problem may not be tomorrows problem)

Mutual trust and respect.
Self-organization. ( themselves for the work done, process for its local
environment, the work schedule)

Extreme programming (XP)

Perhaps the best-known and most widely used agile

method:
Good practice:
1.
2.

iterative development.
customer involvement to EXTREME levels.

Extreme Programming (XP) takes an EXTREME

approach to iterative development.

All requirements are expressed as scenarios (called user stories).
Scenarios are implemented as series of task.
New versions may be built several times per day;
Increments are delivered to customers every 2 weeks;

All tests must be run for every build and the build is only accepted if

tests run successfully.

Extreme Programming (XP)

XP Planning
Begins with the creation of user stories
Agile team assesses each story and assigns a cost
Stories are grouped to for a deliverable increment
A commitment is made on delivery date
After the first increment project velocity is used to help define
subsequent delivery dates for other increments

XP Design
Follows the KIS principle
Encourage the use of CRC cards
For difficult design problems, suggests the creation of design prototype
Encourages refactoringan iterative refinement of the internal program
design
25

Extreme Programming (XP)

XP Coding
Recommends the construction of a unit test for a store
before coding commences
Encourages pair programming

XP Testing
All unit tests are executed daily
Acceptance tests are defined by the customer and
executed to assess customer visible functionality

26

Extreme Programming (XP)

simple design
CRC cards

spike solut ions

prot ot ypes

user st ories
values
accept ance t est crit eria
it erat ion plan

refact oring
pair
programming

Release
sof t ware increment
project velocit y comput ed

unit t est
cont inuous int egrat ion
accept ance t est ing
27

XP and agile principles

Incremental development is supported through small,

frequent system releases.

Customer involvement means full-time customer
engagement with the team.
People not process through pair programming,
collective ownership and a process that avoids long
working hours.
Change supported through regular system releases.
Maintaining simplicity through constant refactoring of
code.

Component Assembly Model

Fourth Generation Techniques (4GT)

Requirem ents
gathering
"Design"
Strategy
Implementation
using 4GL
Testing

4GT Characteristics

Use of software tools that allow software engineer to specify s/w

characteristics at higher level.

The tools generate codes based on specification.

More time in design and testing - increase productivity.
Tools may not be easy to use, codes generated may not be
efficient

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 (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.
32

Team Software Process (TSP)

Build self-directed teams that plan and track their work,

establish goals, and own their processes and plans.

Show managers how to coach and motivate their teams

and how to help them sustain peak performance.

Accelerate software process improvement.

The Capability Maturity Model (CMM), a measure of the

effectiveness of a software process.

Provide improvement guidance to high-maturity

organizations.

33