IS 483 Information Systems Management James Nowotarski 3 April 2003.
James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn...
-
date post
15-Jan-2016 -
Category
Documents
-
view
218 -
download
0
Transcript of James Nowotarski 30 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn...
James Nowotarski
30 October 2008
SE 325/425Principles and
Practices of Software Engineering
Autumn 2008
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
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
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.
Software Configuration Management
6
Software configuration management (SCM) process
identification
change control
version control
configuration auditing
reporting
SCIs
Software Vm.n
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)
8
SCIs
SCIs SCIs
SCIs
modified
approved
extracted
SCIs
stored
Project database
Formaltechnicalreviews
Softwareengineering
tasks
SCM controls
Baselined SCI’s
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
10
Change requests
Change driversUsersBusiness EnvironmentTechnology
Impact analysisWhere-UsedRequirements traceability
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
12
Why traceability?
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
14
An alternate and probably more common representation.
Traceability matrix
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.
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
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.
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.”
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
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
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
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
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
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
Project Management
28
Need for PM balance
PMI focus
Leadershipfocus
Earned Value
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
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
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
Challenges of Project Execution
IT project failure rates are still high . . .
34
Source: Standish Group, 2007
. . . 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
Project Summit, Nov. 13, 2006
If this is your view of PM, you will fail
Value
Deliverables
ActivitiesTime
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
38
Keep eye on horizon
BusinessValue
PMI focus(record & report)
39
• High-level executive who endorses and provides political support for the completion of a project
Key to project success:Project sponsor
Organization
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
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
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
High-Performance Teams
45
Characteristics of High-Performing Teams
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
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.
48
Layered behavioral model
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
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
51
Maslow’s Hierarchy
Managing Diversity
53
Functional Cultural Generational Gender Organizational
Managing Diversity
Global delivery
Planning; high level
tasksExecution
Common processestechnology and tools
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.
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
Risk Management
58
“The basic problem of software development is risk”
Beck, K. (2000). Extreme programming explained. Boston, MA: Addison-Wesley
Risk management
59
“It is futile to try to eliminate risk”
-- Peter Drucker, management guru
Risk management
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
61
What is risk?
62
Categories of software risk
Project Technical Business Legal
Threaten the project plan• Customers• Resources & personnel• Inexperienced management
team• Requirements• Complexity• Size
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
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
65
Categories of software risk
Project Technical Business Legal
• Shareholder lawsuits• Data privacy• Breach of services (third
party solutions provider)
Proactive vs. reactive risk management
Don’t worry, I’ll think of something!!
68
Tackle risk early in the project
69
Risk management process
Identify Analyze Plan
Cost of protection Cost of exposure
$$ $$
Control
70
Risk management process: artifacts
Identify Analyze Plan Control
• List of risks • Probability• Impact• Risk exposure• Cutoff
• Mitigation plan• Monitoring plan• Contingency plan
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
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?
73
Risk management process
Identify Analyze Plan Control
• List of risks • Probability• Impact• Risk exposure• Cutoff
• Mitigation plan• Monitoring plan• Contingency plan
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!
Measuring Probability In numbers Or as symbols/phrases e.g., ‘High’, ‘Medium’, ‘Low’ These can be converted to numbers if desired
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)
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
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.
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
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
81
Risk control
Identify Analyze Plan Control
• List of risks • Probability• Impact• Cutoff• Risk exposure
• Mitigation plan• Monitoring plan• Contingency plan
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
83
Assignment 4 (Risk Management) Readings Current event reports
For November 6
Extra Slides
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?
86
Strategies are typically implemented through projects
87
Expectancy TheoryM = V * E * I
V
I
E
88
Discuss
Millenials (born 1978-92) – How different?
xx