******Created by ebook converter - www.ebook-converter.

com******

function point metric can be that the way one groups input and output
data items into logically related groups can be very subjective. For
example, consider that certain functionality requires the employee
name and employee address to be input. It is possible that one can
consider both these items as a single unit of data, since after all, these
describe a single employee. It is also possible for someone else to
consider an employee’s address as a single unit of input data and name
as another. Such ambiguities leav e sufficient scope for debate and keep
open the possibility for different project managers to arrive at different
function point measures for essentially the same problem.

3.5 PROJECT ESTIMATION TECHNIQUES

Estimation of various project parameters is an important project planning
activity. The different parameters of a project that need to be
estimated include—project size, effort required to complete the project,
project duration, and cost. Accurate estimation of these parameters is
important, since these not only help in quoting an appropriate project
cost to the customer, but also form the basis for resource planning and
scheduling. A large number of estimation techniques have been
proposed by researchers. These can broadly be classified into three
main categories:
• Empirical estimation techniques
• Heuristic techniques
• Analytical estimation techniques
In the following subsections, we provide an overview of the different
categories of estimation techniques.

3.5.1 Empirical Estimation Techniques

Empirical estimation techniques are essentially based on making an
educated guess of the project parameters. While using this technique,
prior experience with development of similar products is helpful.
Although empirical estimation techniques are based on common sense
and subjective decisions, over the years, the different activities involved
in estimation have been formalised to a large extent. We shall discuss
two such formalisations of the basic empirical estimation techniques
known as expert judgement and the Delphi techniques in Sections 3.6.1
and 3.6.2 respectively.

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

3.5.2 Heuristic Techniques

Heuristic techniques assume that the relationships that exist among the
different project parameters can be satisfactorily modelled using
suitable mathematical expressions. Once the basic (independent)
parameters are known, the other (dependent) parameters can be easily
determined by substituting the values of the independent parameters in
the corresponding mathematical expression. Different heuristic
estimation models can be divided into the following two broad
categories—single variable and multivariable models.
S i n g l e variable estimation models assume that various project
characteristic can be predicted based on a single previously estimated basic
(independent) characteristic of the software such as its size. A single variable
estimation model assumes that the relationship between a parameter to be
estimated and the corresponding independent parameter can be
characterised by an expression of the following form:
Estimated Parameter = c1 ed1
In the above expression, e represents a characteristic of the software that
has already been estimated (independent variable). Estimated P arameter is
the dependent parameter (to be estimated). The dependent parameter to be
estimated could be effort, project duration, staff size, etc., c1 a nd d1 are
constants. The values of the constants c1 a nd d1 a r e usually determined
using data collected from past projects (historical data). The COCOMO model
discussed in Section 3.7.1, is an example of a single variable cost estimation
model.
A multivariable cost estimation model assumes that a parameter can be
predicted based on the values of more than one independent parameter. It
takes the following form:
Estimated Resource = c1 p1d1 + c2 p2d2 + ...
where, p1, p2, ... are the basic (independent) characteristics of the
software already estimated, and c1, c2, d1, d2, .... are constants.
Multivariable estimation models are expected to give more accurate
estimates compared to the single variable models, since a project
parameter is typically influenced by several independent parameters.
The independent parameters influence the dependent parameter to
different extents. This is modelled by the different sets of constants c1 ,
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

d1 , c2 , d2 , .... Values of these constants are usually determined from

an analysis of historical data. The intermediate COCOMO model
discussed in Section 3.7.2 can b e considered to be an example of a
multivariable estimation model.

3.5.3 Analytical Estimation Techniques

Analytical estimation techniques derive the required results starting with
certain basic assumptions regarding a project. Unlike empirical and
heuristic techniques, analytical techniques do have certain scientific
basis. As an example of an analytical technique, we shall discuss the
Halstead’s software science in Section 3.8. We shall see that starting
wi th a few simple assumptions, Halstead’s software science derives
some interesting results. Halstead’s software science is especially useful
for estimating software maintenance efforts. In fact, it outperforms both
empirical and heuristic techniques as far as estimating software
maintenance efforts is concerned.

3.6 EMPIRICAL ESTIMATION TECHNIQUES

We have already pointed out that empirical estimation techniques have,
over the years, been formalised to a certain extent. Yet, these are still
essentially euphemisms for pure guess work. These techniques are easy
to use and give reasonably accurate estimates. Two popular empirical
estimation techniques are—Expert judgement and Delphi estimation
techniques. We discuss these two techniques in the following
subsection.

