Software Effort Estimation Techniques

 Barry Boehm, in his classic work on software effort models,

identified the main ways of deriving estimates of software
development effort as:
 algorithmic models, which use 'effort drivers' representing
characteristics of the target system and the implementation
environment to predict effort
Software Effort Estimation Techniques

 expert judgment, based on the advice of knowledgeable staff

 analogy, where a similar, completed, project is identified and its

actual effort is used as the basis of the estimate
 Parkinson, where the staff effort available to do a project
becomes the 'estimate‘
Software Effort Estimation Techniques

 price to win, where the 'estimate' is a figure that seems

sufficiently low to win a contract
 top-down, where an overall estimate for the whole project is
broken down into the effort required for component tasks
Software Effort Estimation Techniques

 bottom-up, where component tasks are identified and sized and

these individual estimates are aggregated
 Clearly, the 'Parkinson' method is not really an effort prediction
method, but a method of setting the scope of a project
 Similarly, 'price to win' is a way of identifying a price and not a
prediction
Software Effort Estimation Techniques

 Although Boehm rejects them as prediction techniques, they

have value as management techniques
 There is, for example, a perfectly acceptable engineering
practice of 'design to cost'
 We will now look at some of these techniques more closely
Software Effort Estimation Techniques

 First we will examine the difference between top-down and

bottom-up estimating

Bottom-up Estimating
 With the bottom-up approach the estimator breaks the project
into its component tasks
Software Effort Estimation Techniques

 With a large project the process of breaking it down into tasks is

iterative: each task is decomposed into its component subtask
and these in turn could be further analyzed
 It is suggested that this is repeated until you get tasks an
individual could do in a week or two
 Why is this not a 'top-down approach'?
Software Effort Estimation Techniques

 After all, you start from the top and work down

 Although this top-down analysis is an essential precursor to

bottom-up estimating, it is really separate process — that of
producing a work breakdown schedule (WBS)
 The bottom-up part comes in adding up the calculated effort for
each activity to get an overall estimate
Software Effort Estimation Techniques

 The bottom-up approach is best at the later, more detailed, stages

of project planning
 If this method is used earlier, assumptions about the characteristics
of the final system and project work methods will have to be made
 Where a project is completely novel or there is no historical data
available, the estimator would be forced to use the bottom-up
approach
Software Effort Estimation Techniques

 A procedural code-oriented approach

 The bottom-up approach described above works at the level of

activities
 In software development a major activity is writing code

 Here we describe how a bottom-up approach can be used at the

level of software components
Software Effort Estimation Techniques

Envisage the number and type of software modules in the final

system
 Most information systems, for example, are built from a small
set of system operations, e.g. Insert, Amend, Update, Display.
Delete, Print
 The same principle should equally apply to embedded system,
albeit with a different set of primitive functions
Software Effort Estimation Techniques

Estimate the SLOC of each identified module

 One way to judge the number of instructions likely to be in a
program is to draw up a program structure diagram and to
visualize how many instructions would be needed to implement
each identified procedure
Software Effort Estimation Techniques

 The estimator may look at existing programs which have a

similar functional description to assist in this process
 Estimate the work content, taking into account complexity
and technical difficulty
 The practice is to multiply the SLOC estimate by a factor for
complexity and technical difficulty
Software Effort Estimation Techniques

 This factor will depend largely on the subjective judgment of

the estimator
 For example, the requirement to meet particular highly
constrained performance targets can greatly increase
programming effort
Software Effort Estimation Techniques

Calculate the work-days effort

 Historical data can be used to provide ratios to convert
weighted SLOC to effort
 Note that the steps above can be used to derive an estimate of
lines of code that can be used as an input to one of the
COCOMO models which are described later
Software Effort Estimation Techniques

The Top-down Approach and Parametric Models

 The top-down approach is normally associated with parametric
(or algorithmic) models
 These may be explained using the analogy of estimating the
cost of rebuilding a house
 Ibis is of practical concern to house-owners who need insurance
