COCOMO

COCOMO ( Co nstructive Co st Mo del ) is an algorithmic cost model that in the software development is used for cost or cost estimation. With the help of mathematical functions, a relationship between certain software metrics and the costs of a project is shown.

Several company-specific parameters flow into the calculation, which determines how many person-months or person-years are necessary to implement a software project. Furthermore, the total duration of the project can be estimated. COCOMO is based on a wide range of experience in large-scale industry, e.g. B. Boeing , where software development has been done. The process was developed in 1981 by Barry W. Boehm , software engineer at Boeing.

Procedure

Definitions and Assumptions

The primary cost driver for the model are the Delivered Source Instructions (DSI) of the project.
The development period begins with the start of product design and ends with the completion of product integration and acceptance tests. The efforts of the other phases are determined separately.
A COCOMO person month - English Staff Month (SM) - consists of 152 working hours (19 working days with 8 working hours each), a person year consists of 12 person months . The person month therefore takes vacation and sick leave times into account.
COCOMO assumes good management on the part of the developers as well as the customers and assumes that unproductive times are kept as short as possible.
COCOMO assumes that the requirements specification does not undergo any fundamental change after the requirements phase. A significant change in the specification also results in a change in the effort estimate.

Delivered Source Instructions (DSI)

As a basis for the calculation, the number of code lines to be delivered must be determined in KDSI (1000 (K) delivered source instructions [1 KDSI = 1000 instructions]). As Delivered only is software that is also given to the customer as part of the product. This definition excludes code written for support software or for testing. The estimate of this size depends on many factors (e.g. programming language) and is not dealt with by COCOMO. Source Instructions correspond to computer instructions written and executable by developers. In addition to the comments, this definition also excludes generated code. Instructions are largely based on the punch cards that were common at the time. In his work, Boehm defines Instructions as card images. Delivered source instructions as well as lines of code or function points are software metrics for measuring the size of the software.

Determine complexity

Then you have to decide whether to work on a simple (“organic mode”), medium (“semi-detached”) or a complex (“embedded”) project. These project modes are central points in COCOMO 81, which represent the differences in the work process in the various work domains. The choice of the project mode has a significant effect on the result of the calculation - the calculation formula remains the same and only the coefficients change.

Organic fashion

Organic mode corresponds to small to medium-sized software projects. Most of the employees involved in the project already have extensive experience with similar projects in this company and with the software and hardware used. This ensures a low communication overhead, as those involved already have a precise idea of the product to be created. Documentation of specifications and interfaces is not handled strictly, which means that negotiations in this regard are concluded more quickly and the resulting additional expenditure (diseconomies of scale) is kept to a minimum. Further characteristics of the organic mode are stable development environments with few new technologies, minimal need for new innovations and little time pressure.

Semidetached mode

The semidetached mode is intended for projects whose size and complexity are somewhere between organic and embedded mode. These are medium-sized projects (between 50 and 300 KDSI) whose participants already have a medium level of experience in developing such systems, or in which the team consists of experienced and inexperienced colleagues or the team only has experience in a certain area. Projects that correspond to this mode are more complex, require more sophisticated interaction routines and flexible interfaces.

Embedded mode

Embedded mode is characterized by its tight, inflexible structures and guidelines. This is also the biggest difference to the other two, rather loosely managed modes. It is mostly aimed at security-relevant projects (e.g. flight assistance systems, systems for banks), which are therefore very inflexible with regard to changes in specifications and interfaces. Furthermore, projects in embedded mode are usually new developments with little or no comparable previous projects. For this reason, these projects are also characterized by the fact that they start with a relatively long analysis and design phase. Once these phases have been completed, as many developers as possible are commissioned to implement and test the system in parallel. Here, the test effort of intermediate projects (in the scope of 8000 DSI) corresponds to that of large projects (128000 DSI) in organic mode.

Calculate effort

The effort PM in person- months is then calculated as a factor m, multiplied by a power n of the metric number.

${\ displaystyle {\ mathit {PM}} = m \ cdot {\ mathit {KDSI}} \; ^ {n}}$

easy: ${\ displaystyle {\ mathit {PM}} = 2 {,} 4 \ cdot {\ mathit {KDSI}} \; ^ {1 {,} 05}}$
medium difficulty: ${\ displaystyle {\ mathit {PM}} = 3 {,} 0 \ cdot {\ mathit {KDSI}} \; ^ {1 {,} 12}}$
complex: ${\ displaystyle {\ mathit {PM}} = 3 {,} 6 \ cdot {\ mathit {KDSI}} \; ^ {1 {,} 20}}$

Example: At 100 KDSI, the person-months are about 300 PM for a simple project, about 500 PM for a medium project, and about 900 PM for a complex project.

Project duration

However, one cannot divide the person-months by any number of people in order to finish the product faster. Carrying a child to term is often used as an example - this cannot be shortened to one month by employing nine women. There are certain processes that have to run sequentially, and the more people are entrusted with a project, the more must be invested in communication.

COCOMO speaks of TDEV, time to develop (development time). The development time TDEV in months is then calculated, depending on the type of complexity, according to:

easy: ${\ displaystyle {\ mathit {TDEV}} = 2 {,} 5 \ cdot {\ mathit {PM}} \; ^ {0 {,} 38}}$
medium difficulty: ${\ displaystyle {\ mathit {TDEV}} = 2 {,} 5 \ cdot {\ mathit {PM}} \; ^ {0 {,} 35}}$
complex: ${\ displaystyle {\ mathit {TDEV}} = 2 {,} 5 \ cdot {\ mathit {PM}} \; ^ {0 {,} 32}}$

