Running head: EVOLUTION OF COCOMO AND FUNCTION POINTS

Software Metrics:

An Analysis of the Evolution of COCOMO and Function Points

Roger E. Masse

University of Maryland

July 8, 1997

Abstract

This paper explores how measurement strategies based on the original Constructive Cost Model (COCOMO81) and Function Point Metrics have changed to address modern software development practice. COCOMO81 has been criticized for not being able to provide accurate estimates of cost or effort early enough in the life cycle since it relies on the "lines-of-code" metric. Function Points have not always been accurate for software projects outside of the typical MIS problem domain that is typically dominated by data storage and grouping requirements. These criticisms have resulted in numerous follow-on systems based on the original designs. As the COCOMO effort evolves, and alternatives and improvements based on Function Points have appeared, each model has required more input parameters so that it may be applied during different phases of the software lifecycle and to a wider variety of development efforts. Systems based on Function Points seem to be widely used. Many studies exist that demonstrate high prediction accuracy using Function Point based models. As testament to this success, the new version of COCOMO (2.0) uses Function Points as one of many cost drivers that influence cost measurement. COCOMO 2.0, the most detailed model yet, embraces the strengths of Function Points, appears to address many of COCOMO81’s original problems, and provides wider usability throughout the lifecycle of newer software development methodologies. Once calibrated, COCOMO 2.0 should evolve to be the most widely used model for measuring the effort of new software projects.

Software Metrics:

An Analysis of the Evolution of COCOMO and Function Points

Of all the software measurement systems that have been used since the dawn of software engineering in the nineteen-sixties, none have been as pervasive or influential as A. J. Albrechts Function Point metric, and Barry Boehms Constructive Cost Model (COCOMO). The fact that these models are still widely used in their original form over fifteen years since their introduction is a tribute to their creators. New developments in software engineering, however, have made these original models less applicable when applied to modern software practice.

Fifteen years of evolving software development trends in industry forced these original cost and effort estimating models to change. The increasing uses of object-orientation, commercial-off-the-shelf (COTS) packages, and iterative lifecycle models have rendered the original specifications of Function points and COCOMO suitable for a decreasing percentage of software efforts.

In 1979 Allan Albrecht introduced the Function Point method while working at IBM. The original design was refined and extended in a subsequent productivity measurement document released by Albrecht in 1984. This introduced a usable Function Point system into the public domain.

Function Point Analysis is a method for measuring the size of software projects based on the end-user’s view of the functions required for the application without regard for technology, tools, or programming language used. Function Points classify these views into the following functionality:

Internal Logical Files. These are logical collections of data maintained within the application.

External Interface Files. These are logical collections of data maintained outside the application but referenced by the application being measured.

External Input. This view represents the ability to control and maintain the processing of data.

External Output. This is the view of data that is leaving the application.

External Inquiries. This view represents request and response overhead for simple data retrieval.

Each of these views are assigned a different weight:

During early stages of the software development lifecycle, each of the above function types become exposed at the functional level and are assigned a weighted value based on these standard metrics (Garmus & Herron, 1996). The total of these weighted function types becomes the Unadjusted Function Points (UFPs).

UFPs become adjusted by assessing fourteen "General System Characteristics" that measure requirements that effect the entire application. Each General System Characteristic is ranked on a "Degree of Influence" scale which ranges from zero (not present) to five (strong influence throughout). The fourteen General System Characteristics that must be assessed are (Albrecht 1984):

The sum of the scores of the fourteen ranked characteristics is the total Degree of Influence (DI), and is converted to a "Technical Complexity Factor" (TCF) using the following formula (Symonds, 1988):

TCF = 0.65 + 0.01 x DI

Function Points (FP) or the relative system size is derived from:

FP’s = UFP’s x TCF

Because Function Points are derived from information available after requirement specification but before design, estimates are available early in the lifecycle (Zues, 1995). This is one of the reasons Function Points are so successful.

Function Points measure the size of a software project. Two Function Point metrics often computed are: "Function Points implemented per staff month" and "Function Points implemented per calendar month". Function points implemented per staff month indicates the amount of effort that goes into system development. For example, a five hundred Function Point application developed by ten people in ten months has a productivity rate of five function points per staff month. Function Points implemented per calendar month indicate the speed that the system can be developed. In the above example, the Function Points implemented per calendar month is fifty.

