Software Project Management

1
 Chapter Three

Software Project Estimation

2
 Introduction

• Estimation is attempt to determine how much money, effort,

resources & time it will take to build a specific software
based system or project.
• Effective software project estimation is one of the most
challenging and important activities in software development.
• Proper project planning and control is not possible without a
sound and reliable estimate.
• Under-estimating a project leads to under-staffing it
» resulting in staff burnout
• Under-scoping the quality assurance effort
» running the risk of low quality deliverables and
• Setting too short a schedule
» resulting in loss of credibility as deadlines are missed.
3
 Cont’d

• Over-estimating a project can be just about as bad for the

organization.
• The project is then likely to cost more than it should
» a negative impact on the bottom line
• Take longer to deliver than necessary
» resulting in lost opportunities and
• Delay the use of your resources on the next project.

4
 Cont’d

• Estimation includes:
» Project size: What will be problem complexity in terms of the effort and
time required to develop the product?
» Cost: How much is it going to cost to develop the project?
» Duration: How long is it going to take to complete development?
» Effort: How much effort would be required?

5
 Metrics for Software Project Size Estimation

• Currently two metrics are popularly being used widely to

estimate size:
» lines of code (LOC) and
» function point (FP).
• The usage of each of these metrics in project size estimation
has its own advantages and disadvantages.

6
 Lines of Code (LOC)

• LOC is the simplest among all metrics available to estimate

project size.
• It 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.
» While counting the number of source instructions, lines used for
commenting the code and the header lines should be ignored.
• In order to estimate the LOC count at the beginning of a
project, project managers usually divide the problem into
modules, and each module into submodules and so on, until
the sizes of the different leaf-level modules can be
approximately predicted.

7
 Shortcomings of LOC

• LOC gives a numerical value of problem size that can vary

widely with individual coding style
• It should consider the local effort needed to specify, design,
code, test, etc. and not just the coding effort.
• LOC measure correlates poorly with the quality and
efficiency of the code.
• LOC metric penalizes use of higher-level programming
languages, code reuse, etc.
• LOC metric measures the lexical complexity of a program
and does not address the more important but subtle issues
of logical or structural complexities.
• It is very difficult to accurately estimate LOC in the final
product from the problem specification. 8
 Function Point (FP)
• Function point metric was proposed by Albrecht [1983].
• 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.
• Each function when invoked reads some input data and
transforms it to the corresponding output data.
• The computation of the number of input and the output data
values to a system gives some indication of the number of
functions supported by the system.
• Albrecht postulated that in addition to the number of basic
functions that a software performs, the size is also
dependent on the number of files and the number of
interfaces. 9
 Cont’d

• Besides using the number of input and output data values,

function point metric computes the size of a software product
(in units of functions points or FPs) using three other
characteristics of the product as shown in the following
expression.
• Function point is computed in two steps. The first step is to
compute the unadjusted function point (UFP).
• UFP = (Number of inputs)*4 + (Number of outputs)*5 +
(Number of inquiries)*4 + (Number of files)*10 + (Number
of interfaces)*10
• The size of a product in function points (FP) can be
expressed as the weighted sum of these five problem
characteristics.
10
 Cont’d

• The weights associated with the five characteristics were

proposed empirically and validated by the observations over
many projects.
• Number of inputs:
» Each data item input by the user is counted.
» Data inputs should be distinguished from user inquiries.
» Inquiries are user commands such as print-account-balance.
» A group of related inputs are considered as a single input.
• Number of outputs:
» The outputs considered refer to reports printed, screen outputs, error
messages produced, etc.

11
 Cont’d
• Number of inquiries:
» It is the number of distinct interactive queries which can be made by the
users.
• Number of files:
» Each logical file is counted. A logical file means groups of logically
related data.
• Number of interfaces:
» Here the interfaces considered are the interfaces used to exchange
information with other systems.

12
 Counting Function Points

• Complexity level of each parameter is graded as low,

average and high.
• The weight for the different parameter can be compute
based on the following table:

13
Cont’d

14
 FP Adjustment

• Organizations that use function point methods develop a

criterion for determining whether a particular entry is Low,
Average or High.
• Nonetheless, the determination of complexity is somewhat
subjective.
FP= UFP * CAF
• Where CAF is a complexity adjustment factor and is equal to
[0.65+0.01*∑Fi].
• The Fi (i=1 to 14) are the degree of influence and are based
on responses to questions.

15
Cont’d

16
 Example
• Consider a project with the following parameters:
i. External Inputs: 10 with low complexity, 15 with average complexity
and 17 with high complexity.
ii. External Output: 6 with low complexity and 13 with high complexity.
iii. External Inquiries: 3 with low complexity, 4 with average complexity.
and 2 with high complexity.
iv. Internal Logical Files: 2 with average complexity and 1 with high
complexity.
v. External Interface Files: 9 with low complexity.

