Software Engineering A Practitioner's Approach - Roger S. Pressman

Chapter 1
 Software & Software Engineering

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.
These slides are designed to accompany Software Engineering: A

Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 1
What is
Software?
Software is: (1) instructions (computer programs)
that when executed provide desired features,
function, and performance; (2) data structures
that enable the programs to adequately manipulate
information and (3) documentation that describes
the operation and use of the programs.

Roger Pressman. 2
What is
Software?
 Software is developed or engineered, it is not
manufactured in the classical sense.
 Software doesn't "wear out."
 Although the industry is moving toward
component-based construction, most software
continues to be custom-built.

Roger Pressman. 3
Wear vs.
Deterioration increased failure
rate due to side effects
Failure
rate
change
actual curve
idealized curve
Time
Roger Pressman. 4
Software
Applications
 system software
 application software
 engineering/scientific
software
 embedded software
 product-line software
 WebApps (Web
applications)
 AI software

Roger Pressman. 5
Software—New Categories
 Open world computing—pervasive, distributed
computing
 Ubiquitous computing—wireless networks
 Netsourcing—the Web as a computing engine
 Open source—”free” source code open to the
computing community (a blessing, but also a
potential curse!)
 Also … (see Chapter 31)
 Data mining
 Grid computing
 Cognitive machines
 Software for nanotechnologies

Roger Pressman. 6
Legacy Software
Why must it change?
 software must be adapted to meet
the needs of new computing
environments or technology.
 software must be enhanced to
implement new business
requirements.
 software must be extended to make
it interoperable with other more
modern systems or databases.
 software must be re-architected to
make it viable within a network
environment.
Roger Pressman. 7
Characteristics of
WebApps - I
 Network intensiveness. A WebApp resides on a network and
must serve the needs of a diverse community of clients.
 Concurrency. A large number of users may access the
WebApp at one time.
 Unpredictable load. The number of users of the WebApp may
vary by orders of magnitude from day to day.
 Performance. If a WebApp user must wait too long (for
access, for server-side processing, for client-side formatting
and display), he or she may decide to go elsewhere.
 Availability. Although expectation of 100 percent availability is
unreasonable, users of popular WebApps often demand
access on a “24/7/365” basis.

Roger Pressman. 8
Characteristics of
WebApps - II
 Data driven. The primary function of many WebApps is to use
hypermedia to present text, graphics, audio, and video content to
the end-user.
 Content sensitive. The quality and aesthetic nature of content
remains an important determinant of the quality of a WebApp.
 Continuous evolution. Unlike conventional application software
that evolves over a series of planned, chronologically-spaced
releases, Web applications evolve continuously.
 Immediacy. Although immediacy—the compelling need to get
software to market quickly—is a characteristic of many application
domains, WebApps often exhibit a time to market that can be a
matter of a few days or weeks.
 Security. Because WebApps are available via network access, it
is difficult, if not impossible, to limit the population of end-users
who may access the application.
 Aesthetics. An undeniable part of the appeal of a WebApp is its
look
These slides and feel.
are designed to accompany Software Engineering: A
Roger Pressman. 9
Software Engineering
 Some realities:
 a concerted effort should be made to understand the
problem before a software solution is developed
 design becomes a pivotal activity
 software should exhibit high quality
 software should be maintainable
 The seminal definition:
 [Software engineering is] the establishment and use of
sound engineering principles in order to obtain
economically software that is reliable and works efficiently
on real machines.

Roger Pressman. 10
 The IEEE definition:
 Software Engineering: (1) The application of a systematic,
disciplined, quantifiable approach to the development,
operation, and maintenance of software; that is, the
application of engineering to software. (2) The study of
approaches as in (1).

Roger Pressman. 11
A Layered
Technology
tools
methods
process model
a “quality” focus

Roger Pressman. 12
A Process
Framework
Process framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities

Roger Pressman. 13
Framework
Activities
 Communication
 Planning
 Modeling
 Analysis of requirements
 Design
 Construction
 Code generation
 Testing
 Deployment

Roger Pressman. 14
Umbrella
Activities
 Software project management
 Formal technical reviews
 Software quality assurance
 Software configuration
management
 Work product preparation and
production
 Reusability management
 Measurement
 Risk management
Roger Pressman. 15
Adapting a Process
Model
 the overall flow of activities, actions, and tasks and the
interdependencies among them
 the degree to which actions and tasks are defined within
each framework activity
 the degree to which work products are identified and
required
 the manner which quality assurance activities are applied
 the manner in which project tracking and control activities
are applied
 the overall degree of detail and rigor with which the
process is described
 the degree to which the customer and other stakeholders
are involved with the project
 the level of autonomy given to the software team
 the degree to which team organization and roles are
prescribed
Roger Pressman. 16
The Essence of
Practice
 Polya suggests:
1. Understand the problem (communication and analysis).
2. Plan a solution (modeling and software design).
3. Carry out the plan (code generation).
4. Examine the result for accuracy (testing and quality
assurance).

Roger Pressman. 17
Understand the
Problem
 Who has a stake in the solution to the problem?
That is, who are the stakeholders?
 What are the unknowns? What data, functions,
and features are required to properly solve the
problem?
 Can the problem be compartmentalized? Is it
possible to represent smaller problems that
may be easier to understand?
 Can the problem be represented graphically? Can
an analysis model be created?

Roger Pressman. 18
Plan the Solution
 Have you seen similar problems before? Are there patterns
that are recognizable in a potential solution? Is there
existing software that implements the data, functions,
and features that are required?
 Has a similar problem been solved? If so, are elements of the
solution reusable?
 Can subproblems be defined? If so, are solutions readily
apparent for the subproblems?
 Can you represent a solution in a manner that leads to
effective implementation? Can a design model be created?

Roger Pressman. 19
Carry Out the Plan
 Does the solution conform to the plan? Is source
code traceable to the design model?
 Is each component part of the solution provably
correct? Has the design and code been
reviewed, or better, have correctness proofs
been applied to algorithm?

Roger Pressman. 20
Examine the Result
 Is it possible to test each component part of the
solution? Has a reasonable testing strategy been
implemented?
 Does the solution produce results that conform to
the data, functions, and features that are required?
Has the software been validated against all
stakeholder requirements?

Roger Pressman. 21
Hooker’s General
Principles
 1: The Reason It All Exists
 2: KISS (Keep It Simple, Stupid!)
 3: Maintain the Vision
 4: What You Produce, Others Will Consume
 5: Be Open to the Future
 6: Plan Ahead for Reuse
 7: Think!

Roger Pressman. 22
Software
Myths
 Affect managers, customers
(and other non-technical
stakeholders) and
practitioners
 Are believable because they
often have elements of truth,
but …
 Invariably lead to bad
decisions,
therefore …
 Insist on reality as you
Roger Pressman. navigate your way through

23
How It all Starts
 SafeHome:
 Every software project is precipitated by some
business need—
• the need to correct a defect in an existing application;
• the need to the need to adapt a ‘legacy system’ to a
changing business environment;
• the need to extend the functions and features of an
existing application, or
• the need to create a new product, service, or system.

Roger Pressman. 24
Chapter 2
 Process Models
Approach, 7/e

use.

Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by
Roger Pressman. 25
A Generic Process
Model

Roger Pressman. 26
Process Flow

Roger Pressman. 27
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

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

Roger Pressman. 30
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]

Roger Pressman. 31
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?

Roger Pressman. 32
The Waterfall
Model
Communication
project initiation Planning
requirement gathering estimating Modeling
scheduling
analysis Construction
tracking
design Deployment
code
test delivery
support
feedback

Roger Pressman. 33
The V-Model

Roger Pressman. 34
The Incremental
Model
increment #n
Communi c at ion
Planni ng
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 d b a c k
delivery of
increment # 2 nth increment
Communi c at ion
Planning
Modeling
des ign code De p l o y m e n t
fe e d b a c k
delivery of
increment # 1 2nd increment
Co mmuni c at io n
Planni ng
M odel ing
des ign c ode
delivery of
De p l o y m e n t
fe edbac k
1st increment
projectEngineering:
These slides are designed to accompany Software calendar time
A
Roger Pressman. 35
Evolutionary Models:
Prototyping
Quick plan
Quick
Communication plan
communication
Modeling
Modeling
Quick design
Quick design
Deployment
Deployment
Delivery
Construction
delivery &
& Feedback of prototype
Construction
feedback Construction
of
ofprototype
prototype

Roger Pressman. 36
Evolutionary Models: The
Spiral planning
estimation
scheduling
risk analysis
communication
modeling
analysis
design
start
deployment
construction
delivery
code
feedback test
Roger Pressman. 37
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

Roger Pressman. 38
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,
These iterative
slides are designed to accompany Software Engineering: A
and
incremental” software process closely
Roger Pressman. 39
The Unified Process (UP)
Elaboration
elaboration
Inception
inception
construction
Release
transition
software increment
production
Roger Pressman. 40
UP
Phases
UP Phases
Inception Elaboration Construction Transition Production
Workflows
Requirements
Analysis
Design
Implementation
Test
Support
Iterations #1 #2 #n-1 #n

Roger Pressman. 41
UP Work Products
Inception phase
Elaboration phase
Vision document
Initial use-case model
Initial project glossary Construction phase
Use-case model
Initial business case Supplementary requirements
Initial risk assessment. including non-functional Design model
Transition phase
Project plan, Analysis model Software components
phases and iterations. Software architecture Integrated software Delivered software increment
Business model, Description. increment Beta test reports
if necessary. Executable architectural General user feedback
Test plan and procedure
One or more prototypes prototype.
I nc ept i o Test cases
n Preliminary design model Support documentation
Revised risk list user manuals
Project plan including installation manuals
iteration plan description of current
adapted workflows increment
milestones
technical work products
Preliminary user manual

Roger Pressman. 42
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. 43
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. 44
Chapter 3
 Agile Development
Approach, 7/e

use.

Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by
Roger Pressman. 45
The Manifesto for
Agile Software
Development
“We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
• Individuals and interactions over processes and
tools
• Working software over comprehensive
documentation
• Customer collaboration over contract
negotiation
• Responding to change over following a plan
That is, while there is value in the items on the
right, we value the items on the left more.”
Kent Beck et al

Roger Pressman. 46
What is
“Agility”?
 Effective (rapid and adaptive) response
to change
 Effective communication among all
stakeholders
 Drawing the customer onto the team
 Organizing a team so that it is in
control of the work performed
Yielding …
 Rapid, incremental delivery of software

Roger Pressman. 47
Agility and the Cost of
Change

Roger Pressman. 48
An Agile Process
 Is driven by customer descriptions of
what is required (scenarios)
 Recognizes that plans are short-lived
 Develops software iteratively with a
heavy emphasis on construction
activities
 Delivers multiple ‘software increments’
 Adapts as changes occur

Roger Pressman. 49
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.
Agile processes harness change for the customer's competitive
advantage.
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 face–to–face
conversation.
Roger Pressman. 50
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 – the art of maximizing the amount of work
not done – is essential.
11. The best architectures, requirements, and designs
emerge from self–organizing teams.
12. At regular intervals, the team reflects on how to become
more effective, then tunes and adjusts its behavior
accordingly.
Roger Pressman. 51
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.
 Common focus.
 Collaboration.
 Decision-making ability.
 Fuzzy problem-solving ability.
 Mutual trust and respect.
 Self-organization.
Roger Pressman. 52
Extreme Programming (XP)
 The most widely used agile process,
originally proposed by Kent Beck
 XP Planning
 Begins with the creation of “user stories”
by listening
 Customer assigns a value to the story.
 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
Roger Pressman.
dates for other increments 53
Extreme Programming
(XP)
 XP Design
 Follows the KIS principle
 Encourage the use of CRC cards (see Chapter 8)
 For difficult design problems, suggests the creation of
“spike solutions”—a design prototype
 Encourages “refactoring”—an iterative refinement of
the internal program design
 XP Coding
 Recommends the construction of a unit test for a
story before coding commences
 Encourages “pair programming”
 XP Testing
 All unit tests are executed daily (whenever code is
modified)
 “Acceptance tests” are defined by the customer and
executed to assess customer visible functionality

Roger Pressman. 54
Extreme Programming (XP)
spike solutions
simple design
prototypes
CRC cards
user stories
values
acceptance test criteria
iteration plan
refactoring
pair
programming
Release
software increment unit test
project velocity computed continuous integration
acceptance testing
Roger Pressman. 55
Adaptive Software
Development
 Originally proposed by Jim Highsmith
 ASD — distinguishing features
 Mission-driven planning
 Component-based focus
 Uses “time-boxing” (See Chapter 24)
 Explicit consideration of risks
 Emphasizes collaboration for requirements
gathering
 Emphasizes “learning” throughout the
process

Roger Pressman. 56
Adaptive Software
Development
adaptive cycle planning Requirements gathering
uses mission statement J AD
project constraints mini-specs
basic requirements
time-boxed release plan
Release
software increment
adjustments for subsequent cycles
components implemented/ tested
focus groups for feedback
formal technical reviews
postmortems
Roger Pressman. 57
Dynamic Systems Development
Method
 Promoted by the DSDM Consortium (
www.dsdm.org)
 DSDM—distinguishing features
 Similar in most respects to XP and/or ASD
 Nine guiding principles
• Active user involvement is imperative.
• DSDM teams must be empowered to make decisions.
• The focus is on frequent delivery of products.
• Fitness for business purpose is the essential criterion for
acceptance of deliverables.
• Iterative and incremental development is necessary to converge
on an accurate business solution.
• All changes during development are reversible.
• Requirements are baselined at a high level
• Testing is integrated throughout the life-cycle.

Roger Pressman. 58
Dynamic Systems Development
Method
These slidesDSDM Life Cycle

are designed (with permission
to accompany Softwareof Engineering:
the DSDM consortium)
A
Roger Pressman. 59
Scrum
 Originally proposed by Schwaber and
Beedle
 Scrum—distinguishing features
 Development work is partitioned into
“packets”
 Testing and documentation are on-going as
the product is constructed
 Work occurs in “sprints” and is derived
from a “backlog” of existing requirements
 Meetings are very short and sometimes
conducted without chairs
 “Demos” are delivered to the customer
with the time-box allocated
Roger Pressman. 60
Scru
m
Scrum Process Flow (used with permission)

Roger Pressman. 61
Crystal
 Proposed by Cockburn and Highsmith
 Crystal—distinguishing features
 Actually a family of process models that
allow “maneuverability” based on problem
characteristics
 Face-to-face communication is
emphasized
 Suggests the use of “reflection
workshops” to review the work habits of
the team

Roger Pressman. 62
Feature Driven
Development
 Originally proposed by Peter Coad et al
 FDD—distinguishing features
 Emphasis is on defining “features”
• a feature “is a client-valued function that can
be implemented in two weeks or less.”
 Uses a feature template
• <action> the <result> <by | for | of | to> a(n)
<object>
 A features list is created and “plan by
feature” is conducted
 Design and construction merge in FDD

Roger Pressman. 63
Feature Driven
Development
Reprinted with permission of Peter Coad

Roger Pressman. 64
Agile
Modeling
 Originally proposed by Scott Ambler
 Suggests a set of agile modeling
principles
 Model with a purpose
 Use multiple models
 Travel light
 Content is more important than
representation
 Know the models and the tools you use to
create them
 Adapt locally
Roger Pressman. 65
Chapter 4
 Principles that Guide Practice
Approach, 7/e

use.

Roger Pressman. 66
Knowledge
 You often hear people say that software development
knowledge has a 3year halflife: half of what you need to
know today will be obsolete within 3 years. In the domain of
technologyrelated knowledge, that’s probably about right.
But there is another kind of software development knowledge
—a kind that I think of as "software engineering principles"—
that does not have a threeyear halflife. These software
engineering principles are likely to serve a professional
programmer throughout his or her career.
Steve McConnell

Roger Pressman. 67
Principles that Guide
Process - I
 Principle #1. Be agile. Whether the process model you choose
is prescriptive or agile, the basic tenets of agile development
should govern your approach.
 Principle #2. Focus on quality at every step. The exit condition
for every process activity, action, and task should focus on the
quality of the work product that has been produced.
 Principle #3. Be ready to adapt. Process is not a religious
experience and dogma has no place in it. When necessary,
adapt your approach to constraints imposed by the problem,
the people, and the project itself.
 Principle #4. Build an effective team. Software engineering
process and practice are important, but the bottom line is
people. Build a self-organizing team that has mutual trust and
respect.

Roger Pressman. 68
Process - II
 Principle #5. Establish mechanisms for communication and
coordination. Projects fail because important information falls
into the cracks and/or stakeholders fail to coordinate their
efforts to create a successful end product.
 Principle #6. Manage change. The approach may be either
formal or informal, but mechanisms must be established to
manage the way changes are requested, assessed, approved
and implemented.
 Principle #7. Assess risk. Lots of things can go wrong as
software is being developed. It’s essential that you establish
contingency plans.
 Principle #8. Create work products that provide value for
others. Create only those work products that provide value for
other process activities, actions or tasks.

Roger Pressman. 69
Practice
 Principle #1. Divide and conquer. Stated in a more
technical manner, analysis and design should always
emphasize separation of concerns (SoC).
 Principle #2. Understand the use of abstraction. At it
core, an abstraction is a simplification of some complex
element of a system used to communication meaning in
a single phrase.
 Principle #3. Strive for consistency. A familiar context
makes software easier to use.
 Principle #4. Focus on the transfer of information. Pay
special attention to the analysis, design, construction,
and testing of interfaces.

Roger Pressman. 70
Practice
 Principle #5. Build software that exhibits effective
