Transcript SE 425 - DePaul University

SE 325/425
Principles and
Practices of Software
Engineering
Autumn 2008
James Nowotarski
23 October 2008
Today’s Agenda
Topic
Duration

Guest speaker
45 minutes

Assignment 2 recap
15 minutes
*** Break

Current events
15 minutes

Software development environments
90 minutes
2
Pothole Tracking
and Repair System
(PHTRS)
Analysis Modeling Exercise
Assignment 2
Use case description –
narrative
Use-case: Activate the system
“If I’m at a remote location, I can use
any PC with appropriate browser
software to log on to the SafeHome
Products Web site . . . “
4
Use case description –
ordered sequence
Use-case: Activate the system
1.
2.
3.
4.
The homeowner observes . . .
The homeowner uses the keypad . .
The homeowner selects and keys in
stay or away . . .
When activation occurs . . .
5
Use case description –
additional elements
Should be primarily for users’ benefit
(secondarily for developers’)
 Elements of a use case







Name (Potential process on L1 DFD; should
relate to users’ goal)
Description
Trigger (external, temporal)
Major inputs & outputs (Potential data flows)
Major steps (Potential processes on L2 DFD)
Pre- and post-conditions (no post-condition for
6
an inquiry)
Use Case Diagram
Identify actors
Model their interactions with the system.
Through elicitation fully explore all the ways each
actor may interact with the system.
Banking Software Product
Withdraw Money
Customer
Teller
7
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
8
Level 0 DFD

L0 DFD (aka “Context” diagram)
Shows the context into which the
business process fits
 Shows the overall process as just one
process
 Shows all “external entities” that
contribute information to or receive
information from the system
 No data stores (unless external)

9
Context Diagram Example
Level 1 DFD for SafeHome security
function
Control
panel
Configure
system
User
commands
& data
Configure
request
Interact
with
user
Password
Configuration information
Start /
stop
Configuration
data
Activate/
deactivate
system
Process
password
Valid ID msg
Configuration
data
Sensors
Configuration
data
Sensor
status
Monitor
sensors
A/d
msg
Display
information
Display
messages
& status Alarm
Sensor
information
Control
panel
display
Alarm
type
Telephone number
tones
Telephone
line
11
Transform mapping
a
b
d
e
h
g
f
i
c
j
data flow model
x1
x2
b
x4
x3
c
a
"Transform" mapping
d
e
f
g
i
h
j
12
Transaction Mapping
Data flow model
f
e
a
d
b
mapping
t
x1
program structure
i
g
h
l
k
j
m
t
b
a
x2
n
d
e
x4
x3
f
g
l
x3.1
h
m
n
j
i
k
13
Today’s Agenda
Topic
Duration

Guest speaker
45 minutes

Assignment 2 recap
15 minutes
*** Break

Current events
15 minutes

Software development environments
90 minutes
14
Today’s Agenda
Topic
Duration

Guest speaker
45 minutes

Assignment 2 recap
15 minutes
*** Break

Current events
15 minutes

Software development environments
90 minutes
15
What is SE?
Software Engineering Body of Knowledge
Software requirements
Software design
Software construction
Software testing
Software maintenance
Software configuration management
Software engineering management
Software engineering process
Software engineering tools and methods
Software quality
tonight
Source: Guide to the Software Engineering Body of Knowledge.
(2004). IEEE. www.swebok.org
16
Anatomy of the technology in a
software development environment
1.
2.
3.
Process management
Information
management
(repository)
Quality management



4.
QFD
Statistical process ctl
Continuous improvmnt
5.



6.


Analysis & Design
Construction
Testing



7.
8.
9.
System mgmt
Change &
configuration mgmt
Service mgmt
Program/project mgmt

System development

Environment mgmt
Plan/Estimate
Schedule
Track
Report
Personal productivity
Teamware
Training/eLearning
17
Three critical factors in
development environments when
designing large software systems

Thin spread of application domain
knowledge

Fluctuating and conflicting
requirements

Communication and coordination
breakdowns
Source: Kurtis, B., Krasner, H., & Iscoe, N. (1988, November). A field study of
the software design process for large projects. Communications of
the ACM, 31(11), 1268-1287.
18
Experience is the best way
to acquire application
domain expertise
“CIOs are shifting their emphasis from technical
knowledge to business knowledge, from
specialization to versatility, from IT expertise
centralized in the IT organization to IT expertise
diffused throughout business areas and regions.”
-- Gartner Group, April 2008
19
Three characteristics
distinguish exceptional
designers