cover to rebuild their property if destroyed
Software Effort Estimation Techniques

 Unless the house-owner is in the building trade he or she is

unlikely to be able to calculate the numbers of bricklayer-hours,
carpenter-hours, electrician-hours, and so on, required
 Insurance companies, however, produce convenient tables
where the house-owner can find estimates of rebuilding costs
based on such parameters as the number of stories and the floor
space of a house
Software Effort Estimation Techniques

 This is a simple parametric model

 Project effort relates mainly to variables associated with

characteristics of the final system
 A parametric model will normally have one or more formulae in
the form:
 effort = (system size) X (productivity rate)
Software Effort Estimation Techniques

 For example, system size might be in the form 'thousands of

lines of code' (KLOC) and have the specific value of 3 KLOC
while the productivity rate was 40 days per KLOC
 These values will often be matters of judgment

 A model to forecast software development effort therefore has

two key components
Software Effort Estimation Techniques

 The first is a method of assessing the amount of the work

needed
 The second assesses the rate of work at which the task can be
done
 For example, Amanda at IOE may estimate that the first
software module to be constructed is 2 KLOC
Software Effort Estimation Techniques

 She may then judge that if Kate undertook the development of

the code, with her expertise she could work at a rate of 40 days
per KLOC per day and complete the work in 2 X 40 days. i.e.
80 days, while Ken, who is less experienced, would need 55
days per KLOC and take 2 x 55, i.e. 110 days to complete the
task
 Software Effort Estimation Techniques

 In this case KLOC is a size driver indicating the amount of work

to be done, while developer experience is a productivity driver
influencing the productivity or work rate
 If you have figures for the effort expended on past projects (in
work-days for instance) and also the system sizes in KLOC, you
should be able to work out a productivity rate as

pwductivity, = effort / size

Software Effort Estimation Techniques

 A more sophisticated way of doing this would be by using the

statistical technique least squares regression to derive an
equation in the form:

effort = constant + (size X constant2)

 Some parametric models, such as that implied by function

points, are focused on system or task size, while others, such
are COCOMO, are more concerned with productivity factors
Software Effort Estimation Techniques

 Those particular models are described in more detail later in

this chapter
 Having calculated the overall effort required, the problem is
then to allocate propor­tions of that effort to the various
activities within that project
 The top-down and bottom-up approaches are not mutually
exclusive
Software Effort Estimation Techniques

 Project managers will probably try to get a number of different

estimates from different people using different methods
 Some parts of an overall estimate could be derived using a top-
down approach while other parts could be calculated using a
bottom-up method
Software Effort Estimation Techniques

Expert Judgment
 This is asking for an estimate of task effort from someone who
is knowledgeable about either the application or the
development environment
 This method is often used when estimating the effort needed to
change an existing piece of software
Software Effort Estimation Techniques

 The estimator would have to examine the existing code in order

to judge the proportion of code affected and from that derive an
estimate
 Someone already familiar with the software would be in the
best position to do this
Software Effort Estimation Techniques

 Some have suggested that expert judgment is simply a matter of

guessing, but our own research has shown that experts tend to
use a combination of an informal analogy approach where
similar projects from the past are identified (see below), supple­
mented by bottom-up estimating
 There may be cases where the opinions of more than one expert
may need to be combined
Software Effort Estimation Techniques

Estimating by Analogy
 This is also called case-based reasoning

 The estimator identifies completed projects (source cases) with

similar characteristics to the new project (the target case)
 The effort recorded for the matching source case is then used as
a base estimate for the target
Software Effort Estimation Techniques

 The estimator then identifies differences between the target and

the source and adjusts the base estimate to produce an estimate
for the new project
 This can be a good approach where you have information about
some previous projects but not enough to draw generalized
conclusions about what might be useful drivers or typical
productivity rates
Software Effort Estimation Techniques

 A problem is identifying the similarities and differences

between applications where you have a large number Of past
projects to analyse
 One attempt to automate this selection process is the ANGEL
software tool
Software Effort Estimation Techniques

 This identifies the source case that is nearest the target by