17
 Cont’d
• In addition to above, the system requires:
i. Significant data communication
ii. Performance is very critical
iii. Designed code may be moderately reusable
iv. System is not designed for multiple installation in different
organizations.
v. Other complexity adjustment factors are treated as
average.
• Compute the function points for the project.

18
Cont’d

19
Cont’d

20
 Feature Point Metric

• Feature point metric incorporates an extra parameter

algorithm complexity.
• This parameter ensures that the computed size using
the feature point metric reflects the fact that the more
is the complexity of a function, the greater is the effort
required to develop it and therefore its size should be
larger compared to simpler functions.

21
 Estimation Techniques
• Estimation of various project parameters is a basic project
planning activity.
• The important project parameters that are estimated include:
project size, effort required to develop the software,
project duration, and cost.
• These estimates not only help in quoting the project cost to the
customer, but are also useful in resource planning and
scheduling.
• There are three broad categories of estimation techniques:
» Empirical estimation techniques
» Heuristic techniques
» Analytical estimation techniques

22
 Empirical Estimation Techniques
• Empirical estimation techniques are based on making an
educated guess of the project parameters.
• 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:
» Expert judgment technique and
» Delphi cost estimation.

23
 Expert Judgment Technique
• In this approach, an expert makes an educated guess of the
problem size after analyzing the problem thoroughly and
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.
• Problems
» Human errors and individual bias.
» Expert may overlook some factors inadvertently.
» Lack of experience and knowledge
• A more refined form of expert judgment is the estimation made
by group of experts.
» It minimizes factors 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. 24
 Delphi Cost Estimation
• Delphi estimation is carried out by a team of experts and a
coordinator.
• In this approach, the coordinator provides each estimator with
a copy of SRS document to make initial estimate.
• 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 and asks the
estimators re-estimate.

25
 Cont’d
• This process is iterated for several rounds.
• However, no discussion among the estimators is allowed
during the entire estimation process to avoid any biasing.
• After the completion of several iterations of estimations, the
coordinator takes the responsibility of compiling the results
and preparing the final estimate.

26
 Heuristic Techniques
• 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.
• Different heuristic estimation models can be divided into the
following two classes:
» Single variable model and
» Multi variable model.

27
 Single Variable Model
• Single variable estimation models provide 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 estimation model takes the following form:
Estimated Parameter = c1 * ed1
• In the above expression, e is the characteristic of the software
which has already been estimated (independent variable).

28
 Cont’d
• Estimated Parameter is the dependent parameter to be
estimated which could be effort, project 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).
• The basic COCOMO model is an example of single variable
cost estimation model.

29
 COCOMO (COst COnstructive MOdel)
In COCOMO, projects are categorized into three types:
» Organic project
» Embedded projects
» Semi-detached projects
Organic projects:
» are in areas in which the organization has considerable experience,
and requirements are less stringent (less strict).
» Usually developed by a small team.
» E.g. simple business systems, simple inventory management systems.
» 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.

30
 Cont’d
Semi-detached projects:
» if the development 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.
» Includes developing a new operating system (OS), a database
management system (DBMS), a complex inventory management
system.
Embedded projects:
» if the software being developed is strongly coupled to complex
hardware, or if the stringent regulations on the operational
procedures exist.
» are in areas in which the organization has little experience, and
stringent requirements for such aspects as interfacing and reliability.
» E.g. real-time command systems. 31
 Basic COCOMO Model
