CH 06

Software Engineering: A Practitioner’s Approach, 6/e
Chapter 6
System Engineering
copyright © 1996, 2001, 2005
R.S. Pressman & Associates, Inc.
For University Use Only

May be reproduced ONLY for student use at the university level
when used in conjunction with 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
System … Wazzat?
 A set or arrangement of things related to
form a unity or organic whole
 A set of facts, rules, principles, etc…
classified and arranged to show a logical
plan linking the various parts
 A method or plan of classification or
arrangement
 An established method of doing
something; method; procedure
ComputerBased System
 A set or arrangement of elements
organized in order to accomplish some
predefined goal by processing
information
System Engineering
 Elements of a computerbased system
 Software
 Hardware
 People
 Database
 Documentation
 Procedures
 Systems
 A hierarchy of macroelements
The Hierarchy
Business or
Product Domain
World view
Domain of interest
Domain view
System element
Element view
Detailed view
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.
System Modeling
 Restraining factors:
 ASSUMPTIONS reduce the number of possible
permutations or variations
 SIMPLIFICATIONS enable to create a model in a timely
fashion
 LIMITATIONS help to bound the system
 CONSTRAINTS guide the manners in which a model is
created and approaches taken when implementing the
model
 PREFERENCES indicate preferred architecture for all data,
functions and technology. May clash with other restraining
factors
System Simulation
 Used to verify and validate models before implementing
them
 Helps eliminating surprises during implementation
 Allows system engineers to “test drive” the specifications
of a system
System Engineering
 Two variants exist:
 Business Process Engineering
 Product Engineering
Business Process Engineering
❏ Uses an integrated set of procedures,
methods, and tools to identify how
information systems can best meet the
strategic goals of an enterprise
❏ Focuses first on the enterprise and then on
the business area
❏ Creates enterprise models, data models and
process models
❏ Creates a framework for better information
management distribution, and control
System Architectures
 Three different architectures must be analyzed and designed
within the context of business objectives and goals:
 Data architecture provides a framework for the information
needs of a business or business function
 Application architecture encompasses those elements of a
system that transform objects within the data architecture for
some business purpose
 Technology infrastructure provides the foundation for the
data and application architectures
The BPE Hierarchy
 Information strategy planning (ISP)
❏ strategic goals defined
❏ success factors/business rules identified
❏ enterprise model created
 Business area analysis (BAA)
❏ processes/services modeled
❏ interrelationships of processes and data
 Application Engineering
❏ a.k.a ... software engineering
❏ modeling applications/procedures that
address (BAA) and constraints of ISP
 Construction and delivery
❏ using CASE and 4GTs, testing
Information Strategy Planning
 Management issues
❏ Define strategic business goals/objectives
❏ Isolate critical success factors
❏ Conduct analysis of technology impact
❏ Perform analysis of strategic systems
 Technical issues
❏ Create a toplevel data model
❏ Cluster by business/organizational area
❏ Refine model and clustering
Defining Objectives and Goals
 Objective—general statement of direction
 Goal—defines measurable objective: “reduce
manufactured cost of our product”
❏ Subgoals:
➪ decrease reject rate by 20% in first 6 months
➪ gain 10% price concessions from suppliers
➪ reengineer 30% of components for ease of manufacture
during first year
 Objectives tend to be strategic while goals tend
to be tactical
Business Area Analysis
 Define “naturally cohesive groupings of business
functions and data” (Martin)
 Perform many of the same activities as ISP, but
narrow scope to individual business area
 Identify existing (old) information systems /
determine compatibility with new ISP model
❏ Define systems that are problematic
❏ Defining systems that are incompatible with new
information model
❏ Begin to establish reengineering priorities
The BAA Process
admin.
manufacturing
sales QC distribution
acct eng’ring
Process
Decomposition Matrices
Process Diagram e.g.,
Flow Data entity/process
Models Model matrix
Product Engineering
The complete
product System analysis
(World view)
capabilities
hardware software Component

engineering
(Domain view)
Processing requirement
data function behavior

Analysis & Design
Modeling
(Element view)
program
component Software
Engineering
Construction
&
Integration
(Detailed view)
Product Architecture Template
(after HatleyPirbhai)
user interface processing
input process and control output

processing functions processing
maintenance and selftest
Architecture Flow Diagram
operator
interface operator requests operator CLSS queries, reports, displays
interface
subsystem
bar code acquisition request
shunt control status
sorting reports
CLSS processing & control report timing/location data

requests
part shunt shunt

bar code bar code number control controller
reader decoding subsystem
subsystem subsystem
raw bar bin
code data shunt commands
location
bar code
data base
access
subsystem report CLSS reports
line
sensor data speed key formating
acquisition subsystem
subsystem sort records
mainframe
communications
BCR status driver
diagnostics shunt status
pulse tach input sensor status
subsystem formated
communications status reporting data
data acquisition bar code
interface reader status diagnostic interface output interface
System Modeling with UML
 Deployment diagrams
 Each 3D box depicts a hardware element that is part of
the physical architecture of the system
 Activity diagrams
 Represent procedural aspects of a system element
 Class diagrams
 Represent system level elements in terms of the data that
describe the element and the operations that manipulate
the data
These and other UML models will be discussed later
Deployment Diagram
CLSS processor
Sorting subsystem Operator display
Sensor data
shunt controller
acquisition subsystem
Conveyor Bar code reader Shunt actuator

Pulse tach
Activity Diagram
st art c onveyor line
read bar c ode get c onveyor speed
valid bar code invalid bar code
det ermine bin loc at ion set f or rejec t bin
send shunt
c ont rol dat a
get shunt st at us read bar c ode get c onveyor st at us
produc e report ent ry
conveyor stopped conveyor in motion
Class Diagram
class name
Box
attributes
barcode note use of capital
forwardSpeed letter for multi-word
conveyorLocation attribute names
height
width
depth
weight
contents
operations
(parentheses at end
readBarcode() of name indicate the
updateSpeed() list of attributes that the
readSpeed() operation requires)
updateLocation()
readLocation()
getDimensions()
getWeight()
checkContents()

CH 06

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CH 06

Uploaded by

Copyright:

Available Formats

Software Engineering: A Practitioner’s Approach, 6/e

For University Use Only

hardware software Component

data function behavior

input process and control output

CLSS processing & control report timing/location data

part shunt shunt

Sorting subsystem Operator display

Conveyor Bar code reader Shunt actuator

read bar c ode get c onveyor speed

valid bar code invalid bar code

det ermine bin loc at ion set f or rejec t bin

get shunt st at us read bar c ode get c onveyor st at us

produc e report ent ry

conveyor stopped conveyor in motion

You might also like