USC
C S E
University of Southern California
Center for Software Engineering
Supannika Koolmanojwong
Based on Donald J. Reifer’s lecture
Copyright RCI, 2005 1
Copyright RCI, 2005 2
USC
C S E
University of Southern California
Center for Software Engineering
Other silver bullets
Reuse/patterns
Streamlined processes
Agile methods
Architecture-first
COTS-based systems
Process paradigms
Experience factory
Metrics-based management
Component-based composition
Best engineering practices
Extreme programming Product-lines
Searching for ways to do the job faster, better and cheaper
Copyright RCI, 2005 3
USC
C S E
University of Southern California
Center for Software Engineering
• As understood by most, engineering decisions involve many options and difficult tradeoffs
– May be several technical solutions for the problem
– The best technical solution is determined by evaluating the tradeoffs using a variety of criteria selected for that purpose
• Software engineering provides you the methods and tools to understand the tradeoffs and select the best answer (typically under constraints)
– Management rejects many of these recommendations because the business benefits are not quantified
Copyright RCI, 2005 4
USC
C S E
University of Southern California
Center for Software Engineering
• Common definition of costs and benefits not widely accepted across the industry
• Productivity
, cost and quality data considered highly confidential and kept secret
• Common definition of the justification processes involved lacking within the engineering community
• Difficult to attribute resulting numbers to one cause or another
• Hard to communicate results engineers talk technical, decision-makers talk business
• Goal of the lecture is to help you communicate better
Copyright RCI, 2005 5
USC
C S E
University of Southern California
Center for Software Engineering
Reduce Avoid/Cut
Time to Market Cost
Improve
Customer
Satisfaction Productivity
Increase
Quality
Improve
There needs to be some compelling business reason for making an improvement, else it won’t be approved
Copyright RCI, 2005 6
• How can we introduce the changes / improvement to the organization ?
• Will they believe my idea?
• Are they going to listen to me?
7
8
Stage in Life Cycle
Innovators
Early adopters
Early majority
Late majority
Laggards
Organizations’ Characteristics
Risk takers
Develop new technology
Push the envelope
Trend setters
Advance technology
Will take high risks when justified
Innovators
Take moderate risks
Followers
Exploit technology
Take limited risks
Critics
Use proven technology
Risk averse
Copyright RCI, 2005 9
USC
C S E
University of Southern California
Center for Software Engineering
1. Establish improvement objectives
2. Improvement proposal collection & analysis
3. Identify innovations
4. Perform cost/benefit analysis
5. Perform pilot
6. Select candidate improvements
7. Provide feedback
Source : Ahern, CMMI Distilled
Copyright RCI, 2005 10
USC
C S E
University of Southern California
Center for Software Engineering
• Lack of incentives • Reward system must be altered
• “Good of the firm” versus “Good of the project”
• Infrastructure shortfalls
• Few meaningful metrics
• Limited cash available
• Reward system must be altered to emphasize “good of firm”
• Policies, processes and decision making structure changes
• Must collect data to quantify impact of changes
• To get funded, must make compelling business case
Copyright RCI, 2005 11
USC
C S E
University of Southern California
Center for Software Engineering
• Keeping up with the competition
–
Playing catch-up is always a motivation for change
• Achieving economic benefits
–
Having a compelling business reason also works
• Supporting new product needs
–
Tying change to a product need justifies investment
• Avoiding legal entanglements
–
Sometimes changes are needed to comply with the law
• Achieving efficiencies
–
Streamlining/simplifying process also justifies change
Copyright RCI, 2005 12
USC
C S E
University of Southern California
Center for Software Engineering
• Organizations fight changes for many reasons
MIDDLE
MANAGEMENT
BARRIERS
ISLAND
CULTURE
WHY CHANGE-
WE’RE SUCCESSFUL
CUSTOMER
INCENTIVES
HACKER
MENTALITY
IGNORANCE
IS BLISS
NEVER
ENOUGH $$
NEVER
ENOUGH TIME
NOT INVENTED
HERE (NIH)
Copyright RCI, 2005
MIDDLE
MANAGEMENT
BARRIERS
13
USC
C S E
University of Southern California
Center for Software Engineering
• Examine the following:
– Consistency with business goals/cycle
– Compatibility with level of process maturity
– Consistency with corporate culture
– Compatibility with investment strategies
– Achievability within desired timetable
• If warranted, be willing to take the risk
– The opportunity should be justifiable in terms of the risk/returns
Copyright RCI, 2005 14
USC
C S E
University of Southern California
Center for Software Engineering
Entrepreneurial Culture
• Seeks opportunity for improvement
• Action-oriented and willing to take risks
• Team-oriented
• Rewards innovation
• Learns from failure
• Creative, imaginative, pliant and flexible
Old-Fashioned Culture
• Prefers the status quo
• Avoids change and risk
• Territorial by nature
• Rewards followers, not innovators
• Penalizes failure
• Persistent, authoritative and rigid
Copyright RCI, 2005 15
USC
C S E
University of Southern California
Center for Software Engineering
1. Tie improvement to organizational goals
2. Emphasize making product-oriented improvements
3. Demonstrate value that justifies improvements
5. Recognize major barriers to change are primarily political and psychological
6. Change your culture to one that rewards risktaking
7. If you don’t have the talent, buy it
4. Make your new processes the way you do business
8. Use numbers to overcome post-decision dissonance
Copyright RCI, 2005 16
USC
C S E
University of Southern California
Center for Software Engineering
Answer Basic Business-Related Questions
• Will this proposal save money , cut costs , increase productivity , speed development or improve quality ?
• Have you looked at the financial and tax implications of the proposal?
• What’s the impact of the proposal on the bottom line?
• Are our competitors doing this? If so, what are the results they are achieving?
• Who are the stakeholders and are they supportive of the proposal?
+ Many more tough questions
Copyright RCI, 2005 17
USC
C S E
University of Southern California
Center for Software Engineering
• Business Case = the materials prepared for decisionmakers to show that the proposed idea is a good one and that the numbers that surround it make sound financial sense
– Most software engineers prepare detailed technical rather than business justifications
– Many of their worthwhile proposals are rejected by management as a consequence
– Use of business cases to complement the technical case can greatly increase their chances of success
Copyright RCI, 2005 18
USC
C S E
University of Southern California
Center for Software Engineering
Factors (5 is best)
Core language features
Java
2
- Degree of standardization & portability 3
- Object-oriented support 3
- Reuse facilities (library, browser, etc.) 3
- Web programming support
- Optimizing compilers available
- Bindings available
- Rich libraries available
5
4
5
4
- Compiler support tools available
- Inexpensive visual tools available
- Oriented toward your products
Score
4
5
5
43
Copyright RCI, 2005
3
44
5
3
5
4
2
5
C/C++
4
4
5
4
19
USC
C S E
University of Southern California
Center for Software Engineering
Factors (5 is best)
- Popularity - improve resumes
- Training opportunities available
- Literature and books available
- Consultants & subcontractors available
Java C++
5 5
5
5
5
4
5
5 with language skills
- Staff maintains competency in language/tools
- Retooling and retraining costs
- Transition costs associated with learning
2
1
1
4
5
5 curve (bring staff up to speed)
Subtotal
___ ___
24 33
Combined Score 67 77
Copyright RCI, 2005 20
USC
C S E
University of Southern California
Center for Software Engineering
1. Prepare white paper
GQM Results
Idea or proposal
7. Get ready to execute
2. Demonstrate technical feasibility
6. Sell the idea and develop support base
Proof of
Concept
3. Conduct market survey
5. Prepare business case
4. Develop business plan
Copyright RCI, 2005
Approval to go-ahead
21
USC
C S E
University of Southern California
Center for Software Engineering
Goal - successful technology transition
Q1 - ready for use?
Q2 - benefits quantified?
M1 - availability of tools M1 - cost avoidance in $
M2 - availability of M2 - time-to-market delta training
M3 - availability of
M3 - quality delta methods
M4 - availability of infrastructure
Use the G-Q-M
Paradigm
Copyright RCI, 2005
Q3 - costs of use understood?
M1 - startup costs
M2 - operational costs
M3 - opportunity costs
22
USC
C S E
University of Southern California
Center for Software Engineering
1. Prepare white paper
– State what you are trying to do crisply
2. Demonstrate technical feasibility
-
Let’s you prove the idea’s value
Provide management with early evidence that you can deliver what you promised them
3. Conduct market survey
– Determine the market need for your idea
– Understand what the competition is doing and what your customers want
– Focus on market creation, not sharing
– Get to market first, be agile and take risks that allow you to seize the opportunity
Copyright RCI, 2005 23
USC
C S E
University of Southern California
Center for Software Engineering
4. Develop business plan
–
Needed before idea will be funded
–
Such plans summarize how you will make or save money, not how you’ll get the job done
5. Prepare business case
–
Convince sponsor idea makes both good technical and business sense and provides value
6. Sell the idea
– Package for sales/champion
7. Get ready to execute
– Plan the project thoroughly
(your project plan)
– Start recruiting key staff
– Work communications and outreach up front
– Search out facilities to colocate team and for conducting demos
– Prepare your operational concepts (support, etc.)
Copyright RCI, 2005 24
USC
C S E
University of Southern California
Center for Software Engineering
Process
Framework
The business planning process proceeds in parallel and interfaces with the software development process
Business Planning Process
Tradeoff and Analysis Processes
Software Development Process
Analytical
Methods
Models Guidelines for
Decision-Making
“Principles, Rules and Tools for Business Case Development”
Copyright RCI, 2005 25
Copyright RCI, 2005 26
Copyright RCI, 2005 27
USC
C S E
University of Southern California
Center for Software Engineering thinking about running a seminar.
1.
Decisions should be made relative to alternatives
2.
If possible, use money as the common denominator
6.
Decisions should consider qualitative factors
7.
The risks associated with
3.
Sunk costs are irrelevant
4.
(Engineering Econ 101)
Investment decisions should recognize the time value of money
5.
Separable decisions must be considered separately quantified if possible
Already ran a java seminar last year ?
8.
The timing associated with making decisions is critical
Any better option ?
9.
Decision processes should different criteria, don’t mix them up. be periodically assessed and continuously improved
Copyright RCI, 2005 28
USC
C S E
University of Southern California
Center for Software Engineering thinking about running a seminar.
6.
Decisions should consider both quantitative and qualitative factors
7.
The risks associated with the decision should be quantified if possible
8.
The timing associated with making decisions is critical
9.
Decision processes should be periodically assessed and continuously improved
Copyright RCI, 2005
Training seminar might improve image and morale.
What if no trainer available , any back up plan ? What is the extra cost?
Time your decision carefully.
Any budget cycle ?
Propose when there is money available.
Keep your eyes open, look for possible improvement.
29
USC
C S E
University of Southern California
Center for Software Engineering
• Address the cultural issues first - they’re the hardest
• Keep senior management informed of your progress
• Build alliances with both projects and people
• Publicize successes and spread the word widely
• Mix it with the middle managers and critics
• Don’t be afraid to change horses in mid-stream
• Deliver something that you can brag about
• Be perceived as successful by others (perception is reality)
• Work continuously to improve the infrastructure you’ve set up to manage the initiative and transfer the technology
Copyright RCI, 2005 30
USC
C S E
University of Southern California
Center for Software Engineering
FW = P (1 + i) N PV = FW/(1 + i) N
Future Worth
• Takes cost of money into account
– A
$$ today is worth more than tomorrow due to inflation
• Takes compounding into account
Present Value
• Normalizes future expenditures using current year dollars as a basis for comparison
• Lets you establish a minimum attractive rate of return
Copyright RCI, 2005 31
Present Value Calculation for Training Example
• Cost of Money or Interest rate = 8%
• Assuming that the training will reduce the personnel turnover by from 6% to 3%
• Reduce lost in productivity $35K a year
2
3
Year Training Cost Benefits Net Benefits 1/(1+i) N
1 $25K $35K $10K 0.9259
4
$25K
$25K
$25K
$35K
$35K
$35K
$10K
$10K
$10K
$40K
0.8573
0.7938
0.7350
Present Value
$9259
$8753
$7938
$7350
$33120
Copyright RCI, 2005 32
2
3
Year Training Cost Benefits Net Benefits 1/(1+i) N Present Value
1 $25K $35K $10K 0.9259
$9259
4
$25K
$25K
$25K
$35K
$35K
$35K
$10K
$10K
$10K
$40K
0.8573
0.7938
0.7350
$8753
$7938
$7350
$33120
• ROI = net benefit / investment
• = $40,000 / $100,000 = 40% or 10% annually
Good choice ?
10% annually for manager – may not be a good idea
Put in the bank, no risks – get 8%
What can we do ?
Copyright RCI, 2005 33
USC
C S E
University of Southern California
Center for Software Engineering
Source: Boehm, Software
Engineering Economics
Analysis Techniques
•
Balanced scorecard
•
Break-even analysis
•
Cause and effect analysis
•
Cost/benefit analysis
•
Opportunity tress
• Pareto analysis
• Payback analysis
• Portfolio analysis
•
Real options theory
• Return-on-Investment/Capital
• Risk analysis (exposure)
• Sensitivity analysis
• Trend analysis
• Value chains
Copyright RCI, 2005 34
Used by managers to keep track of the execution of activities by the staff within their control and to monitor the consequences arising from these actions http://www.balancedscorecard.org/BSCResources/AbouttheBalancedScorecard/tabid/55/Default.aspx
35
http://www.biztoolspro.com/functions/BreakevenAnalysis.htm
36
2
3
Year Training Cost Benefits Net Benefits 1/(1+i) N Present Value
1 $25K $35K $10K 0.9259
$9259
4
$25K
$25K
$25K
$35K
$35K
$35K
$10K
$10K
$10K
$40K
0.8573
0.7938
0.7350
$8753
$7938
$7350
$33120
To determine the number of periods required to recover one’s investment
Payment period = investment /net savings
=($25K) / ($10K/year)
= 2.5 years
= the payback period for the first year’s investment is 2.5 years
Copyright RCI, 2005 37
USC
C S E
University of Southern California
Center for Software Engineering
• Want to bring in training to support PSP/TSP initiative
• How would you justify the investment?
– Should you use cost/benefits , quality improvement or some other approach?
• How would you pay for the training?
– Is this a capital, project or customer expense?
• What are the windows of opportunity and how would you take advantage of them?
– Can you influence next year’s training budget?
– Is there State funds available? Can we partner? Is there mid-year or year-end funds available?
Copyright RCI, 2005 38
USC
C S E
University of Southern California
Center for Software Engineering
Cost/Benefit Ratio = PV (Total costs ($)/Total Benefits ($))
• Non-recurring costs
– Course acquisition ____
– Course conduct
____
Total ____
• Recurring costs
– Course maintenance ____
– Continuing education ____
Total ____
Total Costs ____
Copyright RCI, 2005
• Tangible savings
– Cost avoidance ____
– Cost savings ____
Total ____
• Intangible savings
– Reduced turnover ____
– Less risk exposure____
Total ____
Total Benefits ____
39
USC
C S E
University of Southern California
Center for Software Engineering
Defect Prevention
Decrease
Defect
Prob (Loss)
Defect Detection and Removal
Decrease
Defect
Risk
Exposure
Decrease
Defect
Impact,
Size (Loss)
Value/Risk - Based
Defect Reduction
Graceful Degradation
Source: Boehm
Continuous
Improvement
Copyright RCI, 2005
CI Methods and Metrics
Process, Product, People
Technology
40
USC
C S E
University of Southern California
Center for Software Engineering
- Loss due to unacceptable dependability
Many defects: high P(L)
Critical defects: high S(L)
Risk
Exposure
(RE)
Few defects: low P(L)
Minor defects: low S(L)
Time to Ship (Amount of Testing)
Source: Boehm
Copyright RCI, 2005 41
USC
C S E
University of Southern California
Center for Software Engineering
Loss due to unacceptable dependability
- Loss due to market share erosion
Many defects: high P(L)
Critical defects: high S(L)
Many rivals: high P(L)
Strong rivals: high S(L)
RE
Few rivals: low P(L)
Weak rivals: low S(L) Few defects: low P(L)
Minor defects: low S(L)
Time to Ship (Amount of Testing)
Copyright RCI, 2005
Source: Boehm
42
USC
C S E
University of Southern California
Center for Software Engineering
Sum of Risk Exposures
Many defects: high P(L)
Critical defects: high S(L)
Many rivals: high P(L)
Strong rivals: high S(L)
RE Sweet
Spot
Few rivals: low P(L)
Weak rivals: low S(L) Few defects: low P(L)
Minor defects: low S(L)
Time to Ship (Amount of Testing)
Copyright RCI, 2005
Source: Boehm
43
USC
C S E
University of Southern California
Center for Software Engineering
• Why should they invest in training instead of other alternatives?
– There needs to be a compelling business reason, else why make the effort
– This must be the most attractive option examined
• Why invest now instead of some later time?
– Need to show opportunity is knocking & funds are available
• What do I have to do if I say “yes” to the proposal?
– Must show them that their efforts will be minimal; you’ve done all of the leg work and all they have to do is sign
Copyright RCI, 2005 44
USC
C S E
University of Southern California
Center for Software Engineering
Software packages
• Decision support systems
– Tax planning and schedules
– Trade studies and analysis
• Spreadsheets
– Comparative analysis
– Trade studies and analysis
• Software cost models
– Parametric analysis
– Trade studies and analysis
Copyright RCI, 2005 45
USC
C S E
University of Southern California
Center for Software Engineering
Sizing
Model
Estimating
Model
Risk
Model
* Benchmark analysis * Parametric analysis
* Comparative analysis * Trade studies
* Life cycle cost analysis * “What-if” analysis
Copyright RCI, 2005 46
USC
C S E
University of Southern California
Center for Software Engineering
• Business cases
– Recurring costs
– Non-recurring costs
– Tangible benefits
– Intangible benefits
• Benchmarks
– Competitive comparisons
– Industry norms
• Metrics
– Management measures
• Financial data
– Inflated labor costs
– Labor categories/rates
– Overhead/G&A rates
– Past costs/performance
– Tax rates/legalities
• Marketing information
– Demographic data
– Market position
– Sales forecast
Copyright RCI, 2005 47
USC
C S E
University of Southern California
Center for Software Engineering
Things to Do
• Justify using cost avoidance not reduction
• Keep cost & productivity considerations separate
• Tap money when it becomes available
• Know what cost you can control and who controls the others
• Package numbers for consumption by seniors
Things Not to Do
• Don’t assume the numbers won’t be scrutinized
• Don’t assume you know what your current costs are and how they are allocated to cost centers
• Don’t confuse management by combining cost and profit in same proposal
• Don’t mix cost accounts when justifying ideas
Copyright RCI, 2005 48
USC
C S E
University of Southern California
Center for Software Engineering
• Convincingly summarize the numbers at the start
• Define your terms precisely - communicate meaning using examples
• Be conservative with your numbers
• Quantify tangible benefits in monetary terms
• Don’t mix capital expenditures with project budgets
• Use ranges for cost/benefits whenever possible
• Portray the PV of your benefits in this year’s dollars
• Focus attention on the business, not technical issues
Copyright RCI, 2005 49
USC
C S E
University of Southern California
Center for Software Engineering
• They are like elephants, they never forget a number once uttered
• They will hear only what they want to hear
• Simple is better package charts with at most five bullets
Copyright RCI, 2005 50
USC
C S E
University of Southern California
Center for Software Engineering
• Numbers can be your ally when asking for money
• When talking money, speak your management’s language not your own
• Don’t be casual about numbers, be precise
• To be successful, be perceived as successful
Copyright RCI, 2005 51
USC
C S E
University of Southern California
Center for Software Engineering
• Purpose of case
– Justify investments in process improvement
• Goals of effort
– Develop numbers that get management to buy into near- and long-term investment tactics
• Constraints
– Deal with the firm’s related process improvement folklore, biases and history
Copyright RCI, 2005 52
USC
C S E
University of Southern California
Center for Software Engineering
Your home
Senior Management
Aerospace firm
QA Group
Process Group
Senior Staff
Engineering Manufacturing Field Support Program Mgmt
* Systems
* Software
* Fabrication
* Assembly
* Digital design * Production
Project A
* Field service
* Training
* Test & evaluation
Copyright RCI, 2005
Line of Business
Management
* Fund functional groups
* Coordinate
* Facilitate
53
USC
C S E
University of Southern California
Center for Software Engineering
Maturity Level
5
4
Level 3 a customer requirement
3
Process budget axed
Acquisition falls through
Aim- Reach
Level 4 in 2 years
Firm positioned to be acquired
Seniors get serious about process
2
1
Reach Level 3 corporate goal
Process group reformed
1985 1987 1989 1991 1993 1995 1997 1999 Now
Copyright RCI, 2005 54
USC
C S E
University of Southern California
Center for Software Engineering
• Used by many to characterize the maturity of the processes used to develop software
• Important because:
– Employed as a means to benchmark firms
– Acts as a framework for structuring improvements
– Shown to have positive effect on productivity, quality and cost
– Makes it easier to tackle a big software job like the one you are working on
Copyright RCI, 2005 55
2
4
5
Defect prevention
- Technology change management
- Process change management
Quantitative process management
- Software quality management
3
Organization process focus
- Organization process definition
- Training program
- Integrated software management
- Software product engineering
- Inter-group coordination
- Peer reviews
Requirements management
- Software project planning
- Software project tracking and oversight
- Software subcontract management
- Software qualify assurance
- Software configuration management
Contains:
- 5 Maturity Levels
- 18 Key Process Areas
- 318 Key Practices
Copyright RCI, 2005 56
USC
C S E
University of Southern California
Center for Software Engineering
• Takes 18 to 30 months to move a maturity level
–
From Level 1 to 2 - average of 23 months
–
From Level 2 to 3 - average of 21 months
– From Level 3 to 4 - average of 28 months
• Average investment to move up a maturity level is several million
• The gains attributable to early error detection and correction are substantial (20X cheaper)
• The average increase in productivity attributable to process improvement is 10 percent
Copyright RCI, 2005 57
USC
C S E
University of Southern California
Center for Software Engineering
Strategy
Discipline the
Software Process
Standardize
Products
Professional workforce
Quicken use of new technology
* Proactive, not * Architecture* Career paths * Project sponsors reactive based * Skill-based for IR&D
* Optimizing * Massive reuse education and * Good idea
* CMM-based * Open systems training programs
* ISO-certified * Product lines * Distance * Technology
* Components learning roadmap
Copyright RCI, 2005 58
USC
C S E
University of Southern California
Center for Software Engineering
• Overall experience
– Workforce averages 20 years experience
• Staff capabilities and morale
– Good - newcomers more open to change
• Education & training
– Myriad of training opportunities available
• World-class facilities and environment
– Undercapitalized, but making improvements primarily to reduce personnel turnover
• Technology adoption
– IR&D for software tripled after major client criticized management
Copyright RCI, 2005 59
USC
C S E
University of Southern California
Center for Software Engineering
• Let the numbers do the talking
• Don’t assume that Program Managers understand software (they are clue-less)
• Justifications must be made at the project level
• You must address past experience, both pro & con
• Your plan must focus on near-term results
• Any software processes must be compatible with your existing management infrastructure
• You must track/demonstrate accomplishment of goals
Copyright RCI, 2005 60
USC
C S E
University of Southern California
Center for Software Engineering
Manager
(New)
Process
Developer
(Vacant)
Process
Developer
(Vacant)
Metrics
Analyst
(New)
Project
Liaison
(Consultant)
Project
Liaison
(Consultant)
Curriculum
Developer
(Part-Timer)
Curriculum
Developer
(Part-Timer)
Copyright RCI, 2005 61
USC
C S E
University of Southern California
Center for Software Engineering
Why (Goal): Increase Productivity and Meet Customer Requirements
Questions: Measured What how? option?
Why this option?
Metrics:
Models:
SLOC/hour Do Process Other ROI
Nil improvement approach
COCOMO SEI Maturity Non-discounted
Model ROI
Copyright RCI, 2005 62
USC
C S E
University of Southern California
Center for Software Engineering
1. Involve the
Stakeholders
* Expectations
* Measures of success
Pilot results
2. Develop a vision and strategy
Positive public relations
5. Promote the results
4. Build partnerships
Vision statement
3. Define the work to be performed
Copyright RCI, 2005
* WBS dictionary
* Game plan
63
USC
C S E
University of Southern California
Center for Software Engineering
• Process development
• Education & training
• Process roll-out/project support
• Process assessment
• Promotion & outreach
• Support environment
1.1 Write processes/practices
1.2 Review processes/practices
1.3 Improve process/practices
2.1 Develop/update courseware
2.2 Conduct courses
3.1 Pilot processes/gather feedback
3.2 Provide support to projects
3.3 Deploy metrics/statistical controls
3.4 Perform statistical analysis
4.1 Conduct periodic assessments
5.1 Promote results
5.2 Publish newsletter, articles, and so on
6.1 Establish web site
6.2 Establish process asset library
Copyright RCI, 2005 64
USC
C S E
University of Southern California
Center for Software Engineering
• Process development
– 4 employees ($700K)
• Education & training
– 2 part-timers ($200K)
– $250K for seminars
• Process roll-out/project support
– 2 consultants ($450K)
– Retirees with credibility
• Process assessment
– $200K for outside facilitator
• Promotion and outreach
– $250K to prepare newsletter, work with clients and attend conferences
• Support environment
– $350K for web site development
Copyright RCI, 2005 65
USC
C S E
University of Southern California
Center for Software Engineering
• Process development
• Transition
• Deployment
• CM
• QA
• Distribution management
• User support
• Exploit industry experience by hiring outside assessment firm
• Pilot to demo feasibility, do things middle managers think important
• E&T JIT; dedicated project liaisons
• Steering group CCB; shared/reused assets distinction
• Use process to assure processes
• Access via web site
• FAQ; metrics; dedicated support for users
Copyright RCI, 2005 66
USC
C S E
University of Southern California
Center for Software Engineering
• Justify process budget by:
– Showing the impact of accelerating productivity improvement from 10% to 20% annually
– Looking at impact of early error detection/correction
– Assessing the impact of COTS usage strategy
– Evaluating the impact of moving to an architecture-based reuse strategy
• Show intangibles as added value
Copyright RCI, 2005 67
USC
C S E
University of Southern California
Center for Software Engineering
Year 1
100
Year 2
110
Year 3
121
Year 4
133 Current productivity
(SLOC/staff-month)
(10% nominal gain)
Accelerated gain (20%)
Additional number of
SLOCs that can be generated via acceleration assuming
600 engineers
Cost avoidance
($50/SLOC)
Cumulative cost avoidance
120
72,000
$3.6
million
$3.6
million
144
165,600
$8.3
million
$11.9
million
173
288,000
$14.4
million
$26.3
million
Year 5
146
208
446,400
$22.3
million
$48.6
million
Conservative estimate of savings is $4 million/year
Copyright RCI, 2005 68
USC
C S E
University of Southern California
Center for Software Engineering
• Cost and productivity are related, but are influenced by different factors
• To increase your productivity, you should address:
– Staff skills/expertise, process maturity and tools
• To reduce cost, you should attack:
– Overhead, scope of the job and efficiencies
• There are cases where improvements in your productivity result in increased costs
Copyright RCI, 2005 69
USC
C S E
University of Southern California
Center for Software Engineering
• Benefit of achieving Level 4 is a reduction in errors by a factor of between 20 and 25%
– Majority caught early in requirements and design phases
• Cost avoidance associated with early defect removal is
$20/defect
• For the 12 major programs in your firm, you compute cost avoidance is 1.2 million calculated as follows:
(12 jobs/year)(10 defects 1 /KSLOC)(500KSLOC/job) = 60Kdefects/year
(60K defects/year)($20/defect (avoidance)) = $1.2 million/year
1 As jobs enter test and evaluation; goal is 0.1 defect/KSLOC on delivery
Copyright RCI, 2005 70
USC
C S E
University of Southern California
Center for Software Engineering
• Benefits of enterprise-wide licensing can be substantial
– At the corporate level, this includes major software packages like DBMS
– At the project level, this includes software tools and specialized software like operating systems
• As part of your Level 4 initiative, you plan to put in a licensing process that allows you to lever your buying power and save $1 million/year
Copyright RCI, 2005 71
USC
C S E
University of Southern California
Center for Software Engineering
Pluses
• Cheaper; but does not come for free
• Available immediately
• Known quality (+ or -)
• Vendor responsible for evolution/maintenance
– Don’t have to pay for it
• Can use critical staff resources elsewhere
Minuses
• License costs can be high
• COTS products are not designed to plug & play
• Vendor behavior varies
• Performance often poor
• Vendor responsible for evolution/maintenance
– Have no control over the product’s evolution
Copyright RCI, 2005 72
USC
C S E
University of Southern California
Center for Software Engineering
• Successful firms:
– Make COTS-based system tradeoffs early
– Try before they buy
– Avoid modifying COTS at all costs
– Reconcile products with their architectures
– Emphasize use of standards and open interfaces
– Understand that COTS doesn’t come for free
– Plan to manage parts/technology obsolescence
– Make the vendor a part of the team, whenever possible
– Negotiate enterprise-wide licenses for COTS products
– Influence future paths the vendor will take
– Address the cultural and process issues
Copyright RCI, 2005 73
USC
C S E
University of Southern California
Center for Software Engineering
• Process
– Merge COTS life cycle into your organizational framework
– Make needed tradeoffs
– Think both technical and business issues
• Products
– Fit COTS components into product line strategies
– Maintain open interfaces
– Manage technology refresh
• People
– Make COTS vendors a part of your team
– Increase awareness of COTS experience
– Provide workforce with structure and information
• Institutional
– Improve purchasing and licensing processes
– Maintain market watch
– Capture past performance
Copyright RCI, 2005 74
USC
C S E
University of Southern California
Center for Software Engineering
• Architectures are the framework you use to pull your product lines together
– They are domain-specific and standards-based
– They encapsulate generality and variability
• They guide selection and use of high-leverage assets
– The 20% responsible for 80% of the reuse
• They allow you to take full advantage of both COTS components and reusable assets
– Cost to build for reuse must be factored into analysis
– Benefits of reuse adhere to the 3 times rule
Copyright RCI, 2005 75
USC
C S E
University of Southern California
Center for Software Engineering
Operational Architecture
- Information needs
- User functions
- Performance bounds
System Architecture
- Components and topology
- Networks and connectivity
- Capacity/performance
Technical Architecture
- Information processing standards
- Human-computer interface standards
Copyright RCI, 2005 76
USC
C S E
University of Southern California
Center for Software Engineering
Mathematical libraries
Activity
Managers
Measurement
Functions
Sensor
Manager
Libraries
Posix kernel Multi-threading executive
Inputs
Platform
Copyright RCI, 2005 77
USC
C S E
University of Southern California
Center for Software Engineering
Purchased products
Domain Model
Domain
Analysis
Products for sale
Domain
Design
Asset
Development
Scope
Assets
Domain Engineering
Requirements Architecture
Software Reuse Library
Assets
Requirements Software Integration Operations &
Analysis Development & Test Maintenance
Applications Engineering
Copyright RCI, 2005
Project-specific deliverables
78
USC
C S E
University of Southern California
Center for Software Engineering
ESLOC = ASLOC [AA + AAF(1 + 0.02(SU)(UNFM))] AAF < 0.5
100
ESLOC = ASLOC [AA + AAF + (SU)(UNFM)]
100
Where: AAF = 0.4 (DM) + 0.3 (CM) + 0.3 (IM)
SU = Software Understanding
(zero when DM = 0 & CM = 0)
UNFM = Programmer Unfamiliarity
AA = Assessment and Assimilation
ASLOC = Adapted SLOC
ESLOC = Equivalent new SLOC
Copyright RCI, 2005
AAF > 0.5
79
USC
C S E
University of Southern California
Center for Software Engineering
Application
Real-time executive
Scheduler
Real-time data acquisition
Sensor data processing
Data analysis and alarms
TOTAL
Without Reuse
10,000
25,000
50,000
50,000
25,000
160,000
With Reuse
500
500
10,000
21,000
10,000
42,000
Nominal Development Time (months)
Nominal Effort (staff-months)
Shortest Development Time (months)
Shortest Development Time Effort
Without Reuse
30
845.3
22.5
1208.7
With Reuse
23.4
383.7
17.6
548.7
Conservative estimate of savings is $10 million/year
Copyright RCI, 2005 80
USC
C S E
University of Southern California
Center for Software Engineering
•
Non-Recurring Costs
– Domain engineering - done on
IR&D
– Reusable assets - project funded
– Infrastructure development - done by process group
•
Recurring Costs (per year)
– Architecture maintenance $200K
– Asset maintenance 500K
– Process updates 100K
•
Tangible Benefits
– Cost avoidance $10 million
•
Intangible Benefits
– Deliver 12 months earlier than the norm
– 10 times reduction in efforts at delivery
– Architecture stable, proven and can be demonstrated to clients
– Scheduling algorithms can be optimized and improved
Total Costs $800K Total Benefits $10 million
Copyright RCI, 2005 81
USC
C S E
University of Southern California
Center for Software Engineering
Early Error Reduction
• Cost avoidance = $1.2M/year
• Increased customer satisfaction based on quality
Systematic Reuse
• Cost avoidance = $10M/year
• Faster to market
• 10X quality
• Just starting – expect to reap benefits within 3 years
• Process can be built with reuse in mind
Exploitation of COTS
• Cost avoidance = $1M/year
• Improved maintenance and license leverage with vendors
Productivity Improvement
• Cost avoidance = $4M/year
• Improved capabilities & capacity
Copyright RCI, 2005 82
USC
C S E
University of Southern California
Center for Software Engineering
Tangibles
ROI = Annual Benefits
Investment
ROI = $6.2M
$2.4M
ROI > 250% per year
Assumptions : cost avoidances on page 3 realized with exception of reuse which kicks in after we reach CMM level 4.
Intangibles
• Better product quality
• Quicker to market
• Increased customer satisfaction
• Improved employee morale
• Responds directly to customer requirements
Copyright RCI, 2005 83
USC
C S E
University of Southern California
Center for Software Engineering
• Reaching Level 4 will take 2 years assuming things go as planned
• The major challenge is to get those in the middle on our side (bonus is a good start)
• There are a number of operational challenges
–
Need help in staffing process group – getting requisitions through the system is tedious
–
Need help in licensing – buyer, legal and staff support
• Must keep the momentum moving
Copyright RCI, 2005 84
USC
C S E
University of Southern California
Center for Software Engineering
• Process improvement is a good investment
• To get management support, a good action plan and solid business case is needed
• When justifying initiatives, cost avoidance is preferred to cost reduction
• When determining benefits, categorize them as tangibles and intangibles
• Be conservative, but make your case using the numbers to justify the investments
Copyright RCI, 2005 85
USC
C S E
University of Southern California
Center for Software Engineering
• Numbers can be your ally when asking for money
• When asking for money, talk your management’s language not yours
• Don’t be casual about numbers, be precise
• To be successful, be perceived as successful
Copyright RCI, 2005 86
USC
C S E
University of Southern California
Center for Software Engineering
Guidelines
• Change only if it makes good business sense
• Don’t become enamored with the technology
• Get everyone involved - but not too involved
• Focus changes on product developments
• Look to the future, not the past (sunk costs)
• Be patient and don’t reinvent the wheel
• Do the easy things first to establish credibility
• Be satisfied with a 90 percent solution
• The sum of many small successes is a big success
Copyright RCI, 2005 87
USC
C S E
University of Southern California
Center for Software Engineering
• Talk like a business-person
– Translate technical jargon into business goals
• Act as a business-person
– Assess both the business and technical aspects of the proposal
– Show your bosses you can run a business operation
• Be a business-person
– Focus on the bottom-line using the numbers when you can to make decisions that are good for the firm
Copyright RCI, 2005 88
USC
C S E
University of Southern California
Center for Software Engineering
Topic
Engineering economics and business cases
Computer economics and business cases
Software economics and business cases
Addison-Wesley site for this book
Web Resources www.isye.gatech.edu
(Georgia Institute of Technology)
The WWW virtual library of industrial engineering with information on academic programs, conferences, courses, publications which emphasize their engineering economics core expertise area http://info.berkeley.edu/resources/infoecon (UC Berkeley)
Economics of the Internet with pointers to sites on E-Commerce, E-
Publishing, intellectual property, etc.
www.computereconomics.com
IT cost management support including industry benchmarks
E-Business strategies and market forecasts www.hbsp.harvard.edu
(Harvard Business School)
Access to case studies on E-Commerce and the Internet, change management, entrepreneurship and new technology http://sunset.usc.edu
(University of Southern California)
Information on cost estimating/analysis and the COCOMO suite
Access to software downloads (COCOMO and code counters) www.sei.cmu.edu
(Software Engineering Institute)
Information on their Team Software Process (TSP) and Software
Engineering Measurement & Analysis (SEMA) efforts www.software.org
(Software Productivity Consortium)
Practical measurement techniques including controlled access to their guidebooks, case studies and lessons learned reports www.aw.com/softwarebusinesscases
Updates to this book, student exercises and pointers to additional useful information
Copyright RCI, 2005 89