Strict Function Point metrics force you to think in terms of Function Points or to have a metric that corresponds to a certain level of productivity in Function Points per person and calendar month. Capers Jones (1991) helps bridge this disconnect by giving average productivity rates for commercial, MIS and military applications.

Jones also outlines an alternative use of Function Points: converting them to lines of code and using them as input to the COCOMO model. This is covered in a later section of this paper.

Experts must count Function Points. This prompted the formation of the International Function Point Users Group (IFPUG), an organization that publishes and promotes (among other things) standard counting guidelines for Function Point Analysis. The latest counting rules are defined in Release 4.0 of "Function Point Counting Practices Manual", produced and maintained by the IFPUG (1994), who has contributed to the success and standardization of Function Points worldwide.

Studies have shown Function Point Analysis to be quite consistent with reality. Kemerer, Banker, Datar, and Zweig (1992) published a lengthy study of sixty-five MIS transaction processing projects at MIT and found a consistency of +/- 12%.

The most widely used algorithmic models for computing the required effort for projects are derivatives of COCOMO81 developed by Barry Boehm (1981) while at TRW in the seventies and early eighties. The most fundamental calculation in the COCOMO81 model is the "Effort" equation that equates to "Staff-Months" required for the project. Effort is computed based on an estimate of "Thousands of Delivered Source Instructions" (KDSI), which makes COCOMO81 best suited for application fairly late in the development lifecycle; typically during the design phase. This is one of the primary drawbacks of COCOMO81, since cost and effort estimates are typically needed during the requirements analysis phase.

Every COCOMO81 project is categorized into one of three different "Development Modes" which contribute heavily toward the computation of duration and cost:

Organic Mode. The project is being developed in a familiar, stable environment and is similar to previously developed projects.

Semidetached Mode. The project is characterized somewhere between Organic and Embedded.

Embedded Mode. The project will require much innovation and is subject to tight, inflexible interface requirements and constraints.

Other measurements intrinsic to COCOMO81 are "Time to Develop" (TDEV) and "Average Staffing", which are computed from the Effort equation. COCOMO81 has three levels of complexity: basic, intermediate, and advanced. Each level adds a number of factors to the basic formulae to increase the accuracy of the estimate.

The top-level model, Basic COCOMO, is good enough for rough order estimates. The Effort equations for each mode of development are as follows:

The time to develop the project (TDEV) is based on Effort and is characterized by the following equations:

Average Staffing is computed by dividing Effort by the Time To Develop.

Boehm (1997) suggests that the accuracy of Basic COCOMO is limited because it does not account for differences in hardware, personnel quality and experience, use of modern tools, and other project attributes known to have a significant influence on cost.

Intermediate COCOMO adds accuracy to basic COCOMO by multiplying "Cost Drivers" into the equation with a new variable: "Effort Adjustment Factor" (EAF) and using slightly different multipliers:

EAF is the product of fourteen "Effort Multipliers". If the values for all categories are "Nominal", the EAF would be 1.0 and effectively the results would be the same as Basic COCOMO for a semidetached project. Organic and embedded project estimates go up and down respectively due to the new multipliers. Depending on the cost driver, EAF would be increased or decreased by choosing lower or higher values. The following table illustrates this effect and shows the multipliers associated with each of the fourteen cost drivers (Boehm & Papaccio, 1985):

The detailed model differs from the Intermediate model in only one major aspect: the detailed model uses different Effort multipliers for each phase of a project. Phase dependent Effort multipliers yield better estimates than the Intermediate model. Detailed COCOMO defines six lifecycle phases: requirements, product design, detailed design, coding and unit testing, integration and testing, maintenance.

The detailed model illustrates the importance of recognizing different levels of predictability at each phase of the development cycle. Boehm had the right idea here. But COCOMO81 by itself is not a robust enough model to accurately predicting costs at all phases of development. By going as far as trying to apply weights to the requirements analysis phase while at the same time requiring input for the estimate that is not typically very accurate until the later phases of design, clearly points out a serious flaw in detailed COCOMO.

Function Points are a measure of the size of a project while the outputs of COCOMO are effort and time to develop. A common usage of COCOMO81 is to compute Effort and Time given a mean estimate of lines-of-code (KLOC) produced by Function Point Analysis. In this way COCOMO81 and Function Points provide complimentary information. By critiquing why LOC metrics cannot be used for large-scale studies involving multiple languages, Jones (1991) outlines how to produce LOC, for several different languages, from Function Points. By equivocating "statements" and LOC many practitioners are plugging the results of Function Point analysis into COCOMO implementations. Implementation with modern high-level languages must render this equivocation inaccurate. Jones (1996) appears to recognize this as well judging by the effort he has put into the "leveling" of various implementation languages.