Extremely familiar with the application
domain

Skilled at communicating their vision
to their colleagues

Consumed with the performance of
their projects
20
An exceptional designer
represents a crucial depth and
integration of knowledge domains
Knowledge domains involved in systems building
Crucial
21
Three critical factors in
development environments when
designing large software systems

Thin spread of application domain
knowledge

Fluctuating and conflicting
requirements

Communication and coordination
breakdowns
22
Three critical factors in
development environments when
designing large software systems

Thin spread of application domain
knowledge

Fluctuating and conflicting
requirements

Communication and coordination
breakdowns
23
Three critical factors in
development environments when
designing large software systems

Thin spread of application domain
knowledge

Fluctuating and conflicting
requirements

Communication and coordination
breakdowns
Closely
related
24
Layered behavioral model
25
Software configuration
management (SCM)

The art of coordinating software changes to
minimize confusion

SCM activities:
 Identification
 Change control
 Version control
 Configuration auditing
 Reporting
26
The SCM Process
Sof tware
Vm.n
reporting
conf igurat ion auditing
v ersion control
change cont rol
ident if ication
SCIs
27
Software configuration items
(SCIs)
SRS
SRS
SRS
SRS
SRS
SRS
Design
Documents
SRS
System
Spec
Project
plan
WBS
SRS
SRS
SRS
SRS
SRS
SRS
Code
SRS
SRS
SRS
SRS
SRS
SRS
Test
cases
Change creates complexity
because we have multiple
versions of each SCI.
RMMM
28
Baselined SCI’s
modified
Project database
SCIs
approved
Software
engineering
tasks
SCIs
Formal
technical
reviews
SCIs
stored
SCIs
SCM
controls
extracted
SCIs
29
Baselines

IEEE Std. 610.12-1990 defines a baseline
as:
A specification or product that has been
formally reviewed and agreed upon, that
thereafter serves as the basis for further
development, and that can be changed only
through formal change control procedures.
30
Change requests

Change drivers
Users
 Business
 Environment
 Technology


Impact analysis
Where-Used
 Requirements traceability

31
Requirements traceability
“Requirements traceability is the ability to
describe and follow the life of a
requirement, in both a forward and
backward direction, i.e., from its origins,
through its development and specification, to
its subsequent deployment and use, and
through periods of ongoing refinement and
iteration in any of these phases.”
Gotel and Finkelstein, 1994.
32
Why traceability?
33
Why traceability?
Requirements validation
Validating that all requirements have been fulfilled.
Impact analysis
Assessing the impact of a proposed change
(Existing or new requirements)
Regression testing
Test selection following a change.
Requirements Monitoring
Measuring system’s ongoing ability to meet systemic
requirements.
Recording Rationales
Providing a history
34
Traceability matrix
Req No.
Description
Traces To
U2
Users shall be able to process retirement claims
S10, S11, S12
U3
Users shall be able to process survivor claims
S13
S10
The system shall accept retirement data
U2
S11
The system shall calculate the amount of retirement
U2
S12
The system shall calculate point-to-point travel time
U2
S13
The system shall calculate the amount of survivor
annuity.
U3
Entities
U2
U3
S10
U2
X
U3
X
S12
S13
X
X
S10
X
S11
X
S12
X
S13
S11
X
35
Traceability matrix
An alternate and probably more common representation.
36
http://castalia.cstcis.cti.depaul.edu:8080/Poirot
COLOR KEY:
Green = Activities that
occur each time a trace
query is issued.
Yellow = Batch activities
to maintain term
frequencies in Poirot
2. When a user is evaluating a query, they have the
option of asking for more information about the artifact.
If this occurs then we need to ask the MR (Managed
Resource) to display the artifact. If this function is nonsupported by the MR, we need to retrieve the
additional data and display it ourselves. This is why we
have a link from Client to WMS. The WMS will get the
data through the Resource Manager.
Poirot Engine
Blue = Project setup
activities.
ProcessQuery()
UpdateTerms()
For Version 1.0 of Poirot+ we will update terms
on a batch basis (nightly or upon request).
The Workflow Manager will check which of the
managed resources have changed. It will then
update hierarchical data and term frequency
data in Poirot. It will call upon the services of
the resource manager to locate MR. The
concreteMR class will interface with the API of
the 3rd party tool to actually obtain the data.
WorkFlow System
UpdateRoutine()
UpdateMR(MRName)
Poirot Web Client
1. Poirot Web
Client is the
interface for the
user to issue trace
queries. The user
issues a query, the
query is sent to
Poirot Engine
where it is
serviced and
results are
returned to Poirot
WebClient.
Currently the
webclient talks
directly to the
Poirot Engine,
however maybe it
should talk to the
WMS instead and
have the WMS
forward requests.
(This is an
additional
complication
though)
MR
ResourceMgr
(ManagedResource)
Poirot
data
RegisterMR()
RemoveMR()
GetHierarchy()
GetModuleTerms()
DisplayArtifact()
ConcreteMR
(Ex: DOORS)
ConcreteMR
(Ex: Rat Rose)
ConcreteMR
(Ex: Java Code)
DOORS
Rational Rose
Java Code
The idea is that this is the part of Poirot+ that will be change. We want to
be able to add managed resources dynamically at runtime, or change
their location. We have considered a broker architecture – but that may
be a bit of an overkill because we have a specific ‘service’ that will
manage each resource. We may need each Concrete MR to have a
local and distributed part. Anyway MRs will register themselves with the
ResourceMgr so that they become managed resources of the project.
Control the Change
1.
2.
3.
4.
5.
Need for change is
recognized
Change request is
submitted as a “request
for change” (RFC)
Developer evaluates
Change report is
generated
Change control
authority makes a
decision to either:


