Software

Software Cost Estimation

5 Cost Estimation NOTES

Chapter Includes :
• Introduction
• Software Cost Factors
• programmer’s ability
• Product Complexity
• Product Size
• Required Level of Reliability
• Level of Technology
• Decomposition Technique
• Empirical Estimation Models
• The Structure of Estimation Models

INTRODUCTION
Estimating the cost of the software product is one of the most difficult and error
prone tasks in software engineering. It is difficult to make an accurate cost estimate
during planning phase of software development because of number of factors at that
time, yet contracting practices often require a firm commitment as a part of feasi-
bility study. This coupled with competitive nature of business is a major factor that
contributes to the widespread cost and schedule overruns of software projects. There
are several options that allow to achieve reliable cost and effort estimation:
➤ delay estimation until late in the project
➤ use relatively simple decomposition techniques
➤ develop an empirical model for software cost and effort acquire one or more
automated estimation tools

SOFTWARE COST FACTORS

There are many factors that influence the cost of a software product. The effects of
most of these factors, and hence the cost of a development or maintenance effort, are
difficult to estimate. Primary among the cost factors are the individual abilities of
project personnel and their familiarity with the application area; the complexity of
the product; the size of the product; the available time, the required level of reli-
ability; the level of technology utilized, and the availability, familiarity, and stability 79
of the system used to develop the product. Each factor is discussed in turn.
Software Programmer’s Ability
Engineering
A well-known experiment conducted in 1968 by Harold Sackman and colleagues.
The goal was to determine the relative influence of batch and time-shared access on
programmer productivity. Twelve experienced programmers were each given two
NOTES
programming problems to solve, some using batch facilities and some using time-
sharing. The resulting differences in individual performance among the programmers
were much greater than could be attributed to the relatively small effect of batch or
time-shared machine access. One should hire always outstanding people. It is always
difficult to hire outstanding persons.
On very large projects, the differences in individual programmer ability will tend to
average out, but on projects utilizing five or less programmers, individual differences
in ability can be significant. Cost involved for the project is less, if it involves best
programmers. At the same time hiring them is also a costly affair.

Product Complexity
There are three generally acknowledged categories of software products: applications
programs, which include data processing and scientific programs; utility programs,
such as compilers, linkage editors, and inventory systems; and system level programs,
such as Database management systems, operating systems, and real-time systems.
Applications programs are developed in the environment provided by a language
compiler such as FORTRAN or Pascal or C. Interactions with the operating system
are limited to job control statements and run-time support facilities provided by the
language processor. Utility programs are written to provide user processing environ-
ments and make sophisticated use of operating system facilities. Systems programs
interact directly with the hardware. They typically involve concurrent processing and
timing constraints.
Brooks states that utility programs are three times as difficult to write as applications
programs, and that system programs are three times as difficult to write as utility
programs. His levels of product complexity are thus 1-3-9 for applications - utility
- systems programs.
Boehm uses three levels of product complexity and provides equations to predict
total programmer-months of effort, PM, in terms of the number of thousands of
delivered source instructions, KDSI, in the product. Programmer cost for a software
project can be obtained by multiplying the effort in programmer-months by the cost
per programmer-month. The equations were derived by examining historical data
from a large number of actual projects. These projects were large enough that indi-
vidual differences in programmer productivity tended to average out. In Boehm’s
terminology, the three levels of product complexity are organic, semidetached, and
embedded programs. These levels roughly correspond to applications programs, utility
programs, and systems program:
Applications Programs : PM = 2.4*(KDSI)*1.05
Utility programs : PM = 3.0*(KDSI)*1.12
Systems programs : PM = 3.6*(KDSI)*1.20
If the effort is more then more staff is required which directly increase the cost
estimation.
Product Size
80
A large software product is obviously more expensive to develop than a small one.
Boehm’s equations indicate that the rate of increase in required effort grows with the
number of source instructions at an exponential rate slightly greater than one. Other Software
investigators have developed equations similar to Boehm’s. Some investigators believe Cost Estimation
that the rate of increase in effort grows at an exponential rate slightly less than 1,
but most use an exponent in the range of 1.05 to 1.83.
Required Level of Reliability NOTES

