Transcript Transparency Masters for Software Engineering: A

Preview Slides
for
Software Engineering:
A Practitioner's Approach, 6/e
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.
For review purposes ONLY by potential adopters of
Software Engineering: A Practitioner's Approach.
Any other reproduction or use is expressly prohibited.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
1
Preview
Over 720 slides have been prepared to supplement lectures
associated with the use of Software Engineering: A Practitioner’s
Approach, 6/e (SEPA, 6/e).
This small collection of preview slides has been excerpted from the
complete set to provide you with an indication of the general look
and feel of SEPA, 6/e slides. All slides are available in Microsoft
Powerpoint (.ppt) format.
The complete set of slides may be downloaded at no cost by
adopters of SEPA, 6/e. Contact your McGraw-Hill sales
representative for appropriate information.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
2
Software’s Dual Role

Software is a product



Delivers computing potential
Produces, manages, acquires, modifies, displays, or transmits
information
Software is a vehicle for delivering a product




Supports or directly provides system functionality
Controls other programs (e.g., an operating system)
Effects communications (e.g., networking software)
Helps build other software (e.g., software tools)
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
3
Wear vs. Deterioration
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
4
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.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
5
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 navigate your way through
software engineering

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
6
A Layered Technology
Software Engineering
tools
methods
process model
a “quality” focus
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
7
A Process Framework
Process framework
Framework activities
work tasks
work products
milestones & deliverables
QA checkpoints
Umbrella Activities
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
8
Framework Activities



Communication
Planning
Modeling



Construction



Analysis of requirements
Design
Code generation
Testing
Deployment
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
9
Umbrella Activities








Software project management
Formal technical reviews
Software quality assurance
Software configuration management
Work product preparation and production
Reusability management
Measurement
Risk management
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
10
The CMMI



The CMMI defines each process area in terms of
“specific goals” and the “specific practices” required to
achieve these goals.
Specific goals establish the characteristics that must
exist if the activities implied by a process area are to be
effective.
Specific practices refine a goal into a set of processrelated activities.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
11
Process Patterns



Process patterns define a set of activities, actions, work
tasks, work products and/or related behaviors
A template is used to define a pattern
Typical examples:





Customer communication (a process activity)
Analysis (an action)
Requirements gathering (a process task)
Reviewing a work product (a process task)
Design model (a work product)
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
12
Process Assessment


The process should be assessed to ensure that it meets
a set of basic process criteria that have been shown to
be essential for a successful software engineering.
Many different assessment options are available:




SCAMPI
CBA IPI
SPICE
ISO 9001:2000
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
13
Prescriptive Models
Prescriptive process models advocate an orderly approach to
software engineering
That leads to a few questions …
 If prescriptive process models strive for structure and order, are they
inappropriate for a software world that thrives on change?
 Yet, if we reject traditional process models (and the order they imply)
and replace them with something less structured, do we make it
impossible to achieve coordination and coherence in software work?

These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
14
The Waterfall Model
Com m unic a t ion
proje c t init ia t ion
re quire m e nt ga t he ring
Planning
estimat ing
scheduling
tracking
Mode ling
analysis
design
Const r uc t ion
code
t est
De ploy m e nt
de liv e ry
s upport
f e e dba c k
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
15
The RAD Model
Team # n
M o d e lin g
bus ines s m odeling
dat a m odeling
proc ess m odeling
C o n s t r u c t io n
c om ponent reus e
aut om at ic c ode
generat ion
t est ing
Team # 2
Com m unicat ion
Mo d eling
b u si n e ss m o d e l i n g
dat a m odeling
p ro ce ss m o d e l i n g
Planning
Co nst r uct io n
Team # 1
co m p o n e n t re u se
a u t o m a t i c co d e
g e n e ra t i o n
t e st i n g
Mode ling
De ploym e nt
int egrat ion
deliv ery
feedback
business modeling
dat a modeling
process modeling
Const r uct ion
component reuse
aut omat ic code
generat ion
t est ing
6 0 - 9 0 days
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
16
Evolutionary Models: Prototyping
Qu ick
p l an
Quick
Com m unicat ion
plan
communication
Mo
d e lin g
Modeling
Qu ick d e sig n
Quick design
Deployment
Deployment
De live r y
delivery &
& Fe e dback
feedback
Const r uct ion
Construction
of
ofot
prototype
pr
ot ype
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
17
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
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
18
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
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
19
Extreme Programming (XP)
simple design
CRC cards
spike solut ions
prot ot ypes
user st ories
values
accept ance t est crit eria
it erat ion plan
ref act oring
pair
programming
Release
sof t ware increment
project v elocit y comput ed
unit t est
cont inuous int egrat ion
These courseware materials are to be used in conjunction
withance
Software
A Practitioner’s Approach, 6/e and are provided
accept
t estEngineering:
ing
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
20
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
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
21
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
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
22
What is “Practice”?