measuring the Euclidean distance between cases
 The Euclidean distance is calculated as:

distance = square-root of ((target_parameter1 -

source_parameteri)2 +… (targetpararnetern— sourceparameter n )2)
Software Effort Estimation Techniques

 The above explanation is simply to give an idea of how

Euclidean distance may be calculated
 The ANGEL package uses rather more sophisticated algorithms
based on this principle
Software Effort Estimation Techniques

Albrecht Function Point Analysis

 The above explanation is simply to give an idea of how
Euclidean distance may be calculated
 This is a top-down method that was devised by Allan Albrecht
when he worked for IBM
Software Effort Estimation Techniques

 Albrecht was investigating programming productivity and

needed to quantify the functional size of programs
independently of their programming languages
 He developed the idea of function points (FPs)

 The basis of function point analysis is that information systems

comprise five major components, or 'external user types' in
Albrecht's terminology, that are of benefit to the users
Software Effort Estimation Techniques

 External input types are input transactions which update

internal computer files
 External output types are transactions where data is output to
the user
 Typically these would be printed reports, as screen displays
would tend to come under external inquiry types (see below)
Software Effort Estimation Techniques

 External inquiry types — note the US spelling of inquiry — are

transactions initiated by the user which provide information but
do not update the internal files
 The user inputs some information that directs the system to the
details required
Software Effort Estimation Techniques

 Logical internal file types are the standing files used by the
system
 The term 'file' does not sit easily with modern information
systems
 It refers to a group of data items that is usually accessed
together
 It may be made up of one or more record types
Software Effort Estimation Techniques

 For example, a purchase order file may be made up of a record

type PURCHASE-ORDER plus a second which is repeated for
each item ordered on the purchase order — PURCHASE-
ORDER-ITEM
 In structured systems analysis, a logical internal life would
equate to a data store, while record types would equate to
relational tables or entity types
Software Effort Estimation Techniques

 External interface file types allow for output and input that may
pass to and from other computer applications
Software Effort Estimation Techniques

 Examples of this would be the transmission of accounting data

from an order processing system to the main ledger system or
the production of a file of direct debit details on a magnetic or
electronic medium to be passed to the Bankers Automated
Clearing System (BACS), Files shared between applications
would also be counted here
Software Effort Estimation Techniques

 The analyst identifies each instance of each external user type in

the application
 Each component is then classified as having either high,
average or low complexity
 Software Effort Estimation Techniques

 The counts of each external user type in each complexity band are
multiplied by specified weights (see Table) to get FP scores which are
summed to obtain an overall FP count which indicates the information
processing size
Software Effort Estimation Techniques

 With FPs as originally defined by Albrecht, the question of

whether the external user type was of high, low or average
complexity was intuitive
 The International FP User Group (IFPUG) has now
promulgated rules on how this is assessed
Software Effort Estimation Techniques

 For example, in the case of logical internal files and external

interface tiles, the boundaries shown in Table 5.3 are used to decide
the complexity level

 Similar tables exist for external inputs and outputs

Software Effort Estimation Techniques

 Function point analysis recognizes that the effort required to

implement a computer-based information system relates not just
to the number and complexity of the features provided but also
to the operational environment of the system
 Fourteen factors have been identified which can influence the
degree of difficulty associated with implementing a system
Software Effort Estimation Techniques

 The list that Albrecht produced related particularly to the

concerns of information system developers in the late 970s and
early 1980s, Some technology which was then new and
relatively threatening is now well established
 The technical complexity adjustment (TCA) calculation has had
many problems
Software Effort Estimation Techniques

 Some. have even found that it produces less accurate estimates

than using the unadjusted function point count
 Because of these difficulties, we omit further discussion of TCA
Tables have been calculated to convert the FPs to lines of code
for various languages
Software Effort Estimation Techniques

 For example, it is suggested that 53 lines of Java are needed on

average to implement an FP, while for Visual C++ the figure is
34
 You can then use historical productivity data to convert the lines
of code into an effort estimate, as previously described in
Section 5.7