The basic COCOMO model gives an approximate estimate of
the project parameters.
The basic COCOMO estimation model is given by the
following expressions:
» Effort = a1 х (KLOC)a2 PM
» Tdev = b1 x (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 products,
» Tdev is the estimated time to develop the software, expressed in
months,
» Effort is the total effort required to develop the software product,
expressed in person months (PMs). 32
 Cont’d
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
» 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

33
 Staff Size and Productivity
When effort and development time are known the average
staff size to complete the project may be calculated as:
Average staff size (SS) = E/D Persons
When project size is known, the productivity level may be
calculated as:
Productivity (P) = KLOC/E (in KLOC/PM)

34
 Example
Suppose that a project was estimated to be 400 KLOC.
Calculate the effort and development time for each of the
three modes (organic, semidetached and embedded).

35
 Multivariable cost estimation model
Estimated Resource = c1*e1d1 + c2*e2d2 + ...
• Where e1, e2, … 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,
• The independent parameters influence the dependent
parameter to different extents. This is modeled by the
constants c1, c2, d1, d2, … .
• Values of these constants are usually determined from
historical data.
• The intermediate COCOMO model can be considered to be an
example of a multivariable estimation model. 36
 Intermediate COCOMO
There are 15 different attributes, called cost driver
attributes, that determine the multiplying factors.
These factors depend on product, computer, personnel, and
technology (project) attributes.
Each cost driver has a rating scale (very low, low, nominal,
high, very high, extra high).

37
Multipliers of Cost Drivers

38
Cont’d

39
 Steps for applying COCOMO
Determine the initial estimate (nominal estimate) of the
development effort from the estimate of thousands of
delivered lines of source code (KDLOC).
→ Ei = a * (KDLOC) b
Determine a set of 15 multiplying factors from different
attributes of the project, and compute the effort adjustment
factor (EAF).
→ EAF = product of all the 15 multiplying factors.
Compute the total effort by multiplying the initial effort with the
effort adjustment factor.
→ Total effort = Ei * EAF

40
 Exercise
Assume 4 modules are to be contained in a project. Assume
the project is organic.
The modules are M1 = 0.5 KDLOC, M2 = 0.5 KDLOC, M3 =
0.3 KDLOC, and M4 = 0.7 KDLOC.
And the multiplying factors are:
» RELY, required reliability is …. very high
» CPLX, product complexity is…. high
» STOR, main storage constraint is … high
» Others are … nominal
Calculate: i) The initial effort
ii) The total effort.

41
 Analytical Estimation Techniques
• Analytical estimation techniques derive the required results
starting with basic assumptions regarding 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.
» It 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.

42
 Halstead’s Software Science
• 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 over all program length, potential minimum
value, actual volume, effort, and development time.
• For a given program, let:
» η1 be the number of unique operators used in the program,
» η2 be the number of unique operands used in the program,
» N1 be the total number of operators used in the program,
» N2 be the total number of operands used in the program.

43
 Cont’d…Different Parameters
• Length and Vocabulary
» The length of a program is total usage of all operators and operands in
the program. Thus, length N = N1 +N2.
» Program vocabulary is the number of unique operators and operands
used in the program. Thus, program vocabulary η = η1 + η2.
• Program Volume
» V = Nlog2η
» Here the program volume V is the minimum number of bits needed to
encode the program

44
 Cont’d
• Potential Minimum Volume
» The potential minimum volume V* is defined as the volume of
most succinct program in which a problem can be coded.
» The minimum volume is obtained when the program can be
expressed using a single source code instruction., say a
function call like foo( ) ;.
» In other words, the volume is bound from below due to the fact
that a program would have at least two operators and no less
than the requisite number of operands.
» Thus, if an algorithm operates on input and output data d1, d2,
… dn, the most succinct program would be f(d1, d2, … dn); for
which η1 = 2, η2 = n. Therefore, V* = (2 + η2)log2(2 + η2).

45
 Cont’d
• The program level L is given by L = V*/V.
» The concept of program level L is introduced in an attempt to
measure the level of abstraction provided by the programming
language.
» The above result implies that the higher the level of a language,
the less effort it takes to develop a program using that
language.

46
 Cont’d
• Effort and Time
» The effort required to develop a program can be obtained by
dividing the program volume with the level of the programming
language used to develop the code.
» Thus, effort E = V/L,
» Thus, the programming effort E = V²/V* (since L = V*/V) varies
as the square of the volume.
• The programmer’s time T = E/S, where S the speed of mental
discriminations. The value of S has been empirically
developed from psychological reasoning, and its
recommended value for programming applications is 18.

47
 Cont’d
• Length of Program
• In terms of unique operators and operands
» It can be assumed that any program of length N consists of N/ η
unique strings of length η.
» Now, it is standard combinatorial result that for any given
alphabet of size K, there are exactly Kr different strings of length
r.
• Thus,
» N/η ≤ ηη Or, N ≤ ηη+1

48
 Cont’d
• Since operators and operands usually alternate in a program,
the upper bound can be further refined into N ≤ η η1η1 η2η2.
Also, N must include not only the ordered set of n elements,
but it should also include all possible subsets of that ordered
sets, i.e. the power set of N strings
• Therefore,
» 2N = η η1η1 η2η2 Or, taking logarithm on both sides,
» N = log 2η + log 2(η1η1 η2η2 )
» So we get, N = log 2 (η1η1 η2η2 ) approx
» N= η1log 2η1 + η2log 2η2

49
 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

50
 Cont’d
• The unique operands are:
a, b, c, &a, &b, &c, a+b+c, avg, 3, “%d %d %d”, “avg = %d”
Therefore,
η1 = 12, η2 = 11
Estimated Length = (12*log12 + 11*log11)
= (12*3.58 + 11*3.45)
= (43+38) = 81
Volume = Length*log(23)
= 81*4.52
= 366

51
52