Chapter- 4

Software Project Estimation

4.1 Management Spectrum 4P'
• The management spectrum describes the
management/hierarchy of people associated with a
software project.
• How to make a software project successful.
• Effective Software Project Management focuses on
the four P’s:
– People
– Product
– Process
– Project
• The order is not arbitrary. Manager has to control all
P’s
• Effective software project management focuses on
these items (in this order)
– The people
• Deals with the cultivation of motivated, highly skilled people
• Consists of the stakeholders, the team leaders, and the software
team
– The product
• Product objectives and scope should be established before a
project can be planned
– The process
• The software process provides the framework from which a
comprehensive plan for software development can be established
– The project
• Planning and controlling a software project is done for one
primary reason…it is the only known way to manage complexity.
People –
• The “people factor” is so important that the
Software Engineering Institute has developed
a People Capability Maturity Model
(PeopleCMM) to continually improve its ability
to attract, develop, motivate, organize, and
retain the workforce needed to accomplish its
strategic business objectives.
• The people capability maturity model defines
the following key practice areas for software
people:
a. Staffing
b. communication and coordination
c. work environment
d. performance management
e. Training, compensation, competency analysis
and development, career development,
workgroup development, team/culture
development and others.
• Organizations that achieve high levels of
People-CMM maturity have higher likelihood of
implementing effective software project
management practices
• The Product:- Before a project can be planned,
product objectives and scope should be
established, alternative solutions should be
considered and technical and management
constraints should be identified.
• Without this information, it is impossible to
define reasonable (and accurate) estimates of
the cost, an effective assessment of risk, a
realistic breakdown of project tasks, or a
manageable project schedule that provides a
meaningful indication of progress.
• Objectives identify the overall goals for the
product (from the stakeholders’ points of view)
without considering how these goals will be
achieved.
• Scope identifies the primary data, functions,
and behaviors that characterize the product
• The alternatives enable managers and
practitioners to select a “best” approach, given
the constraints imposed by delivery deadlines,
budgetary restrictions, personnel availability,
technical interfaces, and other factors.
• The Process:- A software process provides the
framework from which a comprehensive plan
for software development can be established.
• A small number of framework activities are
applicable to all software projects, regardless of
their size or complexity.
• A number of different task sets—tasks,
milestones, work products, and quality
assurance points enable the framework
activities to be adapted to the characteristics of
the software project and the requirements of
the project team.
• Finally, umbrella activities—such as software quality
assurance, software configuration management,
and measurement occur throughout the process.

