Submission for 22nd International Forum on COCOMO and Systems/Software Cost Modeling
Business Valuation with Software Cost Modeling – A Case Study
Ray Madachy
USC Center for Systems and Software Engineering
madachy@usc.edu
Abstract
A business valuation was undertaken to quantify the intellectual property value of a software product for
an investment analysis. A parametric cost modeling approach was used to answer the question “how
much would it cost to reproduce the software”. Multiple independent sizing and estimation models were
used. We also performed an organization productivity analysis to support the evaluation and provide
more background for potential investors.
There were a number of uncertainties identified in the valuation process, and accordingly conservative
assumptions were made throughout. The ranges of uncertainties decreased through analysis iterations.
The valuation provided by cost modeling is only part of the overall valuation, which must include other
infrastructure and start-up costs for an assumed competitor.
Introduction and Background
In the COCOMO II book [1] there are eight major software decision situations identified for COCOMO.
However, cost models can also be used to support business decisions that don’t involve software
development or process improvement per se. We used COCOMO in conjunction with other models to
perform a software product value assessment for a company investment analysis. There was no pending
decision to “make or buy” a specific type of software product, but whether to invest in a company that
had intrinsic intellectual value in theirs.
Reifer discusses approaches to value intellectual property in [2]. A standard of value needs to be
defined (in this case an acquisition value), as well as a valuation approach. We chose a cost approach to
predict how much an investor would pay to replace or reproduce the software asset.
The software under consideration is an application that supports banks in auditing specialized accounts.
The client’s staff uses their internal software to perform this service for banks. The software value is
thus derived from the services provided with the software, and in the future when the software is leased
to external customers.
This value estimate was derived by distilling the essential, invariant product characteristics and
abstracting out factors unique to the client. The method below addresses the software business value
concept, measurements and indicators, derives an initial ROM estimate range, and lists issues to be
resolved to reduce uncertainties.
Method
The best approach to software cost estimation is using a combination of methods. Estimates using
different techniques are compared and iterated, and their differences reconciled. Frequently the
iterations help identify differing assumptions in the approaches, and the estimates usually become more
aligned leading to higher confidence in the results. By using several independent techniques and sources
we were able to derive a range of numbers with higher confidence than a single method would have
provided.
1
Submission for 22nd International Forum on COCOMO and Systems/Software Cost Modeling
COCOMO was used to derive product estimates and organizational comparisons using multiple sizing
techniques. The effort multiplier term in the COCOMO effort formula allows analysis of the effort
variance due to single cost factors or groups of factors. This is useful to separate out the intrinsic
product reproduction costs (product attributes) vs. the cost factors that specifically describe the client
environment (personnel, organization, platform and other factors).
We identified two groups of cost factors of significance. Factors in each of these were either:
1) A core attribute of product functional product. E.g. What would someone have to develop to
compete against this product?
2) An organizational differentiator of the client for comparison analysis. E.g. What are the
environmental cost factors that indicate unique productivity advantages/disadvantages, quality or
risk profiles?
In this study the product attributes of Required Software Reliability, Data Base Size, and Product
Complexity were regarded as immutable to characterize the product system if another wanted to replicate
its functionality. Together with size they are used to characterize the base estimate of product
functionality.
The data collected consisted of size, cost driver ratings, and effort. The product program software
consists of ASP and HTML code, and approaches were used to quantify size in both source lines of code
(SLOC) and function points. Source statements were broken out in the following categories: ASP script,
HTML code, dimension statements, comments and blank lines. The total logical source statements
consisting of ASP, HTML and dimension statements were used in the cost model.
An alternative size measure is function points, where individual inputs, outputs, queries, internal logical
files (e.g. data tables) and external interface files are counted and weighted for complexity. These were
also counted and used for two purposes: 1) backfiring to lines of code and 2) independent estimates
based on function point sizing alone.
A function point gearing factor was computed to relate the lines of code to function points, which had to
be weighted by the relative portions of ASP and HTML. The gearing factor predicted considerably
more than the measured logical lines of code. The public function point tables in [3] provide large
ranges, neither the sample size nor project contexts are known, and the actual conversion to lines of code
may be far different at a local site. This was a major source of uncertainty in the analysis.
The product of the COCOMO factor product effort multipliers was 1.47, which implies the product
takes 147% effort compared to a nominal software product. This multiplier was used to estimate the
product effort range using different sizing approaches in COCOMO II (direct SLOC and SLOC
backfired from function points). The backfiring tables in [3] were used for this.
The actual product software development effort was used to validate our estimates and indicate whether
a local model calibration is needed. The 5% uncalibrated effort difference represented extremely good
model performance, and with one data point there is no overriding need to re-calibrate the model. The
model prediction error is a very small component of the overall uncertainty. Since the uncertainty is due
primarily to size considerations and secondarily to the cost drivers, the issue of model calibration of
negligible priority in deriving a sound and narrower range of estimates.
2
Submission for 22nd International Forum on COCOMO and Systems/Software Cost Modeling
The initial estimates were done with COCOMO. The International Software Benchmarking Standards
Group (ISBSG) proprietary database of projects was used for additional independent estimates. It
consists of function point sizing and effort by business area type. The predictions from it are based on
simple regression of effort against size in function points, with no size conversion to SLOC. The native
size is function points, and the data is segregated by application type.
The comparative estimates from ISBSG were derived by querying their database and reporting with their
default ranges where the optimistic estimate represents the 25% percentile of data points, the likely is
the mean and the conservative estimate uses the 75% percentile. With this technique there is a direct
regression of hours against project sizes without an intervening effort model. The “model” in this
approach is the function point sizing technique. The numbers of project data samples in the proprietary
ISBSG database are Accounting (7), Banking (34) and Financial (9).
Figure 1 shows the relative ranges of the estimates using COCOMO and the ISBSG metrics database
(the absolute numbers are proprietary). The last datapoint uses the synthetic backfiring approach from
SLOC to function points with data medians. Based on the inherent uncertainties of this approach and
other reasons per the analysis, we suggested throwing it out (particularly when aligned with the other
four alternative methods). Placing little weight on the method also lends credibility to the
conservativeness of our final estimate range. The final range is fairly insensitive to the choice of
weighting strategy among the others.
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
Figure 1: Estimates with Ranges
The product valuation then converted software effort to labor costs. Not included were the costs of the
organizational overhead such as management, administration, facilities, etc. Also absent were the costs
to develop the user requirements for the product features which describe a new market need.
Establishing the additional value for this portion of the business can be approached from a financial
analysis based upon the added profitability of being first-to-market with a new product or service.
The effort ranges were transformed to dollar costs by applying rates for two labor grades: senior and
programmer rate. The competitive rates used were for the application domain. Based on all the
uncertainties and outlined financial assumptions, we suggested a conservative dollar estimate range to
reproduce the product system. But we strongly recommended more scrutiny on the assumptions.
3
Submission for 22nd International Forum on COCOMO and Systems/Software Cost Modeling
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. These and more issues were identified for further analysis. With an iterative approach however,
we found that the cost modeling approach was able to narrow down the range of estimates and provide a
good enough estimate to proceed with.
A more comprehensive valuation would consider infrastructure and possible start-up costs depending on
the corporate perspective. These are not considered at all this analysis, and therefore 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.
1.
References
[1] 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
[2] Biffl S, Aurum A, Boehm B, Erdogmus H, Grünbacher P (eds.), Value-Based Software Engineering,
Springer, 2005
[3] QSM, Function Point Programming Languages Table, http://www.qsm.com/FPGearing.html, 2007
4