Join Today and Benefit Daily from ABI's 35+ Years of Insolvency Expertise.
Join Today!
Help Center

The Valuation of Computer Software

Journal Issue: 
Column Name: 
Journal Article: 
There are many bankruptcy-related reasons to conduct a computer software valuation. Software valuations are performed to quantify the collateral value of secured debt, to justify new debtor-in-possession financing, to assess a proposed plan of reorganization, to identify spinoff and asset divestiture opportunities, to structure software sale/leaseback transactions and to negotiate license and royalty rate agreements.1

Defining Computer Software

In order to analyze the various methods used to value computer software, it is useful to start with a definition of software. Computer software is sometimes defined as the programs that tell the computer what to do; the broadest definition is that software includes everything that is not hardware.

The definition typically used in valuing software, at least as an operational component of a going-concern business enterprise, reflects the software's function in satisfying its users' needs. Thus, software is the entire range of activities—including feasibility studies, planning and requirements, product design and architecture, file structures and layouts, coding, testing, integration and implementation—that permit delivery of computer processing services to the end-users.

Software Engineering Models for Valuation

Valuation analysts often use software engineering models to estimate the replacement cost of software systems when using the cost approach to value. These models were created to assist software developers in estimating the effort, time and human resources needed to complete a software project. Two of the best known models are the Constructive Cost Model (COCOMO) and the Software Lifecycle Management (SLIM) model.

The COCOMO and SLIM models are considered "empirical" cost approach models. That is, the development time and development cost of the subject software is estimated by reference to a large database of actual software development projects where the actual development times were carefully monitored.

In the COCOMO model, this database of actual software development projects was used to derive the equations and cost drivers. In the SLIM model, the equations are based on the study of actual development projects, and key variables may be assigned using projects in the database with characteristics similar to those of the subject system.

Both models calculate an estimate of effort to develop a software system in terms of person-months. To estimate the cost to develop that system, the number of months should be multiplied by a current cost (as of the valuation date) per person-month.