A more accurate prediction of LOC, depends of the implementation language and its level. As the level of a language goes up, fewer statements to code one Function Point are needed. The following table is an example of the many languages Jones (1996) continues to assess and level:

A superset of Function Points called "Feature Points" was introduced in 1986 by Jones in an attempt to improve the accuracy of estimates for real time, operating system, embedded, communications, and process control software systems (Garmus 1996). Feature Points introduce a new parameter (algorithms) to the five standard function point parameters. Algorithms are assigned a default weight of three and Logical Files are reduced to seven (from ten), which has the effect of reducing the significance of data storage and grouping more prevalent in MIS applications.

Jones (1995) found that when Feature Points are used in classical MIS applications, the results are often similar, except in the case where MIS applications are severely dominated by files. For a telephone-switching project, the Feature Point estimate was notably higher due to the high algorithmic complexity.

Feature Points must be counted like the Function Points they are a superset of. This prompted Jones to introduce ten rules specifically identifying exactly under what conditions an algorithm exists. Further research is underway to develop a more rigorous taxonomy and weighting scale for algorithms.

In 1988 Charles Symons introduced "Mark II" Function Points as a proposal to improve the accuracy of the Function Point metric mainly for project types with high internal technical complexity. Symons asserted that Albrecht’s restriction of fourteen "Technical Complexity Factors" (TCF) is unlikely to be satisfactory for all time and that the "Degree of Influence" (weights) of the fourteen TCFs being restricted to a scale of zero to five, was unlikely to always be valid. As a result, Mark II Function Points add six additional complexity factors to the original fourteen General System Characteristics (Garmus, 1996).

Use of Mark II Function Points has been almost exclusively in the UK and offers promising results for MIS projects with varying degrees of internal complexity. Betteridge (1992) found more accurate cost prediction estimates using Mark II Function Points when compared to the original Function Point Metric and individual manager’s estimates for projects containing large database and transaction processing content.

3D Function Points are an effort to make Function Point Analysis more accurate at projects involving a high degree of computation.

Developed at Boeing by Scott Whitmire (1995), the "3D" part of the name comes from the fact that 3D Function Points consider three dimensions of the applications they’re designed to measure: Data, Function, and Control. The Data portion is very similar to conventional Function Points; the Function measurement considers the complexity of algorithms; and the Control portion measures the number of major state transitions within the application.

Whitmire shows how 3D Function Points can be used to estimate the effort required to implement specific classes in an object-oriented design. As a result, 3D Function Points provide a transitional mechanism between traditional Function Points and software metrics more suitable for object-orientation.

The down side of 3D Function Points appears to be the amount of additional data needed as input to the model. Accurate numbers for estimates in algorithms or state transitions are not readily available until the later stages of design. As a result, 3D Function Points are not the end-all software measurement tool answer by itself, since it suffers from early life cycle phase inaccuracy in a similar way to COCOMO81.

Despite all the advances and improvements to COCOMO81 and Function Points, Boehm (1997) has pointed out a number of development strategies that are not well matched to current measurement models. Graphical User Interface (GUI) builders and other "program generating" tools render the notion of delivered source instructions quite inaccurate. Non-sequential process models that obscure the beginning and ending points of measurement confound data collection and accuracy. Integration of COTS software and other reuse and adaptation strategies are similarly confounding. Rapid prototyping environments are not accounted for in most modern measurement techniques. Finally there is still some question as to the cost implications of integration with the Software Engineering Institutes Capability Maturity Model (SEI-CMM). A CMM mature organization should be able to produce software faster because of the repeatability potential that increases with each level.

Boehm, Clark, Horowitz, Westland, Madachy, and Selby (1995) recognizing the limitations of the original COCOMO, the benefits of Function Point analysis, the importance of accurate estimates throughout modern software life cycles, and other recent detractors to the measurement process, are developing COCOMO version 2.0. COCOMO 2.0 is currently in the process of being calibrated by a number of large corporate participants and should have a stable baseline sometime during 1997. COCOMO 2.0 has three different cost model stages:

The Application Composition Model. By addressing the problem of inaccuracy when using a COTS package, such as a GUI builder, the "Stage 1" model counts outputs based on an "Object Point" metric. Object Points are a complexity-weighted count of number of screens generated, reports produced, or modules that have been integrated. Based on recent work by Banker, Kauffman, and Kumar (1991), it is focused on rapid application development techniques.