For a simple project with 100 KDSI, the COCOMO estimate delivers PM = 302 months and TDEV = 21.9 months.
For a medium-difficult project with 100 KDSI, the COCOMO estimate delivers PM = 521 months and TDEV = 22.3 months.
For a complex project with 100 KDSI, the COCOMO estimate delivers PM = 904 months and TDEV = 22.1 months.

The minimum duration for the COCOMO calculation by TDEV is eight months.

Cost drivers

The extended COCOMO procedure (Intermediate COCOMO) takes into account other so-called cost driver factors that either reduce or increase the calculated base value. These are based on many experiences that have been measured at large companies. Such factors include:

Reliability of the delivered system - is an error only disturbing or does it endanger human life?
How big is the database that needs to be created?
How complex are the input / output processing and the data structures?
How quickly does the system have to deliver results?
How much memory does the system take?
How often do you expect the system to have to be adapted to external framework conditions? Here the bandwidth fluctuates between once a year and monthly.
Team factors - what experience do the team members have in analysis, in the programming language used, with software tools, with this particular hardware?
How tight is the schedule?

The following calculation serves as an example of how much these factors influence the result:

Complex, 128 KDSI, corresponds to 1216 PM (basic calculation according to COCOMO).

factor	from	to
reliability	very high = 1.4	very low = 0.75
complexity	very high = 1.3	very low = 0.70
Memory requirements	high = 1.2	hardly = 1.0
Tool usage	low = 1.1	high = 0.90
Time schedule	fast = 1.23	normal = 1.0
customized	3593 PM	575 PM

Explanation: The individual factors are multiplied to a "total factor" and multiplied by the base value for the effort.
Formula: Adjusted value = base value * (reliability * complexity * memory requirement * tool usage * schedule)

However, these values are only rough empirical values; each company must determine its own factors for itself through cost monitoring and analysis of projects that have been created so far.

Further development

Boehm points out that this model should not be applied lightly: " Basic COCOMO is good for rough order of magnitude estimates of software costs, but its accuracy is necessarily limited because of its lack of factors to account for differences in hardware constraints, personnel quality and experience , use of modern tools and techniques, and other project attributes known to have a significant influence on costs. “(The COCOMO base model is well suited for a rough estimate of the magnitude of the software costs. The accuracy of the model is necessarily limited because of factors for differences in the hardware used, the quality and experience of staff, the use of modern tools and technologies and other characteristics known to have a significant impact on cost.) A relatively accurate result can only be obtained by considering several factors that affect the project (see Intermediate and Detailed COCOMO).

ADA COCOMO

ADA COCOMO is a further development of COCOMO 81 - which is very much characterized by batch processing and the waterfall process model - for adaptation to the TRW implementation of the ADA process model . This model includes risk management, architecture skeletons, incremental implementation and testing, and uniform software metrics. The main focus of the model is to reduce communication overhead and avoid late revisions due to unstable requirements. The changes to COCOMO 81 can be divided into three categories:

General improvements from COCOMO: These mostly include adjustments to the existing and additional cost factors. New factors are e.g. B. Security and Development for software reusability.
Ada-specific effects: New rules for counting instructions (DSI) for the ADA programming language. Additional cost factors related to programming language experience.
Effects caused by the Ada process model: These effects mainly affect the exponents of the regression equations and are derived from the properties of the Ada process model. For this purpose, four scaling factors were introduced (Experience with the Ada Process Model, Design Thoroughness at PDR (Preliminary Design Review), Risks Eliminated at PDR, Requirements Volatility). In addition, a method was provided to estimate the effort of incremental projects.

The rest of COCOMO 81 remained unchanged - the general form with the different modes etc.

COCOMO II

Like its two predecessors, COCOMO II was also developed by Barry W. Boehm and first published in 1997. The officially known version, however, was published in a book in 2000. COCOMO II represents the changes in 'modern' software development, with adjustments to new software development process models as well as new development methodologies (e.g. object-oriented programming). As in COCOMO 81, a distinction is again made between three different types of estimation, with the difference, however, that these increasingly relate to the development status of the project. The subdivision into different project modes was omitted here.

criticism

The COCOMO model is only suitable to a very limited extent for estimating the cost of a project, as it is difficult to estimate the underlying Delivered Source Instructions on the basis of a requirement specification. In addition, it does not go into the fact that software in modern high-level languages can often express more with fewer lines than the languages at the time when COCOMO was developed. The inaccuracy of this estimate makes this method unusable for the effort estimate. Re-analyzes of the coefficients seem to show different values.

literature

The examples are taken from the standard textbook by Ian Sommerville, Software Engineering , Addison-Wesley, ISBN 0-321-21026-3 .
Harry Sneed , Richard Seidl , Manfred Baumgartner: Software in numbers - the measurement of applications . 1st edition. Carl Hanser Verlag , 2010, ISBN 978-3-446-42175-2 .

Web links

credentials

↑ ^a ^b Barry Boehm . Software engineering economics . Englewood Cliffs, NJ: Prentice-Hall, 1981, ISBN 0-13-822122-7
↑ Barry Boehm , et al. Software cost estimation with COCOMO II (with CD-ROM). Englewood Cliffs, NJ: Prentice-Hall, 2000, ISBN 0-13-026692-2
↑ COCOMO: Not worth serious attention . The Shape of Code. May 19, 2016. Retrieved November 4, 2016.

[cocomo1-1] Barry Boehm . Software engineering economics . Englewood Cliffs, NJ: Prentice-Hall, 1981, ISBN 0-13-822122-7

[cocomo2-2] Barry Boehm , et al. Software cost estimation with COCOMO II (with CD-ROM). Englewood Cliffs, NJ: Prentice-Hall, 2000, ISBN 0-13-026692-2

[3] COCOMO: Not worth serious attention . The Shape of Code. May 19, 2016. Retrieved November 4, 2016.