• The Project:
• To manage complexity, we conduct planned and
controlled software projects.
• The project manager of a project or sub-project is
responsible for managing the people, product and
process.
• The responsibilities or activities of software project
manager would be a long list but that has to be
followed to avoid project failure.
• To avoid project failure, a software project manager
and the software engineers who build the product
must avoid a set of common warning signs, understand
the critical success factors that lead to good project
management, and develop a common-sense approach
for planning, monitoring, and controlling the project.
• The success rate for present-day software projects may
have improved but our project failure rate remains
much higher than it should be.
• Its merely due to the development but mostly due to
the steps before development and sometimes due to
the lack of maintenance.
4.2 Metrics for Size Estimation
Currently two metrics are popularly being
used widely to estimate size:
1.Lines of Code (LOC).
2.Function Point (FP).
Lines of Code (LOC)
• LOC is the simplest among all metrics available to
estimate project size.
• This metric is very popular because it is the
simplest to use.
• Using this metric, the project size is estimated by
counting the number of source instructions in the
developed program.
• The size is estimated by comparing it with the
existing systems of the same kind.
• The experts use it to predict the required size of
various components of software and then add
them to get the total size.
• Project manager always divides the problem into
modules, and each module into sub modules and
so on, until the sizes of the different level can be
approximately predicted.
• Determining LOC count at end of project is a very
simple job. However accurate estimation of the
LOC count at the beginning of a project is a very
difficult.
• The units of LOC are:
• KLOC- Thousand lines of code
• NLOC- Non-comment lines of code
• KDSI- Thousands of delivered source instruction
• Parameters to count LOC:
1. count only executable lines.
2. count executable lines plus data definitions.
3. count executable lines, data definitions and
comments.
4. count physical lines on input screen.
Advantages:
• Universally accepted and is used in many models
like COCOMO.
• Estimation is closer to the developer’s
perspective.
• Disadvantages:
• Different programming languages contain a
different number of lines.
• No proper industry standard exists for this
technique.
• It is difficult to estimate the size using this
technique in the early stages of the project.
• Consider the following example for counting
LOC:
KCSI: thousands changed source instructions.
KSSI: thousands shipped source instructions.
First Release of Product Y
KCSI = KSSI = 50 KLOC
Defects/KCSI = 2.0
Total number of defects = 2.0 × 50 = 100
Second Release,
KCSI = 20 KSSI = 50+ 20 (new and changed lines of
code) -4 (assuming 20% are changed lines of
code) = 66
• Defect/KCSI = 1.8 (assuming 10% improvement
over the first release). Total number of
additional defects = 1.8 x 20 = 36.
• Third Release,
KCSI=30 KSSI 66+30 (new and changed lines of
code) -6 (assuming 20% of changed lines of code)
= 90.
Targeted number of additional defects (no more
than previous release) = 36.
Defect rate target for the new and changed lines
of code: 36/30= 1.2 defects/KCSI or lower.
2. Function Point (FP)
• The concept of Function-oriented metrics was
proposed by Albrecht
• The conceptual idea behind the function point
metric is that the size of a software product is
directly dependent on the number of different
Functions or features it supports.
• A software product supporting many features
would certainly be of larger size than a product
with less number of features.
• Each function when invoked reads some input
data and transforms it to the corresponding
output data.
• In this method, the number and type of function
supported by the software are utilized to find FPC
(Function point count).
• The steps in function point analysis are:
• Count the number of functions of each proposed type:
Functions belonging to the following types:
External Input: Functions related to data entering the
system.
External Outputs: Functions related to data existing
from the system.
External Enquires: They lead to data retrieval from the
system.
Internal Files: Logical files maintained within the
system.
External interface files: These are logical files of
other application used by our application.
• Compute the unadjusted function point (UFP)
• Categories each of the function types like simple,
average or complex based on their complexity.
Multiply the count of each function type with its
weighting factor and find the weighted sum.
• Find total degree of influence (TDI) or (Fi)
Use the 14 general characteristics (each scale in
the range 0 – 5) of system to find the degree of
influence of each of them. The sum of all 14
degree of influence will give TDI. The range of TDI
is 0 to 70.

• Compute value adjustment factor (VAF)

• VAF=(TDI*0.01)+0.65
• Find the function point count (FPC)
• FPC=UFP*VAF
OR FP= Count total[0.65+0.01∑(Fi)]
4.3 Project Cost Estimation Approaches
• Software cost estimation is the process of
predicting the effort required to develop a
software system.
• Project cost estimating is the process of
predicting the total cost of the tasks, time, and
resources required to deliver a project's scope
of work.
• There are three approaches of project
estimation, they are:
1. Heuristic Technique
2. Analytical Estimation Technique
3. Empirical Estimation Technique

1. Heuristic Technique
• Heuristic means “to discover”.
• This technique basically use the concept of
learning from the previous project and estimate
the cost.
• The objective is to find a similar system produced
earlier and through knowing how the properties
of the new system vary from the existing one.
• Heuristic techniques assume that the
relationships among the different project
parameters can be modeled using suitable
mathematical expressions.
• Once the basic (independent) parameters are
known, the other (dependent) parameters can
be easily determined by substituting the value of
the basic parameters in the mathematical
expression.
• heuristic estimation models can be divided into
the following two classes:
- Single variable model
- Multi variable model
1. Single Variable Estimation Models:
• It provides a means to estimate the desired
characteristics of a problem, using some
previously estimated basic (independent)
characteristic of the software product such as its
size.
• A single variable estimator model takes the
following form:
• Estimated Parameter = c1 * ed1
• e= characteristic which already have been
calculated.
• Estimated parameter is the dependent
parameter to be estimated.
• The dependent parameters to be estimated
could be effort, duration, staff size etc.
• c1 and d1 are constants
• The values of the constants c1 and d1 are
usually determined using data collected from
past projects (historical data).
• COCOMO is one of this type of models example.
• 2. Multi variable Cost Estimation Model:
• It has the following form
Estimated Resources = c1 * e1d1 + c2 * e2d2 + - - -
e1 and e2 are the basic independent characteristics
of the software already estimated. c1, c2, d1, d2,
are constants.
Multivariable Estimation Models are expected to
give more accurate estimate compared to the
Single Variable Models, since a project parameters
is typically influenced by several independent
parameters.
• The independent parameters influence the
dependent parameter to different extents.
• The constants c1,c2,d1,d2.... are used to model
this.

