Professional Documents
Culture Documents
All copyright information MUST appear if these slides are posted on a website for student
use.
change
actual curve
idealized curve
Time
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 4
Software
Applications
system software
application software
engineering/scientific
software
embedded software
product-line software
WebApps (Web
applications)
AI software
methods
process model
a “quality” focus
Software Engineering
All copyright information MUST appear if these slides are posted on a website for student
use.
delivery of
increment # 2 nth increment
Communi c at ion
Planning
Modeling
analys is C o n s t ru c t i o n
des ign code 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 # 1 2nd increment
Co mmuni c at io n
Planni ng
M odel ing
analys is C o n s t ru c t i o n
des ign c ode
delivery of
De p l o y m e n t
t es t d e l i v e ry
fe edbac k
1st increment
projectEngineering:
These slides are designed to accompany Software calendar time
A
Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by
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
communication
modeling
analysis
design
start
deployment
construction
delivery
code
feedback test
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by
Roger Pressman. 37
Evolutionary Models:
Concurrent
none
Modeling activity
Awaiting
changes
Under review
Under
revision
Baselined
Done
Inception
inception
construction
Release
transition
software increment
production
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by
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
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
All copyright information MUST appear if these slides are posted on a website for student
use.
refactoring
pair
programming
Release
software increment unit test
project velocity computed continuous integration
acceptance testing
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by
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
Release
software increment
adjustments for subsequent cycles
components implemented/ tested
focus groups for feedback
formal technical reviews
postmortems
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill, 2009) Slides copyright 2009 by
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.
All copyright information MUST appear if these slides are posted on a website for student
use.
All copyright information MUST appear if these slides are posted on a website for student
use.
Make lists of
functions, classes
Make lists of
constraints, etc.
formal prioritization?
Elic it requirements
yes no
draw use-case
write scenario
diagram
Create Use-cases
complete template
homeowner
Responds to
alarm event
Encounters an
error condition
Sensor
name/id
type
location
area
characteristics
identify()
enable()
disable()
reconfigure()
Entry/subsystems ready
Do: poll user input panel
Do: read user input
Do: interpret user input State activities
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. 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
Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by
Roger Pressman. 104
A Bridge
system
description
analysis
model
design
model
Access camera
surveillance via the cameras
Internet
Configure SafeHome
system parameters
homeowner
Set alarm
case by providing a
and user ID
flow of interaction
other f unctions
may also be
selected
input tries remain
within a specific
select surveillance
no input
tries remain
select specific
select camera icon
camera - thumbnails
prompt for
another view
specific use-case) or
may also be
selected
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
exit t his
f unct io n
see
ano t her
camera
(0, m)
object1 relationship object 2
(1, 1)
attribute
Another common form:
object1 relationship
object 2
(0, m) (1, 1)
(1,i)
materials lists
1 1 1
DisplayWindow Camera
<<access>>
{password}
Environment
+Tree
+Landscape
+Road
+Wall
+Bridge
+Building RulesOfTheGame
+VisualEffect
+Scene +RulesOfMovement
+ConstraintsOnAction
Characters
+Player
+Protagonist
+Antagonist
+SupportingRole
All copyright information MUST appear if these slides are posted on a website for student
These slides use.
are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
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.
computer
input based output
system
process
data flow
data store
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 147
External Entity
A producer or consumer of data
base
compute
triangle area
height area
sensor #
sensor #, type,
look-up location, age
sensor
report required data
type,
location, age
sensor number
sensor data
a c p2
p1
f
p4 b
d 5
p3 e g
level 1
PSPEC
narrative
pseudocode (PDL)
equations
tables
diagrams and/or charts
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 158
DFDs: A Look Ahead
analysis model
Maps into
design model
activation tables
password = incorrect
& numberOfTries < maxTries
select ing
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
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 166
Sequence Diagram
system reading
A
ready
password entered
request lookup
comparing
result
password = correct
numberOfTries > maxTries request activation
locked
selecting
Photograph
partNumber
TechDescription
partName
component Schematic
partType
Video
description
price
WholesalePrice
RetailPrice
new customer
desc ribes
room*
plac es room
in f loor plan
add to BoM
customization complete
select e-commerce (purchase) 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
lineCost =
price x quant ity
invoke
determineDiscount
discount>0
t otalCost=
totalCost - discount
discount <= 0
t axTotal=
totalCost x taxrate
priceTotal =
totalCost +taxTotal
+shippingCost
All copyright information MUST appear if these slides are posted on a website for student
use.
control
panel target system: surveillance
Security Function function
uses
homeowner peers
uses
uses
sensors sensors
communicates with
Node
Detector Indicator
SafeHome
Executive
Function
selection
External
Communication
Management
GUI Internet
Interface
External
Communication
Management
Security
GUI Internet
Interface
Keypad
processing phone
scheduler
communication
CP display
funct ions
alarm
sensor
sensor
sensor
sensor
sensor
sensor
sensor
sensor
sensor
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by
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.
architectural design
Program
Architecture
function 2
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by
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
Transform flow
This edition of
SEPA does not
cover transaction
mapping. For a
detailed
discussion see the
SEPA website
Transaction
flow
x1 "Transform" mapping
x2 x3 x4
b c d e f g i
a h j
All copyright information MUST appear if these slides are posted on a website for student
use.
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
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
1: buildJob (WOnumber)
2: submitJob (WOnumber)
:WorkOrder
:JobQueue
PrintJ ob
initiateJ ob
WorkOrder
submitJ ob
J obQueue
appropriate attributes
checkPriority ()
accessPaperDB (weight)
returns baseCostperPage
paperCostperPage =
baseCostperPage
size = B paperCostperPage =
paperCostperPage *1 .2
size = C paperCostperPage =
paperCostperPage *1 .4
size = D paperCostperPage =
paperCostperPage *1 .6
color is custom
paperCostperPage =
paperCostperPage *1 .1 4
color is standard
returns
( paperCostperPage )
t
state buildingJ obData
dataInputIncomplete
buildingJ obData
computingJ obCost
entry/ computeJ ob
exit/ save totalJ obCost
formingJ ob
entry/ buildJ ob
exit/ save WOnumber
do/
submittingJ ob
entry/ submitJ ob
exit/initiateJ ob
do/ place on J obQueue
walk to door;
reach for knob;
x1
b x2 c
x3 d
f e
x4
x5
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
easier to maintain
easy to review
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by
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 ...
Practitioner’s Approach, 7/e (McGraw-Hill, 2009). Slides copyright 2009 by
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.
Reusable
Domain Software
Analysis Architecture Artifact
Development Development
Repository
Domain Structural Reusable
model Model Artifacts/
Components
Software Engineering
System Specification
& Construction
Analysis
User Design
Requirements
Analysis
System Application
& Design
Spec Models
Software
Client
Dynamic ORB
Invocation IDL interface
Stubs
Server
LAN
Objects
ORB Core
All copyright information MUST appear if these slides are posted on a website for student
use.
Easy to learn?
Easy to use?
Easy to understand?
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
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
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
objective #5
graphic
objective #n
Navigation
menu
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
All copyright information MUST appear if these slides are posted on a website for student
use.
All copyright information MUST appear if these slides are posted on a website for student
use.
Interface
design
Aesthetic design
Content design
Navigation design
Architecture design
Component design
technology
partNumber
partName
partType 1 is part of
description
price
createNewItem () 1
displayDescription ( ) CompDescription
display TechSpec
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
Network
structure Hierarchical
structure
All copyright information MUST appear if these slides are posted on a website for student
use.
All copyright information MUST appear if these slides are posted on a website for student
use.
Defects Detection
Errors from Errors passed through
Previous step Percent Errors passed
Amplified errors 1:x Efficiency To next step
Development step
with reviews
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
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.
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.
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 360
Chapter 16
Software Quality Assurance
Slide Set to accompany
Software Engineering: A Practitioner’s
Approach, 7/e
by Roger S. Pressman
All copyright information MUST appear if these slides are posted on a website for student
use.
measurement
All copyright information MUST appear if these slides are posted on a website for student
use.
requirements conformance
performance
an indication
of quality
Analysis modeling
Design modeling
Integration test
Validation test
System test
module
to be
tested
results
software
engineer test cases
test cases
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 383
Unit Test
Environment
driver
interface
local data structures
stub stub
test cases
RESULTS
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 384
Integration Testing
Strategies
• Bottom-up testing
• Sandwich testing
B F G
B F G
cluster
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 387
Sandwich Testing
A
Top modules are
tested with stubs
B F G
cluster
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
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.
time required
to diagnose the
symptom and
time required determine the
to correct the error cause
and conduct
regression tests
catastrophic
extreme
serious
disturbing
annoying
mild
Bug Type
All copyright information MUST appear if these slides are posted on a website for student
use.
CONSTRAINT
with a minimum of effort and time
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
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!!
to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 407
Selective Testing
Selected path
loop < 20 X
white- black-
box box
methods
methods
Methods
Strategies
or
modules
V(G)
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
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 414
Basis Path Testing
Notes
you don't need a flow chart,
but the picture will help when
you trace program paths
Simple
loop
Nested
Loops
Concatenated
Loops Unstructured
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
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
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
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
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
Roger Pressman. 419
Black-Box Testing
requirements
output
input events
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
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?
These slides are designed to accompany Software Engineering: A
Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by
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
Z Z
Y Y
X X
One input item at a time L9 orthogonal array
All copyright information MUST appear if these slides are posted on a website for student
use.
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)
Figure 14.3 State diagram for Account class (adapted from [ KIR94])