modularity. Separation of concerns (Principle #1)
establishes a philosophy for software. Modularity
provides a mechanism for realizing the philosophy.
 Principle #6. Look for patterns. Brad Appleton [App00]
suggests that: “The goal of patterns within the software
community is to create a body of literature to help
software developers resolve recurring problems
encountered throughout all of software development.
 Principle #7. When possible, represent the problem and
its solution from a number of different perspectives.
 Principle #8. Remember that someone will maintain the
software.

Roger Pressman. 71
Communication
Principles
 Principle #1. Listen. Try to focus on the speaker’s
words, rather than formulating your response to those
words.
 Principle # 2. Prepare before you communicate. Spend
the time to understand the problem before you meet
with others.
 Principle # 3. Someone should facilitate the activity.
Every communication meeting should have a leader (a
facilitator) to keep the conversation moving in a
productive direction; (2) to mediate any conflict that
does occur, and (3) to ensure than other principles are
followed.
 Principle #4. Face-to-face communication is best. But it
usually works better when some other representation of
the relevant information is present.
Roger Pressman. 72
Communication
Principles
 Principle # 5. Take notes and document decisions. Someone
participating in the communication should serve as a “recorder” and
write down all important points and decisions.
 Principle # 6. Strive for collaboration. Collaboration and consensus
occur when the collective knowledge of members of the team is
combined …
 Principle # 7. Stay focused, modularize your discussion. The more
people involved in any communication, the more likely that discussion
will bounce from one topic to the next.
 Principle # 8. If something is unclear, draw a picture.
 Principle # 9. (a) Once you agree to something, move on; (b) If you
can’t agree to something, move on; (c) If a feature or function is unclear
and cannot be clarified at the moment, move on.
 Principle # 10. Negotiation is not a contest or a game. It works best
when both parties win.
Roger Pressman. 73
Planning Principles
 Principle #1. Understand the scope of the project. It’s
impossible to use a roadmap if you don’t know where
you’re going. Scope provides the software team with a
destination.
 Principle #2. Involve the customer in the planning
activity. The customer defines priorities and establishes
project constraints.
 Principle #3. Recognize that planning is iterative. A
project plan is never engraved in stone. As work begins,
it very likely that things will change.
 Principle #4. Estimate based on what you know. The
intent of estimation is to provide an indication of effort,
cost, and task duration, based on the team’s current
understanding of the work to be done.
Roger Pressman. 74
Planning Principles
 Principle #5. Consider risk as you define the plan. If you have
identified risks that have high impact and high probability,
contingency planning is necessary.
 Principle #6. Be realistic. People don’t work 100 percent of
every day.
 Principle #7. Adjust granularity as you define the plan.
Granularity refers to the level of detail that is introduced as a
project plan is developed.
 Principle #8. Define how you intend to ensure quality. The
plan should identify how the software team intends to ensure
quality.
 Principle #9. Describe how you intend to accommodate
change. Even the best planning can be obviated by
uncontrolled change.
 Principle #10. Track the plan frequently and make
adjustments as required. Software projects fall behind schedule
one
These slides are day at
designed a time. Software Engineering: A
to accompany
Roger Pressman. 75
Modeling Principles
 In software engineering work, two classes of
models can be created:
 Requirements models (also called analysis models)
represent the customer requirements by depicting
the software in three different domains: the
information domain, the functional domain, and the
behavioral domain.
 Design models represent characteristics of the
software that help practitioners to construct it
effectively: the architecture, the user interface, and
component-level detail.

Roger Pressman. 76
Requirements Modeling
Principles
 Principle #1. The information domain of a problem
must be represented and understood.
 Principle #2. The functions that the software performs
must be defined.
 Principle #3. The behavior of the software (as a
consequence of external events) must be represented.
 Principle #4. The models that depict information,
function, and behavior must be partitioned in a manner
that uncovers detail in a layered (or hierarchical)
fashion.
 Principle #5. The analysis task should move from
essential information toward implementation detail.

Roger Pressman. 77
Design Modeling
Principles
 Principle #1. Design should be traceable to the requirements model.
 Principle #2. Always consider the architecture of the system to be
built.
 Principle #3. Design of data is as important as design of processing
functions.
 Principle #5. User interface design should be tuned to the needs of
the end-user. However, in every case, it should stress ease of use.
 Principle #6. Component-level design should be functionally
independent.
 Principle #7. Components should be loosely coupled to one another
and to the external environment.
 Principle #8. Design representations (models) should be easily
understandable.
 Principle #9. The design should be developed iteratively. With each
iteration, the designer should strive for greater simplicity.

Roger Pressman. 78
Agile Modeling Principles
 Principle #1. The primary goal of the software team is to build software, not
create models.
 Principle #2. Travel light—don’t create more models than you need.
 Principle #3. Strive to produce the simplest model that will describe the problem
or the software.
 Principle #4. Build models in a way that makes them amenable to change.
 Principle #5. Be able to state an explicit purpose for each model that is created.
 Principle #6. Adapt the models you develop to the system at hand.
 Principle #7. Try to build useful models, but forget about building perfect
models.
 Principle #8. Don’t become dogmatic about the syntax of the model. If it
communicates content successfully, representation is secondary.
 Principle #9. If your instincts tell you a model isn’t right even though it seems
okay on paper, you probably have reason to be concerned.
 Principle #10. Get feedback as soon as you can.

Roger Pressman. 79
Construction
Principles
 The construction activity encompasses a set of
coding and testing tasks that lead to
operational software that is ready for delivery
to the customer or end-user.
 Coding principles and concepts are closely
aligned programming style, programming
languages, and programming methods.
 Testing principles and concepts lead to the
design of tests that systematically uncover
different classes of errors and to do so with a
minimum amount of time and effort.
Roger Pressman. 80
Preparation Principles
 Before you write one line of code, be sure you:
• Understand the problem you’re trying to solve.
• Understand basic design principles and concepts.
• Pick a programming language that meets the needs of
the software to be built and the environment in which
it will operate.
• Select a programming environment that provides tools
that will make your work easier.
• Create a set of unit tests that will be applied once the
component you code is completed.

Roger Pressman. 81
Coding Principles
 As you begin writing code, be sure you:
• Constrain your algorithms by following structured
programming [Boh00] practice.
• Consider the use of pair programming
• Select data structures that will meet the needs of the design.
• Understand the software architecture and create interfaces
that are consistent with it.
• Keep conditional logic as simple as possible.
• Create nested loops in a way that makes them easily testable.
• Select meaningful variable names and follow other local
coding standards.
• Write code that is self-documenting.
• Create a visual layout (e.g., indentation and blank lines) that
aids understanding.

Roger Pressman. 82
Validation Principles
 After you’ve completed your first coding pass,
be sure you:
• Conduct a code walkthrough when appropriate.
• Perform unit tests and correct errors you’ve uncovered.
• Refactor the code.

Roger Pressman. 83
Testing Principles
 Al Davis [Dav95] suggests the
following:
 Principle #1. All tests should be traceable to
customer requirements.
 Principle #2. Tests should be planned long before
testing begins.
 Principle #3. The Pareto principle applies to
software testing.
 Principle #4. Testing should begin “in the small” and
progress toward testing “in the large.”
 Principle #5. Exhaustive testing is not possible.

Roger Pressman. 84
Deployment Principles
 Principle #1. Customer expectations for the software
must be managed. Too often, the customer expects more
than the team has promised to deliver, and
disappointment occurs immediately.
 Principle #2. A complete delivery package should be
assembled and tested.
 Principle #3. A support regime must be established
before the software is delivered. An end-user expects
responsiveness and accurate information when a
question or problem arises.
 Principle #4. Appropriate instructional materials must
be provided to end-users.
 Principle #5. Buggy software should be fixed first,
delivered later.
Roger Pressman. 85
Chapter 5
 Understanding Requirements
Approach, 7/e

use.

Roger Pressman. 86
Requirements
Engineering-I
 Inception—ask a set of questions that establish …
 basic understanding of the problem
 the people who want a solution
 the nature of the solution that is desired, and
 the effectiveness of preliminary communication and
collaboration between the customer and the
developer
 Elicitation—elicit requirements from all
stakeholders
 Elaboration—create an analysis model that
identifies data, function and behavioral
requirements
 Negotiation—agree on a deliverable system that is
realistic for developers and customers
Roger Pressman. 87
Requirements Engineering-II
 Specification—can be any one (or more) of the
following:
 A written document
 A set of models
 A formal mathematical
 A collection of user scenarios (use-cases)
 A prototype
 Validation—a review mechanism that looks for
 errors in content or interpretation
 areas where clarification may be required
 missing information
 inconsistencies (a major problem when large products
or systems are engineered)
 conflicting or unrealistic (unachievable) requirements.
 Requirements management

Roger Pressman. 88
Incepti
on
 Identify stakeholders
 “who else do you think I should talk to?”
 Recognize multiple points of view
 Work toward collaboration
 The first questions
 Who is behind the request for this work?
 Who will use the solution?
 What will be the economic benefit of a
successful solution
 Is there another source for the solution
that you need?

Roger Pressman. 89
Eliciting
Requirements
 meetings are conducted and attended by both
software engineers and customers
 rules for preparation and participation are
established
 an agenda is suggested
 a "facilitator" (can be a customer, a developer, or an
outsider) controls the meeting
 a "definition mechanism" (can be work sheets, flip
charts, or wall stickers or an electronic bulletin
board, chat room or virtual forum) is used
 the goal is
 to identify the problem
 propose elements of the solution
 negotiate different approaches, and
 specify a preliminary set of solution requirements
Roger Pressman. 90
Eliciting
Requirements
Conduct FAST
meetings
Make lists of
functions, classes
Make lists of
constraints, etc.
formal prioritization?
Elic it requirements
yes no
Use QFD to informally define actors

prioritize prioritize
requirements requirements
draw use-case
write scenario
diagram
Create Use-cases
complete template

Roger Pressman. 91
Quality Function
Deployment
 Function deployment determines the
“value” (as perceived by the
customer) of each function required of
the system
 Information deployment identifies
data objects and events
 Task deployment examines the
behavior of the system
 Value analysis determines the relative
priority of requirements
Roger Pressman. 92
Elicitation Work
Products
 a statement of need and feasibility.
 a bounded statement of scope for the system
or product.
 a list of customers, users, and other
stakeholders who participated in requirements
elicitation
 a description of the system’s technical
environment.
 a list of requirements (preferably organized by
function) and the domain constraints that apply
to each.
 a set of usage scenarios that provide insight
into the use of the system or product under
different operating conditions.
These slides any prototypes developed
Engineering: Ato better define
 are designed to accompany Software
requirements.
Roger Pressman. 93
Building the Analysis
Model
 Elements of the analysis model
 Scenario-based elements
• Functional—processing narratives for software
functions
• Use-case—descriptions of the interaction
between an “actor” and the system
 Class-based elements
• Implied by scenarios
 Behavioral elements
• State diagram
 Flow-oriented elements
• Data flow diagram

Roger Pressman. 94
Use-Cases
 A collection of user scenarios that describe the thread of
usage of a system
 Each scenario is described from the point-of-view of an
“actor”—a person or device that interacts with the
software in some way
 Each scenario answers the following questions:
 Who is the primary actor, the secondary actor (s)?
 What are the actor’s goals?
 What preconditions should exist before the story begins?
 What main tasks or functions are performed by the actor?
 What extensions might be considered as the story is
described?
 What variations in the actor’s interaction are possible?
 What system information will the actor acquire, produce, or
change?
 Will the actor have to inform the system about changes in the
external environment?
 What information does the actor desire from the system?
 Does tothe
These slides are designed actor wish
accompany SoftwaretoEngineering:
be informedA about unexpected
changes?
Roger Pressman. 95
Use-Case Diagram
Arms/ disarms
system
Accesses system sensors

via Internet
homeowner
Responds to
alarm event
Encounters an
error condition
system Reconfigures sensors

administrator and related
system features

Roger Pressman. 96
Class
Diagram
From the SafeHome system …
Sensor
name/id
type
location
area
characteristics
identify()
enable()
disable()
reconfigure()

Roger Pressman. 97
State Diagram
Reading
Commands
State name
System status = “ready”
Display msg = “enter cmd”
Display status = steady
State variables
Entry/subsystems ready
Do: poll user input panel
Do: read user input
Do: interpret user input State activities

Roger Pressman. 98
Analysis
Patterns
Pattern name: A descriptor that captures the essence of the pattern.
Intent: Describes what the pattern accomplishes or represents
Motivation: A scenario that illustrates how the pattern can be used to address the
problem.
Forces and context: A description of external issues (forces) that can affect how
the pattern is used and also the external issues that will be resolved when the
pattern is applied.
Solution: A description of how the pattern is applied to solve the problem with an
emphasis on structural and behavioral issues.
Consequences: Addresses what happens when the pattern is applied and what
tradeoffs exist during its application.
Design: Discusses how the analysis pattern can be achieved through the use of
known design patterns.
Known uses: Examples of uses within actual systems.
Related patterns: On e or more analysis patterns that are related to the named
pattern because (1) it is commonly used with the named pattern; (2) it is
structurally similar to the named pattern; (3) it is a variation of the named pattern.

Roger Pressman. 99
Negotiating
Requirements
 Identify the key stakeholders
 These are the people who will be involved
in the negotiation
 Determine each of the stakeholders
“win conditions”
 Win conditions are not always obvious
 Negotiate
 Work toward a set of requirements that
lead to “win-win”

Roger Pressman. 100
Validating
Requirements - I
 Is each requirement consistent with the overall
objective for the system/product?
 Have all requirements been specified at the proper
level of abstraction? That is, do some requirements
provide a level of technical detail that is
inappropriate at this stage?
 Is the requirement really necessary or does it
represent an add-on feature that may not be
essential to the objective of the system?
 Is each requirement bounded and unambiguous?
 Does each requirement have attribution? That is, is a
source (generally, a specific individual) noted for
each requirement?
 Do any requirements conflict with other
requirements?
Roger Pressman. 101
Validating
Requirements - II
 Is each requirement achievable in the technical
environment that will house the system or
product?
 Is each requirement testable, once implemented?
 Does the requirements model properly reflect the
information, function and behavior of the system to
be built.
 Has the requirements model been “partitioned” in
a way that exposes progressively more detailed
information about the system.
 Have requirements patterns been used to simplify
the requirements model. Have all patterns been
properly validated? Are all patterns consistent
with customer requirements?
Roger Pressman. 102
Chapter 6
 Requirements Modeling: Scenarios, Information,
and Analysis Classes
Approach, 7/e

use.
Roger Pressman. 103
Requirements
Analysis
 Requirements analysis
 specifies software’s operational characteristics
 indicates software's interface with other
system elements
 establishes constraints that software must
meet
 Requirements analysis allows the software
engineer (called an analyst or modeler in this
role) to:
 elaborate on basic requirements established
during earlier requirement engineering tasks
 build models that depict user scenarios,
functional activities, problem classes and their
relationships, system and class behavior, and
the flow
These slides are designed of data
to accompany Software as it is transformed.
Engineering: A
Roger Pressman. 104
A Bridge
system
description
analysis
model
design
model

Roger Pressman. 105
Rules of Thumb
 The model should focus on requirements that are
visible within the problem or business domain.
The level of abstraction should be relatively high.
 Each element of the analysis model should add
to an overall understanding of software
requirements and provide insight into the
information domain, function and behavior of the
system.
 Delay consideration of infrastructure and other
non-functional models until design.
 Minimize coupling throughout the system.
 Be certain that the analysis model provides
value to all stakeholders.
 Keep the model as simple as it can be.

Roger Pressman. 106
Domain
Analysis
Software domain analysis is the identification, analysis,
and specification of common requirements from a
specific application domain, typically for reuse on
multiple projects within that application domain . . .
[Object-oriented domain analysis is] the identification,
analysis, and specification of common, reusable
capabilities within a specific application domain, in
terms of common objects, classes, subassemblies, and
frameworks . . .
Donald Firesmith

Roger Pressman. 107
Domain
Analysis
 Define the domain to be investigated.
 Collect a representative sample of
applications in the domain.
 Analyze each application in the
sample.
 Develop an analysis model for the
objects.

Roger Pressman. 108
Elements of Requirements
Analysis

Roger Pressman. 109
Scenario-Based
Modeling
“[Use-cases] are simply an aid to defining what exists
outside the system (actors) and what should be
performed by the system (use-cases).” Ivar Jacobson
(1) What should we write about?
(2) How much should we write about it?
(3) How detailed should we make our description?
(4) How should we organize the description?

Roger Pressman. 110
What to Write About?
 Inception and elicitation—provide you with the
information you’ll need to begin writing use cases.
 Requirements gathering meetings, QFD, and other
requirements engineering mechanisms are used to
 identify stakeholders
 define the scope of the problem
 specify overall operational goals
 establish priorities
 outline all known functional requirements, and
 describe the things (objects) that will be manipulated by the
system.
 To begin developing a set of use cases, list the functions
or activities performed by a specific actor.
Roger Pressman. 111
How Much to Write
About?
 As further conversations with the stakeholders
progress, the requirements gathering team
develops use cases for each of the functions
noted.
 In general, use cases are written first in an
informal narrative fashion.
 If more formality is required, the same use
case is rewritten using a structured format
similar to the one proposed.

Roger Pressman. 112
Use-
Cases
 a scenario that describes a “thread of
usage” for a system
 actors represent roles people or
devices play as the system functions
 users can play a number of different
roles for a given scenario

Roger Pressman. 113
Developing a Use-
Case
What are the main tasks or functions that are

performed by the actor?
 What system information will the the actor
acquire, produce or change?
 Will the actor have to inform the system about
changes in the external environment?
 What information does the actor desire from
the system?
 Does the actor wish to be informed about
unexpected changes?

Roger Pressman. 114
Use-Case Diagram
SafeHome
Access camera
surveillance via the cameras
Internet
Configure SafeHome
system parameters
homeowner
Set alarm

Roger Pressman. 115
Activity Diagram
Supplements the use enter password
case by providing a
and user ID
graphical valid passwords/ ID invalid passwords/ ID
representation of the select major function prompt for reentry
flow of interaction
other f unctions
may also be
selected
input tries remain
within a specific
select surveillance
no input
tries remain
scenario thumbnail views select a specif ic camera
select specific
select camera icon
camera - thumbnails
view camera output

in labelled window
prompt for
another view
exit this f unction

see another camera

Roger Pressman. 116
Swimlane Diagrams
h o m e o wn e r c a m e ra i nt e rf a c e
Allows the modeler to

represent the flow of enter password
activities described by the and user ID
use-case and at the same

time indicate which actor valid passwo rds/ ID
(if there are multiple

invalid
passwo rds/ ID
select major function
actors involved in a o t her f un ct io ns prompt for reentry
specific use-case) or
may also be
selected
analysis class has

input t ries
select surveillance remain
responsibility for the no inp ut

tries remain
action described by an
activity rectangle th umb nail views select a specif ic camera
select specific
select camera icon
camera - thumbnails
generate video
output
view camera output prompt for

in labelled window another view
exit t his
f unct io n
see
ano t her
camera

Roger Pressman. 117
Data Modeling
 examines data objects
independently of processing
 focuses attention on the data
domain
 creates a model at the
customer’s level of abstraction
 indicates how data objects
relate to one another

Roger Pressman. 118
What is a Data Object?
 a representation of almost any composite information
that must be understood by software.
 composite information—something that has a number of
different properties or attributes
 can be an external entity (e.g., anything that produces or
consumes information), a thing (e.g., a report or a
display), an occurrence (e.g., a telephone call) or event
(e.g., an alarm), a role (e.g., salesperson), an
organizational unit (e.g., accounting department), a
place (e.g., a warehouse), or a structure (e.g., a file).
 The description of the data object incorporates the data
object and all of its attributes.
 A data object encapsulates data only—there is no
reference within a data object to operations that act on
the data.
Roger Pressman. 119
Data Objects and
Attributes
A data object contains a set of attributes that
act as an aspect, quality, characteristic, or
descriptor of the object
object: automobile
attributes:
make
model
body type
price
options code

Roger Pressman. 120
What is a Relationship?
 Data objects are connected to one another in
different ways.
 A connection is established between person and car
because the two objects are related.
• A person owns a car
• A person is insured to drive a car
 The relationships owns and insured to drive
