5.

Software Effort Estimation

What makes the project successful?

Delivering: Stages:
➢ Agreed functionality ➢ Set targets
➢ On time at the agreed cost ➢ Attempt to achieve targets
➢ With the required quality

BUT what if the targets are not achievable?

A key point here is that developers may in fact be very competent, but incorrect estimates
leading to unachievable targets will lead to extreme customer dissatisfaction.

Some problems with estimating :

Subjective nature of estimating :

➢ It may be difficult to produce evidence to support your precise target.
Political pressures :
➢ Managers may wish to reduce estimated costs in order to win support for
acceptance of a project proposal.
Changing technologies:
➢ These bring uncertainties, especially in the early days when there is a ‘learning
curve’.
Projects differ :
➢ Experience on one project may not be applicable to another.

Where are the Estimates Done?:

Strategic planning
Feasibility Study
System specification
Evaluation of supplier’s proposals
Project planning

Problems with Over and under estimating :

1.Parkinson’s Law: ‘Work expands to fill 1.Weinberg’s Zeroth Law of reliability: ‘a

the time available’ software project that does not have to meet a
2.An over-estimate is likely to cause project reliability requirement can meet any other
to take longer than it would otherwise requirement’
 Basic for successful estimating :

❖ The need for historical data:

➢ Need to collect performance details about past project: how big were they? How much
effort/time did they need?
➢ Need to be able to measure the amount of work involved
➢ Traditional size measurement for software is ‘lines of code’ – but this can have problems
❖ Parameters to be Estimated :
Size is a fundamental measure of work
Based on the estimated size, two parameters are estimated:
➢ Effort
➢ Duration
Effort is measured in person-months:
➢ One person-month is the effort an individual can typically put in a month.
Despite our reservation about past project data –we still need to collect and analyze it! If
we don’t know how big the job is, we can’t estimate how long it will take to do.

❖ Measure of Work :

The project size is a measure of the problem complexity in terms of the effort and time
required to develop the product.
Two metrics are used to measure project size:
➢ Source Lines of Code (SLOC)
➢ Function point (FP)
FP is now-a-days favoured over SLOC:
Because of the many shortcomings of SLOC.

❖ Major Shortcomings of SLOC :

No precise defination
Difficult to estimate at start of a project
Only a code measure
Programmer-dependent
Does not consider code complexity

❖ Measure of effort:

Person-Month:

Suppose a project is estimated to take 300 person-months to develop:

➢ Is one person working for 30 days same as 30 persons working for 1 day?
➢ Yes/No? why?
How many hours is a man month?
➢ Default Value: 152 hours per month
➢ 19 days at 8 hours per day.
Mythical Man-Month :

“Cost varies as product of men and months, progress does not.”

➢ Hence the man-month as a unit for measuring the size of job is a dangerous and
deceptive myth.
The myth of additional manpower
➢ Brooks Law: “Adding manpower to a late project makes it later”
For tasks with complex interrelationship, addition of manpower to a late project does

Software Effort Estimation Techniques :

Bottom-up - activity based, analytical

Parametric or algorithmic models e.g. function points
Expert opinion - just guessing?
Analogy - case-based, comparative
Parkinson and ‘price to win’
Top-down – overall estimate for the whole project is broken
➢ This taxonomy is based loosely on Barry Boehm’s in the big blue book,
‘Software Engineering Economics’.
➢ One problem is that different people call these approaches by different names. In the case
of bottom-up and analogy some of the alternative nomenclatures have been listed.
➢ ‘Parkinson’ is setting a target based on the amount of staff effort you happen to have
available at the time.
➢ ‘Price to win’ is setting a target that is likely to win business when tendering for work.
Boehm is scathing about these as methods of estimating.
➢ However, sometimes you might have to start with an estimate of an acceptable cost and
then set the scope of the project and the application to be built to be within that cost.

Bottom-up versus top-down :

Bottom-up
➢ use when no past project data
➢ identify all tasks that have to be done – so quite time-consuming
➢ use when you have no data about similar past project
 Top-down
➢ produce overall estimate based on project cost drivers
➢ based on past project data
➢ divide overall estimate between jobs to be done
There is often confusion between the two approaches as the first part of the bottom-up approach is a top-
down analysis of the tasks to be done, followed by the bottom- up adding up of effort for all the work to be
done.

