COST ESTIMATION: APPROACH AND METHODS

Cost estimation should never be an activity that is performed independently of

technical work. In the early life-cycle phases, cost estimation is closely related
to design activities, where the interaction between these activities is iterated
many times as part of doing design trade studies and early risk analysis. Later
on in the life-cycle, cost estimation supports management activities – primarily
detailed planning, scheduling, and risk management.

The purpose of software cost estimation is to:

• Define the resources needed to produce, verify, and validate the software
product, and manage these activities.

• Quantify, insofar as is practical, the uncertainty and risk inherent in this

estimate.

Cost Estimation
Software cost estimation is the process of predicting the resources required for
the software development process. For a given set of requirements, it is
desirable to know how much it will cost to develop the software to satisfy the
given requirements and how much time development will take. These estimates
are needed before development is initialised. For a software development
process accurate cost and schedule estimates are essential for managing the
project.

Total SW Project cost = SW Development Labour cost + Other Labour

cost + Non-labour cost

SW Development Labour costs include:

• Software Systems Engineering – performed by the software architect, software

system engineer, and subsystem engineer for functional design, software
requirements, and interface specification. Labour for data systems engineering,
which is often forgotten, should also be considered. This includes science
product definition and data management.

• Software Engineering – performed by the cognizant engineer and developers

to unit design, develop code, unit test, and integrate software components

• Software Test Engineering – covers test engineering activities from writing

test plans and procedures to performing any level of test above unit testing.
Other labour cost includes:

• Software management and support – performed by the project element

manager (PEM), software manager, technical lead, and system administration to
plan and direct the software project and software configuration management

• Test-bed development

• Development Environment Support

• Software system-level test support, including development and

simulation software

• Assembly, Test, & Launch Operations (ATLO) support for flight projects

• Administration and Support Costs

• Software Quality Assurance

• Independent Verification & Validation (IV&V)

• Other review or support charges

Non-labour cost includes:

• Support and services, such as workstations, test-bed boards & simulators,

ground support equipment, network and phone charges, etc.

• Software procurements such as development environment, compilers, licenses,

CM tools, test tools, and development tools

• Travel and trips related to customer reviews and interfaces, vendor visits, plus
attendance at project-related conferences

• Training
The COCOMO Model (Barry Boehm 1981):
The COnstructive COst MOdel (COCOMO) is an example of regression models used for
estimating software cost and effort. These methods use a basic formula with parameters that
are determined via a historical database and current project characteristics.

The COCOMO Model is the most widely used and accepted of the cost / effort estimation
models. This model as a size-driven model is highly dependent upon the manager's ability to
estimate the size of the software system at an early stage. This method is generally used in
conjunction with one of the size estimation models such as function points.

The COCOMO exists in a hierarchy of increasingly detailed and accurate forms. The top
level model, Basic COCOMO is applicable to the large majority of software projects: small
to medium products developed in a familiar in-house software development environment.

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
difference in hardware constraints, personnel quality and experience, use of modern tools and
techniques, and other project attributes known to have a significant influence on software
costs. Intermediate COCOMO includes these factors in terms of their aggregate impact on
overall project costs. Detailed COCOMO accounts for the influence of these additional
factors on individual project phases.

The Development Mode:

There are several modes of software development .These different software development
modes have cost-estimating relationships which are similar in form, but which yield
significantly different cost estimates for software products of the same size. In the COCOMO
Model, one of the most important factors contributing to a project's duration and cost is the
Development mode. Every project is considered to be developed in one of three modes:

 Organic Mode.

 Semidetached Mode

 Embedded Mode

 To estimate the effort and development time, COCOMO use the same equations but with
different coefficients ( a, b, c, d in the effort and schedule equations ) for each development
mode. Therefore before using the COCOMO model we must be able to recognise the
development mode of our project.

1. Organic Mode:

In the organic mode the project is developed in a familiar, stable environment and the
product is similar to previously developed products. The product is relatively small,
and requires little innovation. Most people connected with the project have extensive
experience in working with related systems within the organization and therefore can
usefully contribute to the project in its early stages, without generating a great deal of
project communication overhead. An organic mode project is relatively relaxed about
the way the software meets its requirements and interface specifications. If a situation
arises where an exact correspondence of the software product to the original
requirements would cause an extensive rework, the project team can generally
negotiate a modification of the specifications that can be developed more easily.

2. Semidetached Mode:

In this mode project's characteristics are intermediate between Organic and

Embedded. "Intermediate" may mean either of two things:

1. An intermediate level of project characteristics.

2. A mixture of the organic and embedded mode characteristics.

Therefore in an Semidetached mode project, it is possible that:

o The team members all have an intermediate level of experience with related
systems.

o The team has a wide mixture of experienced and inexperienced people.

o The team members have experience related to some aspects of the system
under development, but not others.

The size of a Semidetached mode product generally extends up to 300 KDSI.

3. Embedded Mode:

In this development mode Project is characterized by tight , inflexible constraints and

interface requirements. The product must operate within a strongly coupled complex of
hardware, software, regulations, and operational procedures. The embedded-mode project
does not generally have the option of negotiating easier software changes and fixes by
modifying the requirements and interface specifications. The project therefore need more
effort to accommodate changes and fixes. The embedded mode project is generally charting
its way through unknown territory to a greater extent than the organic mode project. This lead
the project to use a much smaller team of analyst in the early stages, as a large number of
people would get swamped in communication overhead.
Once the embedded mode project has completed its product design, its best strategy is to
bring on a very large team of programmers to perform detailed design, coding and unit testing
in parallel. Otherwise the project would take much longer to complete. This strategy as we
will see leads to the higher peaks in the personnel curves of embedded-mode projects, and to
the greater amount of effort consumed compared to an organic mode project working to the
same total development schedule.