Practice is a broad array of concepts, principles,
methods, and tools that you must consider as software is
planned and developed.
It represents the details—the technical considerations
and how to’s—that are below the surface of the software
process—the things that you’ll need to actually build
high-quality computer software.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
23
The Essence of Practice

George Polya, in a book written in 1945 (!), describes the
essence of software engineering practice …





Understand the problem (communication and analysis).
Plan a solution (modeling and software design).
Carry out the plan (code generation).
Examine the result for accuracy (testing and quality assurance).
At its core, good practice is common-sense problem
solving
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
24
Core Software Engineering
Principles







Provide value to the customer and the user
KIS—keep it simple!
Maintain the product and project “vision”
What you produce, others will consume
Be open to the future
Plan ahead for reuse
Think!
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
25
Software Engineering
Practices

Consider the generic process framework






Communication
Planning
Modeling
Construction
Deployment
Here, we’ll identify



Underlying principles
How to initiate the practice
An abbreviated task set
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
26
System Engineering

Elements of a computer-based system







Software
Hardware
People
Database
Documentation
Procedures
Systems

A hierarchy of macro-elements
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
27
The Hierarchy
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
28
System Modeling



define the processes that serve the needs of the view under consideration.
represent the behavior of the processes and the assumptions on which the
behavior is based.
explicitly define both exogenous and endogenous input to the model.


exogenous inputs link one constituent of a given view with other constituents at
the same level of other levels; endogenous input links individual components of a
constituent at a particular view.
represent all linkages (including output) that will enable the engineer to
better understand the view.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
29
Requirements Engineering-II

Specification—can be any one (or more) of the following:






Validation—a review mechanism that looks for






A written document
A set of models
A formal mathematical
A collection of user scenarios (use-cases)
A prototype
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
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
30
Eliciting Requirements
Conduct FA ST
m eet ings
Make list s of
f unc t ions , c las s es
Mak e lis t s of
c onst raint s , et c.
f orm al priorit izat ion?
El i c i t re q u i re m e n t s
no
y es
Use QFD t o
priorit ize
requirem ent s
def ine act ors
inf orm ally
priorit iz e
requirem ent s
draw use-c as e
diagram
writ e sc enario
Creat e Us e-cas es
c om plet e t em plat e
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
31
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 the actor wish to be informed about unexpected changes?
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
32
Use-Case Diagram
Arms/ disarms
syst em
Accesses syst em
via Int ernet
sensors
homeow ner
Responds t o
alarm event
Encount ers an
error condit ion
syst em
administ rat or
Reconf igures sensors
and relat ed
syst em f eat ures
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
33
Building the Analysis Model

Elements of the analysis model

Scenario-based elements



Class-based elements


Implied by scenarios
Behavioral elements


Functional—processing narratives for software functions
Use-case—descriptions of the interaction between an
“actor” and the system
State diagram
Flow-oriented elements