Proceed
Deny request.
6.
7.
8.
9.
10.
11.
12.
Request if queued for
action. ECO is
generated
(Engineering Change
Order).
Individuals assigned to
configuration objects.
Objects checked out
and change made.
Change audited.
Objects checked in.
Baseline established.
SQA activities
performed.
39
Rebuild & distribute.
Sample RFC form from:
http://www.nws.noaa.gov/oso/oso1/oso11/oso112/drg/drgrc.htm
40
Basic version control
techniques

Maintain ONLY the most recent version
and a history of changes.


Earlier versions are recreated through
“subtractions” from the recent version
Maintain full copies of ALL versions.

More space required
41
Version control


Before and after baselining an object may change
many times.
These changes can be represented in an evolution
graph.
Obj
1.0
Obj
1.1
Obj
1.3
Obj
1.4
Obj
2.0
Obj
2.1
Obj
1.2
Obj
1.1.1
Obj
1.1.2
How does the developer
reference all modules,
documents, and test cases
for version 1.4?
How does the marketing
department know what
customers currently have
version 2.1?
How can we ensure that
changes to 2.1 source code
are properly reflected in
corresponding
documentation?
42
Check-in/Check-out

Most version control tools in widespread use employ
the checkout-edit-checkin model to manage the
evolution of version-controlled files in a repository or
codebase.
http://www.cmcrossroads.com/bradapp/acme/branching/branch-intro.html
43
Serial development with
exclusive checkouts.



In a strictly sequential development model, when a
developer checks-out a file, the file is write-locked:
No one may checkout the file if another developer has it
checked-out. Instead, they must wait for the file to be
checked-in (which releases or removes the write-lock).
This is considered a pessimistic concurrency scheme
which forces all work to take place on a single line of
development.
http://www.cmcrossroads.com/bradapp/acme/branching/branch-intro.html
44
Concurrent development using
branches



Branching is a common mechanism to support concurrent
software development.
Allows development to take place along more than one
path for a particular file or directory.
When the revision on the new branch is modified and
checked-in, the two lines of development will have different
contents and will evolve separately
45
http://www.cmcrossroads.com/bradapp/acme/branching/branch-intro.html
Synchronizing using merges


Merging is the means by which one development line
synchronizes its contents with another development line.
The contents of the latest version on a child branch are
reconciled against the contents of the latest version on the
parent branch (preferably using a 2-way or 3-way file
differencing or comparison tool).
http://www.cmcrossroads.com/bradapp/acme/branching/branch-intro.html
46
For October 30


Read Pressman Chapters 21, 25
Current event reports
47