SE 325/425 Principles and Practices of Software Engineering Autumn 2008
description
Transcript of SE 325/425 Principles and Practices of Software Engineering Autumn 2008
![Page 1: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/1.jpg)
James Nowotarski23 October 2008
SE 325/425Principles and
Practices of Software Engineering
Autumn 2008
![Page 2: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/2.jpg)
2
Topic Duration Guest speaker 45 minutes Assignment 2 recap 15 minutes
*** Break Current events 15 minutes Software development environments 90 minutes
Today’s Agenda
![Page 3: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/3.jpg)
Pothole Tracking and Repair System (PHTRS)
Analysis Modeling ExerciseAssignment 2
![Page 4: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/4.jpg)
4
Use case description – narrative
“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 . . . “
Use-case: Activate the system
![Page 5: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/5.jpg)
5
Use case description – ordered sequence
1. The homeowner observes . . . 2. The homeowner uses the keypad . . 3. The homeowner selects and keys in
stay or away . . . 4. When activation occurs . . .
Use-case: Activate the system
![Page 6: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/6.jpg)
6
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 an inquiry)
![Page 7: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/7.jpg)
7
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
Use Case Diagram
![Page 8: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/8.jpg)
8
Use Case Diagram
homeowner
Arms/ disarms system
Accesses system via Internet
Reconfigures sensors and related
system features
Responds toalarm event
Encounters anerror condition
system administrator
sensors
![Page 9: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/9.jpg)
9
Level 0 DFD
L0 DFD (aka “Context” diagram)Shows the context into which the business
process fitsShows the overall process as just one
processShows all “external entities” that contribute
information to or receive information from the system
No data stores (unless external)
![Page 10: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/10.jpg)
Context Diagram Example
![Page 11: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/11.jpg)
11
Level 1 DFD for SafeHome security function
Controlpanel
Interactwithuser
Processpassword
Configuresystem
Activate/deactivate
system
MonitorsensorsSensors Telephone
line
Alarm
Controlpanel
display
User commands & data
Password
Configurerequest
Start /stop
A/dmsg
Valid ID msg
Sensorstatus
Configuration information
Configuration data
Configuration data
Sensorinformation
Configurationdata
Displayinform-ationDisplay
messages& status Alarm
type
Telephone number tones
MonitorsensorsSensor
status
Sensorinformation
Alarmtype
Telephone number tones
Configurationdata
![Page 12: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/12.jpg)
12
Transform mapping
data flow model
"Transform" mapping
ab
c
d e f g h
ij
x1
x2 x3 x4
b c
a
d e f g i
h j
![Page 13: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/13.jpg)
13
Transaction Mapping
a
b
t
g
h
d
e
f
i
k
j
l
m
n
Data flow model
x1
b
a
t
x2 x3 x4
d e f g h x3.1 l m n
i j
k
mapping
program structure
![Page 14: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/14.jpg)
14
Topic Duration Guest speaker 45 minutes Assignment 2 recap 15 minutes
*** Break Current events 15 minutes Software development environments 90 minutes
Today’s Agenda
![Page 15: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/15.jpg)
15
Topic Duration Guest speaker 45 minutes Assignment 2 recap 15 minutes
*** Break Current events 15 minutes Software development environments 90 minutes
Today’s Agenda
![Page 16: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/16.jpg)
1616
Software Engineering Body of KnowledgeSoftware requirementsSoftware designSoftware constructionSoftware testingSoftware maintenanceSoftware configuration managementSoftware engineering managementSoftware engineering processSoftware engineering tools and methodsSoftware quality
Source: Guide to the Software Engineering Body of Knowledge. (2004). IEEE. www.swebok.org
What is SE?
tonight
![Page 17: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/17.jpg)
17
Anatomy of the technology in a software development environment
1. Process management2. Information
management (repository)
3. Quality management QFD Statistical process ctl Continuous improvmnt
4. System development Analysis & Design Construction Testing
5. Environment mgmt System mgmt Change &
configuration mgmt Service mgmt
6. Program/project mgmt Plan/Estimate Schedule Track Report
7. Personal productivity8. Teamware9. Training/eLearning
![Page 18: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/18.jpg)
18
Thin spread of application domain knowledge
Fluctuating and conflicting requirements
Communication and coordination breakdowns
Three critical factors in development environments when designing large software systems
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.
![Page 19: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/19.jpg)
19
“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
Experience is the best way to acquire application domain expertise
![Page 20: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/20.jpg)
20
Extremely familiar with the application domain
Skilled at communicating their vision to their colleagues
Consumed with the performance of their projects
Three characteristics distinguish exceptional designers
![Page 21: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/21.jpg)
21
An exceptional designer represents a crucial depth and integration of knowledge domains
Knowledge domains involved in systems building
Crucial
![Page 22: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/22.jpg)
22
Thin spread of application domain knowledge
Fluctuating and conflicting requirements
Communication and coordination breakdowns
Three critical factors in development environments when designing large software systems
![Page 23: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/23.jpg)
23
Thin spread of application domain knowledge
Fluctuating and conflicting requirements
Communication and coordination breakdowns
Three critical factors in development environments when designing large software systems
![Page 24: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/24.jpg)
24
Thin spread of application domain knowledge
Fluctuating and conflicting requirements
Communication and coordination breakdowns
Three critical factors in development environments when designing large software systems
Closely related
![Page 25: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/25.jpg)
25
Layered behavioral model
![Page 26: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/26.jpg)
26
The art of coordinating software changes to minimize confusion
SCM activities: Identification Change control Version control Configuration auditing Reporting
Software configuration management (SCM)
![Page 27: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/27.jpg)
27
The SCM Process
identification
change control
version control
configuration auditing
reporting
SCIs
Software Vm.n
![Page 28: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/28.jpg)
28
SRSSRS
SRSSRS
SRSSRSTest
cases
SRSSRS
SRSSRS
SRSSRS
Code
SystemSpec
SRS
Projectplan
SRSSRS
SRSSRS
SRSSRSDesign
Documents
WBS RMMM
Change creates complexity because we have multiple versions of each SCI.
Software configuration items (SCIs)
![Page 29: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/29.jpg)
29
SCIs
SCIs SCIs
SCIs
modified
approved
extracted
SCIs
stored
Project database
Formaltechnicalreviews
Softwareengineering
tasks
SCM controls
Baselined SCI’s
![Page 30: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/30.jpg)
30
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.
Baselines
![Page 31: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/31.jpg)
31
Change requests
Change driversUsersBusiness EnvironmentTechnology
Impact analysisWhere-UsedRequirements traceability
![Page 32: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/32.jpg)
32
“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.
Requirements traceability
![Page 33: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/33.jpg)
33
Why traceability?
![Page 34: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/34.jpg)
34
Requirements validationValidating that all requirements have been fulfilled. Impact analysisAssessing the impact of a proposed change(Existing or new requirements) Regression testingTest selection following a change.Requirements MonitoringMeasuring system’s ongoing ability to meet systemic requirements.Recording RationalesProviding a history
Why traceability?
![Page 35: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/35.jpg)
35
Req No. Description Traces ToU2 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 S11 S12 S13U2 X X X
U3 X
S10 X
S11 X
S12 X
S13 X
Traceability matrix
![Page 36: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/36.jpg)
36
An alternate and probably more common representation.
Traceability matrix
![Page 38: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/38.jpg)
Poirot Web Client
Poirot Engine
ProcessQuery()UpdateTerms()
WorkFlow System
UpdateRoutine()UpdateMR(MRName)
ResourceMgr
RegisterMR()RemoveMR()
MR(ManagedResource)
GetHierarchy()GetModuleTerms()DisplayArtifact()
ConcreteMR(Ex: DOORS)
ConcreteMR(Ex: Rat Rose)
ConcreteMR(Ex: Java Code)
Poirotdata
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.
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)
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 non-supported 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.
COLOR KEY:Green = Activities that occur each time a trace query is issued.
Yellow = Batch activities to maintain term frequencies in Poirot
Blue = Project setup activities.
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.
![Page 39: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/39.jpg)
39
Control the Change1. Need for change is
recognized2. Change request is
submitted as a “request for change” (RFC)
3. Developer evaluates4. Change report is
generated5. Change control
authority makes a decision to either: Proceed Deny request.
6. Request if queued for action. ECO is generated(Engineering Change Order).
7. Individuals assigned to configuration objects.
8. Objects checked out and change made.
9. Change audited.10. Objects checked in.11. Baseline established.
SQA activities performed.
12. Rebuild & distribute.
![Page 40: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/40.jpg)
40
Sam
ple
RFC
form
from
: ht
tp://
ww
w.n
ws.n
oaa.
gov/
oso/
oso1
/oso
11/o
so11
2/dr
g/dr
grc.
htm
![Page 41: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/41.jpg)
41
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
![Page 42: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/42.jpg)
42
Before and after baselining an object may change many times.
These changes can be represented in an evolution graph.
Obj1.0
Obj1.1
Obj1.2
Obj1.3
Obj1.4
Obj2.0
Obj2.1
Obj1.1.1
Obj1.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?
Version control
![Page 43: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/43.jpg)
43
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
![Page 44: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/44.jpg)
44
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
![Page 45: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/45.jpg)
45
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
http://www.cmcrossroads.com/bradapp/acme/branching/branch-intro.html
![Page 46: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/46.jpg)
46
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
Synchronizing using merges
![Page 47: SE 325/425 Principles and Practices of Software Engineering Autumn 2008](https://reader035.fdocuments.in/reader035/viewer/2022081517/56815b65550346895dc95521/html5/thumbnails/47.jpg)
47
Read Pressman Chapters 21, 25 Current event reports
For October 30