Information about Cocomo calculation
Cocomo
Cocomo is a model designed bij Barry W. Boehm to give an estimate of the number of man month it will take to develop a software product.
This "COnstructive COst MOdel" is based on a study of about 60 projects at TRW, which is a company where many large software projects are being build.
The programms examened where ranging in size from 2000 to 100.000 lines of code, and programming languages used range from assebly to PL/I.
Cocomo consists of a hierarchy of 3 increasingly detailed and accurate forms.
- Basic Cocomo
is a static single-valued model that computes software development effort (and cost) as a function of program size expressed in estimated lines of code
- Intermediate Cocomo
computes software development effort as function of program size and a set of "cost drivers" that include subjective assessment of product, hardware,personnel, and project attributes.
- Advanced Cocomo
incorporates all characteristics of the intermediate version with an assessment of the cost driver's impact on each step (analysis, design, etc.) of the software engineering process.
For this project we only implemented the Basic and the Intermediate versions. We will go more into detail about these levels of Cocomo.
Cocomo calculates Effort (E) and Development time (D) using kilo lines of code (KLOC).
Basic Cocomo
Cocomo may be applied to three classes of software projects. These give a general impression of the software project.
- Organic projects
are relatively small, simple software projects in which small teams with good application experience work to a set of less than rigid requirements.
- Semi-detached projects
are intermediate (in size and complexity) software project in which teams with mixed experience levels must meet a mix of rigid and less than rigid requirements.
- Embedded projects
are software project that must be developed within a set of tight hardware, software, and operational constraints.
The basic Cocomo equations take the form...
- E=ab(KLOC)bb
- D=cbdb
...where E is the effort applied in person-months, D is the development time in chronological months, and KLOC is the estimated number of delivered lines of code for the project (express in thousands).
The coefficients ab, bb, cb and db are given in the following table.
-
| Software project
| ab
| bb
| cb
| db
|
| Organic
| 2.4
| 1.05
| 2.5
| 0.38
|
| Semi-detached
| 3.0
| 1.12
| 2.5
| 0.35
|
| Embedded
| 3.6
| 1.20
| 2.5
| 0.32
|
Basic Cocomo is good for quick, early, 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 o
f modern tools and techniques, and other project attributes known to have a significant influence on software costs.
Intermediate Cocomo
The basic model is extended to consider a set of "cost driver attributes" that can be grouped into four major categories, with each a number of sub catagories:
- Product attributes
- Required software reliability
- Size of application database
- Complexity of the product
- Hardware attributes
- Run-time performance constraints
- Memory constraints
- Volatility of the virtual machine environment
- Required turnabout time
- Personnel attributes
- Analyst capability
- Software engineer capability
- Applications experience
- Virtual machine experience
- Programming Language experience
- Project attributes
- Use of software tools
- Application of software engineering methods
- Required development schedule
Each of the 15 attributes is rated on a 6-point scale that ranges from "very low" to "extra high" (in importance or value).
Based on the rating, an effort multiplier is determined from the table below. The product product of all effort multipliers results in an 'effort adjustment factor (EAF). Typical values for EAF range from 0.9 to 1.4.
-
|
| Ratings
|
|
| Very
|
|
|
| Very
| Extra
|
| Cost Drivers
| Low
| Low
| Nominal
| High
| High
| High
|
| Product attributes
|
| Required software reliability
| 0.75
| 0.88
| 1.00
| 1.15
| 1.40
|
| Size of application database
|
| 0.94
| 1.00
| 1.08
| 1.16
|
| Complexity of the product
| 0.70
| 0.85
| 1.00
| 1.15
| 1.30
| 1.65
|
| Hardware attributes
|
| Run-time performance constraints
|
|
| 1.00
| 1.11
| 1.30
| 1.66
|
| Memory constraints
|
|
| 1.00
| 1.06
| 1.21
| 1.56
|
| Volatility of the virtual machine envionment
|
| 0.87
| 1.00
| 1.15
| 1.30
|
| Required turnabout time
|
| 0.87
| 1.00
| 1.07
| 1.15
|
| Personnel attributes
|
| Analyst capability
| 1.46
| 1.19
| 1.00
| 0.86
| 0.71
|
| Software engineer capability
| 1.29
| 1.13
| 1.00
| 0.91
| 0.82
|
| Applications experience
| 1.42
| 1.17
| 1.00
| 0.86
| 0.70
|
| Virtuel machine experience
| 1.21
| 1.10
| 1.00
| 0.90
|
| Programming Language experience
| 1.14
| 1.07
| 1.00
| 0.95
|
| Project attributes
|
| Use of software tools
| 1.24
| 1.10
| 1.00
| 0.91
| 0.82
|
| Application of software engineering methods
| 1.24
| 1.10
| 1.00
| 0.91
| 0.83
|
| Required development schedule
| 1.23
| 1.08
| 1.00
| 1.04
| 1.10
|
The Intermediate Cocomo formula now takes the form...
- E=ai(LOC)(bi).EAF
where E is the effort applied in person-month and LOC is the estimated number of delivered lines of code for the project and EAF the factor calculated above.
The coedfficients ai and the exponent bi are given in the next table.
-
| Software project
| ai
| bi
|
| Organic
| 3.2
| 1.05
|
| Semi-detached
| 3.0
| 1.12
|
| Embedded
| 2.8
| 1.20
|
The Development time D is calculated from E in the same way as with basic Cocomo.
Function Point calculation
To calculate Effort and Development time using Cocomo you need an estimate of delivered lines of code.
A function point analysis is a method of calculation lines of code using function points.
The function point method was originaly developed bij Albrecht. A function point is a rough estimate of a unit of delivered functionality of a software project.
To calculate the number of function points for a software project one counts all the user inputs, user outputs, user inquiries, number of files and
number of external interfaces splitting them up in simple, average and complex ones.
- Number of user inputs
Each user input that provides distinct application oriented data to the software is counted.
- Number of user outputs
Each user output that provides application oriented information to the user is counted. In this context "output" refers to reports, screens, error messages, etc. Individual data items within a report are not counted separately.
- Number of user inquiries
An inquiry is defined as an on-line input that results in the generation of some immediate software response in the form of an on-line output. Each distinct inquiry is counted.
- Number of files
Each logical master file is counted.
- Number of external interfaces
All machine-readable interfaces that are used to transmit information
to another system are counted.
By multiplying these found countings using the table below a total count is created.
-
| Measurement parameter
| Weighting factor |
| Simple | Average | Complex
|
|---|
| Number of user inputs | 3 | 4 | 6
|
| Number of user outputs | 4 | 5 | 7
|
| Number of user inquiries | 3 | 4 | 6
|
| Number of files | 7 | 10 | 15
|
| Number of external interfaces | 5 | 7 | 10
|
This count total isn't the number of function points. To get those we have to use the following formula:
- FP= count total x [0.65 + 0.01 x SUM(Fi)]
The only part of the formula we haven't explained yet is the SUM(Fi) part. This is anumber that says something about the Technical complexity. It is generated bij giving a rate on a scale of 0 to 5 for each of the next questions. The hig
her the rate the more important the function is.
- Does the system require reliable backup and recovery?
- Are datacommunications required?
- Are there distributed processing functions?
- Is preformance critical?
- Will the system run in an existing, heavuly utilized operational enviroment?
- Does the system require on-line data entry?
- Does the on-line data entry require the input transaction to be build over multiple screens or operations?
- Are the master files updated online?
- Are the input, outputs, files or inquiries complex?
- Is the internal processing complex?
- Is the code designed to be reusable?
- Are conversions and installation included in the design?
- Is the system designed for multiple installations in different organizations?
- Is the applications designed to facilitate change and ease of use bij the user?
The final step is to get from function points to lines of code. That can be done by multiplying the number function points with a factor that is different for every programming language. This factor discribes how many source lines it takes to implement 1
function point.
Bibliography
| Boehm, Barry W.
| (1981)
| Software engineering economics
|
| Katwijk, J. van
| (1994)
| Inleiding software engineering
|
Pressman, Roger S.
(adapted by Darrel Ince)
| (1994)
| Software engineering
"A practitioner's approach"
|
