LESSON 3: SOFTWARE COST ESTIMATION

Contents
3.0.Aims and Objectives
3.1.Introduction
3.2.Software Cost Estimation
3.3.Software Cost Factors
3.4.Software Cost Estimation Techniques
3.5.Staffing Level Estimation
3.6.Estimating Software Maintenance Costs
3.7.Review Questions
3.8.Let us Sum up
3.9.Lesson End Activities
3.10. Points for Discussion
3.11. References
3.0. AIMS AND OBJECTIVES

• To Estimate the cost of a software product

• To understand the various factors influence software costs
• To use empirical estimation models

3.1. INTRODUCTION
Software is the most expensive element in most computer-based
systems. A large cost estimation error can make the difference between profit
and loss. Too many variables – human, technical, environmental, political –
can affect the ultimate cost of software and effort applied to it.
3.2. SOFTWARE COST ESTIMATION
Cost estimation
[Boehm 1981], [Putnam 1978], [Albrecht 1983], [Schnupp 1976]

The necessity of cost estimation stems from the requirements of
scheduling and cost planning. For lack of more precise methods, cost
estimation for software development is almost always based on a
comparison of the current project with previous ones. Due to the
uniqueness of software systems, the number of comparable projects is
usually quite small, and empirical data are seldom available. But even if
there are exact cost records of comparable projects, these data are based
on the technical and organizational conditions under which the
comparable project was carried out at that time.

45

The technical and organizational conditions are variable parameters,
which makes empirical data from comparable projects only an unreliable
basis for estimates.

Relationship between the best and worst programming experience
(referring to the same task, [Schnupp 1976]):

The time requirement for each task handled in a team consists of two
basic components ([Brooks 1975]):
(1) Productive work
(2) Communication and mutual agreement of team members
If no communication were necessary among team members, then the
time requirement t for a project would decline with the number n of team
members
t ≈ 1/n
If each team member must exchange information with one other and that
the average time for such communication is k, then the development time
follows the formula:
t ≈ 1/n + k. n2/2
"Adding manpower to a late software project makes it later." ([Brooks 1975])

Most empirical values for cost estimation are in-house and unpublished.
The literature gives few specifications on empirical data, and these often
deviate pronouncedly. The values also depend greatly on the techniques
and tools used.

Distribution of the time invested in the individual phases of software
development (including the documentation effort by share) according to
the selected approach model and implementation technique ([Pomberger
1996]):
Approach model: classical sequential software life cycle
Implementation technique: module-oriented
problem analysis and system specification.... 25%
design................................................................. 25%
implementation.................................................. 15%
testing................................................................ 35%
Approach model: prototyping-oriented software life cycle
Implementation technique: module-oriented
problem analysis and system specification..... 40%
design................................................................. 25%
implementation.................................................. 10%
testing................................................................ 25%
Approach model: object- and prototyping-oriented software life cycle
Implementation technique: object-oriented

46
 problem analysis and system specification..... 45%
design................................................................. 20%
implementation.................................................. 8%
testing................................................................ 27%
The following options are useful to achieve reliable cost and effort estimates:
1. Delay estimation until late in the project. The longer we wait, the less
likely we are to make errors in our estimates. However this is not
practical. Cost estimates must be provided “up-front”.
2. Base estimates on similar projects that have already been
completed. This works well if the current project is quite similar to past
efforts. Unfortunately, past experience has not always been a good
indicator of future results.
3. Use “decomposition techniques” to generate project cost and effort
estimates. These techniques use a “divide and conquer” approach to
estimation. By decomposing a project into major functions and related
software engineering activities, cost and effort estimation can be
performed in a step-wise fashion.
Use one or more empirical models for software cost and effort
estimation. A model is based on experience (historical data) and takes the
form d = f(vi), where d is one of a number of estimated variables (eg. effort,
cost, project duration) and vi are selected independent parameters (eg.
Estimated LOC or FP).
3.3. SOFTWARE COST FACTORS
3.3.1. Factors for cost and time estimates
• Experience and qualifications of the estimator
• Type of software (e.g., function-, data- or object-oriented, time-critical
software with high efficiency requirements, control and monitoring
software with high quality requirements)
• Anticipated complexity (e.g., number of components (modules, classes),
number of component couplings, number of methods per class,
complexity of methods)
• Expected size of program (number of statements)
• Experience and qualifications of personnel (e.g., project experience,
programming experience, knowledge of methods, experience in use of
tools, knowledge of problem domain)
• Techniques and tools to be used (e.g., planning, design and
documentation techniques, test strategies and tools, programming
languages)
• Number of staff members
3.3.2. LOC (Lines of Code) Based Estimation
To illustrate the LOC based estimation technique, let us consider the
development of software for Computer-Aided Design (CAD) application. If we

