University of Southern California
Center for Systems and Software Engineering
Business Valuation with Software
Cost Modeling – A Case Study
Ray Madachy
USC Center for Systems and Software Engineering
madachy@usc.edu
22nd International Forum on COCOMO and
Systems/Software Cost Modeling
November 1, 2007
©USC-CSSE
1
University of Southern California
Center for Systems and Software Engineering
Introduction
• A business valuation was undertaken to quantify
the intellectual property value of a software
product for an acquisition investment analysis
– Product is a financial application that supports banks in
auditing specialized accounts
• A parametric cost modeling approach was used to
answer the question “How much would it cost to
reproduce the software”.
– We also performed an organization productivity analysis
to crosscheck the evaluation and provide more
background for potential investors
• Multiple independent sizing and estimation models
were used
©USC-CSSE
2
University of Southern California
Center for Systems and Software Engineering
Intellectual Property Valuation
• Per Reifer’s guidelines in Value-Based
Software Engineering [Biffl et al. 2005]
– The standard of value was defined as an
acquisition value
– The chosen valuation approach was a cost
approach to predict how much an investor
would pay to replace or reproduce the software
asset
©USC-CSSE
3
University of Southern California
Center for Systems and Software Engineering
Cost Modeling Method
• Cost models can be used to support business
investment decisions that don’t involve
software development or process
improvement per se
• Best approach to software cost estimation is
iteratively using a combination of methods
– Used COCOMO in conjunction with function point
models
• The software value estimate was derived by
distilling the essential, invariant product
characteristics and abstracting out factors
unique to the client
©USC-CSSE
4
University of Southern California
Center for Systems and Software Engineering
Cost Modeling Method (cont.)
• Used the effort multiplier term in COCOMO
to separate out two groups of significant
cost factors
– 1) Core attributes of product functionality. E.g. What
would someone have to develop to compete against this
product?
– 2) Organizational differentiators of the client for
comparison analysis. E.g. What are the environmental
cost factors that indicate unique productivity
advantages/disadvantages, quality or risk profiles?
• Stuck with conservative assumptions at
every turn
©USC-CSSE
5
University of Southern California
Center for Systems and Software Engineering
Software Metrics and Models
• Data collected consisted of size, cost driver ratings, and
effort
– ASP and HTML code
– Size measured in both source lines of code and function points
• Function points used for
– Backfiring to lines of code
– Independent estimates based on function point sizing alone
• Function point gearing factors from public tables used to
convert function points to lines of code as a crosscheck
– Produced considerably larger prediction compared to measured
logical lines of code
• COCOMO calibration was performed to validate our
estimates and indicate whether a local calibration was
needed (only 5% error using default calibration)
©USC-CSSE
6
University of Southern California
Center for Systems and Software Engineering
Software Metrics and Models (cont.)
• Independent estimates were done with COCOMO II
and the International Software Benchmarking
Standards Group (ISBSG) proprietary database of
projects by application type
– ISBSG predictions are based on simple regression of
effort against size in function points
– Project data samples in the ISBSG database are
Accounting (7), Banking (34) and Financial (9)
• Final valuation converted software effort to labor
costs with variable ranges of compensation for
labor grades
©USC-CSSE
7
University of Southern California
Center for Systems and Software Engineering
Estimates with Ranges
400
Estimates with Ranges
350
300
Effort
(Person-Months) 250
200
150
100
50
0
0
COCOMO
II
1
with SLOC
ISBSG
2
Accounting
ISBSG
3
Banking
ISBSG
4
Financial
COCOMO
II
5
backfired
Method
©USC-CSSE
8
University of Southern California
Center for Systems and Software Engineering
Conclusions
•
•
The range of different estimates is typical and came from
alternative, crosschecking estimation methods with different
sources of uncertainty
The major sources of uncertainties were due to sizing and the
backfiring method, the applicability of domain-specific function
point data, and assumed compensation rates
– However, the iterative cost modeling approach was able to narrow down
the range of estimates and provide a good enough estimate for the
client to proceed with
– Stuck with conservative assumptions throughout
•
A more comprehensive valuation would consider infrastructure and
possible start-up costs depending on the corporate perspective
– The actual “cost to reproduce” when considering more aspects would
be higher.
•
We strongly recommended further analysis to refine the data and
assumptions, and to undertake a more comprehensive business
valuation including an income-based approach considering
revenues derived from the software
©USC-CSSE
9
University of Southern California
Center for Systems and Software Engineering
References
• B. Boehm, C. Abts, W. Brown, S. Chulani, B.
Clark, E. Horowitz, R. Madachy, D. Reifer, B.
Steece, Software Cost Estimation with
COCOMO II, Prentice-Hall, 2000
• Biffl S, Aurum A, Boehm B, Erdogmus H,
Grünbacher P (eds.), Value-Based Software
Engineering, Springer, 2005
• QSM, Function Point Programming Languages
Table, http://www.qsm.com/FPGearing.html,
2007
©USC-CSSE
10