Data flow diagram
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
34
Class Diagram
From the SafeHome system …
Sensor
name/ id
ty pe
locat ion
area
characterist ics
ident if y()
enable()
disable()
reconf igure()
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
35
State Diagram
Reading
commands
Init ializat ion
t urn copier
“on“
syst em st at us=“not ready”
display msg = “please wait ”
display st at us = blinking
subsyst ems
ready
ent ry/ swit ch machine on
do: run diagnost ics
do: init iat e all subsyst ems
not jammed
syst em st at us=“Ready”
display msg = “ent er cmd”
display st at us = st eady
paper f ull
ent ry/ subsyst ems ready
do: poll user input panel
do: read user input
do: int erpret user input
t urn copier “of f ”
st art copies
Making copies
copies complet e
syst em st at us=“Copying”
display msg= “copy count =”
display message=#copies
display st at us= st eady
ent ry/ st art copies
do: manage copying
do: monit or paper t ray
do: monit or paper f low
paper t ray empt y
paper jammed
problem diagnosis
syst em st at us=“Jammed”
display msg = “paper jam”
display message=locat ion
display st at us= blinking
load paper
syst em st at us=“load paper”
display msg= “load paper”
display st at us= blinking
ent ry/ paper empt y
do: lower paper t ray
do: monit or f ill swit ch
do: raise paper t ray
not jammed
ent ry/ paper jammed
do: det ermine locat ion
do: provide correct ivemsg.
do: int errupt making copies
Figure 7.6 Preliminary UML st at e diagram for a phot ocopier
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
36
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.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
37
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 of data as it is transformed.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
38
A Bridge
s ys te m
de s cription
analys is
m ode l
de s ign
m ode l
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
39
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 nonfunctional 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.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
40
Use-Case Diagram
Saf eHome
Access camera
surveillance via t he
Int ernet
cameras
Conf igure Saf eHome
syst em paramet ers
homeowner
Set alarm
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
41
Activity Diagram
Supplements the use-case by providing a diagrammatic
representation of procedural flow
ent er password
and user ID
valid passwor ds/ ID
invalid passwor ds/ ID
select major f unct ion
prompt f or reent ry
ot her f unct ions
m ay also be
select ed
input t r ies r em ain
select surveillance
no input
t r ies r em ain
t hum bnail views
select a specif ic cam er a
select specif ic
camera - t humbnails
select camera icon
view camera out put
in labelled window
prompt f or
anot her view
exit t his f unct ion
see anot her cam er a
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
42
Swimlane Diagrams
Allows the modeler to represent the flow of activities described by the use-case and at the
same time indicate which actor (if there are multiple actors involved in a specific use-case)
or analysis class has responsibility for the action described by an activity rectangle
homeowner
c a m e ra
i n t e rf a c e
ent er pas sword
and user ID
valid p asswo r d s/ ID
in valid
p asswo r d s/ ID
select m ajor f unc t ion
o t h er f u n ct io n s
m ay also b e
select ed
prom pt f or reent ry
in p u t t r ies
s elec t surveillance
r em ain
n o in p u t
t r ies r em ain
t h u m b n ail views
select a sp ecif ic cam er a
select specif ic
cam era - t hum bnails
select c am era icon
generat e video
out put
v iew c am era out put
in labelled window
prom pt f or
anot her view
exit t h is
f u n ct io n
see
an o t h er
cam er a
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
43
Flow-Oriented Modeling
Represents how data objects are transformed at they
move through the system
A data flow diagram (DFD) is the diagrammatic form that
is used
Considered by many to be an ‘old school’ approach, floworiented modeling continues to provide a view of the
system that is unique—it should be used to supplement
other analysis model elements
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
44
The Flow Model
Every computer-based system is an
information transform ....
input
computer
based
system
output
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
45
Class-Based Modeling




Identify analysis classes by examining the
problem statement
Use a “grammatical parse” to isolate potential
classes
Identify the attributes of each class
Identify operations that manipulate the attributes
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
46
Analysis Classes







External entities (e.g., other systems, devices, people) that produce or consume
information to be used by a computer-based system.
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 of the system.
Structures (e.g., sensors, four-wheeled vehicles, or computers) that define a class
of objects or related classes of objects.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
47
Selecting Classes—Criteria
retained information
needed services
multiple attributes
common attributes
common operations
essential requirements
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
48
Class Diagram
Class name
System
sy st emI D
v erif icat ionPhoneNumber
sy st emSt at us
delay Time
telephoneNumber
mast erPassword
temporary Password
numberTries
program()
display ()
reset ()
query ()
modif y ()
call()
attributes
operations
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
49
Class Diagram
FloorPlan
type
name
outsideDimensions
determineType ( )
positionFloorplan
scale( )
change color( )
is placed wit hin
is part of
Cam era
Wall
t y pe
ID
loc at ion
f ieldV iew
panA ngle
Zoom Set t ing
t y pe
wallDim ens ions
determineType ( )
computeDimensions ( )
det erm ineTy pe ()
t rans lat eLoc at ion ()
dis play ID()
dis play V iew()
dis play Zoom ()
is used t o build
is used t o build
is used t o build
WallSegm ent
t y pe
s t art Coordinat es
s t opCoordinat es
nex t WallSem ent
determineType ( )
draw( )
Window
Door
t y pe
s t art Coordinat es
s t opCoordinat es
nex t Window
t y pe
st art Coordinat es
st opCoordinat es
nex t Door
determineType ( )
draw( )
determineType ( )
draw( )
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
50
CRC Modeling

Analysis classes have “responsibilities”


Responsibilities are the attributes and operations encapsulated
by the class
Analysis classes collaborate with one another


Collaborators are those classes that are required to provide a
class with the information needed to complete a responsibility.
In general, a collaboration implies either a request for
information or a request for some action.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
51
Analysis Model -> Design Model
sc e n a r i o - b a se d
e l e me nt s
Co m p o n e n t L e v e l D e sig n
f l o w- o r i e n t e d
e l e me nt s
use-cases - text
use-case diagrams
activity diagrams
swim lane diagrams
data flow diagrams
control-flow diagrams
processing narratives
In t e r f a c e D e sig n
Analy sis Model
c l a ss- b a se d
e l e me nt s
class diagrams
analysis packages
CRC models
collaboration diagrams
be ha v i or a l
e l e me nt s
A r c h it e c t u r a l D e sig n
state diagrams
sequence diagrams
D a t a / Cla ss D e sig n
Design Model
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
52
Design Principles