Bottom-up estimating :
Break project into smaller and smaller components
Stop when you get to what one person can do in one/two weeks
Estimate costs for the lowest level activities
At each higher level calculate estimate by adding estimates for lower levels

A procedural code-oriented approach

Envisage the number and type of software modules in the final system
Estimate the SLOC of each identified module
Estimate the work content, taking into account complexity and technical difficulty
Calculate the work-days effort

Top-down estimates :

Produce overall estimate using effort driver(s)

Distribute proportions of overall estimate to components
The initial overall estimate might have been produced using a parametric model, by analogy or
just expert judgment.

Algorithmic/Parametric models :

COCOMO (lines of code) and function points examples of these

problem with COCOMO etc
The problems with COCOMO is that the input parameter for system size is an estimate of
lines of code. This is going to have to be an estimate at the beginning of the project.
Function points, counts various features of the logical design of an information system
and produced an index number which reflects the amount of information processing it
will have to carry out. This can be crudely equated to the amount of code it will need.
Parametric models - the need for historical data :

simplistic model for an estimate

estimated effort = (system size) / productivity
e.g.system size = lines of code productivity
= lines of code per day
productivity = (system size) / effort
➢ based on past projects
This is analogous to calculating speed from distance and time.
Parametric models :
Some models focus on task or system size e.g. Function Points
FPs originally used to estimate Lines of Code, rather than effort
System size’ here can be seen as an index that allows the size of different applications to be
compared. It will usually correlate to the number of lines of code required.
Other models focus on productivity: e.g. COCOMO Lines of code (or FPs etc) an input

COCOMO originally was based on a size parameter of lines of code (actually ‘thousand of
delivered source code instructions’ or kdsi). Newer versions recognize the use of functions
points as a size measure, but convert them to a number called ‘equivalent lines of code (eloc).

Expert judgement :
Asking someone who is familiar with and knowledgeable about the application area and the
technologies to provide an estimate
Particularly appropriate where existing code is to be modified
Research shows that experts’ judgment in practice tends to be based on analogy.

Estimating by analogy:

The source cases, in this situation, are completed projects.

For each of details of the factors that would have a bearing on effort are recorded.
These might include lines of code, function points (or elements of the FP counts such as the
number of inputs, outputs etc), number of team members etc etc.
For the values for the new project are used to find one or more instances from the past
projects than match the current one.
 The actual effort from the past project becomes the basis of the estimate for the new
project.

Stages: identify :
➢ Significant features of the current project
➢ previous project(s) with similar features
➢ differences between the current and previous projects
➢ possible reasons for error (risk)
➢ measures to reduce uncertainty

Automate selection process ANGEL

Albrecht function points Analysis

Albrecht worked at IBM and needed a way of measuring the relative productivity of different
programming languages.
Needed some way of measuring the size of an application without counting lines of code.
Identified five types of component or functionality in an information system
Counted occurrences of each type of functionality in order to get an indication of the size of
an information system

Five function types

• External input (EI) types – input transactions which update internal computer files
• External output (EO) types – transactions which extract and display data from internal
computer files. Generally involves creating reports.
• External inquiry (EQ) types – user initiated transactions which provide information but do not
update internal files. Normally the user inputs some data that guides the system to the information
the user needs.
• Logical internal file (LIF) types – These are standing files. Equates roughly to a data store in
systems analysis terms. Created and accessed by the target system
• External interface file types (EIF) – where data is retrieved from a data store which is actually
maintained by a different application.
 Determine the complexity of each user type (high, average or low).

Albrecht complexity multipliers

External user types Low complexity Medium complexity High complexity

External input types 3 4 6
External output types 4 5 7
External inquiry types 3 4 6
Logical internal file types 7 10 15
External interface file types 5 7 10

The International FP User Group (IFPUG) have developed and published extensive rules
governing FP counting. Hence Albrecht FPs is now often referred to as IFPUG FPs.

Number of record types Number of data types

< 20 20 – 50 > 50

1 Low Low Average

2 to 5 Low Average High

>5 Average High High

The boundaries shown in this table show how the complexity level for the logical internal files is
decided on.
There are similar tables for external inputs and outputs.

Function Points Marks II