47
assume that the range of LOC estimates for the 3D geometric analysis
function is:
Optimistic: 4600
Most likely: 6900
Pessimistic: 8600
Applying the equation to compute EV (Earned Value), the expected value for
the 3D geometric analysis function is 6800 LOC. Estimates for all the
modules of the CAD application are computed in a similar fashion. By
summing all the estimated values, an estimate of the lines of code is
established for the CAD software system.
3.3.3. Process-Based Estimation
The process is decomposed into a relatively small set of activities or tasks
and the effort required to accomplish each task is estimated. A process-
based estimation involves the following steps:
1. Delineate the software functions obtained from the project scope.
2. A series of software process activities must be performed for each
function.
3. Functions and related software process activities may be represented as
part of a table.
4. The planner estimates the effort (eg. person-months) that will be required
to accomplish each software process activity for each software function.
5. Average labor rates (eg. cost/unit effort) are applied to the effort
estimated for each process activity.
6. Costs and Effort for each function and software process activity are
computed.
3.4. SOFTWARE COST ESTIMATION TECHNIQUES
Cost estimation models
• COCOMO Model,
• Putnam Estimation Model
• Function Point Model.
COCOMO MODEL
The constructive cost model is an algorithmic cost estimating model;
it is a bottom-up technique. It starts estimating at sub system level and
finally sums up all the estimates.
The steps required to estimate the software cost using COCOMO are as
follows:
• Identify all subsystems and modules in the product.
• Estimate the size of each module and calculate the size of each
subsystem and total system.

48
 • Specify module-level effort multipliers for each module. The module-
level multipliers are: Product complexity, Programmer capability,
virtual machine experience and Programming language experience.
• Compute the module effort and development time estimates for each
module and its subsystems.
• Compute the total system effort and development time.
• Perform a sensitivity analysis on the estimate to establish tradeoff
benefits
• Add other development costs, such as planning and analysis that are
not included in the estimate.
• Compare the estimate with one developed top-down Delphi estimation.
Identify and rectify the differences in the estimates.
The COCOMO Models are defined for three classes of software projects. They
are:
1. organic mode – relatively small, simple software projects in which small
teams with good application experience work to a set of less than rigid
requirements (e.g. A thermal analysis program developed for a heat
transfer group)
2. semi-detached mode – an intermediate software project in which teams
with mixed experience levels must meet a mix of rigid and less than rigid
requirements (e.g. A transaction processing system with fixed
requirements for terminal hardware and database software)
3. embedded mode – a software project that must be developed with a set
of tight hardware, software, and operational constraints. (eg. Flight
control software for aircraft).
Software Project Estimation using COCOMO:
Nominal Effort equation
PM = ai KLOC bi

TDEV = ci E di

Where PM is Programmer months

TDEV is Product Development time in months.
KLOC is number of delivered lines of code.
ai, ci is coefficients
bi, di is exponents.
Coefficients and exponents are:

S/W Project ai bi ci di

Organic 3.2 1.05 2.5 0.38

Semi- 3.0 1.12 2.5 0.35

detached

49
 Embedded 2.8 1.20 2.5 0.32

Example:
Consider the product to be developed in 10-KLOC embedded mode s/w
product.
PM = (2.8) * (10)1.20
= 44.4
TDEV = (2.5) * (44)0.32
=8.4
It is predicted that 44.4. Programmer months and 8.4 elapsed months for
product development.

Check your progress

i. Three different cost estimation models are ________, _______ and
____________
ii. The COCOMO Models are defined for three classes of software projects.
They are ___________, ____________ and _________
iii. Important factors of Cost estimation are _________ , _______ and
__________
iv. Boehm's maintenance cost estimation is calculated in terms of a quantity
called the ___________________

Solutions

Ii

Iii

Iv

3.5. STAFFING LEVEL ESTIMATION

Estimating Staff includes the processes required to make the most effective
use of the people involved with the project. It includes both organizational
positions (e.g. Manager, senior software engineer, etc.) and specialty (e.g.
Telecommunications, database, etc.). The number of people required varies
for every software project and it can be determined only after an estimate of
development effort is made.

