SE 325/425 Principles and Practices of Software Engineering Autumn 2006
James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering...
-
date post
19-Dec-2015 -
Category
Documents
-
view
216 -
download
1
Transcript of James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering...
![Page 1: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/1.jpg)
James Nowotarski
26 September 2006
SE 325/425Principles and
Practices of Software Engineering
Autumn 2006
![Page 2: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/2.jpg)
2
Topic Duration
Finish RUP, Agile, XP 45 minutes
Risk management 45 minutes
*** Break
Current event reports 15 minutes
Risk management 60 minutes
Wrap-up 15 minutes
Today’s Agenda
![Page 3: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/3.jpg)
3
Survey Results[plus Jordan]
Key issues/trends: Outsourcing 7 Requirements 5 Web 2.0 4 Security 3 Dispersed teams 3 Project mgmt 2/1 Six sigma/Quality 2/1 Agile methods 2 IT working with business units 2 Upgrades 2 Maintenance 1 Communication 1
![Page 4: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/4.jpg)
4
Technology
ProcessPeople
The focus of SE 425 is the process component of software engineering
Core Concepts
Technology
ProcessPeople
… for the delivery of technology-enabled business solutions
![Page 5: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/5.jpg)
5
The waterfall model is the granddaddy of life cycle models
Waterfall
Planning
Modeling
Construction
Deployment
![Page 6: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/6.jpg)
6
Protracted integration and late breakage
Conventional application of the waterfall model typically results in late integration and performance showstoppers
Dev
elop
men
t p
rogr
ess
(% c
oded
)
100%Late designbreakage
Original target date
Source: Royce, W. Software Project Management: A Unified Framework. Addison-Wesley (1998).
Integrationbegins
What’s wrong with waterfall?
![Page 7: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/7.jpg)
7
Why focus on change?
Life cycle phase
Co
st
of
ch
an
ge
Req Anal. Des. Impl. Test Prod
y = axp
![Page 8: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/8.jpg)
8
RUP Guiding Principles
IterativeDevelopment
QualityCustomerValue
Attack riskAccommodatechange
Work togetherExecutablesoftware
Architecturebaseline
Component-baseddevelopment
Objectives
Strategies
Tactics
![Page 9: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/9.jpg)
9
RUP “Hump” Diagram
![Page 10: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/10.jpg)
10
Inside each phase, you plan iterations across disciplines
![Page 11: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/11.jpg)
11
Phase boundaries in waterfall are activities
Systemrequirements
Softwarerequirements
Analysis
Program design
Coding
Testing
Operations
Phase
Phase
Phase
Phase
Phase
Phase
![Page 12: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/12.jpg)
12
Phase boundaries in RUP are milestones
Systemrequirements
Softwarerequirements
Analysis
Program design
Coding
Testing
Operations
RUP Phase
Milestone
![Page 13: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/13.jpg)
13
Iterative Advantages/Disadvantages
Advantages
Disadvantages Difficult to know when an
iteration is done More difficult to manager Higher need for ongoing user
involvement Easier to lose focus, get
distracted (concurrency)
![Page 14: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/14.jpg)
14 Copyright © 1997 by Rational Software Corporation
Risk
Transition
Inception
Elaboration
Construction
PreliminaryIteration
Architect.Iteration
Architect.Iteration
Devel. Iteration
Devel. Iteration
Devel. Iteration
TransitionIteration
TransitionIteration
Post-deployment
Waterfall
Time
Risk Profile: Iterative vs. Waterfall
Iterative
![Page 15: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/15.jpg)
15
Approach References
XP www.extremeprogramming.org
www.xprogramming.com
M. Marchesi et al, Extreme Programming Perspectives, Addison-Wesley, 2002.
Crystal A. Cockburn, Agile Software Development, Addison-Wesley, 2001
SCRUM K. Schwaber and M. Beedle, Agile Software Development with Scrum, Prentice Hall, 2001.
Adaptive Software Development
J. Highsmith, Adaptive Software Development, Dorset House, 2000.
FDD S. Palmer, A Practical Guide to Feature-Driven Development, Prentice Hall, 2002.
Agile - General http://www.agilealliance.org/home
http://www.agilemodeling.com
Agile/Light/Lean Methods
![Page 16: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/16.jpg)
16
RUP Guiding Principles
IterativeDevelopment
QualityCustomerValue
Attack riskAccommodatechange
Work togetherExecutablesoftware
Architecturebaseline
Component-baseddevelopment
Objectives
Strategies
Tactics
![Page 17: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/17.jpg)
17
XP Conceptual Framework
IterativeDevelopment
QualityCustomerValue
Attack riskAccommodatechange
Work togetherExecutablesoftware
Architecturebaseline
Component-baseddevelopment
Objectives
Strategies
Practices
![Page 18: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/18.jpg)
18
Phase boundaries in RUP are milestones
Systemrequirements
Softwarerequirements
Analysis
Program design
Coding
Testing
Operations
RUP Phase
Milestone
![Page 19: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/19.jpg)
19
XP winds the RUP model more tightly
Systemrequirements
Softwarerequirements
Analysis
Program design
Coding
Testing
Operations
Each day on an XP project
FunctioningCode
![Page 20: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/20.jpg)
20
What is XP
“Don’t ask me, ask the system” “Have you written a test case for that yet” Put in production as soon as possible
i.e., don’t “shelter” your code “Without this first pass, the project manager is at the mercy
of human judgment. With this first-pass ‘simulation,’ he can at least perform experimental tests of some key hypotheses and scope down what remains for human judgment, which in the case of computer program design . . . is invariably and seriously optimistic” – Royce, 1970
Rapid Feedback
![Page 21: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/21.jpg)
21
What is XP
“What is the simplest thing that could possibly work?”
Flattened change curve
Assume SimplicityEmbrace Change
![Page 22: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/22.jpg)
22
What is XP
Time
Co
st
of
ch
an
ge
XP purports to change the curve so that the cost to find and repair software problems does not rise dramatically over time
![Page 23: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/23.jpg)
23
What is XP
Quality is assumedExcellent, orInsanely excellent
Quality Work
![Page 24: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/24.jpg)
24
What is XP
Test all the time Continuous integration Pair programming Coding standards Collective ownership Do simplest thing that will work today
“design tomorrow for tomorrow’s problems” Metaphor to aid in understanding the architecture Refactoring and evolutionary design
Key Practices/Features
![Page 25: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/25.jpg)
25
What is XP
Customer on-site as integral part of team Incremental planning
learning to driveprogrammers provide estimates
Short iterations, small releases2 month releases, 2 week iterations
40-hour week
Key Practices/Features (cont.)
![Page 26: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/26.jpg)
26
What is XP
Start design with a test Start coding with a test Test things that might break Testing is isolated Testing is integrated Testing is automated At least one dedicated tester Comprehensive suite of tests
Begin with the end in mind . . .
![Page 27: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/27.jpg)
27
Topic Duration
Finish RUP, Agile, XP 45 minutes
Risk management 45 minutes
*** Break
Current event reports 15 minutes
Risk management 60 minutes
Wrap-up 15 minutes
Today’s Agenda
![Page 28: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/28.jpg)
28
“The basic problem of software development is risk”
Beck, K. (2000). Extreme Programming Explained. Boston, MA: Addison-Wesley
Risk management
![Page 29: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/29.jpg)
29
What is risk?
something that could go wrong Problem that may occur
![Page 30: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/30.jpg)
Proactive vs. reactive risk management
Don’t worry, I’ll think of something!!
![Page 31: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/31.jpg)
![Page 32: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/32.jpg)
Post-Implementation ReviewProject Manager: Dr. Indiana Jones;
Project Objective: To retrieve priceless gold statue for the museum;
Did the project meet objectives? No. Indy got the statue but lost in in the last phase to evil forces;
Project Costs: High. One guide dead, a severely bruised Indy and a priceless archeological find [the cave which contains photo-electric cells for example] destroyed;
Project Benefits : None - Indy did not save statue for society and research;
Overall success: From all perspectives the Cave Project was dismal failure. Not only did the project fail to meet its objectives but one person died and the project manager was placed at risk throughout the project;
![Page 33: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/33.jpg)
Post-Implementation ReviewIn addition, the project manager Dr. Indiana Jones didn't undertake planning or risk assessment and went into the Cave project completely un-prepared.
Finally, Dr. Jones has exhibited no learning from the project and has continued throughout the entire three releases of the Indiana Jones Integrated Project (Release1: Raiders of the Lost Ark; Release 2: The Temple of Doom; Release 3: The Last Crusade) to walk into other Cave Projects without any planning or formal risk assessment;
Conclusion: Dr. Indiana Jones should be demoted from Project Manager to Trainee ASAP.
![Page 34: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/34.jpg)
34
Categories of software risk
Project Technical Business Legal
Threaten the project plan• Customers• Resources & personnel• Inexperienced management
team• Requirements• Complexity• Size
![Page 35: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/35.jpg)
35
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 36: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/36.jpg)
36
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 37: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/37.jpg)
37
Categories of software risk
Project Technical Business Legal
• Shareholder lawsuits• Data privacy• Breach of services (third
party solutions provider)
![Page 38: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/38.jpg)
38
Importance of risk management
• Dependence on electronic information and IT systems is essential to support critical business processes. Successful businesses need to better manage the complex technology that is pervasive throughout their organizations in order to respond quickly and safely to business needs. . .
. . . In addition, the regulatory environment is mandating stricter control over information. This, in turn, is driven by increasing disclosures of information system disasters and increasing electronic fraud. The management of IT-related risks is now being understood as a key part of enterprise governance.
Source: IT Governance Institute
Legal/regulatory risks are increasing in importance
![Page 39: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/39.jpg)
39
“It is futile to try to eliminate risk”
-- Peter Drucker, management guru
Risk management
![Page 40: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/40.jpg)
40
Risk management process
Identify Analyze Plan
Cost of protection Cost of exposure
$$ $$
Control
![Page 41: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/41.jpg)
41
Risk management process: artifacts
Identify Analyze Plan Control
• List of risks • Probability• Impact• Cutoff• Risk exposure
• Mitigation plan• Monitoring plan• Contingency plan
![Page 42: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/42.jpg)
42
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 43: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/43.jpg)
43
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 44: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/44.jpg)
44
Risk management process
Identify Analyze Plan Control
• List of risks • Probability• Impact• Cutoff• Risk exposure
• Mitigation plan• Monitoring plan• Contingency plan
![Page 45: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/45.jpg)
45
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 46: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/46.jpg)
Measuring Probability In numbers Or as symbols/phrases e.g., ‘High’, ‘Medium’, ‘Low’ These can be converted to numbers if desired
![Page 47: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/47.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 48: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/48.jpg)
48
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 49: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/49.jpg)
49
Risk planning
Identify Analyze Plan Control
• List of risks • Probability• Impact• Cutoff• Risk exposure
• Mitigation plan• Monitoring plan• Contingency plan
![Page 50: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/50.jpg)
50
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 51: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/51.jpg)
51
Risk control
Identify Analyze Plan Control
• List of risks • Probability• Impact• Cutoff• Risk exposure
• Mitigation plan• Monitoring plan• Contingency plan
![Page 52: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/52.jpg)
52
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 53: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/53.jpg)
53
Top 2 risks
not ready to go live on scheduled date new system doesn’t interface with existing legacy New system modules don’t interface properly Software quality problems due to inadequate testing Users will not know how to use system (due to
inadequate training) Downtime excessively long while transitioning to new
system Project plan leaves out steps required for dealing with
complexity/scope
![Page 54: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/54.jpg)
54
Mitigation
Talk to Sallie Mae before testing begins Keep old system running until new system
stable More time for testing Talk to experienced personnel Phased rollout Phased delivery, smaller chunks Mock the whole process
![Page 55: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/55.jpg)
55
Monitoring
walkthroughs External party review project Test results (backlog of change
requests, user signoffs, etc.) # users trained, competency
assessment
![Page 56: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/56.jpg)
56
Contingency Planning
do one Fallback plan to existing system
![Page 57: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/57.jpg)
57
“Today, an IT disruption can paralyze a company’s ability to make its products, deliver its services, and connect with its customers, not to mention foul its reputation. Yet few companies have done a thorough job of identifying and tempering their vulnerabilities. Worrying about what might go wrong may not be as glamorous a job as speculating about the future, but it is a more essential job right now.”
Carr, N. (2003, May). IT doesn’t matter. Harvard Business Review. Retrieved September 8, 2006 from EBSCO Host – Business Source Premier database.
Does SE Matter?
![Page 58: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/58.jpg)
58
Read Pressman Chapter 7 Assignment 2 (Risk Management exercise, see course home page) Current Event Reports:
KACZANKOPHAMSHERMANYOCOM-PIATT
For October 3
![Page 59: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/59.jpg)
59
Extra slides
![Page 60: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/60.jpg)
60
Risk vs. Technology Maturity
Impact of Technology Maturity
Risk Early Adopter Mid Adopter Late Adopter
hands-on implementation experience little exper / high riskmore exper / mid risk
much exper / low risk
vendor survival for project after shake-out high risk mid risk low risk
sudden changes in direction of technology high risk mid risk low riskintegrating technology with existing portfolio
high risk mid risk low risk
Benefits
Period for Start of Payoff Short term Mid term Long term
Size of Returns per period Biggest Bigger Big
Risk vs. Return
![Page 61: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/61.jpg)
61
Testing
Requirements
Functional Design
TechnicalDesign
DetailedDesign
Code
Unit Test
IntegrationTest
SystemTest
AcceptanceTest
Flow of Work
Verification
Validation
Testing: Test that the product implements the specification
Legend:
![Page 62: James Nowotarski 26 September 2006 SE 325/425 Principles and Practices of Software Engineering Autumn 2006.](https://reader038.fdocuments.in/reader038/viewer/2022110207/56649d365503460f94a0e811/html5/thumbnails/62.jpg)
62
Change Control Process
Create InitialSections
Create/ModifyDraft
Review Draft(V&V)
Create Changes to Incorporate
Changes Needed In Document
DocumentApproved
Create Review Revise ReviewReview Approved
Time
...
Document in Production and Under Formal Change Control
Document in Production and Under Formal Change Control
Document Under Development and User Change Control
Document Under Development and User Change Control