3.6.1 Expert Judgement

Expert judgement is a widely used size estimation technique. In this
technique, an expert makes an educated guess about the problem size
after analysing the problem thoroughly.
Usually, the expert estimates the cost of the different components (i.e.
modules or subsystems) that would make up the system and then combines
the estimates for the individual modules to arrive at the overall estimate.
However, this technique suffers from several shortcomings. The outcome of
t he expert judgement technique is subject to human errors and individual
bias. Also, it is possible that an expert may overlook some factors
inadvertently. Further, an expert making an estimate may not have relevant

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

experience and knowledge of all aspects of a project. For example, he may

be conversant with the database and user interface parts, but may not be
very knowledgeable about the computer communication part. Due to these
factors, the size estimation arrived at by the judgement of a single expert
may be far from being accurate.
A more refined form of expert judgement is the estimation made by a
group of experts. Chances of errors arising out of issues such as individual
oversight, lack of familiarity with a particular aspect of a project, personal
bias, and the desire to win contract through overly optimistic estimates is
minimised when the estimation is done by a group of experts. However, the
estimate made by a group of experts may still exhibit bias. For example, on
certain issues the entire group of experts may be biased due to reasons such
as those arising out of political or social considerations. Another important
shortcoming of the expert judgement technique is that the decision made by
a group may be dominated by overly assertive members.

3.6.2 Delphi Cost Estimation

Delphi cost estimation technique tries to overcome some of the
shortcomings of the expert judgement approach. Delphi estimation is
carried out by a team comprising a group of experts and a co-ordinator.
In this approach, the co-ordinator provides each estimator with a copy
of the software requirements specification (SRS) document and a form
for recording his cost estimate. Estimators complete their individual
estimates anonymously and submit them to the co-ordinator. In their
estimates, the estimators mention any unusual characteristic of the
product which has influe nce d their estimations. The co-ordinator
prepares the summary of the responses of all the estimators, and also
includes any unusual rationale noted by any of the estimators. The
prepared summary information is distributed to the estimators. Based
on this summary, the estimators re-estimate. This process is iterated
for several rounds. However, no discussions among the estimators is
allowed during the entire estimation process. The purpose behind this
restriction is that if any discussion is allowed among the estimators,
then many estimators may easily get influenced by the rationale of an
estimator who may be more experienced or senior. After the completion
of several iterations of estimations, the co-ordinator takes the
responsibility of compiling the results and preparing the final estimate.
The Delphi estimation, though consumes more time and effort,
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

overcomes an important shortcoming of the expert judgement

technique in that the results can not unjustly be influenced by overly
assertive and senior members.

3.7 COCOMO—A HEURISTIC ESTIMATION TECHNIQUE

COnstructive COst estimation MOdel (COCOMO) was proposed by Boehm
[1981]. COCOMO prescribes a three stage process for project
estimation. In the first stage, an initial estimate is arrived at. Over the
next two stages, the initial estimate is refined to arrive at a more
accurate estimate. COCOMO uses both single and multivariable
estimation models at different stages of estimation.
The three stages of COCOMO estimation technique are—basic COCOMO,
intermediate COCOMO, and complete COCOMO. We discuss these three
stages of estimation in the following subsection.

3.7.1 Basic COCOMO Model

Boehm postulated that any software development project can be
classified into one of the following three categories based on the
development complexity—organic, semidetached, and embedded.
Based on the category of a software development project, he gave
different sets of formulas to estimate the effort and duration from the
size estimate.

Three basic classes of software development projects

In order to classify a project into the identified categories, Boehm
requires us to consider not only the characteristics of the product but
also those of the development team and development environment.
Roughly speaking, the three product development classes correspond to
development of application, utility and system software. Normally, data
processing programs1 are considered to be application programs.
Compilers, linkers, etc., are utility programs. Operating systems and
real-time system programs, etc. are system programs. System
programs interact directly with the hardware and programming
complexities also arise out of the requirement for meeting timing
constraints and concurrent processing of tasks.
Brooks [1975] states that utility programs are roughly three times as
difficult to write as application programs and system programs are roughly
three times as difficult as utility programs. Thus according to Brooks, the
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

relative levels of product development complexity for the three categories