The design process should not suffer from ‘tunnel vision.’
The design should be traceable to the analysis model.
The design should not reinvent the wheel.
The design should “minimize the intellectual distance” [DAV95] between
the software and the problem as it exists in the real world.
The design should exhibit uniformity and integration.
The design should be structured to accommodate change.
The design should be structured to degrade gently, even when aberrant
data, events, or operating conditions are encountered.
Design is not coding, coding is not design.
The design should be assessed for quality as it is being created, not after
the fact.
The design should be reviewed to minimize conceptual (semantic) errors.
From Davis [DAV95]
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
53
Fundamental Concepts








abstraction—data, procedure, control
architecture—the overall structure of the software
patterns—”conveys the essence” of a proven design solution
modularity—compartmentalization of data and function
hiding—controlled interfaces
Functional independence—single-minded function and low coupling
refinement—elaboration of detail for all abstractions
Refactoring—a reorganization technique that simplifies the design
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
54
The Design Model
high
a na ly sis m ode l
class diagrams
analysis packages
CRC models
collaborat ion diagrams
dat a f low diagrams
cont rol-f low diagrams
processing narrat ives
design class realizat ions
subsyst ems
collaborat ion diagrams
use-cases - t ext
use-case diagrams
act ivit y diagrams
sw im lane diagrams
collaborat ion diagrams
st at e diagrams
sequence diagrams
class diagrams
analysis packages
CRC models
collaborat ion diagrams
dat a f low diagrams
cont rol-f low diagrams
processing narrat ives
st at e diagrams
sequence diagrams
t echnical int erf ace
design
Navigat ion design
GUI design
component diagrams
design classes
act ivit y diagrams
sequence diagrams
de sign m ode l
ref inement s t o:
low
ref inement s t o:
design class realizat ions
subsyst ems
collaborat ion diagrams
archit ect ure
element s
component diagrams
design classes
act ivit y diagrams
sequence diagrams
int erface
element s
component -level
element s
Requirement s:
const raint s
int eroperabilit y
t arget s and
conf igurat ion
design class realizat ions
subsyst ems
collaborat ion diagrams
component diagrams
design classes
act ivit y diagrams
sequence diagrams
deployment diagrams
deployment -level
element s
process dimension
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
55
Archetypes
Cont roller
communicat es wit h
Node
Det ect or
Indicat or
Figure 10.7 UML relat ionships f or Saf eHome securit y f unct ion archet ypes
These courseware materials are to(adapt
be used
conjunction
ed f in
rom
[ BOS00] ) with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
56
Component Structure
SafeHome
Execut ive
Funct ion
select ion
Ext ernal
Communicat ion
Management
Securit y
GUI
Surveillance
Home
management
Int ernet
Int erface
Cont rol
panel
processing
det ect or
management
alarm
processing
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
57
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: 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.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
58
Cohesion

Conventional view:


OO view:


the “single-mindedness” of a module
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
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
59
Refactoring
computeJob
PrintJob
initiateJob
WorkOrder
<<interface>>
initiateJob
ap p ro p riat e at t rib u t e s
getJobDescriiption
buildWorkOrder ()
buildJob
p assJo b To Pro d u ct io n ( )
ProductionJob
submitJob
JobQueue
ap p ro p riat e at t rib u t e s
checkPriority ()
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
60
Object Constraint Language (OCL)


complements UML by allowing a software engineer to use a
formal grammar and syntax to construct unambiguous
statements about various design model elements
simplest OCL language statements are constructed in four
parts:




(1) a context that defines the limited situation in which the
statement is valid;
(2) a property that represents some characteristics of the context
(e.g., if the context is a class, a property might be an attribute)
(3) an operation (e.g., arithmetic, set-oriented) that manipulates or
qualifies a property, and
(4) keywords (e.g., if, then, else, and, or, not, implies) that are
used to specify conditional expressions.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
61
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
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
62
Swimlane Diagram
p at ien t
r e q u e st s t h at a
p r e scr ip t io n b e r e f ille d
p h armacist
p h ysician
d e t e r m in e s st at u s o f
p r e scr ip t io n
no ref ills
remaining
ref ills
remaining
ch e cks in v e n t o r y f o r
r e f ill o r alt e r n at iv e
ch e cks p at ie n t
r e co r d s
approv es ref ill
ref ill not
allowed
e v alu at e s alt e r n at iv e
m e d icat io n
r e ce iv e s o u t o f st o ck
n o t if icat io n
out of st ock
alt ernat iv e
av ailable
in st ock
r e ce iv e s t im e / d at e
none
t o p ick u p
p icks u p
p r e scr ip t io n
f ills
p r e scr ip t io n
r e ce iv e s r e q u e st t o
co n t act p h y sician
Fig u re 1 2 .2 Sw imlan e d iag ram fo r p rescrip t io n refill fu n ct io n
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
63
Interface Design Patterns