Software Reliability can be defined as the probability that a program will perform
a required function under stated conditions for a stated period of time. Reliability
can be expressed in terms of accuracy, robustness, completeness, and consistency of
the source code. Reliability characteristics can be built into a software product, but
there is a cost associated with the increased level of analysis, design, implementation,
and verification and validation effort that must be exerted to ensure high reliability.
The desired level of reliability should be established during the planning phase by
considering the cost of software failures. In some cases, product failure may cause
only slight inconvenience to the user, while failure of other products may incur high
financial loss or risk to human life.
Level of Technology
The level of technology in a software development project is reflected by the pro-
gramming language, the abstract machine (hardware plus software), the program-
ming practices, and the software tools used. It is well known that the number of
source instructions written per day is largely independent of the language used, and
that program statements written in high-level languages such as FORTRAN and
Pascal or C typically expand into several machine-level statements. Use of a high level
language instead of assembly language thus increases programmer productivity by a
factor of 5 to 10. Modern programming languages provide additional features to
improve programmer productivity and software reliability. These features include
strong type-checking, data abstraction, separate compilation, exception handling,
interrupt handling, and concurrency mechanisms.
The abstract machine is the set of hardware and software facilities used during the
development process. Familiarity with, stability of, and ease of access to the abstract
machine all influence programmer productivity, and hence the cost of a software
project. Productivity will suffer if programmers need to learn a new machine envi-
ronment as part of the development process, or if the machine is being developed
in parallel with the software, or if programmers have only restricted access to the
machine.
Modern programming practices include use of systematic analysis and design tech-
niques, structured design notations, walkthroughs and inspections, structured cod-
ing, systematic testing, and a program development library. Software tools range
from elementary tools, such as assemblers and basic debugging aids, to compilers and
linkage editors, to interactive text editors and database management systems, to
program design language processors and requirements specification analyzers, to fully
integrated development environments that include configuration management and
automated verification tools.
Check Your Progress
Use of both modern practices and modern development tools reduce the develop- 1. What are cost influ-
ment effort. encing factors for soft-
ware product?
Decomposition Technique : 2. What is software reli-
ability?
In real world software project estimation is a form of problem solving. In most cases,
the problem to be solved is too complex to be considered in one piece. Due to this 81
reason, we break down the problem, re-characterising it as a set of smaller problems.
Software The decomposition approach was considered from two different points of view:
Engineering ➤ Decomposition of the problem and
➤ Decomposition of the process.
NOTES Estimation uses one or both forms of partitioning. But before an estimate can be
made, the project planner must understand the scope of the software to be built and
generate a calculation of its “size”.

I. Software Sizing :
The accuracy of a software project estimate is based on a number of things.
➤ The degree to which the planner has properly estimated the size of the
product to be built.
➤ The ability to translate the size estimate into human efforts.
➤ The degree to which the project plan denotes the abilities of the software
team.
➤ The stability of product requirements and the environment that supports the
software engineering effort.
In the context of project planning, size refers to a quantifiable result of the software
project. If a direct approach is taken, size can be measured in LOC. If an indirect
approach is chosen, size is represented as function point (FP).
The four different approaches to the sizing problem are:
(1) “Fuzzy Logic” Sizing : This approach uses the nearest reasoning techniques that
are the cornerstone of fuzzy logic. To apply this approach, the planner must
identify the type of application and then refine the magnitude within the
original range.
(2) Function (FP) Point Sizing : FP is derived using an empirical relationship based
on countable (direct) measure of software’s information domain and assessment
of software complexity.
(3) Standard Component Sizing : Software is made up of a number of different
“standard components” that are generic to a particular application area. The
project planner estimates the number of occurrences of each standard compo-
nent and then uses historical project data to determine the delivered size per
standard component.
(4) Change Sizing : This approach is used when a project goes through the use of
existing software that must be modified in some way as part of a project. The
planner estimates the number and type of modifications that must be accom-
plished by using an “effort ratio” for each type of change, the size of the change
may be estimated.
The result of each of these sizing approaches is combined statistically to create a
three-point or expected value calculation. This is accomplished by developing opti-
mistic (low), most likely and pessimistic (high) value for size and combining them.