(application, utility and system programs) of products are 1:3:9.
Boehm’s [1981] definitions of organic, semidetached, and embedded
software are elaborated as follows:
Organic: We can classify a development project to be of organic type, if the
project deals with developing a well-understood application program, the size
of the development team is reasonably small, and the team members are
experienced in developing similar types of projects.
Semidetached: A development project can be classify to be of
semidetached type, if the development team consists of a mixture of
experienced and inexperienced staff. Team members may have limited
experience on related systems but may be unfamiliar with some aspects of
the system being developed.
Embedded: A development project is considered to be of embedded type, if
the software being developed is strongly coupled to hardware, or if stringent
regulations on the operational procedures exist. Team members may have
limited experience on related systems but may be unfamiliar with some
aspects of the system being developed.
Observe that in deciding the category of the development project, in
addition to considering the characteristics of the product being developed, we
need to consider the characteristics of the team members. Thus, a simple
data processing program may be classified as semidetached, if the team
members are inexperienced in the development of similar products.
For the three product categories, Boehm provides different sets of
expressions to predict the effort (in units of person-months) and development
time from the size estimation given in kilo lines of source code (KLSC). But,
how much effort is one person-month?
One person month is the effort an individual can typically put in a month. The
person-month estimate implicitly takes into account the productivity losses that
normally occur due to time lost in holidays, weekly offs, coffee breaks, etc.

What is a person-month?
Person-month (PM) is a popular unit for effort measurement.
Person-month (PM) is considered to be an appropriate unit for measuring effort,
because developers are typically assigned to a project for a certain number of
months.

It should be converter
******ebook carefully noted
DEMO that an effort estimation of 100 PM does not
- www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

It should be carefully noted that an effort estimation of 100 PM does not

imply that 100 persons should work for 1 month. Neither does it imply that 1
person should be employed for 100 months to complete the project. The
effort estimation simply denotes the area under the person-month curve (see
Figure 3.3 ) for the project. The plot in Figure 3.3 shows that different
number of personnel may work at different points in the project development.
The number of personnel working on the project usually increases or
decreases by an integral number, resulting in the sharp edges in the plot. We
shall elaborate in Section 3.9 how the exact number of persons to work at
any time on the product development can be determined from the effort and
duration estimates.

Figure 3.3: Person-month curve.

General form of the COCOMO expressions

T he basic COCOMO model is a single variable heuristic model that
gives an approximate estimate of the project parameters. The basic
COCOMO estimation model is given by expressions of the following
forms:
Effort = a1 × (KLOC)a2 PM
Tdev = b1 × (Effort)b2 months
where,

KLOC is the estimated size of the software product expressed in Kilo

Lines Of Code.
a1, a2, b1, b2 are constants for each category of software product.
Tdev is the estimated time to develop the software, expressed in

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

months.
Effort is the total effort required to develop the software product,
expressed in person- months (PMs).

According to Boehm, every line of source text should be calculated as one

LOC irrespective of the actual number of instructions on that line. Thus, if a
single instruction spans several lines (say n lines), it is considered to be
nLOC. The values of a1, a2, b1, b2 for different categories of products as
given by Boehm [1981] are summarised below. He derived these values by
examining historical data collected from a large number of actual projects.
Estimation of development effort: For the three classes of software
products, the formulas for estimating the effort based on the code size are
shown below:
Organic : Effort = 2.4(KLOC)1.05 PM
Semi-detached : Effort = 3.0(KLOC)1.12 PM
Embedded : Effort = 3.6(KLOC)1.20 PM
Estimation of development time: For the three classes of software products,
the formulas for estimating the development time based on the effort are
given below:
Organic : Tdev = 2.5(Effort)0.38 Months
Semi-detached : Tdev = 2.5(Effort)0.35 Months
Embedded : Tdev = 2.5(Effort)0.32 Months
We can gain some insight into the basic COCOMO model, if we plot the
estimated effort and duration values for different software sizes. Figure 3.4
shows the plots of estimated effort versus product size for different categories
of software products.
Observations from the effort-size plot From Figure 3.4, we can observe
that the effort is some what superlinear (that is, slope of the curve>1) in the
size of the software product.

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

Figure 3.4: Effort versus product size.

This is because the exponent in the effort expression is more than 1. Thus,
the effort required to develop a product increases rapidly with project size.
However, observe that the increase in effort with size is not as bad as that
was portrayed in Chapter 1. The reason for this is that COCOMO assumes that
projects are carefully designed and developed by using software engineering
principles.

Observations from the development time—size plot