Patterns are available for









The complete UI
Page layout
Forms and input
Tables
Direct data manipulation
Navigation
Searching
Page elements
e-Commerce
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
64
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
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
65
Strategic Issues







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 formal technical reviews as a filter prior to testing
Conduct formal technical reviews to assess the test strategy and test cases
themselves.
Develop a continuous improvement approach for the testing process.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
66
Testability







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
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
67
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 this program!!
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
68
Boundary Value Analysis
user
queries
mouse
picks
FK
input
output
formats
prompts
input domain
data
output
domain
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
69
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


attribute-based partitioning


categorize and test operations based on their ability to change
the state of a class
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
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
70
Measures, Metrics and Indicators



A measure provides a quantitative indication of the
extent, amount, dimension, capacity, or size of some
attribute of a product or process
The IEEE glossary defines a metric as “a quantitative
measure of the degree to which a system, component, or
process possesses a given attribute.”
An indicator is a metric or combination of metrics that
provide insight into the software process, a software
project, or the product itself
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
71
Measurement Principles




The objectives of measurement should be established before
data collection begins;
Each technical metric should be defined in an unambiguous
manner;
Metrics should be derived based on a theory that is valid for the
domain of application (e.g., metrics for design should draw upon
basic design concepts and principles and attempt to provide an
indication of the presence of an attribute that is deemed
desirable);
Metrics should be tailored to best accommodate specific products
and processes [BAS84]
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
72
Goal-Oriented Software Measurement

The Goal/Question/Metric Paradigm




(1) establish an explicit measurement goal that is specific to the process
activity or product characteristic that is to be assessed
(2) define a set of questions that must be answered in order to achieve the
goal, and
(3) identify well-formulated metrics that help to answer these questions.
Goal definition template





Analyze {the name of activity or attribute to be measured}
for the purpose of {the overall objective of the analysis}
with respect to {the aspect of the activity or attribute that is considered}
from the viewpoint of {the people who have an interest in the measurement}
in the context of {the environment in which the measurement takes place}.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
73
Web Engineering
“Web development is an adolescent … Like most
adolescents, it wants to be accepted as an adult
as it tries to pull away from its parents. If it is
going to reach its full potential, it must take a few
lessons from the more seasoned world of
software development.”
Doug Wallace et al
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
74
The WebE Process
accept ance t est
cust omer use
cust omer evaluat ion
coding
component t est
Release
sof t war e incr ement
refact oring
design model
analysis model
business analysis
formulat ion
it erat ion plan
cont ent
it erat ion
f unct ion
conf igurat ion
cont ent
archit ect ure
navigat ion
int erf ace
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
75
The WebE Process Framework—II

Modeling

Analysis model—establishes a basis for design





Content Analysis.
Interaction Analysis.
Functional Analysis.
Configuration Analysis.
Design model—represents key WebApp elements






Content design
Aesthetic design
Architectural design
Interface design
Navigation design
Component design
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
76
The WebE Process Framework—III

Construction



WebE tools and technology are applied to construct the WebApp
that has been modeled
Testing of all design elements
Delivery and Evaluation (Deployment)




configure for its operational environment
deliver to end-users, and
Evaluation feedback is presented to the WebE team
the increment is modified as required (the beginning of the next
incremental cycle)
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
77
WebE—Best Practices







Take the time to understand the business needs and product objectives,
even if the details of the WebApp are vague.
Describe how users will interact with the WebApp using a scenario-based
approach
Develop a project plan, even it its very brief.
Spend some time modeling what it is that you’re going to build.
Review the models for consistency and quality.
Use tools and technology that enable you to construct the system with as
many reusable components as possible.
Don’t rely on early users to debug the WebApp—design comprehensive
tests and execute them before releasing the system.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
78
WebE Requirements Gathering




Ask stakeholders to define user categories and develop
descriptions for each category
Communicate with stakeholders to define basic WebApp
requirements
Analyze information gathered and use information to
follow-up with stakeholders
Define use-cases (Chapter 8) that describe interaction
scenarios for each user class
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
79
WebApp Planning - In-House








Understand scope, the dimensions of change, and
project constraints
Define an incremental project strategy
Perform risk analysis
Develop a quick estimate
Select a task set (process description)
Establish a schedule
Define project tracking mechanisms
Establish a change management approach
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
80
WebE “Worst Practices”





