Christopher Nowotarski , Paul Markowski , Yvette Richardson Pennsylvania State University
James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn...
-
date post
15-Jan-2016 -
Category
Documents
-
view
219 -
download
0
Transcript of James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn...
![Page 1: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/1.jpg)
James Nowotarski
30 October 2008
SE 325/425Principles and
Practices of Software Engineering
Autumn 2008
![Page 2: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/2.jpg)
2
Topic Duration
Configuration management 45 minutes
Project management 30 minutes
*** Break
Current events 15 minutes
Project management 30 minutes
Risk management 60 minutes
Today’s Agenda
![Page 3: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/3.jpg)
33
Software Engineering Body of Knowledge
Software 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 4: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/4.jpg)
4
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
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 5: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/5.jpg)
Software Configuration Management
![Page 6: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/6.jpg)
6
Software configuration management (SCM) process
identification
change control
version control
configuration auditing
reporting
SCIs
Software Vm.n
![Page 7: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/7.jpg)
7
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 8: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/8.jpg)
8
SCIs
SCIs SCIs
SCIs
modified
approved
extracted
SCIs
stored
Project database
Formaltechnicalreviews
Softwareengineering
tasks
SCM controls
Baselined SCI’s
![Page 9: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/9.jpg)
9
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 10: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/10.jpg)
10
Change requests
Change driversUsersBusiness EnvironmentTechnology
Impact analysisWhere-UsedRequirements traceability
![Page 11: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/11.jpg)
11
“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 12: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/12.jpg)
12
Why traceability?
![Page 13: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/13.jpg)
13
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 S11 S12 S13
U2 X X X
U3 X
S10 X
S11 X
S12 X
S13 X
Traceability matrix
![Page 14: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/14.jpg)
14
An alternate and probably more common representation.
Traceability matrix
![Page 15: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/15.jpg)
17
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 is 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 16: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/16.jpg)
18
Sam
ple
RF
C f
orm
fro
m: N
atio
nal W
eath
er S
ervi
ce
http
://w
ww
.nw
s.no
aa.g
ov/o
so/o
so1/
oso1
1/os
o112
/drg
/drg
rc.h
tm
![Page 17: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/17.jpg)
19
Boeing 767
“Requests for changes came from internal and external sources. Some, such as the color of carpeting or seating arrangements, were negotiated by airline customers; others, such as parts or wiring changes, were proposed by engineers. In total, the two sources generated 12,000 changes on the first 767.”
Source: Harvard Business School. (1991, April 1). The Boeing 767: From concept to production (A). [Case number: 9-688-040]. Boston, MA: Harvard Business School Publishing.
![Page 18: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/18.jpg)
20
Boeing 767
“Managers tracked these changes carefully. Even before the plane’s basic design was frozen, all major changes had to be filed using the same formal procedure. This was done to ensure specifications remained accurate. Once assembly began, a Production Change Board, chaired by the operations department, reviewed all engineering change requests and assessed their likely impact on schedule and cost. If the changes were approved, an implementation plan was then developed.”
![Page 19: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/19.jpg)
21
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 20: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/20.jpg)
22
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 21: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/21.jpg)
23
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 22: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/22.jpg)
24
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 23: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/23.jpg)
25
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 24: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/24.jpg)
26
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 25: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/25.jpg)
Project Management
![Page 26: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/26.jpg)
28
Need for PM balance
PMI focus
Leadershipfocus
![Page 27: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/27.jpg)
Earned Value
![Page 28: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/28.jpg)
30
Earned value (EV)
Definition: Budgeted value of the work actually completed to date
The value of a task is proportional to the size of the task # widgets # lines of code budgeted $$$ (this is what we will use)
EV = % complete X overall size of task
![Page 29: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/29.jpg)
Copyright Copyright © © 2006 The McGraw-Hill Companies. All rights reserved. 2006 The McGraw-Hill Companies. All rights reserved.
Cost/Schedule GraphCost/Schedule GraphCost/Schedule GraphCost/Schedule Graph
FIGURE 13.5
![Page 30: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/30.jpg)
Copyright Copyright © © 2006 The McGraw-Hill Companies. All rights reserved. 2006 The McGraw-Hill Companies. All rights reserved.
Earned Value Review ExerciseEarned Value Review ExerciseEarned Value Review ExerciseEarned Value Review Exercise
FIGURE 13.6
![Page 31: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/31.jpg)
Challenges of Project Execution
![Page 32: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/32.jpg)
IT project failure rates are still high . . .
34
Source: Standish Group, 2007
![Page 33: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/33.jpg)
. . . yet more IT organizations than ever require PMI certification
35
Source: Standish Group, 2007
IT o
rgan
izat
ion
s th
at r
equ
ire
PM
I ce
rtif
icat
ion
fo
r P
M’s
![Page 34: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/34.jpg)
Project Summit, Nov. 13, 2006
If this is your view of PM, you will fail
Value
Deliverables
ActivitiesTime
![Page 35: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/35.jpg)
Establish Business Value Metrics
Old School – Monitor a project
New School – Manage a project
Measure Threshold Action
Schedule 10% variance Beat up the team to get the project done on time
Budget 10% variance Beat up the team to get the project done on budget
Earned Value 10% variance
Measure Threshold Action State< 2% variance No action required
2%-5% varianceIndependent audit/assessment to identify root causes of variance, review results within eight weeks
5%-7% variance Re-evaluate business case to ensure it is still valid. Take immediate action on root cause of variance. Review results within four weeks
7% + Discontinue project — no longer achieving the returns needed to justify the investment
Business Impact Measure
Sacrifice quality and beat up the team
![Page 36: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/36.jpg)
38
Keep eye on horizon
BusinessValue
PMI focus(record & report)
![Page 37: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/37.jpg)
39
• High-level executive who endorses and provides political support for the completion of a project
Key to project success:Project sponsor
![Page 38: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/38.jpg)
Organization
![Page 39: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/39.jpg)
The business situation will drive the degree to which IT is weighted toward business users vs. IT concerns
Business user concerns• Responsiveness• Customization• Innovation
IT concerns• Efficiency • Standards• Control
Business situation
![Page 40: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/40.jpg)
Director - CIO
Director, IS Planning
Director, Software Engineering
Manager, Production
Director, Business Technology
Manager, Administration
Director, Technical Services
• Enterprise Arch• Security• S/W Evaluation
• Business analysts• Program managers• Data warehouse
• Developers• Development tools
• Operations• Help desk• Application support
• Network• PC technicians
• $4B revenue company• 400 person IT shop, $70M
• IT HR• IT Finance
Purely centralized ITCEO
Corporatemanagement
and users
![Page 41: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/41.jpg)
Trend: Matrix IT
CEO
VP Finance VP Marketing VP Product A VP Product B
Function 1
Sys dev’t Finance
Function 1
Function 1
Function 1
CIOArchitecture
Operations
Sys dev’t Marketing
Sys dev’t Product A
Sys dev’t Product B
Sys. dev’t
![Page 42: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/42.jpg)
High-Performance Teams
![Page 43: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/43.jpg)
45
Characteristics of High-Performing Teams
![Page 44: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/44.jpg)
Copyright Copyright © © 2006 The McGraw-Hill Companies. All rights reserved. 2006 The McGraw-Hill Companies. All rights reserved.
Splitting/MultitaskingSplitting/MultitaskingSplitting/MultitaskingSplitting/Multitasking
FIGURE 8.10FIGURE 8.11
![Page 45: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/45.jpg)
Copyright Copyright © © 2006 The McGraw-Hill Companies. All rights reserved. 2006 The McGraw-Hill Companies. All rights reserved.
Splitting/MultitaskingSplitting/MultitaskingSplitting/MultitaskingSplitting/Multitasking
• Splitting/Multitasking
–A scheduling technique use to get a better project schedule and/or increase resource utilization.
•Involves interrupting work on an activity to employ the resource on another activity, then returning the resource to finish the interrupted work.
•Is feasible when startup and shutdown costs are low.
•Is considered the major reason why projects fail to meet schedule.
![Page 46: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/46.jpg)
48
Layered behavioral model
![Page 47: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/47.jpg)
Copyright Copyright © © 2006 The McGraw-Hill Companies. All rights reserved. 2006 The McGraw-Hill Companies. All rights reserved.
The Five-Stage Team Development ModelThe Five-Stage Team Development ModelThe Five-Stage Team Development ModelThe Five-Stage Team Development Model
FIGURE 11.1
![Page 48: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/48.jpg)
Copyright Copyright © © 2006 The McGraw-Hill Companies. All rights reserved. 2006 The McGraw-Hill Companies. All rights reserved.
The Punctuated Equilibrium Model The Punctuated Equilibrium Model of Group Developmentof Group Development
The Punctuated Equilibrium Model The Punctuated Equilibrium Model of Group Developmentof Group Development
FIGURE 11.2
![Page 49: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/49.jpg)
51
Maslow’s Hierarchy
![Page 50: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/50.jpg)
Managing Diversity
![Page 51: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/51.jpg)
53
Functional Cultural Generational Gender Organizational
Managing Diversity
![Page 52: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/52.jpg)
Global delivery
Planning; high level
tasksExecution
Common processestechnology and tools
![Page 53: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/53.jpg)
Copyright Copyright © © 2006 The McGraw-Hill Companies. All rights reserved. 2006 The McGraw-Hill Companies. All rights reserved.
Hofstede Cultural Dimensions FrameworkHofstede Cultural Dimensions FrameworkHofstede Cultural Dimensions FrameworkHofstede Cultural Dimensions Framework
• Individualism versus collectivism– Identifies whether a culture holds individuals or the group
responsible for each member’s welfare.
• Power distance– Describes degree to which a culture accepts status and power
differences among its members.
• Uncertainty avoidance– Identifies a culture’s willingness to accept uncertainty and
ambiguity about the future.
• Masculinity-femininity– Describes the degree to which the culture emphasizes
competitive and achievement-oriented behavior or displays concerns for relationships.
![Page 54: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/54.jpg)
Copyright Copyright © © 2006 The McGraw-Hill Companies. All rights reserved. 2006 The McGraw-Hill Companies. All rights reserved.
Sample Country Clusters on Hofstede’s Dimensions Sample Country Clusters on Hofstede’s Dimensions of Individualism-Collectivism and Power Distanceof Individualism-Collectivism and Power Distance
Sample Country Clusters on Hofstede’s Dimensions Sample Country Clusters on Hofstede’s Dimensions of Individualism-Collectivism and Power Distanceof Individualism-Collectivism and Power Distance
FIGURE 15.5
![Page 55: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/55.jpg)
Risk Management
![Page 56: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/56.jpg)
58
“The basic problem of software development is risk”
Beck, K. (2000). Extreme programming explained. Boston, MA: Addison-Wesley
Risk management
![Page 57: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/57.jpg)
59
“It is futile to try to eliminate risk”
-- Peter Drucker, management guru
Risk management
![Page 58: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/58.jpg)
60
“Companies demonstrated to us that running away from risk is a loser, and that risk comes with the territory of a valuable project.”
De Marco, T. & Lister, T. (2003). Waltzing with bears: Managing risks on software projects. New York: Dorset House.
Risk management
![Page 59: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/59.jpg)
61
What is risk?
![Page 60: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/60.jpg)
62
Categories of software risk
Project Technical Business Legal
Threaten the project plan• Customers• Resources & personnel• Inexperienced management
team• Requirements• Complexity• Size
![Page 61: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/61.jpg)
63
Categories of software risk
Project Technical Business Legal
Threaten software quality• Applying unproven
technology• Conversion may uncover
“dirty” data• New interface with a legacy
system
![Page 62: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/62.jpg)
64
Categories of software risk
Project Technical Business Legal
Threaten viability of the software product
• Lack of business champion• Senior management
support wanes• Falls out of alignment with
business strategy• Loses budget or personnel
![Page 63: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/63.jpg)
65
Categories of software risk
Project Technical Business Legal
• Shareholder lawsuits• Data privacy• Breach of services (third
party solutions provider)
![Page 64: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/64.jpg)
Proactive vs. reactive risk management
Don’t worry, I’ll think of something!!
![Page 65: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/65.jpg)
68
Tackle risk early in the project
![Page 66: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/66.jpg)
69
Risk management process
Identify Analyze Plan
Cost of protection Cost of exposure
$$ $$
Control
![Page 67: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/67.jpg)
70
Risk management process: artifacts
Identify Analyze Plan Control
• List of risks • Probability• Impact• Risk exposure• Cutoff
• Mitigation plan• Monitoring plan• Contingency plan
![Page 68: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/68.jpg)
71
Risk identification: 80/20 rule
80% of the engineering is consumed by 20% of the requirements
80% of the software cost, errors, and resource consumption is caused by 20% of the components
![Page 69: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/69.jpg)
72
Risk identification: checklists
Example: Technology risks: Is the technology to be built new to your
organization? Do the requirements require the creation of
new algorithms? Does the software interface with new or
unproven hardware or unproven vendor products?
Do the requirements require the creation of components that are unlike anything your organization has previously built?
Do requirements demand the use of new analysis, design, or testing methods?
Do requirements put excessive performance constraints on the product?
![Page 70: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/70.jpg)
73
Risk management process
Identify Analyze Plan Control
• List of risks • Probability• Impact• Risk exposure• Cutoff
• Mitigation plan• Monitoring plan• Contingency plan
![Page 71: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/71.jpg)
74
Risk analysis
Software risks always involve the two characteristics of uncertainty and loss.
Uncertainty – The level of certainty about whether the event may or may not happen.
Loss – What is the impact of the event if it does occur?
Don’t hide from project risk. Face it head on!
![Page 72: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/72.jpg)
Measuring Probability In numbers Or as symbols/phrases e.g., ‘High’, ‘Medium’, ‘Low’ These can be converted to numbers if desired
![Page 73: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/73.jpg)
Measuring Impact Same approach as probability – but ‘units’ will probably
be different. e.g., $, time lost, image loss, lives lost
Usually reduced to economic terms
0
0.2
0.4
0.6
0.8
1
1.2
Cat
astr
ophi
c
Larg
e
Med
ium
Low
Sig
nific
ant
Neg
ligib
leterm
loss
(m
illi
on
s)
![Page 74: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/74.jpg)
77
Risk Assessment Example
RISK CATEGORY DESCRIPTION PROBABILITY IMPACTMITIGATION PLAN
CONTINGENCY PLAN
Schedule Unless everything falls into place, may not hit 7/1 conversion go live date
M H
Example
![Page 75: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/75.jpg)
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
Risk Exposure ExampleRisk Exposure Example
Risk identification.Risk identification. Only 70 percent of the software Only 70 percent of the software components scheduled for reuse will, in fact, be integrated into components scheduled for reuse will, in fact, be integrated into the application. The remaining functionality will have to be the application. The remaining functionality will have to be custom developed.custom developed.
Risk probability.Risk probability. 80% (likely). 80% (likely). Risk impact.Risk impact. 60 reusable software components were planned. If 60 reusable software components were planned. If
only 70 percent can be used, 18 components would have to be only 70 percent can be used, 18 components would have to be developed from scratch (in addition to other custom software that developed from scratch (in addition to other custom software that has been scheduled for development). Since the average has been scheduled for development). Since the average component is 100 LOC and local data indicate that the software component is 100 LOC and local data indicate that the software engineering cost for each LOC is $14.00, the overall cost (impact) engineering cost for each LOC is $14.00, the overall cost (impact) to develop the components would be 18 x 100 x 14 = $25,200.to develop the components would be 18 x 100 x 14 = $25,200.
Risk exposure. Risk exposure. RE = 0.80 x 25,200 ~ $20,200. RE = 0.80 x 25,200 ~ $20,200.
![Page 76: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/76.jpg)
79
Risk planning
Identify Analyze Plan Control
• List of risks • Probability• Impact• Risk exposure• Cutoff
• Mitigation plan• Monitoring plan• Contingency plan
RMMM=Risk Mitigation, Monitoring, & Mgmt
![Page 77: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/77.jpg)
80
Risk Assessment Example
RISK CATEGORY DESCRIPTION PROBABILITY IMPACTMITIGATION PLAN
CONTINGENCY PLAN
Schedule Unless everything falls into place, may not hit 7/1 conversion go live date
M H Cut scope to increase likelihood of hitting date;
If date not hit, continue running old system
Example
![Page 78: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/78.jpg)
81
Risk control
Identify Analyze Plan Control
• List of risks • Probability• Impact• Cutoff• Risk exposure
• Mitigation plan• Monitoring plan• Contingency plan
![Page 79: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/79.jpg)
82
Group Problem
ERP System Doesn’t Make Grade in Indianahttp://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=95863
In retrospect:• What were the top 2 risks?• What might they have done different to mitigate,
monitor, and manage these risks?
Small group activity
![Page 80: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/80.jpg)
83
Assignment 4 (Risk Management) Readings Current event reports
For November 6
![Page 81: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/81.jpg)
Extra Slides
![Page 82: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/82.jpg)
85
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 83: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/83.jpg)
86
Strategies are typically implemented through projects
![Page 84: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/84.jpg)
87
Expectancy TheoryM = V * E * I
V
I
E
![Page 85: James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008.](https://reader036.fdocuments.net/reader036/viewer/2022062423/56649d4a5503460f94a2679c/html5/thumbnails/85.jpg)
88
Discuss
Millenials (born 1978-92) – How different?
xx