T he development time versus the product size in KLOC is plotted in
Figure 3.5. From
Figure 3.5, we can observe the following:

The development time is a sublinear function of the size of the product.

That is, when the size of the product increases by two times, the time
to develop the product does not double but rises moderately. For
example, to develop a product twice as large as a product of size
100KLOC, the increase in duration may only be 20 per cent. It may
appear surprising that the duration curve does not increase
superlinearly—one would normally expect the curves to behave similar
to those in the effort-size plots. This apparent anomaly can be
explained by the fact that COCOMO assumes that a project
development is carried out not by a single person but by a team of
developers.
From Figure 3.5 we can observe that for a project of any given size, the
******ebook converter DEMO - www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

development time is roughly the same for all the three categories of
products. For example, a 60 KLOC program can be developed in
approximately 18 months, regardless of whether it is of organic, semi-
detached, or embedded type. (Please verify this using the basic
COCOMO formulas discussed in this section). However, according to
the COCOMO formulas, embedded programs require much higher effort
than either application or utility programs. We can interpret it to mean
that there is more scope for parallel activities for system programs
than those in utility or application programs.

Figure 3.5: Development time versus size.

Cost estimation
From the effort estimation, project cost can be obtained by multiplying
the estimated effort (in man-month) by the manpower cost per month.
Implicit in this project cost computation is the assumption that the
entire project cost is incurred on account of the manpower cost alone.
However, in addition to manpower cost, a project would incur several
other types of costs which we shall refer to as the overhead costs. The
overhead costs would include the costs due to hardware and software
required for the project and the company overheads for administration,
office space,electricity, etc. De pending on the expected values of the
overhead costs, the project manager has to suitably scale up the cost

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

arrived by using the COCOMO formula.

Implications of effort and duration estimate

An important implicit implication of the COCOMO estimates are that if you
try to complete the project in a time shorter than the estimated duration,
then the cost will increase drastically. But, if you complete the project over a
longer period of time than that estimated, then there is almost no decrease
in the estimated cost value. The reasons for this are discussed in Section 3.9.
Thus, we can consider that the COCOMO effort and duration values to
indicate the following.
The effort and duration values computed by COCOMO are the values for completing
the work in the shortest time without unduly increasing manpower cost.
Let us now elaborate the above statement. When a project team consists
of a single member, the member would never be idle for want of work, but
the project would take too long to complete. On the other hand, when there
are too many members, the project would be completed in much shorter
time, but often during the project duration some members would have to idle
for want of work.
The project duration is as computed by the COCOMO model, all the
developers remain busy with work during the entire development period.
Whenever a project is to be completed in a time shorter than the duration
estimated by using COCOMO, some idle time on the part of the developers
would exist. Such idle times would result in increased development cost. An
optimum sized team for a project is one in which any developer any time
during development does not sit idle waiting for work, but at the same time
consists of as many members as possible to reduce the development time.
We can think of the duration given by COCOMO is called the as the optimal
duration. It is called optimal duration, if the project is attempted to be
completed in any shorter time, then the effort required would rise rapidly.
This may appear as a paradox—after all, it is the same product that would be
developed, though over a shorter time, then why should the effort required
rise rapidly? This can be explained by the fact that for every product at any
point during the project development, there is a limit on the number of
parallel activities that can meaningfully be identified and carried out. Thus if
more number of developers are deployed than the optimal size, some of the
developers would have to idle, since at some point in development or other,
it would not be possible to assign them any work at all. These idle times

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

would show up as higher effort and larger cost.

Staff-size estimation
Given the estimations for the project development effort and the nominal
development time, can the required staffing level be determined by a
simple division of the effort estimation by the duration estimation? The
answer is “No”. It will be a perfect recipe for project delays and cost
overshoot. We examine the staffing problem in more detail in Section
3.9. From the discussions in Section 3.9, it would become clear that the
simple division approach to obtain the staff size would be highly
improper.
Example 3.2 Assume that the size of an organic type software product has
been estimated to be 32,000 lines of source code. Assume that the average
salary of a software developer is Rs. 15,000 per month. Determine the effort
required to develop the software product, the nominal development time, and
the cost to develop the product.
From the basic COCOMO estimation formula for organic software: Effort =
2.4 × (32)1.05 = 91 PM
Nominal development time = 2.5 × (91)0.38 = 14 months
Staff cost required to develop the product = 91 × Rs. 15, 000 = Rs.
1,465,000