We have a great idea, so lets begin building the
WebApp—now.
Stuff will change constantly, so there’s no point in trying
to understand WebApp requirements.
Developers whose dominant experience has been in
traditional software development can develop WebApps
immediately. No new training is required.
Be bureaucratic.
Testing? Why bother?
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
81
Analysis
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 described in detail.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
82
State Diagram
Validat ing user
select “log-in”
Select ing user act ion
userid
v alidat ed
sy st em st at us=“input ready”
display msg = “ent eruserid”
display msg =“ent er pswd”
password v alidat ed
n e w cu st o m e r
ent ry / log-in request ed
do: run user v alidat ion
exit / set user access swit ch
selec t ot her f unct ions
sy st em st at us=“link ready”
display : nav igat ion choices”
ent ry / v alidat ed user
do: link as required
exit / user act ion select ed
c ust omiz at ion c omplet e
select e-c ommerc e (purc hase) f unct ionalit y
selec t cust omiz at ion f unc t ionalit y
next select ion
Cust omiz ing
select descript iv e
cont ent
sy st em st at us=“input ready ”
display : basic inst ruct ions
Def ining room
room being def ined
ent ry / v alidat ed user
do: process user select ion
exit / cust omizat ion t erminat ed
select descript ive
cont ent
Sav ing f loor plan
sy st em st at us=“input ready ”
display: st orage indicat or
ent ry / f loor plan sav e select ed
do: st ore f loor plan
exit / save complet ed
sy st em st at us=“input ready ”
display : roomdef . window
ent ry / roomdef . select ed
all rooms do: run room queries
def ined
do: st ore room v ariables
exit / room complet ed
select sav e f loor plan
select ent er room in f loor plan
Building f loor plan
select descript iv e
cont ent
sy st em st at us=“input ready ”
display: f loor plan window
ent ry / f loor plan select ed
do: insert room in place
do: st ore f loor plan v ariables
exit / room insert ion complet ed
room insert ion complet ed
Figure 1 8 .6 Part ial st at e diagram f or n e w c u s t o m eint
r eract ion
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
83
Relationship-Navigation Analysis


Relationship-navigation analysis (RNA) identifies relationships
among the elements uncovered as part of the creation of the
analysis model
Steps:





Stakeholder analysis—identifies the various user categories and
establishes an appropriate stakeholder hierarchy
Element analysis—identifies the content objects and functional
elements that are of interest to end users
Relationship analysis—describes the relationships that exist among the
WebApp elements
Navigation analysis—examines how users might access individual
elements or groups of elements
Evaluation analysis—considers pragmatic issues (e.g., cost/benefit)
associated with implementing the relationships defined earlier
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
84
WebE Design Pyramid
user
Interface
design
Aesthetic design
Content design
Navigation design
Architecture design
Component design
technol ogy
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
85
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
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
86
WebApp Design Goals

Identity


Robustness


designed in a manner that is intuitive and predictable
Visual appeal


The user expects robust content and functions that are relevant to the user’s needs
Navigability


Establish an “identity” that is appropriate for the business purpose
the look and feel of content, interface layout, color coordination, the balance of
text, graphics and other media, navigation mechanisms must appeal to endusers
Compatibility

With all appropriate environments and configurations
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
87
MVC Architecture
co n t ro ller
manages user request s
select s model behav ior
select s v iew response
behav ior request
( st at e change)
user request
or dat a
browser
v iew select ion
m o d el
encapsulat es funct ionalit y
encapsulat es cont ent object s
incorporat es all webApp st at es
client
dat a from model
HTML dat a
view
updat e request
ext ernal dat a
prepares dat a from model
request updat es from model
present s v iew select ed by
cont roller
serv er
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
88
Hypermedia Design Patterns-I


Architectural patterns.

assist in the design of content and WebApp architecture

many architectural patterns are available (e.g., Java Blueprints
at java.sun.com/blueprints/)
Component construction patterns.


recommend methods for combining WebApp components (e.g.,
content objects, functions) into composite components.
Navigation patterns.

assist in the design of NSUs, navigation links and the overall
navigation flow of the WebApp. _
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
89
Testing Quality Dimensions-I

Content is evaluated at both a syntactic and semantic level.




syntactic level—spelling, punctuation and grammar are assessed for
text-based documents.
semantic level—correctness (of information presented), consistency
(across the entire content object and related objects) and lack of
ambiguity are all assessed.
Function is tested for correctness, instability, and general
conformance to appropriate implementation standards (e.g.,Java or
XML language standards).
Structure is assessed to ensure that it



properly delivers WebApp content and function
is extensible
can be supported as new content or functionality is added.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
90
Testing Quality Dimensions-II

Usability is tested to ensure that each category of user



Navigability is tested to ensure that


is supported by the interface
can learn and apply all required navigation syntax and semantics
all navigation syntax and semantics are exercised to uncover any
navigation errors (e.g., dead links, improper links, erroneous links).
Performance is tested under a variety of operating conditions,
configurations, and loading to ensure that


the system is responsive to user interaction
the system handles extreme loading without unacceptable operational
degradation
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
91
The 4 P’s