II. Problem Based Estimation (Calculation) :

Lines of Code and Function, Point data are used in two ways during software project
82 estimation.
 ➤ As an estimation variable to “size” each element of the software. Software
➤ As baseline metrics collected from past projects and used in conjunction with Cost Estimation
estimation variables to develop cost and effort projections.
Both LOC and FP estimation are distinct estimation techniques. In spite of that NOTES
both have a number of characteristics in common. The project planner beings with
a bounded statement of software scope. After this statement attempts to decompose
software into problem functions that can each be calculated individually. LOC or FP
is then calculated for each function.
Then baseline productivity metrics are applied to the appropriate estimation variable
and cost or effort for the function is derived. Function estimates are combined to
produce an overall estimate for the entire project.
In general, LOC/pm or FP/pm averages should be computed by project domain.
That is, projects should be grouped by team size, application area, complexity and
other relevant parameters. Local domain averages should then be computed. When
a new project is estimated it should first be assigned to a domain and then the
appropriate domain average for productivity should be used in generating the esti-
mate.
The LOC and FP estimation techniques differ in the level of detail required for
decomposition and target of the partitioning. When LOC is used as the estimation
variable, decomposition is absolutely essential and is often taken to considerable
levels of details. The following decomposition approach has been adapted.

define product scope;

identify functions by decomposing scope;
do while functions remain
select a functionj
assign all function to subfunctions list;
do while subfunctions remain
select subfunctionk
if subfunctions resembles sunfunctiond described in a historical data
base
then note historical cost, effort, size (LOC or FP) data for
subfunctiond;
adjust historical cost, effort, size data based on any differ-
ences;
use adjust cost, effort, size data to derive partial estimate,
E p;
project estimate = sum of {E};
else if cost, effort, size (LOC or FP) for subfunctionk can be
estimated
then derive partial estimate, Ep;
project estimate = sum of {Ep}; Check Your Progress
else subdivide subfunctionk into smaller subfunctions;
3. What is empirical
add these to subfunctions list; estimation?
endif 4. What is process based
endif extimation?
enddo
enddo 83
Software This decomposition approach assumes that all functions can be decomposed into
Engineering subfunctions that will resemble entries in a historical data base. Otherwise another
sizing approach must be applied. The greater the degree of partitioning the more
likely reasonably accurate estimates of LOC can be developed.
NOTES In case of FP estimates, decompositions work differently. Rather than focusing on
function, each of the information domain characteristics inputs, outputs, data files,
inquiries and external interfaces as well as the 14 complexity adjustment values are
calculated. The resultant estimates can then be used to derive a FP value that can
be tied to past data and used to produce an estimate.
Regardless of the estimation variable that is used, the project planner begins by
calculating a range of values for each function. The planner calculates an optimistic,
most likely and pessimistic size value for each function. An implicit indication of the
degree of uncertainty is provided when a range of values is represented.
An expected value can then be computed. The expected value for the estimation
variable (size) S, can be calculated as a weighted average of the optimistic (sept), most
likely (Sm) and pessimistic (Spess) estimated. For example-
S = (sopt + 4sm + spess)/6
It provides us “most likely” estimate and act according to a beta probability distri-
bution.

III. Process Based Estimation :

The most common technique for estimating a project is to base the estimate on the
process that will be used. That is, the process is decomposed into a relatively small
set of tasks and the effort required to accomplish each task is calculated.
Like the problem-based techniques, process based estimation begins with a delinea-
tion of software functions obtained from the project scope. A series of software
process activities must be performed for each function.
Once problem functions and process activities are completed, then the planner
estimates the effort that will be required to accomplish each software process activity
for each software function, Average labor rates are then applied to the effort estimated
for each process activity. It is very likely the labor rate will vary for each task.
Costs and effort for each function and software process activity are computed as the
last step. If process-based estimation is performed separately of LOC or FP estima-
tion, we now have two or three estimates for cost and effort that may be compared
and reconciled. If both sets of estimates show reasonable agreement, there is good
reason to believe that the estimates are reliable. If, on the other hand, the result of
these decomposition techniques shows little agreement, further investigation and
analysis must be performed.