3.7.2 Intermediate COCOMO

The basic COCOMO model assumes that effort and development time are
functions of the product size alone. However, a host of other project
parameters besides the product size affect the effort as well as the time
required to develop the product. For example the effort to develop a
product would vary depending upon the sophistication of the
development environment.
Therefore, in order to obtain an accurate estimation of the effort and
project duration, the effect of all relevant parameters must be taken into
account. The intermediate COCOMO model recognises this fact and refines
the initial estimates.
The intermediate COCOMO model refines the initial estimate obtained using the basic
COCOMO expressions by scaling the estimate up or down based on the evaluation of
a set of attributes of software development.

The intermediate
******ebook COCOMO
converter model
DEMO uses a set of 15 cost drivers (multipliers)
- www.ebook-converter.com*******
******Created by ebook converter - www.ebook-converter.com******

The intermediate COCOMO model uses a set of 15 cost drivers (multipliers)

that are determined based on various attributes of software development.
These cost drivers are multiplied with the initial cost and effort estimates
(obtained from the basic COCOMO) to appropriately scale those up or down.
For example, if modern programming practices are used, the initial estimates
are scaled downward by multiplication with a cost driver having a value less
than 1. If there are stringent reliability requirements on the software product,
the initial estimates are scaled upward. Boehm requires the project manager
to rate 15 different parameters for a particular project on a scale of one to
three. For each such grading of a project parameter, he has suggested
appropriate cost drivers (or multipliers) to refine the initial estimates.
In general, the cost drivers identified by Boehm can be classified as being
attributes of the following items:
Product: The characteristics of the product that are considered include the
inherent complexity of the product, reliability requirements of the product,
etc.
Computer: Characteristics of the computer that are considered include the
execution speed required, storage space required, etc.
Personnel: The attributes of development personnel that are considered
include the experience level of personnel, their programming capability,
analysis capability, etc.
Development environment: Development environment attributes capture
the development facilities available to the developers. An important
parameter that is considered is the sophistication of the automation (CASE)
tools used for software development.
We have discussed only the basic ideas behind the intermediate COCOMO
model. A detailed discussion on the intermediate COCOMO model are beyond
the scope of this book and the interested reader may refer [Boehm81].

3.7.3 Complete COCOMO

A major shortcoming of both the basic and the intermediate COCOMO
models is that they consider a software product as a single
homogeneous entity. However, most large systems are made up of
several smaller sub-systems. These sub-systems often have widely
different characteristics. For example, some sub-systems may be
considered as organic type, some semidetached, and some even
embedded. Not only may the inherent development complexity of the

******ebook converter DEMO - www.ebook-converter.com*******

******Created by ebook converter - www.ebook-converter.com******

subsystems be different, but for some subsystem the reliability

requirements may be high, for some the development team might have
no previous experience of similar development, and so on.
The complete COCOMO model considers these differences in characteristics
of the subsystems and estimates the effort and development time as the sum
of the estimates for the individual sub-systems.
In other words, the cost to develop each sub-system is estimated
separately, and the complete system cost is determined as the subsystem
costs. This approach reduces the margin of error in the final estimate.
L e t us consider the following development project as an example
application of the complete COCOMO model. A distributed management
information system (MIS) product for an organisation having offices at several
places across the country can have the following sub-component:
• Database part
• Graphical user interface (GUI) part
• Communication part
Of these, the communication part can be considered as embedded
software. The database part could be semi-detached software, and the GUI
part organic software. The costs for these three components can be
estimated separately, and summed up to give the overall cost of the system.
To further improve the accuracy of the results, the different parameter
values of the model can be fine-tuned and validated against an organisation’s
historical project database to obtain more accurate estimations. Estimation
models such as COCOMO are not totally accurate and lack a full scientific
justification. Still, software cost estimation models such as COCOMO are
required for an engineering approach to software project management.
Companies consider computed cost estimates to be satisfactory, if these are
within about 80 per cent of the final cost. Although these estimates are gross
approximations—without such models, one has only subjective judgements to
rely on.

3.7.4 COCOMO 2
Since the time that COCOMO estimation model was proposed in the early
1980s, the software development paradigms as well as the
characteristics of development projects have undergone a sea change.
The present day software projects are much larger in size and reuse of
existing software to develop new products has become pervasive. For
example, component-based development and service-oriented
******ebook converter DEMO - www.ebook-converter.com*******