People — the most important element of a
successful project
Product — the software to be built
Process — the set of framework activities and
software engineering tasks to get the job done
Project — all work required to make the product a
reality
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
92
Software Teams
How to lead?
How to organize?
How to collaborate?
How to motivate?
How to create good ideas?
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
93
The Project

Projects get into trouble when …










Software people don’t understand their customer’s needs.
The product scope is poorly defined.
Changes are managed poorly.
The chosen technology changes.
Business needs change [or are ill-defined].
Deadlines are unrealistic.
Users are resistant.
Sponsorship is lost [or was never properly obtained].
The project team lacks people with appropriate skills.
Managers [and practitioners] avoid best practices and lessons learned.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
94
A Good Manager Measures
process
process metrics
project metrics
measurement
product metrics
product
What do we
use as a
basis?
• size?
• function?
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
95
Project Planning Task Set-I



Establish project scope
Determine feasibility
Analyze risks


Risk analysis is considered in detail in Chapter 25.
Define required resources



Determine require human resources
Define reusable software resources
Identify environmental resources
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
96
Project Planning Task Set-II

Estimate cost and effort




Decompose the problem
Develop two or more estimates using size, function points,
process tasks or use-cases
Reconcile the estimates
Develop a project schedule

Scheduling is considered in detail in Chapter 24.




Establish a meaningful task set
Define a task network
Use scheduling tools to develop a timeline chart
Define schedule tracking mechanisms
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
97
Estimation for Agile Projects



Each user scenario (a mini-use-case) is considered separately for
estimation purposes.
The scenario is decomposed into the set of software engineering tasks that
will be required to develop it.
Each task is estimated separately. Note: estimation can be based on
historical data, an empirical model, or “experience.”


Estimates for each task are summed to create an estimate for the scenario.


Alternatively, the ‘volume’ of the scenario can be estimated in LOC, FP or some
other volume-oriented measure (e.g., use-case count).
Alternatively, the volume estimate for the scenario is translated into effort using
historical data.
The effort estimates for all scenarios that are to be implemented for a given
software increment are summed to develop the effort estimate for the
increment.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
98
Scheduling Principles






compartmentalization—define distinct tasks
interdependency—indicate task interrelationship
effort validation—be sure resources are available
defined responsibilities—people must be assigned
defined outcomes—each task must have an output
defined milestones—review for quality
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
99
Timeline Charts
Tasks
Week 1
Week 2
Week 3
Week 4
Week n
Task 1
Task 2
Task 3
Task
4
Task 5
Task 6
Task 7
Task 8
Task 9
Task 10
Task 11
Task 12
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
100
Earned Value Analysis (EVA)

Earned value



is a measure of progress
enables us to assess the “percent of completeness” of a project
using quantitative analysis rather than rely on a gut feeling
“provides accurate and reliable readings of performance from as
early as 15 percent into the project.” [FLE98]
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
101
Seven Principles







Maintain a global perspective—view software risks within the context of system and the
business problem
Take a forward-looking view—think about the risks that may arise in the future; establish
contingency plans
Encourage open communication—if someone states a potential risk, don’t discount it.
Integrate—a consideration of risk must be integrated into the software process
Emphasize a continuous process—the team must be vigilant throughout the software process,
modifying identified risks as more information is known and adding new ones as better insight is
achieved.
Develop a shared product vision—if all stakeholders share the same vision of the software, it
likely that better risk identification and assessment will occur.
Encourage teamwork—the talents, skills and knowledge of all stakeholder should be pooled
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
102
Software Quality Assurance
Process
Definition &
Standards
Formal
Technical
Reviews
Analysis
&
Reporting
Measurement
Test
Planning
& Review
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
103
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.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
104
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 welldefined 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 the process to ensure that future work does not reintroduce the causes
of defects.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
105
The SCM Process
Addresses the following questions …






How does a software team identify the discrete elements of a
software configuration?
How does an organization manage the many existing versions of a
program (and its documentation) in a manner that will enable
change to be accommodated efficiently?
How does an organization control changes before and after software
is released to a customer?
Who has responsibility for approving and ranking changes?
How can we ensure that changes have been made properly?
What mechanism is used to appraise others of changes that are
made?
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
106
Formal Methods Concepts


data invariant—a condition that is true throughout the execution
of the system that contains a collection of data
state



Many formal languages, such as OCL (Section 28.5) , use the notion
of states as they were discussed in Chapters 7 and 8, that is, a
system can be in one of several states, each representing an
externally observable mode of behavior.
The Z language (Section 28.6)defines a state as the stored data
which a system accesses and alters
operation—an action that takes place in a system and reads or
writes data to a state


precondition defines the circumstances in which a particular
operation is valid
postcondition defines what happens when an operation has
completed its action
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
107
Formal Specification

The block handler