Empirical Estimation Models :

It uses empirically obtained formulas to predict effort as a function of LOC or FP.
The empirical data that support most estimation models are derived from a limited
sample of projects. For this reason, no estimation model is correct for all classes of
software and in all development environments. Therefore, the results obtained from
such models must be used judiciously.

The Structure of Estimation Models :

An estimation model is derived using regression analysis on data obtained from past
software projects. The overall structure of such models takes the form -
84
E = A + B + (ev)c
Where A, B and C are empirically obtained constants, E is efforts in (person - months) Software
and ev is the estimation variable (either LOC or FP). Generally maximum number of Cost Estimation
estimation models have some form of project adjustment component that enables E to
be adjustment component that enables E to be adjusted by other project properties.
Among the many LOC - oriented estimation models are -
NOTES
0.91
E = 5.2 x (KLOC) Walston - Felix model
E = 5.5 + 0.73 x (KLOC)1.16 Bailey-Basili model
E = 3.2 x (KLOC)1.05 Boehm simple model
E = 5.288 x (KLOC)1.047 Doty model for KLOC >9
Fp - oriented models have also been proposed. These include -
E = -13.39 + 0.0545 FP Albrecht and Gaffney model.
E = 60.62 x 7.728 x 10-8 FP3 Kamerer model
E = 585.7 + 15.12 FP Matson, Barnett and Mellichamp model

SUMMARY
• Estimating the cost of the software product is one of the most difficult and error
prone tasks in software engineering. It is difficult to make an accurate cost estimate
during planning phase of software development because of number of factors at
that time, yet contracting practices often require a firm commitment as a part of
feasibility study. This coupled with competitive nature of business is a major factor
that contributes to the widespread cost and schedule overruns of software projects.
• There are many factors that influence the cost of a software product. The effects of
most of these factors, and hence the cost of a development or maintenance effort, are
difficult to estimate. Primary among the cost factors are the individual abilities of
project personnel and their familiarity with the application area; the complexity of
the product; the size of the product; the available time, the required level of reliabil-
ity; the level of technology utilized, and the availability, familiarity, and stability of
the system used to develop the product.
• Software Reliability can be defined as the probability that a program will perform
a required function under stated conditions for a stated period of time.
• The level of technology in a software development project is reflected by the
programming language, the abstract machine (hardware plus software), the
programming practices, and the software tools used.
• In real world software project estimation is a form of problem solving. In most
cases, the problem to be solved is too complex to be considered in one piece.
Due to this reason, we break down the problem, recharacterising it as a set of
smaller problems.
• The most common technique for estimating a project is to base the estimate
on the process that will be used. That is, the process is decomposed into a
relatively small set of tasks and the effort required to accomplish each task is
calculated.
• The Empirical Estimation model uses empirically obtain formulas to predict
effort as a function of LOC or FP. The empirical data that support most
estimation models are derived from a limited sample of projects.
85
Software ANSWERS TO "CHECK YOUR PROGRESS"
Engineering 1. There are many factors that influence the cost of a software product. The
effects of most of these factors, and hence the cost of a development or
maintenance effort, are difficult to estimate. Primary among the cost
NOTES factors are the individual abilities of project personnel and their familiar-
ity with the application area; the complexity of the product; the size of
the product; the available time, the required level of reliability; the level
of technology utilized, and the availability, familiarity, and stability of the
system used to develop the product.
2. Software Reliability can be defined as the probability that a program will
perform a required function under stated conditions for a stated period
of time.
3. The Empirical Estimation model uses empirically obtain formulas to
predict effort as a function of LOC or FP. The empirical data that support
most estimation models are derived from a limited sample of projects.
4. Process based estimation begins with a delineation of software functions
obtained from the project scope. A series of software process activities
must be performed for each function.

EXERCISE
1. Define estimation. What are the various Software Cost factors ?

2. Write short note on :

(a) Product Complexity

(b) Software Reliability

3. What do you understand by Decomposition Technique ?

4. Explain the following :

(a) Software Sizing

(b) Problem based Estimation

(c) Process based Estimation

5. Explain Empirical Estimation models.

86