2. Analytical Estimation Technique

• Analytical estimation techniques derive the
required results starting from basic assumptions
related to the project.
• Thus, unlike empirical and heuristic techniques,
analytical techniques do have scientific basis.
• Halstead‘s software science is an example of an
analytical technique.
• Halstead’s software science can be used to derive
some interesting results starting with a few simple
assumptions.
• Halstead’s software science is especially useful for
estimating software maintenance efforts.
• In fact, it outperforms both empirical and heuristic
techniques when used for predicting software
maintenance efforts
• Halstead‘s Software Science – An Analytical
Technique
• Halstead’s software science is an analytical
technique to measure size, development effort,
and development cost of software products.
• Halstead used a few primitive program
parameters to develop the expressions for
overall program length, potential minimum
value, actual volume, effort, and development
time.
• Estimated Program length= (n1*logn1 +
n2*logn2)
• Example: Let us consider the following C
program:
main( )
{
int a, b, c, avg;
scanf(“%d %d %d”, &a, &b, &c);
avg = (a+b+c)/3;
printf(“avg = %d”, avg);
}
• The unique operators are:
• main, (), {}, int, scanf, &, “, ”, “;”, =, +, /, printf
• The unique operands are:
• a, b, c, &a, &b, &c, a+b+c, avg, 3, “%d %d %d”,
“avg = %d”
• Therefore, n1 = 12, n2 = 11
• Estimated Length = (12*log12 + 11*log11)
=(12*3.58 + 11*3.45)
=(43+38)
= 81

• Volume = Length*log(23)
=81*4.52
=366
3. Empirical Estimation Technique
• Empirical estimation techniques are 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, different activities
involved in estimation have been formalized
over the years.
• Two popular empirical estimation techniques
are:
• 1. Expert judgment technique
• 2. Delphi cost estimation.

1. Expert Judgment Technique –

• Expert judgment is one of the most widely used
estimation techniques.
• In this approach, an expert makes an educated guess
of the problem size after analyzing the problem
thoroughly.
• Usually, the expert estimates the cost of the different
components (i.e. modules or subsystems) of the
system and then combines them to arrive at the
overall estimate
• However, this technique is subject to human
errors and individual bias.
• Also, it is possible that the expert may overlook
some factors inadvertently.
• Further, an expert making an estimate may not
have experience and knowledge of all aspects of
a project.
2. Delphi cost estimation –
Delphi cost estimation approach tries to overcome
some of the short comings of the expert judgment
approach.
• Delphi estimation is carried out by a team
comprising of a group of experts and a coordinator.
• In this approach, the coordinator 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(without name) and submit to the
coordinator.
• In their estimates, the estimators mention any
unusual characteristic of the product which has
influenced his estimation.
• The coordinator prepares and distributes the
summary of the responses of all the estimators,
and includes any unusual rationale noted by any of
the estimators.
• Based on this summary, the estimators re-estimate.
• This process is repeated for several rounds.
• However, no discussion among the estimators is
allowed during the entire estimation process.
• The idea behind this 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 coordinator takes the
responsibility of compiling the results and
preparing the final estimate.
4.4 COCOMO (Constructive Cost Model)
• COCOMO is one of the most widely used
software estimation models in the world.
• This model is developed in 1981 by Barry
Boehm to give estimation of number of man-
months it will take to develop a software
product.
• Also called as COCOMO 81 model.
• COCOMO predicts the efforts and schedule of
software product based on size of software.
• COCOMO has three different models that
reflect complexity
1. Basic Model
2. Intermediate Model
3. Complete Model

1) Basic COCOMO:
The basic COCOMO is employed for rough
calculations, limiting software estimation
precision.
• This is because the model only considers lines of
source code and constant values.
• It derived from software project types rather
than other elements that significantly impact
the software development process.

2) Intermediate COCOMO:
The Intermediate COCOMO model expands the
Basic COCOMO model that takes into account a
collection of cost drivers to improve the cost
estimating model's accuracy.
3) Complete/Detailed COCOMO:
The model contains all qualities of both Basic
COCOMO and Intermediate COCOMO techniques
for each software engineering process. The
model considers each project's development
phase (analysis, design, and so on).