The Basic COCOMO Model:

The Basic Model makes its estimates of required effort (measured in Staff-Months SM )
based primarily on your estimate of the software project's size ( as measured in thousands of
Delivered Source Instructions KDSI ):

SM = a * ( KDSI )b

The Basic model also presents an equation for estimating the development schedule (Time of
Develop TDEV ) of the project in months:

TDEV= c * ( SM )d

The Basic COCOMO Effort and schedule equations for organic mode software
projects are:

SM = 2.4 * ( KDSI )1.05

TDEV= 2.50 * ( SM )0.38

The Basic COCOMO Effort and schedule equations for organic mode software
projects are:

SM = 3.0 * ( KDSI )1.12

TDEV= 2.50 * ( SM )0.35

4.  The Basic COCOMO Effort and schedule equations for organic mode software
projects are:

SM = 3.6 * ( KDSI )1.20

TDEV= 2.50 * ( SM )0.32

Intermediate COCOMO Model: 
 The Intermediate COCOMO is an extension of the basic COCOMO model. Here we use the
same basic equation for the model. But coefficients are slightly different for the effort
equation. Also in addition to the size as the basic cost driver we use 15 more predictor
variables. These added cost drivers help to estimate effort and cost with more accuracy. An
estimator looks closely at many factors of a project such as amount of external storage
required, execution speed constraints, experience of the programmers on the team, experience
with the implementation language, use of software tools, etc., for each characteristic, the
estimator decide where on the scale of "very low" , " low", " Nominal", "High", "Very High"
and "High" the project falls. Each characteristic gives an adjustment factor( from the table 7 )
and all factors are multiplied together to give an Effort Adjustment Factor ( EAF).If a project
is judged normal in some characteristic the adjustment factor will be 1 for that characteristic (
Nominal column in Table 7 ), which means that that factor has no effect on overall EAF. The
effort equation for the intermediate model has the form of:

SM = EAF * a * ( KDSI )b
If we assume that the project is "Nominal" in every aspect then all adjustment factors would be 1, which
results in EAF=1, and the effort equation would have the same form as the Basic mode.

in addition to the EAF the model parameter "a" is slightly different in Intermediate COCOMO, but the "b"
parameter is the same. The effort equation for different modes of Intermediate COCOMO is given in the
following table:

Intermediate Effort
Development Mode
Equation
Organic: SM = EAF * 3.2 * ( KDSI )1.05
Semi Detached SM = EAF * 3.0* ( KDSI )1.12
Embedded SM = EAF * 2.8* ( KDSI )1.20

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:-

 Product attributes
o Required software reliability
o Size of application database
o Complexity of the product
 Hardware attributes
o Run-time performance constraints
o Memory constraints
o Volatility of the virtual machine environment
o Required turnabout time
  Personnel attributes
o Analyst capability
o Software engineering capability
o Applications experience
o Virtual machine experience
o Programming language experience
 Project attributes
o Use of software tools
o Application of software engineering methods
o 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.

Detailed COCOMO
In detailed COCOMO, the effort is calculated as function of program size and a
set of cost drivers given according to each phase of the life cycle. The phases
used in Detailed COCOMO are the requirements planning and product design,
detailed design, code and unit test, and the integration testing.

Effort = (a*sizeb ) * EAF * sum(Wi).

(Wi) is the weights of life cycle model. The life cycle activities like
requirements planning, system design, detailed design, code and unit testing,
integration and testing.

ADVANTAGES OF COCOMO'81

• COCOMO is transparent; one can see how it works unlike other models
such as SLIM

• Drivers are particularly helpful to the estimator to understand the impact

of different factors that affect project costs

DRAWBACKS OF COCOMO'81

• It is hard to accurately estimate KDSI early on in the project, when most

effort estimates are required

• KDSI, actually, is not a size measure it is a length measure

 • Extremely vulnerable to mis-classification of the development mode

• Success depends largely on tuning the model to the needs of the

organization, using historical data which is not always available

DIFFERENCES BETWEEN COCOMO I AND COCOMO II

• The major differences between COCOMO I AND COCOMO II are:

COCOMO'81 requires software size in KDSI as an input, but COCOMO
II is based on KSLOC (logical code). The major difference between DSI
and SLOC is that a single Source Line of Code may be several physical
lines. For example, an "if-then-else" statement would be counted as one
SLOC, but might be counted as several DSI.

• COCOMO II addresses the following three phases of the spiral life cycle:
applications development, early design and post architecture

• COCOMO'81 provides point estimates of effort and schedule, but

COCOMO II provides likely ranges of estimates that represent one
standard deviation around the most likely estimate.

• The estimation equation exponent is determined by five scale factors

(instead of the three development modes)

• Changes in cost drivers are:

§ Added cost drivers (7): DOCU, RUSE, PVOL, PLEX, LTEX, PCON, SITE

§ Deleted cost drivers (5): VIRT, TURN, VEXP, LEXP, MODP

§ Alter the retained ratings to reflect more up-do-date software practices

• Data points in COCOMO I: 63 and COCOMO II: 161

• COCOMO II adjusts for software reuse and reengineering where

automated tools are used for translation of existing software, but
COCOMO'81 made little accommodation for these factors

• COCOMO II accounts for requirements volatility in its estimates