Developed by Charles R. Symons

‘Software sizing and estimating - Mk II FPA’, Wiley & Sons, 1991.
Builds on work by Albrecht
Work originally sponsored by CCTA:
➢ should be compatible with SSADM; mainly used in UK
has developed in parallel to IFPUG FPs
A simpler method
FP score for of each external user type = Multiply the weight of each complexity by the count of
each external user type that has that complexity.
 FP count = summation of all the FP scores.
FP count indicates the size of the information processing.
Information processing size is initially measured in unadjusted function points(UFPs)

For each transaction the UFPs are calculated:-

𝑊𝑖 * (number of input data element types) +
𝑊𝑒 * (number of entity types referenced) +
𝑊𝑜 * (number of output data element types) +

𝑊𝑖 , 𝑊𝑒 and 𝑊𝑜 are weightings derived by asking developers the proportions of effort spent in
previous projects developing the code dealing respectively with inputs, accessing and modifying
stored data and processing outputs.
Most FP counters use industry averages which are currently
0.58 for 𝑊𝑖 , 1.66 for 𝑊𝑒 and 0.26 for 𝑊𝑜 .

COSMIC Full Function Points

COSMIC FFPs stands for Common Software Measurement International Consortium Full
Function Points.
This approach is developed to measure the sizes of real-time or embedded systems.
In COSMIC method: the system architecture is decomposed into a hierarchy of software layers.
They define 4 data groups that a software component can deal with
➢ Entries (E), effected by sub-processes that moves the data group into the software
component in question from a user outside its boundary.
➢ Exits (X), effected by sub-processes that moves the data group from the software
component into a user outside its boundary.
➢ Reads (R), data movements that move data groups from a persistent storage (database) to
the SW component.
➢ Writes (W), data movements that move data groups from the SW component to a persistent
storage.
The overall FFP is derived by simply summing the counts of the four groups all together.
The method doesn’t take account of any processing of the data groups once they are moved into
the software component.
It is not recommended for systems that include complex mathematical algorithms.
COCOMO II: A Parametric Productivity Model

It is a parametric productivity model.

It is developed by Barry Boehm in the late 1970s.
COCOMO is short for COnstructive COst MOdel.
It refers to a group of models.
The basic model was built around the following equation:
➢ Effort= c(size)k
➢ The effort is measured in person-months (pm), consisting of units of 152 working hours.
➢ The size is measured in (Kdsi) thousands of delivered source code of instructions.
➢ c and k are constants.
The first step is to derive an estimate the system size in terms of kdsi.
C and k constants values depend on classifying the system in
Boehm’s terms as either:
➢ Organic mode or
➢ Embedded mode or
➢ Semi-detached mode.

Organic mode.
• Small team,
• Small system,
• Interface requirements flexible,
• In-house software development.
➢ Examples: Systems such as payroll, inventory.

Embedded mode.
• Product has to operate within very tight constraints,
• the project team is large,
• development environment consists of many complex interfaces,
• Changes are very costly.
➢ Examples: Real-time systems such as those for air traffic control, ATMs, or weapon
systems.
Semi-detached mode.
• Combined elements from the two above modes or characteristics that come in between.
➢ Examples: Systems such as compilers, database systems, and editors.

System type c k

Organic 2.4 1.05

Semi-detached 3.0 1.12

Embedded 3.6 1.20

COCOMO II takes into account that there is a wider range of process models in use than before.
COCOMO II is designed to accommodate the fact that estimates will be needed at different stages
of the system life cycle.
COCOMO II has models for three different stages:
• Application composition.
• Early design.
• Post Architecture.

Fig. Accuracy of different COCOMO II estimations

Problem: 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 software engineers be 15,000/- per
month.
Determine
➢ The effort required to develop the software product
➢ Cost required to develop the product
Barry Boehm and his co-workers have refined a family of cost estimation models of which the
key one is COCOMO II.
This approach uses various multipliers and exponents the values of which have been set initially
by experts.

Fig. COCOMO II scale factor values

 • Precedentedness (PREC) This quality is the degree to which there are precedents or similar