50
Project schedule primarily depends on effort. However, the relationship is
not linear. During the earlier phases of the project like Requirement
Analysis and HLD a lesser number of people would be required as against
those required during the Build phase (for coding and unit testing). Once
Build phase is complete, the staff requirement for the next phase i.e. the
Testing phase would be lower. While staffing a project, adequate care is
taken to have a blend of experienced and non-so-experienced people.
3.6. ESTIMATING SOFTWARE MAINTENANCE COSTS
Maintenance Costs
• Typical software organizations spend anywhere from 40 to 70 percent
of all funds for maintenance.
• Maintenance-bound organizations result loss or postponement of
development opportunities.
• Customer dissatisfaction when requests cannot be addressed.
• Reduction in overall software quality as a result of changes that
introduce latent errors in the maintained software.
Maintenance cost factors
Non-technical factors
• Application domain
• Staff stability
• Program age
• External environment
• Hardware stability
1) The application being supported.
If the application of the program is clearly defined and well
understood, the system requirements may be definitive and
maintenance due to changing requirements minimized.
If the application is completely new, it is likely that the initial
requirements will be modified frequently, as users gain experience
with the system.
2) Staff stability. It is easier for the original writer of a program to
understand and change a program rather than some other individual
who must understand the program by study of its documentation and
code listing.
If the programmer of a system also maintains that system,
maintenance costs will be reduced.
In practice, the nature of the programming profession is such that
individuals change jobs regularly. It is unusual for one person to develop
and maintain a program throughout its useful life.
3) The lifetime of the program.
The useful life of a program depends on its application.

51
 Programs become obsolete when the application becomes obsolete or
their original hardware is replaced and conversion costs exceed
rewriting costs.
The older a program, the more it has been maintained and the more
degraded its structure.
Maintenance costs tend to rise with program age.
4) The dependence of the program on its external environment.
If a program is dependent on its external environment it must be
modified as that environment changes. For example, changes in a
taxation system might require payroll, accounting, and stock control
programs to be modified. Taxation changes are relatively common and
maintenance costs for these programs are related to the frequency of
these changes.
A program used in a mathematical application does not normally
depend on humans changing the assumptions on which the program
is based.
5) Hardware stability.
If a program is designed to operate on a particular hardware
configuration and that configuration does not change during the
program's lifetime, no maintenance costs due to hardware changes will
be incurred. However, hardware developments are so rapid that this
situation is rare. The program must be modified to use new hardware
which replaces obsolete equipment.
Maintenance cost estimation
Boehm's maintenance cost estimation

Boehm's maintenance cost estimation ([Boehm 1981]) is calculated in
terms of a quantity called the Annual Change Traffic (ACT) which is
defined as follows:
The fraction of a software product's source instructions which undergo
change during a (typical) year either through addition or modification.
ACT = (DSIadded + DSImodified) / DSItotal
PM = ACT * MM
where
DSI is no. of source instructions
PM is no. of Program months.
MM is no. of months for development
A further enhancement is provided by an effort adjustment factor EAF
PM = ACT * EAF * MM
Where
EAF – recognize that the effort multipliers for maintenance may be
different from the effort multipliers used for development.

52
3.7. REVIEW QUESTIONS
1. Define Estimation
2. What are the types of estimation?
3. What are the factors that affect the efficiency of estimation? Explain the
factors.
4. Discuss estimation using decomposition techniques
5. Discuss empirical estimation models.
6. Write a note on automated estimation tools.
7. Specify, design and develop a program that implements COCOMO model.
8. Discuss the importance of making correct estimates project management

3.8. LET US SUM UP

• COCOMO was proposed by Barry W. Boehm in Software Engineering

Economics.
• COCOMO covers a broad spectrum of software development projects:

• From application software to systems software

• From small software to large software
• From new development to modifications / enhancements
• This model is good for estimating both effort and elapsed time by
project phases
• The model needs lines-of-code as input

3.9. LESSON END ACTIVITIES

i. Some experimental evidence suggests that the initial size estimate for a
project affects the nature and results of the project. Consider two
different managers charged with developing the same application one
estimates that the size of the application will be 50,000 lines while the
other estimates that will be 1,00,000 lines. Discuss how these
estimates affect the project throughout its life cycle.

3.10. POINTS FOR DISCUSSION

i. Use the COCOMO equations to estimate the programmer-months and
development time for your term project. Prepare a range of estimates
based on probable product size.

53
3.11. REFERENCES
1. Richard Fairley, “Software Engineering Concepts”, Tata McGraw-Hill,
1997.
2. Roger S.Pressman, Software engineering- A practitioner’s Approach,
McGraw-Hill International Edition, 5th edition, 2001.
3. http://sunset.usc.edu/COCOMO2.0/Cocomo.html
4. Matson, J., B. Barett, and J. Mellichamp, “Software Development Cost
Estimation Using Funciton Points”, IEEE Trans. Software Engineering vol.
20, no 4, April 1994, pp. 275-287

54