Estimation of Effort: Calculations –

• The Cocomo model divides software projects into 3
types
1. Organic Project
It belongs to small & simple software projects which
are handled by a small team with good domain
knowledge and few rigid requirements. Example: Small
data processing or Inventory management system.
2. Semidetached Project It is an intermediate (in terms
of size and complexity) project, where the team having
mixed experience (both experience & inexperience
resources) to deals with rigid/non rigid requirements.
Ex. Database design
3. Embedded Project
This project having a high level of complexity with
a large team size by considering all sets of
parameters (software, hardware and operational).
Example: Banking software
 COCOMO II
• COCOMO-II is the revised version of the original
Cocomo (Constructive Cost Model) and is
developed at University of Southern California.
• It is the model that allows one to estimate the
cost, effort and schedule when planning a new
software development activity.
• COCOMO II provides the following three-stage
series of models for estimation of Application
Generator, System Integration, and
Infrastructure software projects.
• The Application Composition Model

• This model involves prototyping efforts to

resolve potential high- risk issues such as user
interfaces, software/system interaction,
performance.
• The costs of this type of effort are best
estimated by the Applications Composition
model. It is suitable for projects built with
modern GUI-builder tools.
• The Early Design Model
• The Early Design model involves exploration of
alternative software/system architectures and
concepts of operation.
• It uses a small set of new Cost Drivers, and
new estimating equations.
• Based on Unadjusted Function Points or
KSLOC.
• Estimates can be done after the user
requirements have been agreed.
• The Post-Architecture Model
• The Post-Architecture model involves the
actual development and maintenance of a
software product Estimates.
• In COCOMO II effort is expressed as Person
Months (PM).
• The inputs are the Size of software
development, a constant, A, and a scale factor,
B.
• The size is in units of thousands of source lines
of code (KSLOC).
• The parameters used in COCOMO II are
described below:-
1. Person month-
• A person month is the amount of time one
person spends working on the software
development project for one month.
• The nominal effort for a given size project and
expressed as person months (PM) is given by
Equation
PMnominal =A* (Size)B
Where, A- constant
• B = 0.91 + 0.01 ∑(exponent driver ratings)
• - B ranges from 0.91 to 1.23
• - 5 drivers; 6 rating levels each

2. Maintenance size is the amount of project code

that is change.
It is calculated as below:-
Size=[(BaseCodeSize) *MCF] *MAF
For maintenance projects that involve more than
20% change in the existing base code COCOMO II
uses maintenance size
3. Maintenance Change Factor = MCF
• The percentage of change to the base code is
called the Maintenance Change Factor (MCF).
• MCF= (SizeAdded +SizeModified)/BaseCodeSize
• Maintenance effort (MAF)
4.5 Risk Management
What is a software risk?
• Risk refers to the uncertainties related to future
happenings with the project. A risk is any uncertain
event that may or may not happen, which will
impact the project.
• A risk is "an uncertain event or condition that, if it
occurs, has a positive or negative effect on a
project's objectives."
• This means the risks can be predicted and brought
within control.
• However, when the risk becomes a reality, it leads to
unwanted losses.
• The risk may be proactive or reactive
• Reactive Risk Strategy
• Reactive risk strategy follows that the risks have to
be tackled at the time of their occurrence.
• No precautions are to be taken as per this strategy.
• They are meant for risks with relatively smaller
impact.
• More commonly, the software team does nothing
about risks until something goes wrong.
• Then, the team take action in an attempt to
correct the problem rapidly. This is often called a
fire-fighting mode.
• Proactive risk strategies
• It follows that the risks have to be identified before
start of the project.
• They have to be analysed by assessing their
probability of occurrence, their impact after
occurrence, and steps to be followed for its
precaution
• Possibilities and types of risks are identified, they
are checked and arranged as per their priority and
impact and prioritized according to their
importance.
• Then after ranking the risk the main plan of the
project team is to avoid the risk.
• Types of Software Risks
There are two basic types of risks:
(a) Generic Risk : Generic Risk is the general
purpose possible threat to every software
product.
(b) Product Specific Risk: Product Specific risk can
be find out only by those with a clear
understanding of the technology going to be
used for that project.
Different Categories of Risks: -
(a) Project Risk: - Threaten the project plan. That is if
project risk become real it is likely that project
schedule will slip and that costs will increase. Project
risks identity potential budgetary, schedule,
personnel, resource, customer and requirement
problem.
(b) Technical Risk: - Threaten the quality and timeliness
of the software to be produced. If technical risk
becomes real, implementation may become difficult or
impossible.
(c) Business Risk: - Threaten the viability of the software
to be built. Business risk often jeopardizes the product
or the project.
(d) Market Risk:- Building product that no one
wants
(e) Strategic Risk: - Building a product that no
longer fits into the business strategy
(f) Management Risk: - Building a product that
the sale force doesn‘t understand.
(g) Budget Risk: - Losing budgetary or personnel
commitment
• Risk Assessment