The block handler maintains a reservoir of unused blocks and will also keep track of blocks that are currently in use. When blocks are released
from a deleted file they are normally added to a queue of blocks waiting to be added to the reservoir of unused blocks.




The state
used, free: P BLOCKS
BlockQueue: seq P BLOCKS
Data Invariant
used > free = \
used < free = AllBlocks
i: dom BlockQueue BlockQueue i # used
i, j : dom BlockQueue i ≠ j => BlockQueue i > BlockQueue j = \
Precondition
#BlockQueue > 0
Postcondition
used' = used \ head BlockQueue
free’ = free < head BlockQueue
BlockQueue' = tail BlockQueue
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
108
BlockHandler using UML
1
*
Block
BlockSet
e le m e n t s
num ber
*
*
*
fre e
b lo ckQu e u e
u se d
{ o rd e re d }
*
allBlo cks
{ su b se t }
{ su b se t }
1
1
1
BlockHandler
1
ad d Blo ck( )
re m o v e Blo ck( )
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
109
BlockHandler in OCL

No block will be marked as both unused and used.



All the sets of blocks held in the queue will be subsets of the collection of currently used blocks.








context BlockHandler inv:
allBlocks = used->union(free)
The collection of unused blocks will have no duplicate block numbers.



context BlockHandler inv:
blockQueue->forAll(blockSet1, blockSet2 |
blockSet1 <> blockSet2 implies
blockSet1.elements.number->excludesAll(blockSet2.elements.number))
The expression before implies is needed to ensure we ignore pairs where both elements are the same Block.
The collection of used blocks and blocks that are unused will be the total collection of blocks that make up files.


context BlockHandler inv:
blockQueue->forAll(aBlockSet | used->includesAll(aBlockSet ))
No elements of the queue will contain the same block numbers.


context BlockHandler inv:
(self.used->intersection(self.free)) ->isEmpty()
context BlockHandler inv:
free->isUnique(aBlock | aBlock.number)
The collection of used blocks will have no duplicate block numbers.


context BlockHandler inv:
used->isUnique(aBlock | aBlock.number)
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
110
The Cleanroom Process Model
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
111
The CBSE Process
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
112
Component-Based Development



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
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
113
Reuse Economics

Consider a new application, X, that requires 60 percent new code and the
reuse of three structure points, SP1, SP2, and SP3. Average costs for
qualification, adaptation, integration, and maintenance are available.

overall effort = Enew + Equal + Eadapt + Eint
where




Enew = effort required to engineer and construct new software components
(determined using techniques described in Chapter 23).
Equal = effort required to qualify SP1, SP2, and SP3.
Eadapt = effort required to adapt SP1, SP2, and SP3.
Eint = effort required to integrate SP1, SP2, and SP3.

The effort required to qualify, adapt, and integrate SP1, SP2, and SP3 is determined
by taking the average of historical data collected for qualification, adaptation, and
integration of the reusable components in other applications.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
114
Reengineering
Business
processes
IT
systems
Reengineering
Software
applications
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
115
Software Reengineering
Forward
engineering
Data
restructuring
code
restructuring
inventory
analysis
document
restructuring
reverse
engineering
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
116
Importance of Software-Revisited

In Chapter 1, software was characterized as a differentiator.



The function delivered by software differentiates products, systems,
and services and provides competitive advantage in the marketplace.
But software is more that a differentiator.
The programs, documents, and data that are software help to
generate the most important commodity that any individual,
business, or government can acquire—information.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
117
Software Engineering Ethics-I

An ACM/IEEE-CS Joint Task Force has produced a Software
Engineering Code of Ethics and Professional Practices
(Version 5.1). The code [ACM98] states:

Software engineers shall commit themselves to making the analysis,
specification, design, development, testing and maintenance of software
a beneficial and respected profession. In accordance with their
commitment to the health, safety and welfare of the public, software
engineers shall adhere to the following Eight Principles:
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
118
Software Engineering Ethics-I








1. PUBLIC - Software engineers shall act consistently with the public interest.
2. CLIENT AND EMPLOYER - Software engineers shall act in a manner that is in the best
interests of their client and employer consistent with the public interest.
3. PRODUCT - Software engineers shall ensure that their products and related modifications meet
the highest professional standards possible.
4. JUDGMENT - Software engineers shall maintain integrity and independence in their
professional judgment.
5. MANAGEMENT - Software engineering managers and leaders shall subscribe to and promote
an ethical approach to the management of software development and maintenance.
6. PROFESSION - Software engineers shall advance the integrity and reputation of the profession
consistent with the public interest.
7. COLLEAGUES - Software engineers shall be fair to and supportive of their colleagues.
8. SELF - Software engineers shall participate in lifelong learning regarding the practice of their
profession and shall promote an ethical approach to the practice of the profession.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided
with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
119