define the relevant connections between
person and car.
 Several instances of a relationship can exist
 Objects can be related in many different ways

Roger Pressman. 121
ERD Notation
One common form:
(0, m)
object1 relationship object 2
(1, 1)
attribute
Another common form:
object1 relationship
object 2
(0, m) (1, 1)

Roger Pressman. 122
Building an ERD
 Level 1—model all data objects
(entities) and their “connections”
to one another
 Level 2—model all entities and
relationships
 Level 3—model all entities,
relationships, and the attributes
that provide further depth

Roger Pressman. 123
The ERD: An Example
request
Customer places
for service
(1,1) (1,m)
(1,1)
standard (1,n) work
task table generates
order
(1,1) (1,1) (1,1)
selected work (1,w)
from consists
(1,w) tasks of
(1,i)
materials lists

Roger Pressman. 124
Class-Based Modeling
 Class-based modeling represents:
 objects that the system will manipulate
 operations (also called methods or services) that will
be applied to the objects to effect the manipulation
 relationships (some hierarchical) between the objects
 collaborations that occur between the classes that are
defined.
 The elements of a class-based model include
classes and objects, attributes, operations, CRC
models, collaboration diagrams and packages.

Roger Pressman. 125
Identifying Analysis
Classes
 Examining the usage scenarios developed as
part of the requirements model and perform a
"grammatical parse" [Abb83]
 Classes are determined by underlining each noun or
noun phrase and entering it into a simple table.
 Synonyms should be noted.
 If the class (noun) is required to implement a
solution, then it is part of the solution space;
otherwise, if a class is necessary only to describe a
solution, it is part of the problem space.
 But what should we look for once all of the
nouns have been isolated?

Roger Pressman. 126
Manifestations of Analysis
Classes
 Analysis classes manifest themselves in one of the
following ways:
• External entities (e.g., other systems, devices, people) that
produce or consume information
• Things (e.g, reports, displays, letters, signals) that are part of
the information domain for the problem
• Occurrences or events (e.g., a property transfer or the
completion of a series of robot movements) that occur within
the context of system operation
• Roles (e.g., manager, engineer, salesperson) played by people
who interact with the system
• Organizational units (e.g., division, group, team) that are
relevant to an application
• Places (e.g., manufacturing floor or loading dock) that
establish the context of the problem and the overall function
• Structures (e.g., sensors, four-wheeled vehicles, or computers)
that define a class of objects or related classes of objects
Roger Pressman. 127
Potential Classes
 Retained information. The potential class will be useful during analysis
only if information about it must be remembered so that the system can
function.
 Needed services. The potential class must have a set of identifiable
operations that can change the value of its attributes in some way.
 Multiple attributes. During requirement analysis, the focus should be on
"major" information; a class with a single attribute may, in fact, be
useful during design, but is probably better represented as an attribute
of another class during the analysis activity.
 Common attributes. A set of attributes can be defined for the potential
class and these attributes apply to all instances of the class.
 Common operations. A set of operations can be defined for the potential
class and these operations apply to all instances of the class.
 Essential requirements. External entities that appear in the problem
space and produce or consume information essential to the operation
of any solution for the system will almost always be defined as classes
in the requirements model.

Roger Pressman. 128
Defining Attributes
 Attributes describe a class that has been selected
for inclusion in the analysis model.
 build two different classes for professional baseball
players
• For Playing Statistics software: name, position, batting
average, fielding percentage, years played, and games
played might be relevant
• For Pension Fund software: average salary, credit
toward full vesting, pension plan options chosen,
mailing address, and the like.

Roger Pressman. 129
Defining Operations
 Do a grammatical parse of a processing
narrative and look at the verbs
 Operations can be divided into four broad
categories:
 (1) operations that manipulate data in some way
(e.g., adding, deleting, reformatting, selecting)
 (2) operations that perform a computation
 (3) operations that inquire about the state of an
object, and
 (4) operations that monitor an object for the
occurrence of a controlling event.

Roger Pressman. 130
CRC Models
 Class-responsibility-collaborator (CRC) modeling
[Wir90] provides a simple means for
identifying and organizing the classes that are
relevant to system or product requirements.
Ambler [Amb95] describes CRC modeling in
the following way:
 A CRC model is really a collection of standard index
cards that represent classes. The cards are divided
into three sections. Along the top of the card you
write the name of the class. In the body of the card
you list the class responsibilities on the left and the
collaborators on the right.
Roger Pressman. 131
CRC
Modeling Class:
Class:
Description:
Class:
Description:
Class:FloorPlan
Description:
Responsibility:
Description: Collaborator:
Responsibility: Collaborator:
defines floor plan name/type
manages floor plan positioning
scales floor plan for display
scales floor plan for display
incorporates walls, doors and windows Wall
shows position of video cameras Camera

Roger Pressman. 132
Class Types
 Entity classes, also called model or business
classes, are extracted directly from the statement of
the problem (e.g., FloorPlan and Sensor).
 Boundary classes are used to create the interface
(e.g., interactive screen or printed reports) that the
user sees and interacts with as the software is
used.
 Controller classes manage a “unit of work” [UML03]
from start to finish. That is, controller classes can
be designed to manage
 the creation or update of entity objects;
 the instantiation of boundary objects as they obtain
information from entity objects;
 complex communication between sets of objects;
 validation of data communicated between objects or

between the user and the application.
Roger Pressman. 133
Responsibili
ties
 System intelligence should be distributed
across classes to best address the needs of
the problem
 Each responsibility should be stated as
generally as possible
 Information and the behavior related to it
should reside within the same class
 Information about one thing should be
localized with a single class, not distributed
across multiple classes.
 Responsibilities should be shared among
related classes, when appropriate.

Roger Pressman. 134
Collaboratio
ns
 Classes fulfill their responsibilities in one of two
ways:
 A class can use its own operations to manipulate its
own attributes, thereby fulfilling a particular
responsibility, or
 a class can collaborate with other classes.
 Collaborations identify relationships between
classes
 Collaborations are identified by determining
whether a class can fulfill each responsibility itself
 three different generic relationships between
classes [WIR90]:
 the is-part-of relationship
 the has-knowledge-of relationship
 the depends-upon relationship
Roger Pressman. 135
Composite Aggregate
Class
Player
PlayerHead PlayerBody PlayerArms PlayerLegs

Roger Pressman. 136
Associations and
Dependencies
 Two analysis classes are often related
to one another in some fashion
 In UML these relationships are called
associations
 Associations can be refined by indicating
