View
216
Download
1
Category
Tags:
Preview:
Citation preview
James Nowotarski
26 September 2006
SE 325/425Principles and
Practices of Software Engineering
Autumn 2006
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
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
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
5
The waterfall model is the granddaddy of life cycle models
Waterfall
Planning
Modeling
Construction
Deployment
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?
7
Why focus on change?
Life cycle phase
Co
st
of
ch
an
ge
Req Anal. Des. Impl. Test Prod
y = axp
8
RUP Guiding Principles
IterativeDevelopment
QualityCustomerValue
Attack riskAccommodatechange
Work togetherExecutablesoftware
Architecturebaseline
Component-baseddevelopment
Objectives
Strategies
Tactics
9
RUP “Hump” Diagram
10
Inside each phase, you plan iterations across disciplines
11
Phase boundaries in waterfall are activities
Systemrequirements
Softwarerequirements
Analysis
Program design
Coding
Testing
Operations
Phase
Phase
Phase
Phase
Phase
Phase
12
Phase boundaries in RUP are milestones
Systemrequirements
Softwarerequirements
Analysis
Program design
Coding
Testing
Operations
RUP Phase
Milestone
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)
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
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
16
RUP Guiding Principles
IterativeDevelopment
QualityCustomerValue
Attack riskAccommodatechange
Work togetherExecutablesoftware
Architecturebaseline
Component-baseddevelopment
Objectives
Strategies
Tactics
17
XP Conceptual Framework
IterativeDevelopment
QualityCustomerValue
Attack riskAccommodatechange
Work togetherExecutablesoftware
Architecturebaseline
Component-baseddevelopment
Objectives
Strategies
Practices
18
Phase boundaries in RUP are milestones
Systemrequirements
Softwarerequirements
Analysis
Program design
Coding
Testing
Operations
RUP Phase
Milestone
19
XP winds the RUP model more tightly
Systemrequirements
Softwarerequirements
Analysis
Program design
Coding
Testing
Operations
Each day on an XP project
FunctioningCode
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
21
What is XP
“What is the simplest thing that could possibly work?”
Flattened change curve
Assume SimplicityEmbrace Change
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
23
What is XP
Quality is assumedExcellent, orInsanely excellent
Quality Work
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
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.)
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 . . .
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
28
“The basic problem of software development is risk”
Beck, K. (2000). Extreme Programming Explained. Boston, MA: Addison-Wesley
Risk management
29
What is risk?
something that could go wrong Problem that may occur
Proactive vs. reactive risk management
Don’t worry, I’ll think of something!!
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;
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.
34
Categories of software risk
Project Technical Business Legal
Threaten the project plan• Customers• Resources & personnel• Inexperienced management
team• Requirements• Complexity• Size
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
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
37
Categories of software risk
Project Technical Business Legal
• Shareholder lawsuits• Data privacy• Breach of services (third
party solutions provider)
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
39
“It is futile to try to eliminate risk”
-- Peter Drucker, management guru
Risk management
40
Risk management process
Identify Analyze Plan
Cost of protection Cost of exposure
$$ $$
Control
41
Risk management process: artifacts
Identify Analyze Plan Control
• List of risks • Probability• Impact• Cutoff• Risk exposure
• Mitigation plan• Monitoring plan• Contingency plan
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
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?
44
Risk management process
Identify Analyze Plan Control
• List of risks • Probability• Impact• Cutoff• Risk exposure
• Mitigation plan• Monitoring plan• Contingency plan
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!
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)
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
49
Risk planning
Identify Analyze Plan Control
• List of risks • Probability• Impact• Cutoff• Risk exposure
• Mitigation plan• Monitoring plan• Contingency plan
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
51
Risk control
Identify Analyze Plan Control
• List of risks • Probability• Impact• Cutoff• Risk exposure
• Mitigation plan• Monitoring plan• Contingency plan
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
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
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
55
Monitoring
walkthroughs External party review project Test results (backlog of change
requests, user signoffs, etc.) # users trained, competency
assessment
56
Contingency Planning
do one Fallback plan to existing system
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?
58
Read Pressman Chapter 7 Assignment 2 (Risk Management exercise, see course home page) Current Event Reports:
KACZANKOPHAMSHERMANYOCOM-PIATT
For October 3
59
Extra slides
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
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:
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
Recommended