The Early Design Model. Similar to the original COCOMO model, the Stage 2 model uses Unadjusted Function Points, with the additional option of LOC, as input. Being tailored for measurement of a projects cost and duration during the early phases of the life cycle, Stage 2 is best applied when only partial information is available on the ultimate nature of the product. As such the fourteen cost drivers found in COCMO81 are reduced to seven aggregate cost drivers.

The Post-Architecture Model. Once the architecture of a project begins to form, during the design phases of the life cycle, this model can most accurately measure cost and duration using a new set of equations, counting rules, and cost drivers. The Stage 3 model is best applied after the major risks of the project have been resolved and is driven by seventeen multiplicative cost drivers.

Stages 2 and 3 replace the three COCOMO81 development modes with a set of five "Scale Factors"; two of which, Precedentedness and Flexibility, cover the effects of COCOMO81. Two others, Architecture/Risk Resolution and Team Cohesion are adapted from ADA COCOMO (Boehm, 1997). Finally, the Process Maturity factor reduces estimates based on increased mastery of the SEI-CMM. These Scale Factors account for costs introduced by the scaling up of a project.

Boehm et al. has addressed several issues that seem applicable to modern software practice such as: estimating in the face of the spiral life cycle model and prototyping; component-based construction such as a GUI builder; and the use of object-oriented techniques. COCOMO 2.0 is based on the rationale that "The granularity of the software cost estimation model needs to be consistent with the granularity of the information available to support cost estimation" (University of Southern California, 1997, p4).

The most recent arrival in the software metrics playing field, COCOMO 2.0, is more complex than the counterparts it was derived from and is based on. While COCOMO 2.0 retains some of the principles of COCOMO81 and Function Point analysis, it introduces an abundant set of new formulae and cost drivers. Modern software practice has demanded better accuracy in measurement despite the added complexity of factors like prototyping, component-based construction, object-oriented development and design, and complex life cycle management. More than any other model, COCOMO 2.0 appears to address these issues. Time will tell, as studies are conducted, if the promise of wider ranging, more accurate measurement will become reality.

References

Albrecht, Allan J., (1984). IBM CIS&A Guideline 313, AD/M Productivity Measurement and Estimate Validation IBM, Purchase, New York, November 1984.

Betteridge R., (1992). Successful Experience of Using Function Points to Estimate Project Costs Early in the Life Cycle. Computer, Vol. 34 No. 10, 655-657. Institute of Electrical and Electronics Engineers, Inc.

Banker, R.D., Kauffman, R.J., Kumar, R., An Empirical Test of Object-based Output Measurement Metrics in a Computer Aided

Software Engineering (CASE) Environment. Journal of Management Information Systems, 8 (3), Winter 1991-92, 127-50

Boehm, B. W., (1981). Software Engineering Economics, Prentice-Hall, 1981

Boehm, B. W., (1997). Experiences in Software Cost Modeling. In Jones C. Principles of Software Cost Estimating, McGraw-Hill, 1997

Boehm, B. W., Clark B., Horowitz E., Westland C., R. Madachy R., Selby R., (1995). The COCOMO 2.0 Software Cost Estimation Model. In Proceedings of the USC Center for Software Engineering's Focused Workshop on COCOMO 2.0, University of Southern California

Boehm, B. W., Papaccio P. N., (1988). Understanding and Controlling Software Costs. IEEE Transactions on Software Engineering V. 14, n. 10 (October 1988)

Boehm, B. W., Penedo, M. H., Stuckle E. D., Williams R. D., Pyster A. B., (1984). A Software Development Environment for Improving Productivity. Computer, Vol 17. No. 6 (June 1984), 30-42.

Garmus, D., Herron D., (1996). Estimation Effective Early Estimation. Software Development (July 1996), 57-65

International Function Point Users Group, (1994) Function Point Counting Practices Manual, (Release 4.0)

Jones, C., (1991). Applied Software Measurement, McGraw Hill, New York, ISBN 0-07-032813-7

Symons, C. R., (1988). Function Point Analysis: Difficulties and Improvements. IEEE Transactions on Software Engineering, Vol. 14, No. 1 (January 1988), 2-11.

Whitmire, S. A., (1995). An Introduction to 3D Function Points, Software Development, Vol. 3, No. 4 (April 1995)