multiplicity (the term cardinality is used in
data modeling
 In many instances, a client-server
relationship exists between two
analysis classes.
 In such cases, a client-class depends on
the server-class in some way and a
dependency
These slides are designed relationship
to accompany Software Engineering: A is established
Roger Pressman. 137
Multiplicit
y
Wall
1 1 1
is used to build is used to build
1..* 0..* is used to build 0..*
WallSegment Window Door

Roger Pressman. 138
Dependenci
es
DisplayWindow Camera
<<access>>
{password}

Roger Pressman. 139
Analysis
Packages
 Various elements of the analysis model (e.g.,
use-cases, analysis classes) are categorized
in a manner that packages them as a
grouping
 The plus sign preceding the analysis class
name in each package indicates that the
classes have public visibility and are
therefore accessible from other packages.
 Other symbols can precede an element within
a package. A minus sign indicates that an
element is hidden from all other packages
and a # symbol indicates that an element is
accessible only to packages contained within
a given package.
Roger Pressman. 140
Analysis Packages
package name
Environment
+Tree
+Landscape
+Road
+Wall
+Bridge
+Building RulesOfTheGame
+VisualEffect
+Scene +RulesOfMovement
+ConstraintsOnAction
Characters
+Player
+Protagonist
+Antagonist
+SupportingRole

Roger Pressman. 141
Reviewing the CRC
Model
 All participants in the review (of the CRC model) are given a
subset of the CRC model index cards.
 Cards that collaborate should be separated (i.e., no reviewer
should have two cards that collaborate).
 All use-case scenarios (and corresponding use-case diagrams)
should be organized into categories.
 The review leader reads the use-case deliberately.
 As the review leader comes to a named object, she passes a
token to the person holding the corresponding class index
card.
 When the token is passed, the holder of the class card is asked
to describe the responsibilities noted on the card.
 The group determines whether one (or more) of the
responsibilities satisfies the use-case requirement.
 If the responsibilities and collaborations noted on the index
cards cannot accommodate the use-case, modifications are
made to the cards.
 This may include the definition of new classes (and
corresponding CRC index cards) or the specification of new
or revised responsibilities or collaborations on existing
cards.
Roger Pressman. 142
Chapter 7
 Requirements Modeling: Flow,
Behavior, Patterns, and WebApps
Approach, 7/e

These slides use.
are designed to accompany Software Engineering: A
Roger Pressman. 143
Requirements Modeling
Strategies
 One view of requirements modeling, called structured
analysis, considers data and the processes that transform
the data as separate entities.
 Data objects are modeled in a way that defines their
attributes and relationships.
 Processes that manipulate data objects are modeled in a
manner that shows how they transform data as data
objects flow through the system.
 A second approach to analysis modeled, called object-
oriented analysis, focuses on
 the definition of classes and
 the manner in which they collaborate with one another to
effect customer requirements.

Roger Pressman. 144
Flow-Oriented
Modeling
 Represents how data objects are transformed at they
move through the system
 data flow diagram (DFD) is the diagrammatic form that
is used
 Considered by many to be an “old school” approach,
but continues to provide a view of the system that is
unique—it should be used to supplement other analysis
model elements

Roger Pressman. 145
The Flow Model
Every computer-based system is an
information transform ....
computer
input based output
system

Roger Pressman. 146
Flow Modeling
Notation
external entity
process
data flow
data store
Roger Pressman. 147
External Entity
A producer or consumer of data
Examples: a person, a device, a sensor
Another example: computer-based

system
Data must always originate somewhere

and must always be sent to something

Roger Pressman. 148
Process
A data transformer (changes input
to output)
Examples: compute taxes, determine area,

format report, display graph
Data must always be processed in some

way to achieve system function

Roger Pressman. 149
Data Flow
Data flows through a system, beginning

as input and transformed into output.
base
compute
triangle area
height area

Roger Pressman. 150
Data Stores
Data is often stored for later use.
sensor #
sensor #, type,
look-up location, age
sensor
report required data
type,
location, age
sensor number
sensor data

Roger Pressman. 151
Data Flow Diagramming:
Guidelines
 all icons must be labeled with
meaningful names
 the DFD evolves through a number of
levels of detail
 always begin with a context level
diagram (also called level 0)
 always show external entities at
level 0
 always label data flow arrows
 do not represent procedural logic
Roger Pressman. 152
Constructing a DFD—I
 review user scenarios and/or
the data model to isolate data
objects and use a grammatical
parse to determine “operations”
 determine external entities
(producers and consumers of
data)
 create a level 0 DFD

Roger Pressman. 153
Level 0 DFD Example
processing
user request requested
video
digital signal
video monitor
processor
video
source NTSC
video signal

Roger Pressman. 154
Constructing a DFD
—II
 write a narrative describing the
transform
 parse to determine next level
transforms
 “balance” the flow to maintain data
flow continuity
 develop a level 1 DFD
 use a 1:5 (approx.) expansion ratio

Roger Pressman. 155
The Data Flow
Hierarchy
a b
x P y level 0
a c p2
p1
f
p4 b
d 5
p3 e g
level 1

Roger Pressman. 156
Flow Modeling
Notes
 each bubble is refined until it
does just one thing
 the expansion ratio decreases as
the number of levels increase
 most systems require between 3
and 7 levels for an adequate flow
model
 a single data flow item (arrow)
may be expanded as levels
increase (data dictionary
provides information)
Roger Pressman. 157
Process Specification
(PSPEC)
bubble
PSPEC
narrative
pseudocode (PDL)
equations
tables
diagrams and/or charts
Roger Pressman. 158
DFDs: A Look Ahead
analysis model
Maps into
design model

Roger Pressman. 159
Control Flow
Modeling
 Represents “events” and the
processes that manage events
 An “event” is a Boolean condition that
can be ascertained by:
• listing all sensors that are "read" by the
software.
• listing all interrupt conditions.
• listing all "switches" that are actuated by an
operator.
• listing all data conditions.
• recalling the noun/verb parse that was
applied to the processing narrative, review
all "control items" as possible CSPEC
These slides are designedinputs/outputs.
to accompany Software Engineering: A
Roger Pressman. 160
Control Specification
(CSPEC)
The CSPEC can be:
state diagram
(sequential spec)
state transition table

combinatorial spec
decision tables
activation tables

Roger Pressman. 161
Behavioral
Modeling
 The behavioral model indicates how software
will respond to external events or stimuli. To
create the model, the analyst must perform
the following steps:
• Evaluate all use-cases to fully understand the
sequence of interaction within the system.
• Identify events that drive the interaction
sequence and understand how these events relate
to specific objects.
• Create a sequence for each use-case.
• Build a state diagram for the system.
• Review the behavioral model to verify accuracy
and consistency.

Roger Pressman. 162
State
Representations
 In the context of behavioral modeling, two
different characterizations of states must be
considered:
 the state of each class as the system performs
its function and
 the state of the system as observed from the
outside as the system performs its function
 The state of a class takes on both passive
and active characteristics [CHA93].
 A passive state is simply the current status of
all of an object’s attributes.
 The active state of an object indicates the
current status of the object as it undergoes a
continuing transformation or processing.

Roger Pressman. 163
State Diagram for the
ControlPanel Class
t imer < lockedTime
timer > lockedTime locked
password = incorrect
& numberOfTries < maxTries
reading comparing numberOfTries > maxTries

key hit
password
entered do: validatePassword
password = correct
select ing
act ivat ion successful

Roger Pressman. 164
The States of a System
 state—a set of observable
circum-stances that
characterizes the behavior of a
system at a given time
 state transition—the movement
from one state to another
 event—an occurrence that
causes the system to exhibit
some predictable form of
behavior
 action—process that occurs as a
consequence
These slides are designed to accompany SoftwareofEngineering:
making A a
transition
Roger Pressman. 165
Behavioral Modeling
 make a list of the different states of
a system (How does the system
behave?)
 indicate how the system makes a
transition from one state to another
(How does the system change
state?)
 indicate event
 indicate action
 draw a state diagram or a sequence
diagram
Roger Pressman. 166
Sequence Diagram
homeowner control panel system sensors

sensors
system reading
A
ready
password entered
request lookup
comparing
result
password = correct
numberOfTries > maxTries request activation
locked
timer > lockedTime

A
selecting
activation successful activation successful
Figure 8.27 Sequence diagram (partial) for SafeHome security function

Roger Pressman. 167
Writing the Software
Specification
Everyone knew exactly
what had to be done
until someone wrote it
down!

Roger Pressman. 168
Patterns for Requirements
Modeling
 Software patterns are a mechanism for capturing
domain knowledge in a way that allows it to be
reapplied when a new problem is encountered
 domain knowledge can be applied to a new problem
within the same application domain
 the domain knowledge captured by a pattern can be
applied by analogy to a completely different application
domain.
 The original author of an analysis pattern does not
“create” the pattern, but rather, discovers it as
requirements engineering work is being conducted.
 Once the pattern has been discovered, it is documented

Roger Pressman. 169
Discovering Analysis
Patterns
 The most basic element in the description of a
requirements model is the use case.
 A coherent set of use cases may serve as the
basis for discovering one or more analysis
patterns.
 A semantic analysis pattern (SAP) “is a pattern that
describes a small set of coherent use cases that
together describe a basic generic application.”
[Fer00]

Roger Pressman. 170
Requirements Modeling for
WebApps
Content Analysis. The full spectrum of content to be
provided by the WebApp is identified, including
text, graphics and images, video, and audio data.
Data modeling can be used to identify and
describe each of the data objects.
Interaction Analysis. The manner in which the user
interacts with the WebApp is described in detail.
Use-cases can be developed to provide detailed
descriptions of this interaction.
Functional Analysis. The usage scenarios (use-
cases) created as part of interaction analysis
define the operations that will be applied to
WebApp content and imply other processing
functions. All operations and functions are
described in detail.
Configuration Analysis. The environment and
infrastructure in which the WebApp resides are
Roger Pressman. 171
described in detail.
When Do We Perform
Analysis?
 In some WebE situations, analysis and
design merge. However, an explicit
analysis activity occurs when …
 the WebApp to be built is large and/or
complex
 the number of stakeholders is large
 the number of Web engineers and other
contributors is large
 the goals and objectives (determined
during formulation) for the WebApp will
effect the business’ bottom line
 the success of the WebApp will have a
strong bearing on the success of the
business
Roger Pressman. 172
The Content Model
 Content objects are extracted from use-cases
 examine the scenario description for direct and
indirect references to content
 Attributes of each content object are identified
 The relationships among content objects
and/or the hierarchy of content maintained by a
WebApp
 Relationships—entity-relationship diagram or UML
 Hierarchy—data tree or UML

Roger Pressman. 173
Data Tree
MarketingDescription
Photograph
partNumber
TechDescription
partName
component Schematic
partType
Video
description
price
WholesalePrice
RetailPrice
Figure 1 8 .3 Data tree for aSafeHome component

Roger Pressman. 174
The Interaction Model
 Composed of four elements:
 usecases
 sequence diagrams
 state diagrams
 a user interface prototype
 Each of these is an important UML

notation and is described in Appendix
I

Roger Pressman. 175
Sequence Diagram
:Product :Billof FloorPlan BoM
:Room :FloorPlan
Component Materials Repository Repository
new customer
desc ribes
room*
plac es room
in f loor plan
save f loor plan c onf iguration
selec ts produc t c omponent*
add to BoM
save bill of materials
Figure 18.5 Sequence diagram for use-case:select SafeHome components

Roger Pressman. 176
State Diagram
Validating user Selecting user action
userid select other functions
system status=“input ready” validated system status=“link ready”
select “log-in” displaymsg = “enteruserid” display: navigation choices”
displaymsg =“enterpswd”
password validated
entry/ validated user
entry/ log-in requested
n e w cu sto me r do: link as required
do: run user validation
exit/user action selected
exit/set user access switch
customization complete
select e-commerce (purchase) functionality
select customization functionality
next selection
Saving floor plan
Customizing select descriptive
content system status=“input ready”
system status=“input ready” Defining room select descriptive display: storage indicator
display: basic instructions content
room being defined system status=“input ready” entry/ floor plan save selected
display: roomdef. window do: store floor plan
entry/validated user exit/save completed
do: process user selection
entry/ roomdef. selected
exit/ customization terminated all rooms do: run room queries
defined do: store room variables
exit/room completed
Building floor plan select descriptive

select save floor plan
content
system status=“input ready”
select enter room in floor plan display: floor plan window
entry/ floor plan selected

do: insert room in place
do: store floor plan variables
exit/room insertion completed
room insertion completed
Figure 18.6 Partial state diagram for new c us tomer

interaction

Roger Pressman. 177
The Functional Model
 The functional model addresses two
processing elements of the WebApp
 user observable functionality that is
delivered by the WebApp to end-users
 the operations contained within analysis
classes that implement behaviors
associated with the class.
 An activity diagram can be used to
represent processing flow

Roger Pressman. 178
Activity Diagram
init ialize totalCost
no components remain onBoMList components remain onBoMList
invoke get price and

calcShippingCost quantity
returns:
shippingCost
lineCost =
price x quant ity
invoke
determineDiscount
returns: discount add lineCost to

tot alCost
discount>0
t otalCost=
totalCost - discount
discount <= 0
t axTotal=
totalCost x taxrate
priceTotal =
totalCost +taxTotal
+shippingCost
Figure 18.7 Activity diagram for c omputePrice

( ) operation
Roger Pressman. 179
The Configuration
Model
 Server-side
 Server hardware and operating system
environment must be specified
 Interoperability considerations on the
server-side must be considered
 Appropriate interfaces, communication
protocols and related collaborative
information must be specified
 Client-side
 Browser configuration issues must be
identified
 Testing requirements should be defined
Roger Pressman. 180
Navigation Modeling-I
 Should certain elements be easier to reach
(require fewer navigation steps) than others?
What is the priority for presentation?
 Should certain elements be emphasized to
force users to navigate in their direction?
 How should navigation errors be handled?
 Should navigation to related groups of
elements be given priority over navigation to
a specific element.
 Should navigation be accomplished via links,
via search-based access, or by some other
means?
 Should certain elements be presented to
users based on the context of previous
navigation
These slides are actions?
designed to accompany Software Engineering: A
 Should a navigation log be maintained for
Roger Pressman. 181
Navigation Modeling-II
 Should a full navigation map or menu (as opposed
to a single “back” link or directed pointer) be
available at every point in a user’s interaction?
 Should navigation design be driven by the most
commonly expected user behaviors or by the
perceived importance of the defined WebApp
elements?
 Can a user “store” his previous navigation through
the WebApp to expedite future usage?
 For which user category should optimal navigation
be designed?
 How should links external to the WebApp be
handled? overlaying the existing browser window?
as a new browser window? as a separate frame?
Roger Pressman. 182
Chapter 9
 Architectural Design
Approach, 7/e

use.

Roger Pressman. 183
Why
Architecture?
The architecture is not the operational software. Rather,

it is a representation that enables a software engineer
to:
(1) analyze the effectiveness of the design in meeting its
stated requirements,
(2) consider architectural alternatives at a stage when
making design changes is still relatively easy, and
(3) reduce the risks associated with the construction of
the software.

Roger Pressman. 184
Why is Architecture
Important?
 Representations of software architecture are
an enabler for communication between all
parties (stakeholders) interested in the
development of a computer-based system.
 The architecture highlights early design
decisions that will have a profound impact on
all software engineering work that follows
and, as important, on the ultimate success of
the system as an operational entity.
 Architecture “constitutes a relatively small,
intellectually graspable mode of how the
system is structured and how its components
work together” [BAS03].
Roger Pressman. 185
Architectural
Descriptions
 The IEEE Computer Society has proposed IEEE-Std-
1471-2000, Recommended Practice for Architectural
Description of Software-Intensive System, [IEE00]
 to establish a conceptual framework and vocabulary for use
during the design of software architecture,
 to provide detailed guidelines for representing an architectural
description, and
 to encourage sound architectural design practices.
 The IEEE Standard defines an architectural description (AD)
as a “a collection of products to document an architecture.”
 The description itself is represented using multiple views, where
each view is “a representation of a whole system from the
perspective of a related set of [stakeholder] concerns.”

Roger Pressman. 186
Architectural Genres
 Genre implies a specific category within the
overall software domain.
 Within each category, you encounter a number
of subcategories.
 For example, within the genre of buildings, you
would encounter the following general styles:
houses, condos, apartment buildings, office
buildings, industrial building, warehouses, and so
on.
 Within each general style, more specific styles might
apply. Each style would have a structure that can be
described using a set of predictable patterns.
Roger Pressman. 187
Architectural
Styles
Each style describes a system category that encompasses: (1) a
set of components (e.g., a database, computational modules)
that perform a function required by a system, (2) a set of
connectors that enable “communication, coordination and
cooperation” among components, (3) constraints that define
how components can be integrated to form the system, and
(4) semantic models that enable a designer to understand the
overall properties of a system by analyzing the known
properties of its constituent parts.
 Data-centered
architectures
 Data flow architectures
 Call and return
architectures
 Object-oriented
Practitioner’s Approach, 7/earchitectures
(McGraw-Hill, 2009). Slides copyright 2009 by
Roger Pressman. 188
 Layered architectures
Data-Centered
Architecture

Roger Pressman. 189
Data Flow
Architecture

Roger Pressman. 190
Call and Return
Architecture

Roger Pressman. 191
Layered
Architecture

Roger Pressman. 192
Architectural
Patterns
 Concurrency—applications must handle multiple
tasks in a manner that simulates parallelism
 operating system process management pattern
 task scheduler pattern
 Persistence—Data persists if it survives past the
execution of the process that created it. Two
patterns are common:
 a database management system pattern that applies
the storage and retrieval capability of a DBMS to the
application architecture
 an application level persistence pattern that builds
persistence features into the application architecture
 Distribution— the manner in which systems or
components within systems communicate with one
another in a distributed environment
 A broker acts as a ‘middle-man’ between the client
component and a server component.

Roger Pressman. 193
Architectural
Design
 The software must be placed into
context
 the design should define the external
entities (other systems, devices, people)
that the software interacts with and the
nature of the interaction
 A set of architectural archetypes
should be identified
 An archetype is an abstraction (similar to a
class) that represents one element of
system behavior
 The designer specifies the structure
Practitioner’s of the system 2009).by
Slidesdefining
copyright 2009 by and refining
Approach, 7/e (McGraw-Hill,
Roger Pressman. 194
software components that implement
Architectural Context
Safehome Internet-based
Product system
control
panel target system: surveillance
Security Function function
uses
homeowner peers
uses
uses
sensors sensors

Roger Pressman. 195
Archetypes
Controller
communicates with
Node
Detector Indicator

Practitioner’s Approach, 7/e 10.7
Figure (McGraw-Hill, 2009).
UML relationships Slidessecurity
for SafeHome copyright
function2009 by
archetypes
Roger Pressman. (adapted from [BOS00]) 196
Component
Structure
SafeHome
Executive
Function
selection
External
Communication
Management
Security Surveillance Home

management
GUI Internet
Interface
Control detector alarm

panel management processing
processing

Roger Pressman. 197
Refined Component
Structure
SafeHome
Executive
External
Communication
Management
Security
GUI Internet
Interface
Control detector alarm

panel management processing
processing
Keypad
processing phone
scheduler
communication
CP display
funct ions
alarm
sensor
sensor
sensor
sensor
sensor
sensor
sensor
sensor
sensor
Roger Pressman. 198
Analyzing Architectural
Design
1. Collect scenarios.
2. Elicit requirements, constraints, and environment description.
3. Describe the architectural styles/patterns that have been chosen
to address the scenarios and requirements:
• module view
• process view
• data flow view
4. Evaluate quality attributes by considered each attribute in
isolation.
5. Identify the sensitivity of quality attributes to various
architectural attributes for a specific architectural style.
6. Critique candidate architectures (developed in step 3) using the
sensitivity analysis conducted in step 5.

Roger Pressman. 199
Architectural
Complexity
 the overall complexity of a proposed
architecture is assessed by considering the
dependencies between components within the
architecture [Zha98]
 Sharing dependencies represent dependence
relationships among consumers who use the same
resource or producers who produce for the same
consumers.
 Flow dependencies represent dependence relationships
between producers and consumers of resources.
 Constrained dependencies represent constraints on the
relative flow of control among a set of activities.
Roger Pressman. 200
ADL
 Architectural description language (ADL) provides
a semantics and syntax for describing a software
architecture
 Provide the designer with the ability to:
 decompose architectural components
 compose individual components into larger architectural
blocks and
 represent interfaces (connection mechanisms) between
components.

Roger Pressman. 201
An Architectural Design
Method
customer requirements
"four bedrooms, three baths,
lots of glass ..."
architectural design

Roger Pressman. 202
Deriving Program
Architecture
Program
Architecture

Roger Pressman. 203
Partitioning the
Architecture
 “horizontal” and “vertical”
partitioning are required

Roger Pressman. 204
Horizontal
Partitioning
 define separate branches of the
module hierarchy for each major
function
 use control modules to coordinate
communication between functions
function 1 function 3
function 2
Roger Pressman. 205
Vertical Partitioning:
Factoring
 design so that decision making
and work are stratified
 decision making modules should
reside at the top of the
architecture decision-makers
workers

Roger Pressman. 206
Why Partitioned
Architecture?
 results in software that is easier to
test
 leads to software that is easier to
maintain
 results in propagation of fewer side
effects
 results in software that is easier to
extend

Roger Pressman. 207
Structured Design
 objective: to derive a
program architecture that
is partitioned
 approach:
 a DFD is mapped into a
program architecture
 the PSPEC and STD are used
to indicate the content of
each module
 notation: structure chart

Roger Pressman. 208
Flow
Characteristics
Transform flow
This edition of
SEPA does not
cover transaction
mapping. For a
detailed
discussion see the
SEPA website
Transaction
flow

Roger Pressman. 209
General Mapping
Approach
isolate incoming and outgoing flow
boundaries; for transaction flows, isolate
the transaction center
working from the boundary outward, map

DFD transforms into corresponding modules
add control modules as required
refine the resultant program structure

using effective modularity concepts
Roger Pressman. 210
General Mapping
Approach
 Isolate the transform center by specifying incoming
and outgoing flow boundaries
 Perform "first-level factoring.”
 The program architecture derived using this mapping
results in a top-down distribution of control.
 Factoring leads to a program structure in which top-level
components perform decision-making and low-level
components perform most input, computation, and output
work.
 Middle-level components perform some control and do
moderate amounts of work.
 Perform "second-level factoring."

Roger Pressman. 211
Transform
Mapping
b g h
a e f
d
c i
j
data flow model
x1 "Transform" mapping
x2 x3 x4
b c d e f g i
a h j

Roger Pressman. 212
Factori
ngdirection of increasing
decision making typical "decision
making" modules
typical "worker" modules

Roger Pressman. 213
First Level
Factoring main
program
controller
input processing output

controller controller controller

Roger Pressman. 214
Second Level
Mapping
main
D
C
control
A
B
A
B
C
mapping from the D

flow boundary outward

Roger Pressman. 215
Chapter 10
 Component-Level Design
Approach, 7/e

use.

Roger Pressman. 216
What is a
Component?
 OMG Unified Modeling Language
Specification [OMG01] defines a component
as
 “… a modular, deployable, and replaceable part
of a system that encapsulates implementation
and exposes a set of interfaces.””
 OO view: a component contains a set of
collaborating classes
 Conventional view: a component contains
processing logic, the internal data structures
that are required to implement the processing
logic, and an interface that enables the
component to be invoked and data to be
passed to it.
Roger Pressman. 217
OO Component analysis class
PrintJ ob
numberOf Pages
numberOf Sides
paperType
magnif ic ation
productionFeatures
design component
c omputeJ obCost( ) c omputeJ ob
passJ obt oPrinter( )
PrintJ ob
initiateJ ob
<<in terf ace>> elaborated design class

co mp u teJ o b
PrintJ ob
comput ePageCost ( )
numberOf Pages
comput ePaperCost ( ) numberOf Sides
comput eProdCost ( ) paperType
comput eTot alJ obCost ( ) paperWeight
paperSize
paperColor
magnif icat ion
colorRequirement s
product ionFeat ures
collationOpt ions
bindingOpt ions
coverSt ock
<<in t erf ace>> bleed
in itiat eJ o b priorit y
t otalJ obCost
buildWorkOrder() WOnumber
checkPriority ()
passJ obt o Product ion()
computePageCost ( )
computePaperCost ()
computeProdCost ( )
computeTotalJ obCost ()
buildWorkOrder( )
checkPriorit y ()
passJ obto Product ion( )

Roger Pressman. 218
Conventional Component
design component
getJ obData
ComputePageCost
accessCostsDB
elaborated module
PageCost
in: numberPages
in: numberDocs
in: sides= 1, 2
in: color=1, 2, 3, 4
in: page size = A, B, C, B
out : page cost
in: job size
in: color=1, 2, 3, 4
in: pageSize = A, B, C, B
out : BPC
out : SF
get J obData (numberPages, numberDocs,

sides, color, pageSize, pageCost) job size ( J S) =
accessCost sDB (jobSize, color, pageSize, numberPages * numberDocs;
BPC, SF) lookup base page cost (BPC) -->
computePageCost() accessCostsDB (J S, color) ;
lookup size fact or ( SF) -->
accessCostDB ( J S, color, size)
job complexity fact or ( J CF) =
1 + [ ( sides-1) * sideCost + SF]
pagecost = BPC * J CF

Roger Pressman. 219
Basic Design Principles
 The Open-Closed Principle (OCP). “A module
[component] should be open for extension but closed
for modification.
 The Liskov Substitution Principle (LSP). “Subclasses
should be substitutable for their base classes.
 Dependency Inversion Principle (DIP). “Depend on
abstractions. Do not depend on concretions.”
 The Interface Segregation Principle (ISP). “Many
client-specific interfaces are better than one general
purpose interface.
 The Release Reuse Equivalency Principle (REP). “The
granule of reuse is the granule of release.”
 The Common Closure Principle (CCP). “Classes that
change together belong together.”
 The Common Reuse Principle (CRP). “Classes that
aren’t reused together should not be grouped
Source: Martin, R., “Design Principles and Design Patterns,” downloaded from http:www.objectmentor.com, 2000.
together.”
Roger Pressman. 220
Design Guidelines
 Components
 Naming conventions should be
established for components that are
specified as part of the architectural
model and then refined and elaborated as
part of the component-level model
 Interfaces
 Interfaces provide important information
about communication and collaboration
(as well as helping us to achieve the OPC)
 Dependencies and Inheritance
 it is a good idea to model dependencies
from left to right and inheritance from
bottom (derived classes) to top (base
classes).
Roger Pressman. 221
Cohesion
 Conventional view:
 the “single-mindedness” of a module
 OO view:
 cohesion implies that a component or class
encapsulates only attributes and operations
that are closely related to one another and to
the class or component itself
 Levels of cohesion
 Functional
 Layer
 Communicational
 Sequential
 Procedural
 Temporal
 utility

Roger Pressman. 222
Coupling
 Conventional view:
 The degree to which a component is connected
to other components and to the external world
 OO view:
 a qualitative measure of the degree to which
classes are connected to one another
 Level of coupling
 Content
 Common
 Control
 Stamp
 Data
 Routine call
 Type use
 Inclusion or import
 External

Roger Pressman. 223
Component Level
Design-I
 Step 1. Identify all design classes that
correspond to the problem domain.
 Step 2. Identify all design classes that
correspond to the infrastructure domain.
 Step 3. Elaborate all design classes that
are not acquired as reusable components.
 Step 3a. Specify message details when
classes or component collaborate.
 Step 3b. Identify appropriate interfaces for
each component.

Roger Pressman. 224
Component-Level
Design-II
 Step 3c. Elaborate attributes and define
data types and data structures required to
implement them.
 Step 3d. Describe processing flow within
each operation in detail.
 Step 4. Describe persistent data sources
(databases and files) and identify the
classes required to manage them.
 Step 5. Develop and elaborate behavioral
representations for a class or component.
 Step 6. Elaborate deployment diagrams to
provide additional implementation detail.
 Step 7. Factor every component-level design
representation and always consider
alternatives.
Roger Pressman. 225
Collaboration Diagram
:ProductionJob
1: buildJob (WOnumber)
2: submitJob (WOnumber)
:WorkOrder
:JobQueue

Roger Pressman. 226
Refactoring
computeJ ob
PrintJ ob
initiateJ ob
WorkOrder
appropriate attributes <<interface>>

getJ obDescriiption buildJ ob initiateJ ob
buildWorkOrder ()
passJ obToProduction()
ProductionJ ob
submitJ ob
J obQueue
appropriate attributes
checkPriority ()

Roger Pressman. 227
Activity Diagram validate attributes
input
accessPaperDB (weight)
returns baseCostperPage
paperCostperPage =
baseCostperPage
size = B paperCostperPage =
paperCostperPage *1 .2
size = C paperCostperPage =
size = D paperCostperPage =
color is custom
paperCostperPage =
paperCostperPage *1 .1 4
color is standard
returns
( paperCostperPage )

Roger Pressman. 228
Statechar behavior within the
t
state buildingJ obData
dataInputIncomplete
buildingJ obData
entry/ readJ obData()

exit/displayJ obData()
do/ checkConsistency()
include/ dataInput
dataInputCompleted [all data

items consistent]/ displayUserOptions
computingJ obCost
entry/ computeJ ob
exit/ save totalJ obCost
jobCostAccepted [customer is authorized]/

getElectronicSignature
formingJ ob
entry/ buildJ ob
exit/ save WOnumber
do/
submittingJ ob
entry/ submitJ ob
exit/initiateJ ob
do/ place on J obQueue
jobSubmitted[all authorizations acquired]/

printWorkOrder
Roger Pressman. 229
Component Design for
WebApps
 WebApp component is
 (1) a well-defined cohesive function that manipulates
content or provides computational or data
processing for an end-user, or
 (2) a cohesive package of content and functionality
that provides end-user with some required
capability.
 Therefore, component-level design for
WebApps often incorporates elements of
content design and functional design.

Roger Pressman. 230
Content Design for
WebApps
 focuses on content objects and the manner in which they
may be packaged for presentation to a WebApp end-
user
 consider a Web-based video surveillance capability
within SafeHomeAssured.com
 potential content components can be defined for the video
surveillance capability:
• (1) the content objects that represent the space layout (the
floor plan) with additional icons representing the location of
sensors and video cameras;
• (2) the collection of thumbnail video captures (each an
separate data object), and
• (3) the streaming video window for a specific camera.
 Each of these components can be separately named and
manipulated as a package.

Roger Pressman. 231
Functional Design for
WebApps
 Modern Web applications deliver increasingly
sophisticated processing functions that:
 (1) perform localized processing to generate content and
navigation capability in a dynamic fashion;
 (2) provide computation or data processing capability that
is appropriate for the WebApp’s business domain;
 (3) provide sophisticated database query and access, or
 (4) establish data interfaces with external corporate
systems.
 To achieve these (and many other) capabilities, you will
design and construct WebApp functional components
that are identical in form to software components for
conventional software.
Roger Pressman. 232
Designing Conventional
Components
 The design of processing logic is
governed by the basic principles of
algorithm design and structured
programming
 The design of data structures is
defined by the data model developed
for the system
 The design of interfaces is governed
by the collaborations that a
component must effect

Roger Pressman. 233
Algorithm Design
 the closest design activity to
coding
 the approach:
 review the design description for the
component
 use stepwise refinement to develop
algorithm
 use structured programming to
implement procedural logic
 use ‘formal methods’ to prove logic

Roger Pressman. 234
Stepwise
Refinement
open
walk to door;
reach for knob;
open door; repeat until door opens

turn knob clockwise;
walk through;if knob doesn't turn, then
close door. take key out;
find correct key;
insert in lock;
endif
pull/push door
move out of way;
end repeat
Roger Pressman. 235
Algorithm Design
Model
 represents the algorithm at a level
of detail that can be reviewed for
quality
 options:
 graphical (e.g. flowchart, box diagram)
 pseudocode (e.g., PDL) ... choice of many
 programming language
 decision table

Roger Pressman. 236
Structured
Programming
uses a limited set of logical constructs:
sequence
conditional — if-then-else, select-case
loops — do-while, repeat until
leads to more readable, testable code

can be used in conjunction with ‘proof of
correctness’
important for achieving high quality,
but not enough
Roger Pressman. 237
A Structured Procedural
Design a
add a condition Z,
if true, exit the program
x1
b x2 c
x3 d
f e
x4
x5

Roger Pressman. 238
Decision Table
Rules
Conditions 1 2 3 4 5 6
regular customer T T
silver customer T T
gold customer T T
special discount F T F T F T
Rules
no discount
apply 8 percent discount
apply 15 percent discount
apply additional x percent discount

Roger Pressman. 239
Program Design Language
(PDL) if condition x
then process a;
else process b;
endif
if-then-else PDL
easy to combine with source code
machine readable, no need for graphics input
graphics can be generated from PDL
enables declaration of data as well as procedure
easier to maintain

Roger Pressman. 240
Why Design
Language?
can be a derivative of the HOL of choice
e.g., Ada PDL
machine readable and processable
can be embedded with source code,

therefore easier to maintain
can be represented in great detail, if

designer and coder are different
easy to review
Roger Pressman. 241
Component-Based
Development
 When faced with the possibility of
reuse, the software team asks:
 Are commercial off-the-shelf (COTS)
components available to implement the
requirement?
 Are internally-developed reusable
components available to implement the
requirement?
 Are the interfaces for available
components compatible within the
architecture of the system to be built?
 At the same time, they are faced with
the
These slides are following
designed impediments
to accompany Software Engineering: A to reuse ...
Roger Pressman. 242
Impediments to
Reuse  Few companies and organizations have anything that
even slightly resembles a comprehensive software
reusability plan.
 Although an increasing number of software vendors
currently sell tools or components that provide direct
assistance for software reuse, the majority of
software developers do not use them.
 Relatively little training is available to help software
engineers and managers understand and apply reuse.
 Many software practitioners continue to believe that
reuse is “more trouble than it’s worth.”
 Many companies continue to encourage of software
development methodologies which do not facilitate
reuse
 Few companies provide an incentives to produce
reusable program components.

Roger Pressman. 243
The CBSE
ProcessDomain Engineering
Reusable
Domain Software
Analysis Architecture Artifact
Development Development
Repository
Domain Structural Reusable
model Model Artifacts/
Components
System Specification
& Construction
Analysis
User Design
Requirements
Analysis
System Application
& Design
Spec Models
Software

Roger Pressman. 244
Domain Engineering
1. Define the domain to be investigated.
2. Categorize the items extracted from the
domain.
3. Collect a representative sample of
applications in the domain.
4. Analyze each application in the sample.
5. Develop an analysis model for the objects.

Roger Pressman. 245
Identifying Reusable
Components
• Is component functionality required on future implementations?
• How common is the component's function within the domain?
• Is there duplication of the component's function within the
domain?
• Is the component hardware-dependent?
• Does the hardware remain unchanged between implementations?
• Can the hardware specifics be removed to another component?
• Is the design optimized enough for the next implementation?
• Can we parameterize a non-reusable component so that it becomes
reusable?
• Is the component reusable in many implementations with only
minor changes?
• Is reuse through modification feasible?
• Can a non-reusable component be decomposed to yield reusable
components?
• How valid is component decomposition for reuse?
Roger Pressman. 246
Component-Based
SE a library of components must be
available
 components should have a
consistent structure
 a standard should exist, e.g.,
 OMG/CORBA
 Microsoft COM
 Sun JavaBeans

Roger Pressman. 247
CBSE Activities
 Component
qualification
 Component adaptation
 Component
composition
 Component update

Roger Pressman. 248
Qualificat
ion
Before a component can be used, you must consider:
• application programming interface (API)

• development and integration tools required by the
component
• run-time requirements including resource usage (e.g.,
memory or storage), timing or speed, and network protocol
• service requirements including operating system interfaces
and support from other components
• security features including access controls and authentication
protocol
• embedded design assumptions including the use of specific
numerical or non-numerical algorithms
• exception handling

Roger Pressman. 249
Adaptati
on
The implication of “easy integration” is:
(1) that consistent methods of resource
management have been implemented for all
components in the library;
(2) that common activities such as data
management exist for all components, and
(3) that interfaces within the architecture and
with the external environment have been
implemented in a consistent manner.

Roger Pressman. 250
Compositi
on
 An infrastructure must be established
to bind components together
 Architectural ingredients for
composition include:
 Data exchange model
 Automation
 Structured storage
 Underlying object model

Roger Pressman. 251
OMG/ CORBA
 The Object Management Group has published a common
object request broker architecture (OMG/CORBA).
 An object request broker (ORB) provides services that
enable reusable components (objects) to communicate with
other components, regardless of their location within a
system.
 Integration of CORBA components (without modification)
within a system is assured if an interface definition
language (IDL) interface is created for every component.
 Objects within the client application request one or more
services from the ORB server. Requests are made via an
IDL or dynamically at run time.
 An interface repository contains all necessary information
about the service’s request and response formats.
Roger Pressman. 252
ORB Architecture
Interface Client
Repository
Client
Dynamic ORB
Invocation IDL interface
Stubs
Server
LAN
Objects
ORB Core
ORB Server Object

interface IDL Adapter
Stubs Interface
Repository

Roger Pressman. 253
Microsoft COM
 The component object model (COM) provides a
specification for using components produced by
various vendors within a single application running
under the Windows operating system.
 COM encompasses two elements:
 COM interfaces (implemented as COM objects)
 a set of mechanisms for registering and passing messages
between COM interfaces.

Roger Pressman. 254
Sun JavaBeans
 The JavaBeans component system is a portable,
platform independent CBSE infrastructure
developed using the Java programming language.
 The JavaBeans component system encompasses a
set of tools, called the Bean Development Kit
(BDK), that allows developers to
 analyze how existing Beans (components) work
 customize their behavior and appearance
 establish mechanisms for coordination and
communication
 develop custom Beans for use in a specific application
 test and evaluate Bean behavior.
Roger Pressman. 255
Classificatio
n  Enumerated classification—
components are described by
defining a hierarchical structure in
which classes and varying levels of
subclasses of software components
are defined
 Faceted classification—a domain
area is analyzed and a set of basic
descriptive features are identified
 Attribute-value classification—a set
of attributes are defined for all
components in a domain area
Roger Pressman. 256
Indexing

Roger Pressman. 257
The Reuse
Environment
 A component database capable of storing software
components and the classification information
necessary to retrieve them.
 A library management system that provides access
to the database.
 A software component retrieval system (e.g., an
object request broker) that enables a client
application to retrieve components and services
from the library server.
 CBSE tools that support the integration of reused
components into a new design or implementation.
Roger Pressman. 258
Chapter 11
 User Interface Design
Approach, 7/e

use.

Roger Pressman. 259
Interface Design
Easy to learn?
Easy to use?
Easy to understand?

Roger Pressman. 260
Interface Design
Typical Design Errors
lack of consistency
too much memorization
no guidance / help
no context sensitivity
poor response
Arcane/unfriendly

Roger Pressman. 261
Golden Rules
 Place the user in control

 Reduce the user’s
memory load
 Make the interface
consistent

Roger Pressman. 262
Place the User in
Control
Define interaction modes in a way that does not
force a user into unnecessary or undesired actions.
Provide for flexible interaction.
Allow user interaction to be interruptible and
undoable.
Streamline interaction as skill levels advance and
allow the interaction to be customized.
Hide technical internals from the casual user.
Design for direct interaction with objects that appear
on the screen.

Roger Pressman. 263
Reduce the User’s Memory
Load
Reduce demand on short-term memory.
Establish meaningful defaults.
Define shortcuts that are intuitive.
The visual layout of the interface should be based on a
real world metaphor.
Disclose information in a progressive fashion.

Roger Pressman. 264
Make the Interface
Consistent
Allow the user to put the current task into a
meaningful context.
Maintain consistency across a family of
applications.
If past interactive models have created user
expectations, do not make changes unless there is
a compelling reason to do so.

Roger Pressman. 265
User Interface Design
Models
 User model — a profile of all end
users of the system
 Design model — a design realization
of the user model
 Mental model (system perception)
— the user’s mental image of what
the interface is
 Implementation model — the
interface “look and feel” coupled
with supporting information that
describe interface syntax and
semantics
Roger Pressman. 266
User Interface Design
Process

Roger Pressman. 267
Interface
Analysis
 Interface analysis means
understanding
 (1) the people (end-users) who will interact
with the system through the interface;
 (2) the tasks that end-users must perform
to do their work,
 (3) the content that is presented as part of
the interface
 (4) the environment in which these tasks
will be conducted.

Roger Pressman. 268
User Analysis
 Are users trained professionals, technician, clerical, or
manufacturing workers?
 What level of formal education does the average user have?
 Are the users capable of learning from written materials or
have they expressed a desire for classroom training?
 Are users expert typists or keyboard phobic?
 What is the age range of the user community?
 Will the users be represented predominately by one gender?
 How are users compensated for the work they perform?
 Do users work normal office hours or do they work until the job
is done?
 Is the software to be an integral part of the work users do or
will it be used only occasionally?
 What is the primary spoken language among users?
 What are the consequences if a user makes a mistake using the
system?
 Are users experts in the subject matter that is addressed by the
system?
 Do users want to know about the technology the sits behind the
These slides areinterface?
Roger Pressman. 269
Task Analysis and Modeling
 Answers the following questions …
 What work will the user perform in specific
circumstances?
 What tasks and subtasks will be performed as the
user does the work?
 What specific problem domain objects will the
user manipulate as work is performed?
 What is the sequence of work tasks—the
workflow?
 What is the hierarchy of tasks?
 Use-cases define basic interaction
 Task elaboration refines interactive tasks
 Object elaboration identifies interface objects
(classes)
 Workflow analysis defines how a work process
is completed when several people (and roles)
are
These slides are involved
Roger Pressman. 270
Swimlane Diagram
pat ient pharmacist physician
re q ue st s t h at a d et ermine s st at u s o f
pre scrip tio n b e re f ille d p re scrip tio n
no refills ch ecks pat ien t

remaining reco rd s
refills
remaining approves refill
refill not
ch e cks in v en t o ry f o r allowed
re f ill o r alte rnativ e
e v alu at es alte rn ativ e

me d icat io n
re ceiv e s o u t o f st o ck out of stock
n o tif icat io n
alternative
available
in stock
re ceiv e s t ime / d at e none
t o pick up
p icks u p f ills
pre scrip tio n p re scrip t io n
receiv es re q ue st to
co nt act p h y sician
Software
These slides are designed to accompanyFigure Engineering: A
12.2 Swimlane diagram for prescript ion refill function

Roger Pressman. 271
Analysis of Display
Content
 Are different types of data assigned to consistent
geographic locations on the screen (e.g., photos
always appear in the upper right hand corner)?
 Can the user customize the screen location for
content?
 Is proper on-screen identification assigned to all
content?
 If a large report is to be presented, how should it
be partitioned for ease of understanding?
 Will mechanisms be available for moving directly
to summary information for large collections of
data.
 Will graphical output be scaled to fit within the
bounds of the display device that is used?
 How will color to be used to enhance
understanding?
Practitioner’s How will error messages and2009
warning be
 Approach, 7/e (McGraw-Hill, 2009) Slides copyright by
Roger Pressman.presented to the user? 272
Interface Design Steps
 Using information developed during
interface analysis, define interface
objects and actions (operations).
 Define events (user actions) that will
cause the state of the user interface
to change. Model this behavior.
 Depict each interface state as it will
actually look to the end-user.
 Indicate how the user interprets the
state of the system from information
provided through the interface.
Roger Pressman. 273
Design Issues
 Response time
 Help facilities
 Error handling
 Menu and command
labeling
 Application
accessibility
 Internationalization

Roger Pressman. 274
WebApp Interface
Design
 Where am I? The interface should
 provide an indication of the WebApp that has been
accessed
 inform the user of her location in the content
hierarchy.
 What can I do now? The interface should always
help the user understand his current options
 what functions are available?
 what links are live?
 what content is relevant?
 Where have I been, where am I going? The
interface must facilitate navigation.
 Provide a “map” (implemented in a way that is easy to
understand) of where the user has been and what
paths may be taken to move elsewhere within the
WebApp.
Roger Pressman. 275
Effective WebApp
Interfaces
 Bruce Tognozzi [TOG01] suggests…
 Effective interfaces are visually apparent
and forgiving, instilling in their users a
sense of control. Users quickly see the
breadth of their options, grasp how to
achieve their goals, and do their work.
 Effective interfaces do not concern the
user with the inner workings of the
system. Work is carefully and continuously
saved, with full option for the user to undo
any activity at any time.
 Effective applications and services
perform a maximum of work, while
requiring a 2009)
minimum of2009
Practitioner’s Approach, 7/e (McGraw-Hill, Slides copyright information
by from
276
Roger Pressman.
users.
Interface Design
Principles-I
 Anticipation—A WebApp should be designed so
that it anticipates the use’s next move.
 Communication—The interface should
communicate the status of any activity initiated by
the user
 Consistency—The use of navigation controls,
menus, icons, and aesthetics (e.g., color, shape,
layout)
 Controlled autonomy—The interface should
facilitate user movement throughout the WebApp,
but it should do so in a manner that enforces
navigation conventions that have been established
for the application.
 Efficiency—The design of the WebApp and its
interface should optimize the user’s work
efficiency, not the efficiency of the Web engineer
who
These slides are designs
designed and
to accompany builds
Software it orA the client-server
Engineering:
environment that executes it.
Roger Pressman. 277
Interface Design
Principles-II
 Focus—The WebApp interface (and the content it
presents) should stay focused on the user task(s) at
hand.
 Fitt’s Law—“The time to acquire a target is a function of
the distance to and size of the target.”
 Human interface objects—A vast library of reusable
human interface objects has been developed for
WebApps.
 Latency reduction—The WebApp should use multi-tasking
in a way that lets the user proceed with work as if the
operation has been completed.
 Learnability— A WebApp interface should be designed to
minimize learning time, and once learned, to minimize
relearning required when the WebApp is revisited.

Roger Pressman. 278
Interface Design
Principles-III
 Maintain work product integrity—A work product (e.g., a
form completed by the user, a user specified list) must be
automatically saved so that it will not be lost if an error
occurs.
 Readability—All information presented through the
interface should be readable by young and old.
 Track state—When appropriate, the state of the user
interaction should be tracked and stored so that a user
can logoff and return later to pick up where she left off.
 Visible navigation—A well-designed WebApp interface
provides “the illusion that users are in the same place,
with the work brought to them.”

Roger Pressman. 279
Interface Design
Workflow-I
 Review information contained in the analysis model
and refine as required.
 Develop a rough sketch of the WebApp interface
layout.
 Map user objectives into specific interface actions.
 Define a set of user tasks that are associated with each
action.
 Storyboard screen images for each interface action.
 Refine interface layout and storyboards using input
from aesthetic design.

Roger Pressman. 280
Mapping User
Objectives Menu bar
major functions
List of user objectives

graphic, logo, and company name
objective #1
objective #2
objective #3
objective #4
objective #5
graphic
objective #n
Home page text copy
Navigation
menu

Roger Pressman. 281
Interface Design
Workflow-II
 Identify user interface objects that are
required to implement the interface.
 Develop a procedural representation of the
user’s interaction with the interface.
 Develop a behavioral representation of the
interface.
 Describe the interface layout for each state.
 Refine and review the interface design
model.

Roger Pressman. 282
Aesthetic Design
 Don’t be afraid of white space.
 Emphasize content.
 Organize layout elements from top-left
to bottom right.
 Group navigation, content, and
function geographically within the
page.
 Don’t extend your real estate with the
scrolling bar.
 Consider resolution and browser
window size when designing layout.
Roger Pressman. 283
Design Evaluation
Cycle preliminary
design
build
prototype #1
interface
build
prototype n
#
interface
user
evaluate's
interface
design
modifications
are made
evaluation
is studied by
designer
Interface design
is complete

Roger Pressman. 284
Chapter 12
 Pattern-Based Design
Approach, 7/e

use.

Roger Pressman. 285
Design Patterns
 Each of us has encountered a design problem
and silently thought: I wonder if anyone has
developed a solution to for this?
 What if there was a standard way of describing a
problem (so you could look it up), and an organized
method for representing the solution to the problem?
 Design patterns are a codified method for
describing problems and their solution allows
the software engineering community to
capture design knowledge in a way that
enables it to be reused.
Roger Pressman. 286
Design Patterns
 Each pattern describes a problem that occurs over
and over again in our environment and then
describes the core of the solution to that problem in
such a way that you can use the solution a million
times over without ever doing it the same way
twice.
• Christopher Alexander, 1977
 “a three-part rule which expresses a relation
between a certain context, a problem, and a
solution.”

Roger Pressman. 287
Basic Concepts
 Context allows the reader to understand the
environment in which the problem resides and
what solution might be appropriate within that
environment.
 A set of requirements, including limitations
and constraints, acts as a system of forces that
influences how
 the problem can be interpreted within its context and
 how the solution can be effectively applied.

Roger Pressman. 288
Effective Patterns
 Coplien [Cop05] characterizes an effective design
pattern in the following way:
 It solves a problem: Patterns capture solutions, not just abstract
principles or strategies.
 It is a proven concept: Patterns capture solutions with a track
record, not theories or speculation.
 The solution isn't obvious: Many problem-solving techniques
(such as software design paradigms or methods) try to derive
solutions from first principles. The best patterns generate a
solution to a problem indirectly--a necessary approach for the
most difficult problems of design.
 It describes a relationship: Patterns don't just describe modules,
but describe deeper system structures and mechanisms.
 The pattern has a significant human component (minimize
human intervention). All software serves human comfort or
quality of life; the best patterns explicitly appeal to aesthetics
and utility.
Roger Pressman. 289
Generative Patterns
 Generative patterns describe an important and
repeatable aspect of a system and then provide
us with a way to build that aspect within a
system of forces that are unique to a given
context.
 A collection of generative design patterns
could be used to “generate” an application or
computer-based system whose architecture
enables it to adapt to change.

Roger Pressman. 290
Kinds of Patterns
 Architectural patterns describe broad-based design problems
that are solved using a structural approach.
 Data patterns describe recurring data-oriented problems and
the data modeling solutions that can be used to solve them.
 Component patterns (also referred to as design patterns) address
problems associated with the development of subsystems and
components, the manner in which they communicate with one
another, and their placement within a larger architecture
 Interface design patterns describe common user interface
problems and their solution with a system of forces that
includes the specific characteristics of end-users.
 WebApp patterns address a problem set that is encountered
when building WebApps and often incorporates many of the
other patterns categories just mentioned.
Roger Pressman. 291
Kinds of Patterns
 Creational patterns focus on the “creation, composition, and
representation of objects, e.g.,
 Abstract factory pattern: centralize decision of what factory to instantiate
 Factory method pattern: centralize creation of an object of a specific type
choosing one of several implementations
 Structural patterns focus on problems and solutions associated with
how classes and objects are organized and integrated to build a larger
structure, e.g.,
 Adapter pattern: 'adapts' one interface for a class into one that a client expects
 Aggregate pattern: a version of the Composite pattern with methods for
aggregation of children
 Behavioral patterns address problems associated with the assignment
of responsibility between objects and the manner in which
communication is effected between objects, e.g.,
 Chain of responsibility pattern: Command objects are handled or passed on to
other objects by logic-containing processing objects
 Command pattern: Command objects encapsulate an action and its parameters

Roger Pressman. 292
Frameworks
 Patterns themselves may not be sufficient to develop a
complete design.
 In some cases it may be necessary to provide an
implementation-specific skeletal infrastructure, called a
framework, for design work.
 That is, you can select a “reusable mini-architecture that
provides the generic structure and behavior for a family of
software abstractions, along with a context … which specifies
their collaboration and use within a given domain.” [Amb98]
 A framework is not an architectural pattern, but rather a
skeleton with a collection of “plug points” (also called
hooks and slots) that enable it to be adapted to a specific
problem domain.
 The plug points enable you to integrate problem specific
classes or functionality within the skeleton.
Roger Pressman. 293
Describing a Pattern
 Pattern name—describes the essence of the pattern in a short but expressive
name
 Problem—describes the problem that the pattern addresses
 Motivation—provides an example of the problem
 Context—describes the environment in which the problem resides including
application domain
 Forces—lists the system of forces that affect the manner in which the problem
must be solved; includes a discussion of limitation and constraints that must be
considered
 Solution—provides a detailed description of the solution proposed for the
problem
 Intent—describes the pattern and what it does
 Collaborations—describes how other patterns contribute to the solution
 Consequences—describes the potential trade-offs that must be considered when
the pattern is implemented and the consequences of using the pattern
 Implementation—identifies special issues that should be considered when
implementing the pattern
 Known uses—provides examples of actual uses of the design pattern in real
applications
 Related patterns—cross-references related design patterns
Roger Pressman. 294
Pattern Languages
 A pattern language encompasses a collection of patterns
 each described using a standardized template (Section
12.1.3) and
 interrelated to show how these patterns collaborate to
solve problems across an application domain.
 a pattern language is analogous to a hypertext
instruction manual for problem solving in a specific
application domain.
 The problem domain under consideration is first described
hierarchically, beginning with broad design problems
associated with the domain and then refining each of the
broad problems into lower levels of abstraction.

Roger Pressman. 295
Pattern-Based Design
 A software designer begins with a
requirements model (either explicit or implied)
that presents an abstract representation of the
system.
 The requirements model describes the problem
set, establishes the context, and identifies the
system of forces that hold sway.
 Then …

Roger Pressman. 296
Pattern-Based Design

Roger Pressman. 297
Thinking in Patterns
 Shalloway and Trott [Sha05] suggest the following
approach that enables a designer to think in patterns:
 1. Be sure you understand the big picture—the context in
which the software to be built resides. The requirements
model should communicate this to you.
 2. Examining the big picture, extract the patterns that are
present at that level of abstraction.
 3. Begin your design with ‘big picture’ patterns that
establish a context or skeleton for further design work.
 4. “Work inward from the context” [Sha05] looking for
patterns at lower levels of abstraction that contribute to the
design solution.
 5. Repeat steps 1 to 4 until the complete design is fleshed
out.
 6. Refine the design by adapting each pattern to the
specifics of the software you’re trying to build.
Roger Pressman. 298
Design Tasks—I
 Examine the requirements model and develop a
problem hierarchy.
 Determine if a reliable pattern language has been
developed for the problem domain.
 Beginning with a broad problem, determine whether
one or more architectural patterns are available for it.
 Using the collaborations provided for the architectural
pattern, examine subsystem or component level
problems and search for appropriate patterns to address
them.
 Repeat steps 2 through 5 until all broad problems have
been addressed.

Roger Pressman. 299
Design Tasks—II
 If user interface design problems have been
isolated (this is almost always the case), search
the many user interface design pattern
repositories for appropriate patterns.
 Regardless of its level of abstraction, if a
pattern language and/or patterns repository or
individual pattern shows promise, compare the
problem to be solved against the existing
pattern(s) presented.
 Be certain to refine the design as it is derived
from patterns using design quality criteria as a
guide.
Roger Pressman. 300
Pattern Organizing
Table

Roger Pressman. 301
Common Design
Mistakes
 Not enough time has been spent to understand the
underlying problem, its context and forces, and as a
consequence, you select a pattern that looks right, but is
inappropriate for the solution required.
 Once the wrong pattern is selected, you refuse to see
your error and force fit the pattern.
 In other cases, the problem has forces that are not
considered by the pattern you’ve chosen, resulting in a
poor or erroneous fit.
 Sometimes a pattern is applied too literally and the
required adaptations for your problem space are not
implemented.

Roger Pressman. 302
Chapter 13
 WebApp Design
Approach, 7/e

use.

Roger Pressman. 303
Design & WebApps
“There are essentially two basic approaches to
design: the artistic ideal of expressing yourself
and the engineering ideal of solving a problem
for a customer.”
Jakob Nielsen
 When should we emphasize WebApp
design?
 when content and function are complex
 when the size of the WebApp encompasses
hundreds of content objects, functions,
and analysis classes
 when the success of the WebApp will have
a direct impact oncopyright
the success
Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides 2009 by of the
304
Roger Pressman.
business
Design & WebApp
Quality
 Security
 Rebuff external attacks
 Exclude unauthorized access
 Ensure the privacy of users/customers
 Availability
 the measure of the percentage of time that
a WebApp is available for use
 Scalability
 Can the WebApp and the systems with
which it is interfaced handle significant
variation in user or transaction volume
 Time to Market
Roger Pressman. 305
Quality Dimensions for End-
Users
 Time
 How much has a Web site changed since the last
upgrade?
 How do you highlight the parts that have changed?
 Structural
 How well do all of the parts of the Web site hold
together.
 Are all links inside and outside the Web site working?
 Do all of the images work?
 Are there parts of the Web site that are not
connected?
 Content
 Does the content of critical pages match what is
supposed to be there?
 Do key phrases exist continually in highly-changeable
pages?
 Do critical pages maintain quality content from
version
These slides are designed to version?
Roger Pressman.  What about dynamically generated HTML pages? 306
Quality Dimensions for End-
Users
 Accuracy and Consistency
 Are today's copies of the pages downloaded the
same as yesterday's? Close enough?
 Is the data presented accurate enough? How do
you know?
 Response Time and Latency
 Does the Web site server respond to a browser
request within certain parameters?
 In an E-commerce context, how is the end to end
response time after a SUBMIT?
 Are there parts of a site that are so slow the user
declines to continue working on it?
 Performance
 Is the Browser-Web-Web site-Web-Browser
connection quick enough?
 How does the performance vary by time of day, by
load and usage?
 Is performance
These slides are designed adequate
to accompany Software Engineering:for
A E-commerce
Roger Pressman.
applications? 307
WebApp Design Goals
 Consistency
 Content should be constructed consistently
 Graphic design (aesthetics) should present a consistent
look across all parts of the WebApp
 Architectural design should establish templates that lead to
a consistent hypermedia structure
 Interface design should define consistent modes of
interaction, navigation and content display
 Navigation mechanisms should be used consistently
across all WebApp elements

Roger Pressman. 308
WebApp Design Goals
 Identity
 Establish an “identity” that is appropriate for the
business purpose
 Robustness
 The user expects robust content and functions that are relevant to
the user’s needs
 Navigability
 designed in a manner that is intuitive and predictable
 Visual appeal
 the look and feel of content, interface layout,
color coordination, the balance of text, graphics
and other media, navigation mechanisms must
appeal to end-users
 Compatibility
 With all appropriate environments and
configurations
Roger Pressman. 309
WebE Design Pyramid
user
Interface
design
Aesthetic design
Content design
Navigation design
Architecture design
Component design
technology

Roger Pressman. 310
WebApp Interface
Design
 Where am I? The interface should
 provide an indication of the WebApp that has been
accessed
 inform the user of her location in the content
hierarchy.
 What can I do now? The interface should always
help the user understand his current options
 what functions are available?
 what links are live?
 what content is relevant?
 Where have I been, where am I going? The
interface must facilitate navigation.
 Provide a “map” (implemented in a way that is easy to
understand) of where the user has been and what
paths may be taken to move elsewhere within the
WebApp.
Roger Pressman. 311
Effective WebApp
Interfaces
 Bruce Tognozzi [TOG01] suggests…
 Effective interfaces are visually apparent
and forgiving, instilling in their users a
sense of control. Users quickly see the
breadth of their options, grasp how to
achieve their goals, and do their work.
 Effective interfaces do not concern the
user with the inner workings of the
system. Work is carefully and continuously
saved, with full option for the user to undo
any activity at any time.
 Effective applications and services
perform a maximum of work, while
requiring a 2009)
minimum of2009
Practitioner’s Approach, 7/e (McGraw-Hill, Slides copyright information
by from
312
Roger Pressman.
users.
Interface Design
Principles-I
 Anticipation—A WebApp should be designed so
that it anticipates the use’s next move.
 Communication—The interface should
communicate the status of any activity initiated by
the user
 Consistency—The use of navigation controls,
menus, icons, and aesthetics (e.g., color, shape,
layout)
 Controlled autonomy—The interface should
facilitate user movement throughout the WebApp,
but it should do so in a manner that enforces
navigation conventions that have been established
for the application.
 Efficiency—The design of the WebApp and its
interface should optimize the user’s work
efficiency, not the efficiency of the Web engineer
who
These slides are designs
designed and
to accompany builds
Software it orA the client-server
Engineering:
environment that executes it.
Roger Pressman. 313
Interface Design
Principles-II
 Focus—The WebApp interface (and the content it
presents) should stay focused on the user task(s) at
hand.
 Fitt’s Law—“The time to acquire a target is a function of
the distance to and size of the target.”
 Human interface objects—A vast library of reusable
human interface objects has been developed for
WebApps.
 Latency reduction—The WebApp should use multi-tasking
in a way that lets the user proceed with work as if the
operation has been completed.
 Learnability— A WebApp interface should be designed to
minimize learning time, and once learned, to minimize
relearning required when the WebApp is revisited.

Roger Pressman. 314
Interface Design
Principles-III
 Maintain work product integrity—A work product (e.g., a
form completed by the user, a user specified list) must be
automatically saved so that it will not be lost if an error
occurs.
 Readability—All information presented through the
interface should be readable by young and old.
 Track state—When appropriate, the state of the user
interaction should be tracked and stored so that a user
can logoff and return later to pick up where she left off.
 Visible navigation—A well-designed WebApp interface
provides “the illusion that users are in the same place,
with the work brought to them.”

Roger Pressman. 315
Aesthetic Design
 Don’t be afraid of white space.
 Emphasize content.
 Organize layout elements from top-left
to bottom right.
 Group navigation, content, and
function geographically within the
page.
 Don’t extend your real estate with the
scrolling bar.
 Consider resolution and browser
window size when designing layout.
Roger Pressman. 316
Content Design
 Develops a design representation for
content objects
 For WebApps, a content object is more closely aligned
with a data object for conventional software
 Represents the mechanisms required
to instantiate their relationships to
one another.
 analogous to the relationship between analysis classes and
design components described in Chapter 11
 A content object has attributes that include content
specific information and implementationspecific
attributes that are specified as part of design
Roger Pressman. 317
Design of Content
Objects
ProductComponent
partNumber
partName
partType 1 is part of
description
price
createNewItem () 1
displayDescription ( ) CompDescription
display TechSpec
Sensor Camera ControlPanel SoftFeature
1 1..* 0..1 0..1 1
MarketingDescription Photograph Schematic Video TechDescription
text color horizontal dimension horizontal dimension horizontal dimension text color
font style vertical dimension vertical dimension vertical dimension font style
font size border style border style border style font size
line spacing audio volume line spacing
text image size text image size
background color background color

Roger Pressman. 318
Architecture Design
 Content architecture focuses on the manner in which
content objects (or composite objects such as Web
pages) are structured for presentation and navigation.
 The term information architecture is also used to connote
structures that lead to better organization, labeling,
navigation, and searching of content objects.
 WebApp architecture addresses the manner in which the
application is structured to manage user interaction,
handle internal processing tasks, effect navigation, and
present content.
 Architecture design is conducted in parallel with
interface design, aesthetic design and content design.

Roger Pressman. 319
Content Architecture
Linear
structure Grid
structure
Network
structure Hierarchical
structure

Roger Pressman. 320
Navigation Design
 Begins with a consideration of the
user hierarchy and related use-cases
 Each actor may use the WebApp somewhat
differently and therefore have different
navigation requirements
 As each user interacts with the
WebApp, she encounters a series of
navigation semantic units (NSUs)
 NSU—“a set of information and related
navigation structures that collaborate in
the fulfillment of a subset of related user
requirements”
Roger Pressman. 321
Navigation Semantic
Units
 Navigation semantic unit
 Ways of navigation (WoN)—represents the best
navigation way or path for users with certain
profiles to achieve their desired goal or sub-
goal. Composed of …
• Navigation nodes (NN) connected by Navigation
links
link12 link24
NN2
NN1
NN4 NSU
link13 NN3 link34

Roger Pressman. 322
Navigation Syntax
 Individual navigation link—text-based links,
icons, buttons and switches, and graphical
metaphors..
 Horizontal navigation bar—lists major content
or functional categories in a bar containing
appropriate links. In general, between 4 and 7
categories are listed.
 Vertical navigation column
 lists major content or functional categories
 lists virtually all major content objects within
the WebApp.
 Tabs—a metaphor that is nothing more than a
variation of the navigation bar or column,
representing content or functional categories
as tab sheets that are selected when a link is
Practitioner’s required.
Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by
Roger Pressman. 323
 Site maps—provide an all-inclusive tab of
Component-Level
Design
 WebApp components implement the
following functionality
 perform localized processing to generate
content and navigation capability in a
dynamic fashion
 provide computation or data processing
capability that are appropriate for the
WebApp’s business domain
 provide sophisticated database query and
access
 establish data interfaces with external
corporate systems.
Roger Pressman. 324
Chapter 14
 Quality Concepts
Approach, 7/e

use.

Roger Pressman. 325
Software Quality
 In 2005, ComputerWorld [Hil05] lamented that
 “bad software plagues nearly every organization that uses
computers, causing lost work hours during computer downtime,
lost or corrupted data, missed sales opportunities, high IT support
and maintenance costs, and low customer satisfaction.
 A year later, InfoWorld [Fos06] wrote about the
 “the sorry state of software quality” reporting that the quality
problem had not gotten any better.
 Today, software quality remains an issue, but who is to blame?
 Customers blame developers, arguing that sloppy practices lead to
low-quality software.
 Developers blame customers (and other stakeholders), arguing
that irrational delivery dates and a continuing stream of changes
force them to deliver software before it has been fully validated.

Roger Pressman. 326
Quality
 The American Heritage Dictionary
defines quality as
 “a characteristic or attribute of
something.”
 For software, two kinds of quality may
be encountered:
 Quality of design encompasses
requirements, specifications, and the
design of the system.
 Quality of conformance is an issue focused
primarily on implementation.
 User satisfaction = compliant product +
good
These slides are designed quality
to accompany + delivery
Software Engineering: A within budget and
Roger Pressman. schedule 327
Quality—A Philosophical
View
 Robert Persig [Per74] commented on the thing we call
quality:
 Quality . . . you know what it is, yet you don't know what it is.
But that's self-contradictory. But some things are better than
others, that is, they have more quality. But when you try to say
what the quality is, apart from the things that have it, it all goes
poof! There's nothing to talk about. But if you can't say what
Quality is, how do you know what it is, or how do you know that
it even exists? If no one knows what it is, then for all practical
purposes it doesn't exist at all. But for all practical purposes it
really does exist. What else are the grades based on? Why else
would people pay fortunes for some things and throw others in
the trash pile? Obviously some things are better than others . . .
but what's the betterness? . . . So round and round you go,
spinning mental wheels and nowhere finding anyplace to get
traction. What the hell is Quality? What is it?
Roger Pressman. 328
Quality—A Pragmatic
View
 The transcendental view argues (like Persig) that quality is
something that you immediately recognize, but cannot
explicitly define.
 The user view sees quality in terms of an end-user’s
specific goals. If a product meets those goals, it exhibits
quality.
 The manufacturer’s view defines quality in terms of the
original specification of the product. If the product
conforms to the spec, it exhibits quality.
 The product view suggests that quality can be tied to
inherent characteristics (e.g., functions and features) of a
product.
 Finally, the value-based view measures quality based on
how much a customer is willing to pay for a product. In
reality, quality encompasses all of these views and more.
Roger Pressman. 329
Software Quality
 Software quality can be defined as:
 An effective software process applied in a manner that
creates a useful product that provides measurable value for
those who produce it and those who use it.
 This definition has been adapted from [Bes04] and
replaces a more manufacturing-oriented view
presented in earlier editions of this book.

Roger Pressman. 330
Effective Software
Process
 An effective software process establishes the
infrastructure that supports any effort at building a high
quality software product.
 The management aspects of process create the checks
and balances that help avoid project chaos—a key
contributor to poor quality.
 Software engineering practices allow the developer to
analyze the problem and design a solid solution—both
critical to building high quality software.
 Finally, umbrella activities such as change management
and technical reviews have as much to do with quality
as any other part of software engineering practice.

Roger Pressman. 331
Useful Product
 A useful product delivers the content, functions,
and features that the end-user desires
 But as important, it delivers these assets in a
reliable, error free way.
 A useful product always satisfies those
requirements that have been explicitly stated
by stakeholders.
 In addition, it satisfies a set of implicit
requirements (e.g., ease of use) that are
expected of all high quality software.
Roger Pressman. 332
Adding Value
 By adding value for both the producer and user of a software
product, high quality software provides benefits for the
software organization and the end-user community.
 The software organization gains added value because
high quality software requires less maintenance effort,
fewer bug fixes, and reduced customer support.
 The user community gains added value because the
application provides a useful capability in a way that
expedites some business process.
 The end result is:
 (1) greater software product revenue,
 (2) better profitability when an application supports a
business process, and/or
 (3) improved availability of information that is crucial for
the business.
Roger Pressman. 333
Quality Dimensions
 David Garvin [Gar87]:
 Performance Quality. Does the software deliver all
content, functions, and features that are specified as part of
the requirements model in a way that provides value to the
end-user?
 Feature quality. Does the software provide features that
surprise and delight first-time end-users?
 Reliability. Does the software deliver all features and
capability without failure? Is it available when it is
needed? Does it deliver functionality that is error free?
 Conformance. Does the software conform to local and
external software standards that are relevant to the
application? Does it conform to de facto design and coding
conventions? For example, does the user interface conform
to accepted design rules for menu selection or data input?
Roger Pressman. 334
Quality Dimensions
 Durability. Can the software be maintained (changed) or
corrected (debugged) without the inadvertent generation
of unintended side effects? Will changes cause the error
rate or reliability to degrade with time?
 Serviceability. Can the software be maintained (changed)
or corrected (debugged) in an acceptably short time
period. Can support staff acquire all information they need
to make changes or correct defects?
 Aesthetics. Most of us would agree that an aesthetic entity
has a certain elegance, a unique flow, and an obvious
“presence” that are hard to quantify but evident
nonetheless.
 Perception. In some situations, you have a set of prejudices
that will influence your perception of quality.
Roger Pressman. 335
The Software Quality
Dilemma
 If you produce a software system that has terrible
quality, you lose because no one will want to buy it.
 If on the other hand you spend infinite time, extremely
large effort, and huge sums of money to build the
absolutely perfect piece of software, then it's going to
take so long to complete and it will be so expensive to
produce that you'll be out of business anyway.
 Either you missed the market window, or you simply
exhausted all your resources.
 So people in industry try to get to that magical middle
ground where the product is good enough not to be
rejected right away, such as during evaluation, but also
not the object of so much perfectionism and so much
work that it would take too long or cost too much to
complete. [Ven03]
Roger Pressman. 336
“Good Enough”
Software
 Good enough software delivers high quality functions and
features that end-users desire, but at the same time it delivers
other more obscure or specialized functions and features that
contain known bugs.
 Arguments against “good enough.”
 It is true that “good enough” may work in some application
domains and for a few major software companies. After all, if a
company has a large marketing budget and can convince enough
people to buy version 1.0, it has succeeded in locking them in.
 If you work for a small company be wary of this philosophy. If
you deliver a “good enough” (buggy) product, you risk permanent
damage to your company’s reputation.
 You may never get a chance to deliver version 2.0 because bad
buzz may cause your sales to plummet and your company to fold.
 If you work in certain application domains (e.g., real time
embedded software, application software that is integrated with
hardware can be negligent and open your company to expensive
litigation.
Roger Pressman. 337
Cost of Quality
 Prevention costs include
 quality planning
 formal technical reviews
 test equipment
 Training
 Internal failure costs include
 rework
 repair
 failure mode analysis
 External failure costs are
 complaint resolution
 product return and replacement
 help line support
 warranty work

Roger Pressman. 338
Cost
 The relative costs to find and repair an error or defect
increase dramatically as we go from prevention to
detection to internal failure to external failure costs.

Roger Pressman. 339
Quality and Risk
 “People bet their jobs, their comforts, their safety, their
entertainment, their decisions, and their very lives on
computer software. It better be right.” SEPA, Chapter 1
 Example:
 Throughout the month of November, 2000 at a hospital in
Panama, 28 patients received massive overdoses of gamma rays
during treatment for a variety of cancers. In the months that
followed, five of these patients died from radiation poisoning and
15 others developed serious complications. What caused this
tragedy? A software package, developed by a U.S. company, was
modified by hospital technicians to compute modified doses of
radiation for each patient.

Roger Pressman. 340
Negligence and
Liability
 The story is all too common. A governmental or
corporate entity hires a major software developer or
consulting company to analyze requirements and then
design and construct a software-based “system” to
support some major activity.
 The system might support a major corporate function (e.g.,
pension management) or some governmental function
(e.g., healthcare administration or homeland security).
 Work begins with the best of intentions on both sides,
but by the time the system is delivered, things have gone
bad.
 The system is late, fails to deliver desired features and
functions, is error-prone, and does not meet with
customer approval.
 Litigation ensues.
Roger Pressman. 341
Quality and Security
 Gary McGraw comments [Wil05]:
 “Software security relates entirely and completely to
quality. You must think about security, reliability,
availability, dependability—at the beginning, in the
design, architecture, test, and coding phases, all through
the software life cycle [process]. Even people aware of
the software security problem have focused on late life-
cycle stuff. The earlier you find the software problem,
the better. And there are two kinds of software
problems. One is bugs, which are implementation
problems. The other is software flaws—architectural
problems in the design. People pay too much attention
to bugs and not enough on flaws.”
Roger Pressman. 342
Achieving Software
Quality
 Critical success factors:
 Software Engineering Methods
 Project Management Techniques
 Quality Control
 Quality Assurance

Roger Pressman. 343
Chapter 15
 Review Techniques
Approach, 7/e

use.

Roger Pressman. 344
What Are Reviews?
 a meeting conducted by
technical people for technical
people
 a technical assessment of a
work product created during
the software engineering
process
 a software quality assurance
mechanism
 a training ground

Roger Pressman. 345
What Reviews Are Not
 A project summary or progress

assessment
 A meeting intended solely to
impart information
 A mechanism for political or
personal reprisal!

Roger Pressman. 346
What Do We Look For?
 Errors and defects
 Error—a quality problem found before the software is released
to end users
 Defect—a quality problem found only after the software has been
released to endusers
 We make this distinction because errors and defects have very
different economic, business, psychological, and human
impact
 However, the temporal distinction made between errors and
defects in this book is not mainstream thinking

Roger Pressman. 347
Defect Amplification
 A defect amplification model [IBM81] can be used to illustrate
the generation and detection of errors during the design and
code generation actions of a software process.
Defects Detection
Errors from Errors passed through
Previous step Percent Errors passed
Amplified errors 1:x Efficiency To next step
Newly generated errors
Development step

Roger Pressman. 348
Defect Amplification
 In the example provided in SEPA,
Section 15.2,
 a software process that does NOT include
reviews,
• yields 94 errors at the beginning of testing
and
• Releases 12 latent defects to the field
 a software process that does include
reviews,
• yields 24 errors at the beginning of testing
and
• releases 3 latent defects to the field
 A cost analysis indicates that the process
with NO reviews 2009). Slidescosts
Practitioner’s Approach, 7/e (McGraw-Hill approximately
copyright 2009 by 3
Roger Pressman.
times more than the process with reviews,349
Metrics
 The total review effort and the total number of
errors discovered are defined as:
• Ereview = Ep + Ea + Er
• Errtot = Errminor + Errmajor
 Defect density represents the errors found per
unit of work product reviewed.
• Defect density = Errtot / WPS
 where …

Roger Pressman. 350
Metrics
 Preparation effort, Ep—the effort (in person-hours) required to
review a work product prior to the actual review meeting
 Assessment effort, Ea— the effort (in person-hours) that is
expending during the actual review
 Rework effort, Er— the effort (in person-hours) that is dedicated
to the correction of those errors uncovered during the review
 Work product size, WPS—a measure of the size of the work
product that has been reviewed (e.g., the number of UML
models, or the number of document pages, or the number of
lines of code)
 Minor errors found, Errminor—the number of errors found that can
be categorized as minor (requiring less than some pre-specified
effort to correct)
 Major errors found, Errmajor— the number of errors found that
can be categorized as major (requiring more than some pre-
specified
These slides are effort
designed to to correct)
accompany Software Engineering: A
Roger Pressman. 351
An Example—I
 If past history indicates that
 the average defect density for a requirements model
is 0.6 errors per page, and a new requirement model
is 32 pages long,
 a rough estimate suggests that your software team
will find about 19 or 20 errors during the review of
the document.
 If you find only 6 errors, you’ve done an extremely
good job in developing the requirements model or
your review approach was not thorough enough.

Roger Pressman. 352
An Example—II
 The effort required to correct a minor model error (immediately after
the review) was found to require 4 person-hours.
 The effort required for a major requirement error was found to be 18
person-hours.
 Examining the review data collected, you find that minor errors occur
about 6 times more frequently than major errors. Therefore, you can
estimate that the average effort to find and correct a requirements error
during review is about 6 person-hours.
 Requirements related errors uncovered during testing require an
average of 45 person-hours to find and correct. Using the averages
noted, we get:
 Effort saved per error = Etesting – Ereviews
 45 – 6 = 30 person-hours/error
 Since 22 errors were found during the review of the requirements
model, a saving of about 660 person-hours of testing effort would be
achieved. And that’s just for requirements-related errors.

Roger Pressman. 353
Overall
 Effort expended with and without
reviews
with reviews
Roger Pressman. 354
Informal Reviews
 Informal reviews include:
 a simple desk check of a software engineering work
product with a colleague
 a casual meeting (involving more than 2 people) for the
purpose of reviewing a work product, or
 the revieworiented aspects of pair programming
 pair programming encourages continuous review as
a work product (design or code) is created.
 The benefit is immediate discovery of errors and better
work product quality as a consequence.

Roger Pressman. 355
Formal Technical
Reviews
 The objectives of an FTR are:
 to uncover errors in function, logic, or implementation for
any representation of the software
 to verify that the software under review meets its
requirements
 to ensure that the software has been represented according
to predefined standards
 to achieve software that is developed in a uniform manner
 to make projects more manageable
 The FTR is actually a class of reviews that includes
walkthroughs and inspections.
Roger Pressman. 356
The Review Meeting
 Between three and five people (typically)
should be involved in the review.
 Advance preparation should occur but should
require no more than two hours of work for
each person.
 The duration of the review meeting should be
less than two hours.
 Focus is on a work product (e.g., a portion of a
requirements model, a detailed component design,
source code for a component)

Roger Pressman. 357
The Players
 Producer—the individual who has developed the work
product
 informs the project leader that the work product is
complete and that a review is required
 Review leader—evaluates the product for readiness,
generates copies of product materials, and distributes
them to two or three reviewers for advance preparation.
 Reviewer(s)—expected to spend between one and two
hours reviewing the product, making notes, and
otherwise becoming familiar with the work.
 Recorder—reviewer who records (in writing) all important
issues raised during the review.

Roger Pressman. 358
Conducting the Review
 Review the product, not the producer.
 Set an agenda and maintain it.
 Limit debate and rebuttal.
 Enunciate problem areas, but don't attempt to solve every
problem noted.
 Take written notes.
 Limit the number of participants and insist upon advance
preparation.
 Develop a checklist for each product that is likely to be
reviewed.
 Allocate resources and schedule time for FTRs.
 Conduct meaningful training for all reviewers.
 Review your early reviews.
Roger Pressman. 359
Sample-Driven Reviews
(SDRs)
 SDRs attempt to quantify those work products that are
primary targets for full FTRs.
To accomplish this …
 Inspect a fraction ai of each software work product, i.
Record the number of faults, fi found within ai.
 Develop a gross estimate of the number of faults within
work product i by multiplying fi by 1/ai.
 Sort the work products in descending order according to
the gross estimate of the number of faults in each.
 Focus available review resources on those work
products that have the highest estimated number of
faults.
Roger Pressman. 360
Chapter 16
 Software Quality Assurance
Approach, 7/e

use.

Roger Pressman. 361
Comment on Quality
 Phil Crosby once said:
 The problem of quality management is not what people
don't know about it. The problem is what they think they
do know . . .
 Everybody is for it. (Under certain conditions, of course.)
 Everyone feels they understand it. (Even though they
wouldn't want to explain it.)
 Everyone thinks execution is only a matter of following natural
inclinations. (After all, we do get along somehow.)
 And, of course, most people feel that problems in these areas are
caused by other people. (If only they would take the time to
do things right.)

Roger Pressman. 362
Elements of SQA
 Standards
 Reviews and Audits
 Testing
 Error/defect collection and analysis
 Change management
 Education
 Vendor management
 Security management
 Safety
 Risk management
Roger Pressman. 363
Role of the SQA Group-
I
 Prepares an SQA plan for a project.
 The plan identifies
• evaluations to be performed
• audits and reviews to be performed
• standards that are applicable to the project
• procedures for error reporting and tracking
• documents to be produced by the SQA group
• amount of feedback provided to the software project
team
 Participates in the development of the project’s
software process description.
 The SQA group reviews the process description for
compliance with organizational policy, internal
software standards, externally imposed standards
(e.g., ISO-9001), and other parts of the software
project plan.

Roger Pressman. 364
Role of the SQA Group-
II
 Reviews software engineering activities to verify
compliance with the defined software process.
 identifies, documents, and tracks deviations from the
process and verifies that corrections have been made.
 Audits designated software work products to verify
compliance with those defined as part of the
software process.
 reviews selected work products; identifies, documents,
and tracks deviations; verifies that corrections have
been made
 periodically reports the results of its work to the
project manager.
 Ensures that deviations in software work and work
products are documented and handled according to
a documented procedure.
 Records any noncompliance and reports to senior
management.
 Noncompliance items are tracked until they are
resolved.
Roger Pressman. 365
SQA Goals (see Figure 16.1)
 Requirements quality. The correctness, completeness,
and consistency of the requirements model will have a
strong influence on the quality of all work products that
follow.
 Design quality. Every element of the design model
should be assessed by the software team to ensure that it
exhibits high quality and that the design itself conforms
to requirements.
 Code quality. Source code and related work products
(e.g., other descriptive information) must conform to
local coding standards and exhibit characteristics that
will facilitate maintainability.
 Quality control effectiveness. A software team should
apply limited resources in a way that has the highest
likelihood of achieving a high quality result.
Roger Pressman. 366
Statistical
SQA
Product Collect information on all defects
Find the causes of the defects
& Process Move to provide fixes for the process
measurement
... an understanding of how

to improve quality ...

Roger Pressman. 367
Statistical SQA
 Information about software errors and defects is
collected and categorized.
 An attempt is made to trace each error and defect to its
underlying cause (e.g., non-conformance to
specifications, design error, violation of standards, poor
communication with the customer).
 Using the Pareto principle (80 percent of the defects can
be traced to 20 percent of all possible causes), isolate the
20 percent (the vital few).
 Once the vital few causes have been identified, move to
correct the problems that have caused the errors and
defects.

Roger Pressman. 368
Six-Sigma for Software
Engineering
 The term “six sigma” is derived from six standard
deviations—3.4 instances (defects) per million
occurrences—implying an extremely high quality
standard.
 The Six Sigma methodology defines three core
steps:
 Define customer requirements and deliverables and
project goals via well-defined methods of customer
communication
 Measure the existing process and its output to
determine current quality performance (collect defect
metrics)
 Analyze defect metrics and determine the vital few
causes.
 Improve the process by eliminating the root causes of
defects.
 Control
Practitioner’s Approach, the process
7/e (McGraw-Hill tocopyright
2009). Slides ensure that
2009 by future work does
Roger Pressman. 369
not reintroduce the causes of defects.
Software Reliability
 A simple measure of reliability is
mean-time-between-failure (MTBF),
where
MTBF = MTTF + MTTR
 The acronyms MTTF and MTTR are
mean-time-to-failure and mean-time-
to-repair, respectively.
 Software availability is the probability
that a program is operating according
to requirements at a given point in
time and is defined as
Roger Pressman. Availability = [MTTF/(MTTF + MTTR)] x

370
Software Safety
 Software safety is a software quality
assurance activity that focuses on
the identification and assessment of
potential hazards that may affect
software negatively and cause an
entire system to fail.
 If hazards can be identified early in
the software process, software design
features can be specified that will
either eliminate or control potential
hazards.
Roger Pressman. 371
ISO 9001:2000
Standard
 ISO 9001:2000 is the quality assurance
standard that applies to software
engineering.
 The standard contains 20 requirements that
must be present for an effective quality
assurance system.
 The requirements delineated by ISO
9001:2000 address topics such as
 management responsibility, quality system,
contract review, design control, document and
data control, product identification and
traceability, process control, inspection and
testing, corrective and preventive action,
control of quality records, internal quality
audits, training, servicing, and statistical
techniques.
Roger Pressman. 372
Chapter 17
 Software Testing Strategies
Approach, 7/e

use.

Roger Pressman. 373
Software
Testing
Testing is the process of
exercising a program with the
specific intent of finding errors
prior to delivery to the end
user.

Roger Pressman. 374
What Testing
Shows
errors
requirements conformance
performance
an indication
of quality

Roger Pressman. 375
Strategic Approach
 To perform effective testing, you should conduct
effective technical reviews. By doing this, many errors
will be eliminated before testing commences.
 Testing begins at the component level and works
"outward" toward the integration of the entire computer-
based system.
 Different testing techniques are appropriate for different
software engineering approaches and at different points
in time.
 Testing is conducted by the developer of the software
and (for large projects) an independent test group.
 Testing and debugging are different activities, but
debugging must be accommodated in any testing
strategy.
Roger Pressman. 376
V&V
 Verification refers to the set of tasks that ensure
that software correctly implements a specific
function.
 Validation refers to a different set of tasks that
ensure that the software that has been built is
traceable to customer requirements. Boehm
[Boe81] states this another way:
 Verification: "Are we building the product right?"
 Validation: "Are we building the right product?"

Roger Pressman. 377
Who Tests the
Software?
developer independent tester

Understands the system Must learn about the system,
but, will test "gently" but, will attempt to break it
and, is driven by "delivery" and, is driven by quality

Roger Pressman. 378
Testing Strategy
System engineering
Analysis modeling
Design modeling
Code generation Unit test
Integration test
Validation test
System test

Roger Pressman. 379
Testing Strategy
 We begin by ‘testing-in-the-small’ and
move toward ‘testing-in-the-large’
 For conventional software
 The module (component) is our initial
focus
 Integration of modules follows
 For OO software
 our focus when “testing in the small”
changes from an individual module (the
conventional view) to an OO class that
encompasses attributes and operations
and implies communication and
collaboration
Roger Pressman. 380
Strategic Issues
 Specify product requirements in a
quantifiable manner long before testing
commences.
 State testing objectives explicitly.
 Understand the users of the software and
develop a profile for each user category.
 Develop a testing plan that emphasizes “rapid
cycle testing.”
 Build “robust” software that is designed to
test itself
 Use effective technical reviews as a filter
prior to testing
 Conduct technical reviews to assess the test
strategy and test cases themselves.
 are
These slides
Develop a continuous improvement approach
for the testing process.
Roger Pressman. 381
Unit Testing
module
to be
tested
results
software
engineer test cases

Roger Pressman. 382
Unit Testing
module
to be
tested
interface
local data structures
boundary conditions
independent paths
error handling paths
test cases
Roger Pressman. 383
Unit Test
Environment
driver
interface
local data structures
Module boundary conditions

independent paths
error handling paths
stub stub
test cases
RESULTS
Roger Pressman. 384
Integration Testing
Strategies
• Top down testing
• Bottom-up testing
• Sandwich testing

Roger Pressman. 385
Top Down
Integration
A
top module is tested with
stubs
B F G
stubs are replaced one at

a time, "depth first"
C
as new modules are integrated,
some subset of tests is re-run
D E

Roger Pressman. 386
Bottom-Up
Integration
A
B F G
drivers are replaced one at a

time, "depth first"
C
worker modules are grouped into

builds and integrated
D E
cluster
Roger Pressman. 387
Sandwich Testing
A
Top modules are
tested with stubs
B F G
Worker modules are grouped into

builds and integrated
D E
cluster
Roger Pressman. 388
Regression Testing
 Regression testing is the re-execution of some subset of
tests that have already been conducted to ensure that
changes have not propagated unintended side effects
 Whenever software is corrected, some aspect of the
software configuration (the program, its documentation,
or the data that support it) is changed.
 Regression testing helps to ensure that changes (due to
testing or for other reasons) do not introduce
unintended behavior or additional errors.
 Regression testing may be conducted manually, by re-
executing a subset of all test cases or using automated
capture/playback tools.

Roger Pressman. 389
Smoke
Testing
 A common approach for creating “daily builds” for
product software
 Smoke testing steps:
 Software components that have been translated into
code are integrated into a “build.”
• A build includes all data files, libraries, reusable modules,
and engineered components that are required to implement
one or more product functions.
 A series of tests is designed to expose errors that will
keep the build from properly performing its function.
• The intent should be to uncover “show stopper” errors that
have the highest likelihood of throwing the software project
behind schedule.
 The build is integrated with other builds and the entire
product (in its current form) is smoke tested daily.
• The integration approach may be top down or bottom up.

Roger Pressman. 390
Object-Oriented
Testing
 begins by evaluating the correctness
and consistency of the analysis and
design models
 testing strategy changes
 the concept of the ‘unit’ broadens due to
encapsulation
 integration focuses on classes and their
execution across a ‘thread’ or in the
context of a usage scenario
 validation uses conventional black box
methods
 test case design draws on
conventional methods, but also
Practitioner’s encompasses
Approach, 7/e (McGraw-Hill 2009). special features
Slides copyright 2009 by
Roger Pressman. 391
Testing the CRC Model
1. Revisit the CRC model and the object-relationship model.
2. Inspect the description of each CRC index card to determine if a
delegated responsibility is part of the collaborator’s definition.
3. Invert the connection to ensure that each collaborator that is
asked for service is receiving requests from a reasonable source.
4. Using the inverted connections examined in step 3, determine
whether other classes might be required or whether responsibilities
are properly grouped among the classes.
5. Determine whether widely requested responsibilities might be
combined into a single responsibility.
6. Steps 1 to 5 are applied iteratively to each class and through
each evolution of the analysis model.

Roger Pressman. 392
OO Testing
Strategy
 class testing is the equivalent of
unit testing
 operations within the class are tested
 the state behavior of the class is
examined
 integration applied three different
strategies
 thread-based testing—integrates the
set of classes required to respond to
one input or event
 use-based testing—integrates the set of
classes required to respond to one use
case
Roger Pressman.  cluster testing—integrates the set of 393
High Order
Testing
 Validation testing
 Focus is on software requirements
 System testing
 Focus is on system integration
 Alpha/Beta testing
 Focus is on customer usage
 Recovery testing
 forces the software to fail in a variety of ways and verifies that
recovery is properly performed
 Security testing
 verifies that protection mechanisms built into a system will, in
fact, protect it from improper penetration
 Stress testing
 executes a system in a manner that demands resources in
abnormal quantity, frequency, or volume
 Performance Testing
 test the run-time performance of software within the context of
an integrated system

Roger Pressman. 394
Debugging: A Diagnostic
Process

Roger Pressman. 395
The Debugging
Process

Roger Pressman. 396
Debugging Effort
time required
to diagnose the
symptom and
time required determine the
to correct the error cause
and conduct
regression tests

Roger Pressman. 397
Symptoms &
Causes symptom and cause may be
geographically separated
symptom may disappear when

another problem is fixed
cause may be due to a

combination of non-errors
cause may be due to a system

or compiler error
symptom cause may be due to

assumptions that everyone
cause believes
symptom may be intermittent

Roger Pressman. 398
Consequences of
Bugs
infectious
damage
catastrophic
extreme
serious
disturbing
annoying
mild
Bug Type
Bug Categories: function-related bugs,

system-related bugs, data bugs, coding bugs,
design bugs, documentation bugs, standards
violations, etc.
Roger Pressman. 399
Correcting the Error
 Is the cause of the bug reproduced in another part of the program? In
many situations, a program defect is caused by an erroneous
pattern of logic that may be reproduced elsewhere.
 What "next bug" might be introduced by the fix I'm about to make?
Before the correction is made, the source code (or, better, the
design) should be evaluated to assess coupling of logic and
data structures.
 What could we have done to prevent this bug in the first place? This
question is the first step toward establishing a statistical
software quality assurance approach. If you correct the process
as well as the product, the bug will be removed from the
current program and may be eliminated from all future
programs.

Roger Pressman. 400
Final Thoughts
 Think -- before you act to correct
 Use tools to gain additional insight
 If you’re at an impasse, get help from
someone else
 Once you correct the bug, use
regression testing to uncover any side
effects

Roger Pressman. 401
Chapter 18
 Testing Conventional Applications
Approach, 7/e

use.

Roger Pressman. 402
Testabil
ity Operability—it operates cleanly

 Observability—the results of each test case
are readily observed
 Controllability—the degree to which testing
can be automated and optimized
 Decomposability—testing can be targeted
 Simplicity—reduce complex architecture and
logic to simplify tests
 Stability—few changes are requested during
testing
 Understandability—of the design

Roger Pressman. 403
What is a “Good” Test?
 A good test has a high
probability of finding an error
 A good test is not redundant.
 A good test should be “best of
breed”
 A good test should be neither
too simple nor too complex

Roger Pressman. 404
Internal and External
Views
 Any engineered product (and most other
things) can be tested in one of two ways:
 Knowing the specified function that a product has
been designed to perform, tests can be conducted
that demonstrate each function is fully operational
while at the same time searching for errors in each
function;
 Knowing the internal workings of a product, tests
can be conducted to ensure that "all gears mesh," that
is, internal operations are performed according to
specifications and all internal components have been
adequately exercised.

Roger Pressman. 405
Test Case
Design
"Bugs lurk in corners
and congregate at
boundaries ..."
Boris Beizer
OBJECTIVE to uncover errors
CRITERIA in a complete manner
CONSTRAINT
with a minimum of effort and time
Roger Pressman. 406
Exhaustive Testing
loop < 20 X
14
There are 10 possible paths! If we execute one
test per millisecond, it would take 3,170 years to
test
These slides are this
designed program!!
Roger Pressman. 407
Selective Testing
Selected path
loop < 20 X

Roger Pressman. 408
Software Testing
white- black-
box box
methods
methods
Methods
Strategies

Roger Pressman. 409
White-Box
Testing
... our goal is to ensure that all

statements and conditions have
been executed at least once ...
Roger Pressman. 410
Why
Cover?
logic errors and incorrect assumptions
are inversely proportional to a path's
execution probability
we oftenbelievethat a path is not

likely to be executed; in fact, reality is
often counter intuitive
typographical errors are random; it's

likely that untested paths will contain
some
Roger Pressman. 411
Basis Path
Testing
First, we compute the cyclomatic
complexity:
number of simple decisions + 1
or
number of enclosed areas + 1
In this case, V(G) = 4

Roger Pressman. 412
Cyclomatic
Complexity
A number of industry studies have indicated
that the higher V(G), the higher the probability
or errors.
modules
V(G)
modules in this range are

more error prone
Roger Pressman. 413
Basis Path
Testing
1
Next, we derive the
independent paths:
2 Since V(G) = 4,
there are four paths
3 Path 1: 1,2,3,6,7,8
4
5 6
Path 2: 1,2,3,5,7,8
Path 3: 1,2,4,7,8
Path 4: 1,2,4,7,2,4,...7,8
Finally, we derive test
7 cases to exercise these
paths.
8
Roger Pressman. 414
Basis Path Testing
Notes
you don't need a flow chart,
but the picture will help when
you trace program paths
count each simple logical test,

compound tests count as 2 or
more
basis path testing should be

applied to critical modules
Roger Pressman. 415
Deriving Test Cases
 Summarizing:
 Using the design or code as a foundation, draw a
corresponding flow graph.
 Determine the cyclomatic complexity of the resultant
flow graph.
 Determine a basis set of linearly independent paths.
 Prepare test cases that will force execution of each
path in the basis set.

Roger Pressman. 416
Loop Testing
Simple
loop
Nested
Loops
Concatenated
Loops Unstructured
Loops
Roger Pressman. 417
Loop Testing: Simple
Loops
Minimum conditions—Simple Loops
1. skip the loop entirely
2. only one pass through the loop
3. two passes through the loop
4. m passes through the loop m < n
5. (n-1), n, and (n+1) passes through
the loop
where n is the maximum number
of allowable passes
Roger Pressman. 418
Loop Testing: Nested
Loops
Nested Loops
Start at the innermost loop. Set all outer loops to their
minimum iteration parameter values.
Test the min+1, typical, max-1 and max for the
innermost loop, while holding the outer loops at their
minimum values.
Move out one loop and set it up as in step 2, holding all
other loops at typical values. Continue this step until
the outermost loop has been tested.
Concatenated Loops
If the loops are independent of one another
then treat each as a simple loop
else* treat as nested loops
endif*
for example, the final loop counter value of loop 1 is
used
These slides are totoinitialize
designed loopEngineering:
accompany Software 2. A
Roger Pressman. 419
Black-Box Testing
requirements
output
input events
Roger Pressman. 420
Black-Box
Testing
 How is functional validity tested?
 How is system behavior and performance
tested?
 What classes of input will make good test
cases?
 Is the system particularly sensitive to
certain input values?
 How are the boundaries of a data class
isolated?
 What data rates and data volume can the
system tolerate?
 What effect will specific combinations of
data have on system operation?
Roger Pressman. 421
Graph-Based Methods
To understand the
objects that are object
#1
Directed link object
#2
(link weight)
modeled in
software and the Undirected link
Node weight
(value
relationships that Parallel links
)
connect these object
#
objects 3
(a)
In this context, we
consider the term new menu select generates document
“objects” in the file (generation time  1.0 sec) window
broadest possible allows editing

context. It encompasses is represented as of Attributes:
data objects, traditional contains
components (modules), document background color: white
text color: default color
and objectoriented tex
t or preferences
elements of computer
(b)
software.
Roger Pressman. 422
Comparison Testing
 Used only in situations in which the
reliability of software is absolutely
critical (e.g., human-rated systems)
 Separate software engineering teams
develop independent versions of an
application using the same specification
 Each version can be tested with the same
test data to ensure that all provide
identical output
 Then all versions are executed in parallel
with real-time comparison of results to
ensure consistency
Roger Pressman. 423
Orthogonal Array
Testing
 Used when the number of input
parameters is small and the values
that each of the parameters may
take are clearly bounded
Z Z
Y Y
X X
One input item at a time L9 orthogonal array

Roger Pressman. 424
Model-Based Testing
 Analyze an existing behavioral model for the software
or create one.
 Recall that a behavioral model indicates how software will
respond to external events or stimuli.
 Traverse the behavioral model and specify the inputs
that will force the software to make the transition from
state to state.
 The inputs will trigger events that will cause the transition
to occur.
 Review the behavioral model and note the expected
outputs as the software makes the transition from state
to state.
 Execute the test cases.
 Compare actual and expected results and take corrective
action as required.
Roger Pressman. 425
Software Testing
Patterns
 Testing patterns are described in much the
same way as design patterns (Chapter 12).
 Example:
• Pattern name: ScenarioTesting
• Abstract: Once unit and integration tests have been
conducted, there is a need to determine whether the
software will perform in a manner that satisfies users.
The ScenarioTesting pattern describes a technique for
exercising the software from the user’s point of view. A
failure at this level indicates that the software has
failed to meet a user visible requirement. [Kan01]

Roger Pressman. 426
Chapter 19
 Testing Object-Oriented Applications
Approach, 7/e

use.

Roger Pressman. 427
OO Testing
 To adequately test OO systems, three things
must be done:
 the definition of testing must be broadened to
include error discovery techniques applied to object-
oriented analysis and design models
 the strategy for unit and integration testing must
change significantly, and
 the design of test cases must account for the unique
characteristics of OO software.

Roger Pressman. 428
‘Testing’ OO Models
 The review of OO analysis and design models
is especially useful because the same semantic
constructs (e.g., classes, attributes, operations,
messages) appear at the analysis, design, and
code level
 Therefore, a problem in the definition of class
attributes that is uncovered during analysis
will circumvent side affects that might occur if
the problem were not discovered until design
or code (or even the next iteration of analysis).

Roger Pressman. 429
Correctness of OO
Models
 During analysis and design, semantic correctness can be
asesssed based on the model’s conformance to the real
world problem domain.
 If the model accurately reflects the real world (to a level
of detail that is appropriate to the stage of development
at which the model is reviewed) then it is semantically
correct.
 To determine whether the model does, in fact, reflect
real world requirements, it should be presented to
problem domain experts who will examine the class
definitions and hierarchy for omissions and ambiguity.
 Class relationships (instance connections) are evaluated
to determine whether they accurately reflect real-world
object connections.
Roger Pressman. 430
Class Model
Consistency
 Revisit the CRC model and the object-relationship
model.
 Inspect the description of each CRC index card to
determine if a delegated responsibility is part of the
collaborator’s definition.
 Invert the connection to ensure that each collaborator
that is asked for service is receiving requests from a
reasonable source.
 Using the inverted connections examined in the
preceding step, determine whether other classes might
be required or whether responsibilities are properly
grouped among the classes.
 Determine whether widely requested responsibilities
might be combined into a single responsibility.
Roger Pressman. 431
OO Testing Strategies
 Unit testing
 the concept of the unit changes
 the smallest testable unit is the encapsulated class
 a single operation can no longer be tested in isolation (the
conventional view of unit testing) but rather, as part of a
class
 Integration Testing
 Thread-based testing integrates the set of classes required to respond
to one input or event for the system
 Use-based testing begins the construction of the system by testing
those classes (called independent classes) that use very few (if any)
of server classes. After the independent classes are tested, the next
layer of classes, called dependent classes
 Cluster testing [McG94] defines a cluster of collaborating classes
(determined by examining the CRC and object-relationship model)
is exercised by designing test cases that attempt to uncover errors
in the collaborations.
Roger Pressman. 432
OO Testing Strategies
 Validation Testing
 details of class connections disappear
 draw upon use cases (Chapters 5 and 6) that are part
of the requirements model
 Conventional black-box testing methods (Chapter
18) can be used to drive validation tests

Roger Pressman. 433
OOT
Methods
Berard [Ber93] proposes the following approach:
1. Each test case should be uniquely identified and should be

explicitly associated with the class to be tested,
2. The purpose of the test should be stated,
3. A list of testing steps should be developed for each test
and should contain [BER94]:
a. a list of specified states for the object that is to be
tested
b. a list of messages and operations that will be
exercised as a consequence of the test
c. a list of exceptions that may occur as the object is
tested
d. a list of external conditions (i.e., changes in the
environment external to the software that must
exist in order to properly conduct the test)
e. supplementary information that will aid in
understanding or implementing the test.
Roger Pressman. 434
Testing Methods
 Fault-based testing
 The tester looks for plausible faults (i.e., aspects of
the implementation of the system that may result in
defects). To determine whether these faults exist, test
cases are designed to exercise the design or code.
 Class Testing and the Class Hierarchy
 Inheritance does not obviate the need for thorough
testing of all derived classes. In fact, it can actually
complicate the testing process.
 Scenario-Based Test Design
 Scenario-based testing concentrates on what the
user does, not what the product does. This means
capturing the tasks (via use-cases) that the user has
to perform, then applying them and their variants as
tests.

Roger Pressman. 435
OOT Methods: Random
Testing
 Random testing
 identify operations applicable to a class
 define constraints on their use
 identify a minimum test sequence
• an operation sequence that defines the
minimum life history of the class (object)
 generate a variety of random (but valid) test
sequences
• exercise other (more complex) class instance
life histories

Roger Pressman. 436
OOT Methods: Partition
Testing
Partition Testing

 reduces the number of test cases required to test
a class in much the same way as equivalence
partitioning for conventional software
 state-based partitioning
• categorize and test operations based on their ability
to change the state of a class
 attribute-based partitioning
• categorize and test operations based on the
attributes that they use
 category-based partitioning
• categorize and test operations based on the generic
function each performs

Roger Pressman. 437
OOT Methods: Inter-Class
Testing
 Inter-class testing
 For each client class, use the list of class
operators to generate a series of random test
sequences. The operators will send messages
to other server classes.
 For each message that is generated,
determine the collaborator class and the
corresponding operator in the server object.
 For each operator in the server object (that
has been invoked by messages sent from the
client object), determine the messages that it
transmits.
 For each of the messages, determine the next
level of operators that are invoked and
incorporate these into the test sequence

Roger Pressman. 438
OOT Methods: Behavior
Testing
The tests to be empty set up
designed should open acct setupAccnt acct
achieve all state deposit
coverage [KIR94]. (initial)
That is, the deposit
operation
sequences should working
acct
cause the balance
credit withdraw
Account class to accntInfo
make transition withdrawal
through all (final)
allowable states dead nonworking

acct close acct
Figure 14.3 State diagram for Account class (adapted from [ KIR94])

Roger Pressman. 439

Software Engineering A Practitioner's Approach - Roger S. Pressman

Uploaded by

Document Information

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

Software Engineering A Practitioner's Approach - Roger S. Pressman

Uploaded by

Copyright:

Available Formats

Chapter 1

 Software & Software Engineering

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

For non-profit educational use only

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

 Software for nanotechnologies

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

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

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

These slides are designed to accompany Software Engineering: A

Roger Pressman. navigate your way through

These slides are designed to accompany Software Engineering: A

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

For non-profit educational use only

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

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

These slides are designed to accompany Software Engineering: A

These slides are designed to accompany Software Engineering: A

represents the state

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

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

For non-profit educational use only

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

These slides are designed to accompany Software Engineering: A

 Agile team assesses each story and

 After the first increment “project velocity”

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 slidesDSDM Life Cycle

Scrum Process Flow (used with permission)

These slides are designed to accompany Software Engineering: A

These slides are designed to accompany Software Engineering: A

Reprinted with permission of Peter Coad

These slides are designed to accompany Software Engineering: A

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

For non-profit educational use only

These slides are designed to accompany Software Engineering: A

These slides are designed to accompany Software Engineering: A