past cases for the current project.
• Development flexibility (FLEX) This reflects the number of different ways there are of
meeting the requirements.
• Architecture/risk resolution (RESL) This reflects the degree of uncertainty about the
requirements.
• Team cohesion (TEAM) This reflects the degree to which there is a large dispersed team
(perhaps in several countries) as opposed to there being a small tightly knit team.
• Process maturity (PMAT) The more structured and organized the way the software is
produced, the lower the uncertainty.

Each of the scale factors for project is rated according to a range of judgments: very low, low,
nominal, high, very high, extra high.
There is a number related to each rating of the individual scale factors - see Table
5.5.
These are summed, then multiplied by 0.01 and added to the constant (B=0.91) to get the overall
exponent scale factor.

Cost Estimation
Project cost can be obtained by multiplying the estimated effort (in man-month, from the effort
estimate) with the man power cost per month.
The entire project cost is incurred on account of the manpower cost alone.
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 of hardware and software required for the project and
the company overheads for administration, office space, etc.
Depending on the expected values of the overhead costs, the project manager has to suitably scale
up the cost estimated by using the COCOMO formula.

Staffing Pattern

After the effort required to complete a software project has been estimated, the staffing
requirement for the project can be determined.
Norden was one of the first to investigate staffing pattern of general research and development
(R&D) type of projects.
Putnam’s extended the work of Norden.

Norden’s work

Norden studied the staffing patterns of several R&D projects.

He found the staffing patterns of R&D projects to be very different from that of manufacturing or
sales type of work.
 The staffing pattern of R&D type of projects changes dynamically over time for efficient
manpower utilization.
At the start of an R&D project, the activities of the project are planned and initial investigations
are made.
During this time, the manpower requirements are low.
As the project progresses, the manpower requirement increases until it reaches a peak. Thereafter
the manpower requirement gradually decreases
Norden conclude the staffing pattern for any R&D project can be approximated by the Rayleigh
distribution curve

Putnam’s work:

Putnam studied the problem of staffing of software projects and found the staffing pattern for
software development projects characteristics very similar to R & D projects.
Putnam adapted the Rayleigh-Norden curve to relate the number of delivered lines of code to the
effort and the time required to develop the product.
After product delivery, the number of project staff falls consistently during product maintenance.
Putnam suggested that starting from a small number of developers, there should be a staff build up
and after a peak size has been achieved.
Experience shows that a very rapid build-up of project staff any time during the project
development correlates with schedule slippage.

Effect of Schedule Compression

It is quite common for a project manager to encounter client requests to deliver products faster,
that is, to compress the delivery schedule.
It is important to understand the impact of schedule compression on project cost.
Putnam studied the effect of schedule compression on the development effort and expressed it in
the form of equation:
𝑡𝑑𝑜𝑟𝑔 4
𝑝𝑚𝑛𝑒𝑤 = 𝑝𝑚𝑜𝑟𝑔 ∗ (𝑡𝑑 )
𝑛𝑒𝑤
Where 𝑝𝑚𝑛𝑒𝑤 is the new effort, 𝑝𝑚𝑜𝑟𝑔 is the originally estimated effort and 𝑡𝑑𝑜𝑟𝑔 is the originally
estimated time for project completion and 𝑡𝑑𝑛𝑒𝑤 is the compressed schedule.
When the schedule of a project is compressed, the required effort increases in proportion to the
fourth power of the degree of compression.
 Example
If the estimated development time using COCOMO formulas is 1 year:
Then to develop the product in 6 months, the total effort required (and hence the project cost)
increases 16 times.

Capers Jones’ Estimating Rules of Thumb :

Rule 1: SLOC-function point equivalence:

One function point = 125 SLOC for C programs.
Rule 2: Project duration estimation:
Function points raised to the power 0.4 predicts the approximate development time in
calendar months.
Rule 3: Rate of requirements creep:
User requirements creep in at an average rate of 2% per month from the design through
coding phases.
Rule 4: Defect removal efficiency:
Each software review, inspection, or test step will find and remove 30% of the bugs that are
present.
Rule 5: Project manpower estimation:
The size of the software (in function points) divided by 150 predicts the approximate number
of personnel required for developing the application.
Rule 6: Software development effort estimation:
The approximate number of staff months of effort required to develop software is given by the
software development time multiplied with the number of personnel required.
Rule 7: Function points divided by 500 predicts the approximate number of personnel required for
regular maintenance activities.