The cost per person-month is a comprehensive or "fully loaded" cost that includes the average base salary of the development project team members and other factors. These other factors include, but are not limited to, perquisites, payroll taxes (e.g., FUTA, SUTA, FICA and workman's compensation), employee "fringe" benefits (e.g., life, health, disability and dental insurance, pension plans and continuing education), and an allocation of organizational overhead (e.g., including secretarial support, office space, computer use, supplies, marketing, management and supervisory time).

COCOMO Model Theory and Methodology

COCOMO was developed by Barry W. Boehm and is described in the classic textbook entitled Software Engineering Economics (Prentice-Hall Inc., 1981). This cost estimation method projects the amount of effort required to create the subject software, taking into consideration the size of the programs, the program characteristics and the resource constraint environment in which they are to be developed.

Dr. Boehm defines an effort equation in his basic COCOMO model. That basic model estimates the number of person-months to develop a software product as a function of the metric called "delivered source instructions." The number of delivered source instructions is a measurement that is similar to the functioning lines of code in the final compiled software programs. This person-month estimate includes all phases of the development from product design through integration and testing, including documentation. Delivered source instructions are source program lines of code including job control language, data declarations and format statements—but excluding programmer comment lines, unmodified utility software and, generally, non-delivered support software. The basic COCOMO model allows for three different modes of software development, with a specific effort equation provided for each.

The software development modes characterize three general environments in which software is developed: the organic, semidetached and embedded modes. Organic projects are defined as small in terms of number of delivered source instructions (under 50,000) and project team size. The project team has extensive experience working with related software systems. Additionally, organic projects do not require complicated algorithms. Organic projects are developed in a familiar and stable environment and are not developed under severe time constraints. Examples of organic systems are scientific models, business models and batch-type data reduction.

Embedded projects are defined as large and are characterized by tight hardware, software and operational constraints. Large project teams and complex data processing architectures and algorithms are usually involved in the embedded mode development environment. Examples of embedded systems are avionics and ambitious command-control systems.

The semidetached mode in an intermediate software development environment between the organic mode and the embedded mode. The size of semidetached mode projects is typically under 300,000 delivered source instructions. Examples of software created in the semidetached environment include most transaction processing systems and ambitious inventory or production control systems.2

COCOMO 2.0

Dr. Boehm and his associates at the University of Southern California recently developed a new version of COCOMO. The model is currently undergoing calibration (i.e., numbers are being assigned to the effort multipliers and other constants are being finalized) and should be released in early 1999. Version 1.2 of the preliminary COCOMO 2.0 Model Definition Manual describes three different models.

The most detailed model, the "Post-Architecture" model, is analogous to the intermediate COCOMO model discussed above. This model has been updated to make it consistent with software development practices in the 1990s and beyond. A summary description of the differences in the effort estimation equations, between the intermediate COCOMO (hereafter "COCOMO-1") and preliminary post-architecture (hereafter "COCOMO-2") models follows.

In COCOMO-1, the selection of one of three software development modes (i.e., organic, semidetached or embedded) determined the constant and exponent to be used in the equation to estimate development effort. In COCOMO-2, there is only one constant, but the value of the exponent is a function of five scaling factors.

COCOMO-1 used 15 cost drivers to calculate the effort adjustment factor. Two of these have been eliminated in the new version: those related to the use of modern programming practices and computer turnaround time. Four new cost drivers have been added to recognize the effects on productivity of reusability requirements, documentation requirements, personnel turnover and development at multiple sites.

In COCOMO-2, new and reused (i.e., adapted or modified) lines of code are quantified separately. A percentage of the reused lines of code can be designated as automatically translated, and a productivity rate is used to estimate the effort to translate these lines of code. The remainder of the reused or adapted lines of code are converted to equivalent new source lines of code. This conversion is based upon the percent of modification (i.e., to the design, code, and integration and test) as well as the effort to assess and assimilate the reused module, the understandability of the reused code, and the programmer's familiarity (or lack thereof) with the code. Because code is reused primarily to reduce development effort, the equivalent new source lines of code would typically be less than the adapted source lines of code.

A breakage factor is introduced in COCOMO-2 to adjust the total lines of code. This adjustment recognizes that code is often written but discarded due to changing end-user requirements. COCOMO-2 also includes a very detailed set of counting rules for lines of code.

To valuation analysts who use this engineering cost model, the release of the updated COCOMO 2.0 is very exciting. The most frequent criticism of the original COCOMO is that it was published in 1989 and was based on older empirical data. Critics will find that this and many other concerns are addressed in the new model.

SLIM Model Theory and Methodology

SLIM was developed by Lawrence H. Putnam, a former Special Assistant to the Commanding General of the Army Computer Systems Command and the founder of Quantitative Software Management Company (QSM), which markets the model.

The SLIM model has been used by QSM customers such as Digital Equipment Corp., Electronic Data Systems, Honeywell, IBM, Motorola and the U.S. Air Force, Army and Navy in estimating development costs for, and in managing, their software creation projects.

A database of more than 3,000 actual software development projects allows the SLIM model to estimate system development parameters based on actual empirical data from similar software projects. New software projects are added to the database each year.

Much of the basic theory and other discussions behind the development of the SLIM model is presented in the article "Software Cost Estimating and Life-Cycle Control: Getting the Software Numbers" (IEEE, 1980), by Lawrence H. Putnam. The SLIM Model is described in detail in a book written by Lawrence H. Putnam and Ware Myers entitled, Measures for Excellence: Reliable Software on Time, Within Budget (Yourdon Press, 1992).

The software life cycle is defined as consisting of four phases: feasibility study, functional design, main build and maintenance. The empirical evidence studied by Mr. Putnam led him to develop the following two parameters and their respective equations:

Productivity Parameter = SLOC/(Effort/B)1/3 (Time)4/3
Manpower Buildup Parameter = Total Effort/Time3

Where:
Effort = the number of person-months devoted to the main build phase
B = special skills factor related to system size
Time = elapsed calendar time for the main build phase
SLOC = number of source lines of code
Total Effort = the number of person-months devoted to all software development phases

Ranges of productivity parameters are mapped to a productive index (PI) with values ranging between 1 and 40. Similarly, the manpower buildup parameters were mapped to manpower buildup indices (MBIs) with values ranging between -3 and 10.

Peter V. Norden found that over time manpower levels in software development fit a Rayleigh distribution. Mr. Putnam compared his empirical evidence to the Rayleigh curve and determined that the Rayleigh curve was representative of his findings. There are a variety of statistical curves, including Rayleigh curves, used in the SLIM model.

The SLIM computer model allows the valuation analyst to specify the type of system to be developed and the expected number of lines of code. A productivity index may be input directly, or it may be assigned by the program based upon the QSM database of projects of that type and size. The analyst may use the QSM model defaults for the shapes of the staffing curves for the four phases and for their overlaps in time and effort; or the analyst may modify these assumptions.

A number of constraints may be imposed in the SLIM model. These constraints may be assigned desired probabilities and weights. The constraints are: time, effort and cost limits, minimum and maximum staff, and a reliability limit, quantified by mean time to defect.

The SLIM model uses a Monte Carlo simulation to find an optimal solution, given the development assumptions and constraints for a software project. The elapsed time, measured as effort in the number of person-months (PM), and cost are calculated for each phase of development, and a development team staffing plan is generated.

Conclusion

Determining the value of proprietary software in a bankruptcy reorganization is a complex process. The valuation approaches outlined here provide some proven methods to consider the many variables at issue. Keep in mind that when market data can be found for comparable or similar systems, a market approach may be indicated. If the subject software was capable of generating license fee income, then an income approach may be applicable.


Footnotes

1 Consider the case of the data processing department of a debtor-in-possession company that has developed an accounting system consisting of four modules or subsystems: accounts payable, accounts receivable, fixed assets and general ledger. These systems, which run on PCs or client/servers with Windows/Windows 95, are used by the executives of the operating company to manage business operations. A fifth module, bank reconciliation, was abandoned before it was completed with no likelihood of being revived. Licensing revenues are increasing and the company is profitable. Due to the fact that the value of the internally developed computer software is included in the bankruptcy estate of the subject operating company taxpayer, a valuation of the software is needed. Return to article

2 As defined in Software Engineering Economics, the effort equations for the three development modes in the basic COCOMO model are presented below:

Organic PM = 2.4 (KDSI)1.05
Semidetached PM = 3.0 (KDSI)1.12
Embedded PM = 3.6 (KDSI)1.20

Where:
PM = Number of person-months of development effort
KDSI = Thousands of delivered source instructions

Dr. Boehm refined the basic COCOMO model by introducing 15 cost drivers with associated effort multipliers. The product of these multipliers is defined as the effort adjustment factor, and the effort equations are normalized by modifying the coefficients.

The software development effort equations are:
Organic PM = 3.2 (KDSI)1.05 x EAF
Semidetached PM = 3.0 (KDSI)1.12 x EAF
Embedded PM = 2.8 (KDSI)1.20 x EAF

Where:
EAF = Effort adjustment factor
Return to article

Journal Date: 
Monday, February 1, 1999

Reprint Request