• Risk assessment involves the evaluation of the

risk. We take a triplet into consideration for
understanding risk assessment in detail.
• In the triple ri stands for risk, li stands for
likelihood that is probability of the risk, and
xi represents impact of the risk.
• In initial stages of project planning a risk is
stated generally. As the time passes, it is
important to divide that risks into sub types
and try to refine it.
• Risk identification
• Risk identification can be defined as
systematic attempt to specify or find out
threats to the project plan. Project plan
includes estimation, resource distribution etc.
• With the help of finding well known and
predictable risks, the project manager or
leader can take first step to deal with or avoid
them.
• These risks need to be controlled or avoided
as per its form.
• Risk Analysis
• After identification of the risk, risk analysis has
to be done.
• The process of risk analysis is analyzing the
potential risks with its types and details.
• The time and efforts needed for risks analysis
are huge.
• Analysis starts with what risks are there, their
probability and consequences with their
impact on the project
• Risk Containment
• Containing risk is the process of keeping track
of noticed risk, finding new risk, monitoring
risk, analyzing the risk.
• Inputs for this Phase:
• Project management Plan
• Risk register
• Work performance data
• Work performance report.
• outputs for this Phase:
• Change Request
• Work performance Information
• Project management plan update
• Project documents updates
• RMMM Strategy
• Risk mitigation, monitoring, and management
(RMMM) plan.
• A risk management strategy can be included in
the software project plan or the risk
management steps can be organized into a
separate Risk Mitigation, Monitoring and
Management Plan.
• The RMMM plan documents all work
performed as part of risk analysis and is used
by the project manager as part of the overall
project plan.
• Once RMMM has been documented and the
project has begun, risk mitigation and
monitoring steps starts.
• Risk mitigation is a problem avoidance activity.
• Risk monitoring is a project tracking activity
with three primary objectives:
1. To assess whether predicted risks do, in fact,
occur;
2. To ensure that risk aversion steps defined for
the risk are being properly applied; and
3. To collect information that can be used for
future risk analysis.
• In many cases, the problems that occur during
a project can be traced to more than one risk.
Another job of risk monitoring is to attempt to
allocate origin (what risk(s) caused which
problems throughout the project).
• An effective strategy must consider three
issues:
• Risk avoidance
• Risk monitoring
• Risk management and contingency planning.
• Risk mitigation or Risk avoidance
• If a software team adopts a proactive approach to
risk, avoidance is always the best strategy.
• This is achieved by developing a plan for risk
mitigation.
• Meet with current staff to determine causes for
turnover (e.g., poor working conditions, low pay,
and competitive job market).
• Mitigate those causes that are under our control
before the project starts
• Once the project starts, assume turnover will occur
and develop techniques to ensure continuity when
people leave.
• Organize project teams so that information
about each development activity is widely
dispersed.
• Define documentation standards and establish
mechanisms to be sure that documents are
developed in a timely manner.
• Conduct peer reviews of all work (so that more
than one person is "up to speed).
• Assign a backup staff member for every critical
technologist.
• Risk monitoring
• As the project proceeds, risk monitoring activities
commence.
• The project manager monitors factors that may provide an
indication of whether the risk is becoming more or less likely.
• In the case of high staff turnover, the following factors can be
monitored:
• General attitude of team members based on project
pressures.
• Interpersonal relationships among team members.
• Potential problems with compensation and benefits.
• The availability of jobs within the company and outside it.
• project manager should monitor the effectiveness of risk
mitigation steps.
• Risk management
• RMMM steps take additional project cost.
• Part of risk management, therefore, is to
evaluate when the benefits accrued by the
RMMM steps are outweighed by the costs
associated with implementing them.
• In essence, the project planner performs a
classic cost/benefit analysis.