Cocomo

COCOMO is an acronym meaning ''Constructive COst MOdel.'' It was developed by Barry Boehm [10.15] and has been a cornerstone of the industry with respect to estimating the levels of effort and times required to develop software.

The basic equations for COCOMO, a formal cost-estimating relationship (CER), follow:

PM

= C(KDSI)X

(10.1)

TDEV

= D(PM)Y

(10.2)

PROD

= PM

(10.3)

FTES

PM TDEV

(10.4)

person-months required to complete software thousands of delivered source instructions required development time productivity full-time equivalent staff needed empirically derived constants where PM = KDSI = TDEV = PROD = FTES = C, D, X, Y =

The environment within which the software development is being carried out is defined as the mode of the effort. For Boehm's organic mode, characterized by a relatively small team, extensive experience, and a stable in-house environment, Equations (10.1) and (10.2) become

To illustrate the results obtained by these COCOMO equations, assume that the number of delivered source instructions is estimated to be 40,000. The preceding two equations then yield

PM = 2.4(40)105 = (2.4)(48.1) = 115.4 person-months TDEV = 2.5(115.4)038 = (2.5)(6.076) = 15.2 months

The productivity is thus

PROD = 410'00,0 = 346.6 DSI/PM, or about 16.5 DSI per day 115.4

and the full-time equivalent staff required is

115.4

The COCOMO equations are nonlinear so that, for example, if the DSI doubles to 80,000, the person-months and development time become 239 and 20 months, respectively, and the productivity drops slightly to 15.9 DSI per day. Thus, the calculations are rather straightforward and yield important planning estimates for the software developer.

One of the more serious questions raised with respect to COCOMO (and there are several issues that have been raised regarding COCOMO's use) is that of obtaining good estimates of the delivered source instructions. Indeed, if they are not valid or accurate, then the usual ''garbage-in, garbage-out'' admonition applies. This issue has never really been solved, but various enterprises have made attempts at trying to assure good input estimates. Among the best of these approaches is to obtain multiple and independent estimates from key personnel on the development team to see what the spread might be and to ultimately converge on a workable consensus. This is a recommended approach when attempting to utilize COCOMO or its variants for which the fundamental input is the delivered source instructions or lines of code.

Other criticisms of COCOMO have focused on the fact that other variables, such as the language used, use or not of CASE tools, and so forth, are not explicitly accounted for. Some of this criticism is blunted by the extensions to COCOMO (e.g., REVIC, discussed in what follows) that take such variables into consideration in an explicit manner.

COCOMO II [10.16] is, of course, an update of COCOMO I, as described briefly above. The model is designed to accommodate three basic levels of granularity, as well as three stages in the life of software development. These levels refer to:

1. Prototyping. The input is sized in object points.

2. Early Design. The input is provided in source statements (lines of code) or function points, and there are seven effort multipliers.

3. Post Architecture. The input is stated in source statements or function points, and there are seventeen effort multipliers.

There are also five scale factors that replace the previous use of the organic, semidetached, and embedded modes.

The source statements form of the COCOMO II model basically takes the same form as that in COCOMO I. That is, person-months (PM) are calculated with the following formula:

where PM is the effort in person-months, A is characterized by a set of effort multipliers (EMs), size is the number of source statements, and B represents a set of scale factors that model economies (B < 1.0) or diseconomies (B > 1.0) of scale. The value of B is itself a function of five scale factors, namely:

1. Precedentedness

2. Development flexibility

3. Risk resolution

4. Team cohesion

5. Process maturity

The value of A is also a function of seven or seventeen cost drivers, known as effort multipliers, depending upon whether one is using the early design or the post architecture version of the model. The reader is referred to the COCOMO II book [10.16] for complete lists of these effort multipliers, as well as how they may be used to determine the value of A in the basic COCOMO equation.

Thus, a central theme of COCOMO II is that it is a model that estimates person-months as a function of 12 (5 scale drivers + 7 effort multipliers) or of 22 (5 scale drivers + 17 effort multipliers) additional variables. These variables are factors that influence the effectiveness and efficiency of the software development effort. COCOMO II also spells out relationships for project scheduling, as was the case for COCOMO I. COCOMO II also expands its areas of consideration, including important topics such as reuse, reengineering, rapid application development, the use of commercial-off-the-shelf (COTS) software, software quality, productivity estimation and risk assessment. COCOMO II is considered to be another major step forward in understanding the quantitative relationships that surround the development of software.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment