Ex.
no 4
Date SOFTWARE COST ESTIMATION USING COSTAR
AIM:
To study software cost estimation using costar and estimate cost of a sample project
using the same.
Software Cost Estimation Using Costar
The ability to accurately estimate the time and/or cost taken for a project to come in to
its successful conclusion is a serious problem for software engineers. The use of a repeatable,
clearly defined and well understood software development process has, in recent years,
shown itself to be the most effective method of gaining useful historical data that can be used
for statistical estimation. In particular, the act of sampling more frequently, coupled with the
loosening of constraints between parts of a project, has allowed more accurate estimation and
more rapid development times.
The Constructive Cost Model (COCOMO) is an algorithmic software cost estimation
model developed by Barry Boehm. The model uses a basic regression formula, with
parameters that are derived from historical project data and current project characteristics.
COCOMO was first published in 1981 Barry W. Boehm's Book Software engineering
economics[1] as a model for estimating effort, cost, and schedule for software projects. It
drew on a study of 63 projects at TRW Aerospace where Barry Boehm was Director of
Software Research and Technology in 1981. The study examined projects ranging in size
from 2,000 to 100,000 lines of code, and programming languages ranging
from assembly to PL/I. These projects were based on the waterfall model of software
development which was the prevalent software development process in 1981.
Basic COCOMO
Basic COCOMO computes software development effort (and cost) as a function of
program size. Program size is expressed in estimated thousands of lines of code (SLOC)
COCOMO applies to three classes of software projects:
1. Organic projects - "small" teams with "good" experience working with "less than
rigid" requirements
2. Semi-detached projects - "medium" teams with mixed experience working with a mix
of rigid and less than rigid requirements
3. Embedded projects - developed within a set of "tight" constraints (hardware, software,
operational, ......)
The basic COCOMO equations take the form
Effort Applied (E) = ab(SLOC)bb [ man-months ]
Development Time (D) = cb(Effort Applied)db [months]
People required (P) = Effort Applied / Development Time [count]
where, SLOC is the estimated number of delivered lines (expressed in thousands ) of code for
project, The coefficients ab, bb, cb and db are given in the following table.
Fig 4.1 The coefficients ab, bb, cb and db
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
Intermediate COCOMO
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. This extension considers a set of four "cost
drivers",each with a number of subsidiary attributes:-
1. Product attributes
2. Required software reliability
3. Size of application database
4. Complexity of the product
5. Hardware attributes
6. Run-time performance constraints
7. Memory constraints
8. Volatility of the virtual machine environment
9. Required turnabout time
10. Personnel attributes
11. Analyst capability
12. Software engineering capability
13. Applications experience
14. Virtual machine experience
15. Programming language experience
16. Project attributes
17. Use of software tools
18. Application of software engineering methods
19. Required development schedule
Each of the 15 attributes receives a rating on a six-point scale that ranges from "very low"
to "extra high" (in importance or value). An effort multiplier from the table below applies to
the rating. The product of all effort multipliers results in an effort adjustment factor (EAF).
Typical values for EAF range from 0.9 to 1.4.
Fig 4.2 Cost drivers and Ratings
Cost Drivers Ratings
Nomina Very Extra
Very Low Low l High High High
Product attributes
Required software 0.75 0.88 1.00 1.15 1.40
reliability
Size of application 0.94 1.00 1.08 1.16
database
Complexity of the 0.70 0.85 1.00 1.15 1.30 1.65
product
Hardware attributes
Run-time performance 1.00 1.11 1.30 1.66
constraints
Memory constraints 1.00 1.06 1.21 1.56
Volatility of the virtual 0.87 1.00 1.15 1.30
machine environment
Required turnabout 0.87 1.00 1.07 1.15
time
Personnel attributes
Analyst capability 1.46 1.19 1.00 0.86 0.71
Applications 1.29 1.13 1.00 0.91 0.82
experience
Software engineer 1.42 1.17 1.00 0.86 0.70
capability
Virtual machine 1.21 1.10 1.00 0.90
experience
Programming language 1.14 1.07 1.00 0.95
experience
Project attributes
Application of software 1.24 1.10 1.00 0.91 0.82
engineering methods
Use of software tools 1.24 1.10 1.00 0.91 0.83
Required development 1.23 1.08 1.00 1.04 1.10
schedule
The Intermediate Cocomo formula now takes the form:
E=ai(SLoC)(bi).EAF
where E is the effort applied in person-months, SLoC is the estimated number of thousands of
delivered lines of code for the project, and EAF is the factor calculated above. The coefficient
ai and the exponent bi are given in the next table.
Fig 4.3 Coeffiecients ai and bi
Software ai bi
project
Organic 3.2 1.05
Semi-detached 3.0 1.12
Embedded 2.8 1.20
The Development time D calculation uses E in the same way as in the Basic COCOMO.
Using Costar
Most of the interactions with Costar will involve creating and modifying components. We
define subcomponents, assign cost driver values, estimate the size of each component, etc.
One component is always distinguished as "the current component". The name of the
current component, the cost drivers you've assigned to it, and other data describing the
current component are shown in the main Costar window.
A given component may be made up of any number of subcomponents. When you
create a new subcomponent, it becomes a subcomponent of the current component. It inherits
values for each of its attributes from its parent component. The following attributes are
inherited:
Settings for the Cost Drivers
Cost per Person-Month settings
Maintenance, Adaptation, and Conversion settings
Costar makes it easy to perform "what-if" analyses, and to compare different project plans.
You may develop a new estimate based upon an older one, and then use Costar to compare
the two.
A Costar estimate consists of:
1. A name
2. An ID
3. A one line comment
4. 5 Scale Drivers (COCOMO II models) or a Development Mode (COCOMO 81
models)
5. An associated database (e.g. COCOMO II.2000)
6. APM settings
7. Names & costs of labor classes
8. One or more components
One estimate is always distinguished as "the current estimate". All of the Costar
commands operate on the current estimate.
When there is only a single component in an estimate, the SLOC value for the component
is identical to the total SLOC value for the estimate. But when a component has
subcomponents, the SLOC value is derived from the SLOC values of its subcomponents.
Costar lets you specify SLOC values in three different ways:
1. We can explicitly enter a SLOC value such as 3,000.
2. We can use the Reuse Tab to calculate the SLOC.
3. We can use the Function Point Tab to calculate the SLOC.
