Estimation

techniques
Experience-based techniques
Algorithmic cost modeling
Estimation
techniques
• Estimating project schedules is difficult. You have to make initial estimates on the basis
of an incomplete user requirements definition.
• There are so many uncertainties that it is impossible to estimate system development
costs accurately during the early stages of a project. Nevertheless, organizations need
to make software effort and cost estimates.
• Two types of techniques can be used for making estimates:

1. Experience-based techniques: The estimate of future effort requirements is

based on the manager’s experience of past projects and the application domain.
Essentially, the manager makes an informed judgment of what the effort
requirements are likely to be.
2. Algorithmic cost modeling: In this approach, a formulaic approach is used to
compute the project effort based on estimates of product attributes, such as size,
process characteristics, and experience of staff involved in.
Estimation techniques
• Organizations need to make software effort and cost estimates. There
are two types of technique that can be used to do this:
• Experience-based techniques The estimate of future effort requirements is
based on the manager’s experience of past projects and the application
domain. Essentially, the manager makes an informed judgment of what the
effort requirements are likely to be.
• Algorithmic cost modeling In this approach, a formulaic approach is used to
compute the project effort based on estimates of product attributes, such as
size, and process characteristics, such as experience of staff involved.

Chapter 23 Project Planning 3

Estimate uncertainty

Chapter 23 Project Planning 4

Experience-based approaches
• Experience-based techniques rely on judgments based on experience
of past projects and the effort expended in these projects on software
development activities.
• Typically, you identify the deliverables to be produced in a project and
the different software components or systems that are to be
developed.
• You document these in a spreadsheet, estimate them individually and
compute the total effort required.
• It usually helps to get a group of people involved in the effort
estimation and to ask each member of the group to explain their
estimate.
Chapter 23 Project Planning 5
Problem with experience-based approaches
• The difficulty with experience-based techniques is that a new
software project may not have much in common with previous
projects.
• Software development changes very quickly and a project will often
use unfamiliar techniques such as web services, application system
configuration or HTML5.
• If you have not worked with these techniques, your previous
experience may not help you to estimate the effort required, making
it more difficult to produce accurate costs and schedule estimates.

Chapter 23 Project Planning 6

Algorithmic cost modeling

• Algorithmic cost modeling uses a mathematical formula to predict project

costs based on estimates of the project size, the type of software being
developed, and other team, process, and product factors.

• Algorithmic cost models are developed by analyzing the costs and

attributes of completed projects, then finding the closest-fit formula to the
actual costs incurred. Algorithmic cost models are primarily used to make
estimates of software development costs.
❑ In both cases, you need to use your judgment to estimate either the
effort directly or the project and product characteristics. In the
startup phase of a project, these estimates have a wide margin of
error.

❑ During development planning, estimates become more and more

accurate as the project progresses
• Most algorithmic models for estimating effort in a software project are based on a simple
formula:

• A: a constant factor, which depends on local organizational practices and the type of
software that is developed.
• Size: an assessment of the code size of the software or a functionality estimate expressed in
function or application points.
• B: represents the complexity of the software and usually lies between 1 and 1.5.
• M: is a factor that takes into account process, product and development attributes,
such as the dependability requirements for the software and the experience of
the development team.

These attributes may increase or decrease the overall difficulty of developing the system.
• The number of lines of source code (SLOC) in the delivered system is the
fundamental size metric that is used in many algorithmic cost models.
• To estimate the number of lines of code in a system, you may use a
combination of approaches:
1. Compare the system to be developed with similar systems and use their
code size as the basis for your estimate.
2. Estimate the number of function or application points in the system and
formulaically convert these to lines of code in the programming language
used.
3. Rank the system components using judgment of their relative sizes and use
a known reference component to translate this ranking to code sizes.
•Most algorithmic estimation models have an exponential
component (B in the above equation) that increases with the size
and complexity of the system.
•This reflects the fact that costs do not usually increase linearly
with project size.
•As the size and complexity of the software increase, extra costs
are incurred because of the communication overhead of larger
teams, more complex configuration management, more difficult
system integration, and so on.
•The more complex the system, the more these factors affect the
cost.
 COCOMO cost modeling
COCOMO 1
COCOMO was developed by a software engineer Barry Boehm in 1981.
The COCOMO estimates the cost for software product development in terms of effort (resources
required to complete the project work) and schedule (time required to complete the project work)
based on the size of the software product. It estimates the required number of Man-Months (MM) for
the full development of software products.

According to Boehm, the estimation should be divided into 3 stages-

Basic Model
Intermediate Model
Detailed Model
Basic COCOMO
∙ Basic COCOMO computes software development effort (and cost) as a function of program size.
∙ Program size is expressed in estimated thousands of source lines of code (SLOC, KLOC).

COCOMO applies to three classes of software projects:

▪ Organic projects - "small" teams with "good" experience working with "less than rigid"
requirements (simple business system, simple inventory management system etc.)
▪ Semi-detached projects - "medium" teams with mixed experience working with a mix
of rigid and less than rigid requirements ( new OS or DBMS, complex inventory
management system etc.)
▪ Embedded projects - developed within a set of "tight" constraints. It is also combination
of organic and semi-detached projects.(hardware, software, operational, ...)
(embedded avionics, real time command system etc.)
∙ The basic COCOMO equations take the form

bb
Effort Applied (E) = ab(KLOC) [ man-months ]
db
Development Time (D) = cb(Effort Applied) [months]
People required (P) = Effort Applied / Development Time [count]
where, KLOC is the estimated number of delivered lines ,expressed in thousands of lines of code
for project.
The coefficients ab, bb, cb and db are given in the following table:

∙ Basic COCOMO is good for quick estimate of software costs.

∙ However it does not account for differences in hardware constraints, personnel quality and experience, use of modern tools and techniques, etc
Effort estimation are of two types

This approach of determining total effort from the total size is what we refer
to as the top-down approach, as overall effort is first determined and then
from this the effort for different parts are obtained.

Another approach for effort estimation is the bottom-up approach. In this approach, the
project is first divided into tasks and then estimates for the different tasks of the project
are first obtained. Prom the estimates of the different tasks, the overall estimate is
determined. That is, the overall estimate of the project is derived from the estimates of its
parts. This type of approach is also called activity-based estimation
Intermediate COCOMO
The basic steps in the intermediate COCOMO model are:

1. Obtain an initial estimate of the development effort from the estimate of thousands
of delivered lines of source code (KLOC).
2. Determine a set of 15 multiplying factors from different attributes of the project.
3. Adjust the effort estimate by multiplying the initial estimate with all the multiplying
factors.(Effort Adjustment Factor)

To determine the effort E in person-months the equation used is of the type

b Final Effort E = Ei * EAF

Initial Effort (Ei) = a(KLOC)
The value of the constants a and b depend on the project type. In COCOMO
projects are categorized into three types-organic, semidetached, and embedded
Intermediate COCOMO
∙ Intermediate COCOMO computes software development effort as function of
program size and a set of "cost drivers" that include subjective assessment of
product, hardware, personnel and project attributes.
∙ This extension considers a set of four "cost drivers", each with a number of
subsidiary attributes:-

Examples of the attributes are required

software reliability (RELY) application experience (AEXP)
product complexity (CPLX) use of modern tools (TOOL)
analyst capability (ACAP) development schedule (SCHD)
As an example, suppose a system for office automation has to be designed. From the
requirements, it is clear that there will be four major modules in the system: data
entry, data update, query, and report generator. It is also clear from the
requirements that this project will fall in the organic category.

The sizes for the different modules and the overall system are estimated to be:

Data Entry 0.6 KLOC

Data Update 0.6 KLOC
Query 0.8 KLOC
Reports 1.0 KLOC

TOTAL 3.0 KLOC

All other factors had a nominal rating. From these, the effort adjustment factor (EAF) is

Total Size is 3.0 KLOC And for the Organic category the constant values for a=3.2 and for b=1.05

Hence ,The initial effort estimate for the project is

The final effort estimate, E, is obtained by multiplying the initial estimate by the EAF. That is, E = EAF * Ei

Using the EAF, the adjusted effort estimate is

The percentage of total effort spent in a phase varies with the type and
size of the project. The percentages for an organic software project are
given in Table. Using this table, the estimate of the effort required for
each phase can be determined from the total effort estimate
 The office automation system's size estimate is 3 KLOC, so we will have to use
interpolation to get the appropriate percentage (the two end values for interpolation
will be the percentages for 2 KLOC and 8 KLOC). The percentages for the different
phases are: design—16%, detailed design—25.83%, code and unit test—41.66%, and
integration and testing—16.5%. With these, the effort estimates for the different
phases are:

Effort Estimates for the different phases are:

Percentage of Phase-wise distribution of effort * Effort estimate E

These effort estimates will be used later during personnel planning

Average Duration Estimation

In COCOMO, the schedule is determined by using the equation, for an organic type of software is

For other project types, the constants vary only slightly.

The duration or schedule of the different phases is obtained in the same manner as in effort distribution. The
percentages for the different phases are given in Table

In this COCOMO table, the detailed design, coding, and unit testing phases are combined
into one "programming phase."
overall size estimate for the project is 3 KDLOC, and the final effort estimate obtained
was 16.34 PM. As this is an organic system, the overall duration will be determined by
the equation

Using this we get the project duration D as

Using the preceding table, which gives the duration of the different phases as a percentage of the total project duration,
we can obtain the duration of the different phases. The duration of the different phases is:
 COCOMO cost
modeling
COCOMO 2

The application composition model

The early design model
The reuse model
The post-architecture level
COCOMO cost modeling
• The best known algorithmic cost modeling technique and tool is the COCOMO II model.
• This empirical model was derived by collecting data from a large number of software
projects of different sizes.
• These data were analyzed to discover the formulas that were the best fit to the observations.
• These formulas linked the size of the system and product, project, and team factors to the
effort to develop the system.
• COCOMO II is a freely available model that is supported with open-source tools.
• COCOMO II was developed from earlier COCOMO (Constructive Cost Modeling) cost
estimation models, which were largely based on original code development (B. W. Boehm
1981; B. Boehm and Royce 1989).
• The COCOMO II model takes into account modern approaches to software development, such
as rapid development using dynamic languages, development with reuse, and database
programming.
• COCOMO II embeds several submodels based on these techniques, which produce
increasingly detailed estimates.
The submodels that are part of the COCOMO II model are: (figure in the next slide)
1. An application composition model: This models is using when the software is composed
from existing components/reusable components. Software size estimates are based on
application points, and a simple size/productivity formula is used to estimate the effort
required.
2. An early design model: This model is used during early stages of the system design
after the requirements have been established. The estimate is based on the standard
estimation formula, with a simplified set of 7 multipliers. Estimates are based on
function points, which are then converted to number of lines of source code.
3. A reuse model: This model is used to compute the effort required to integrate reusable
components and/or automatically generated program code.
4. A post-architecture model: Once the system architecture has been designed, a more
accurate estimate of the software size can be made. Again, this model uses the
standard formula for cost estimation discussed above. However, it includes a more
extensive set of 17 multipliers reflecting personnel capability, product, and project
characteristics
COCOMO Estimation Models
• Of course, in large systems, different parts of the system may be
developed using different technologies, and you may not have to
estimate all parts of the system to the same level of accuracy.
• In such cases, you can use the appropriate submodel for each part of
the system and combine the results to create a composite estimate.
The application composition model
• The application composition model was introduced into COCOMO II to support the
estimation of effort required for prototyping projects and for projects where the software
is developed by composing existing components.
• It is based on an estimate of weighted application points (sometimes called object points),
divided by a standard estimate of application point productivity.
• The number of application points in a program is derived from four simpler estimates:
■the number of separate screens or web pages that are displayed;
■the number of reports that are produced;
■the number of modules in imperative programming languages (such as Java); and
■the number of lines of scripting language or database programming code.
This estimate is then adjusted according to the difficulty of developing each application
point.
Productivity depends on the developer’s experience and capability as well as the capabilities
of the software tools (ICASE) used to support development. Figure (next slide) shows the
levels of application-point productivity suggested by the COCOMO model developers.
Application Composition
Assess Object
Counts

Classification Of
Complexity Levels
Assign Complexity Weight
To Each Object

Determine Object
Points

Compute New
Object Points

Calculation Of
Productivity Rate

Compute The Effort

In Person Months.
•Assess object counts: Estimate the number of screens, reports and 3 GL
components that will comprise this application.
•Classification of complexity levels:
We have to classify each object instance (depending on values of its characteristics) into :-
o simple
o medium
o Difficult
• Assign complexity weight to each object : The weights are used for
three object types :-
o screen
o report
o 3GL components
•Determine object points: Add all the weighted object instances to get one
number and this known as object-point count.
•Compute new object points: We have to estimate the percentage of reuse
to be achieved in a project. Depending on the percentage reuse, the new object
points (NOP) are computed.

Object Points * (100 - %reuse)

NOP = ---------------------------------------------
100

NOP are the object points that will need to be developed and differ from the
object point count because there may be reuse( percentage of
the Product development which is accomplished by exploiting the existence of
existing component's design-or-development effort).
•Calculation of productivity rate: The productivity rate can be
calculated as:

Productivity rate (PROD) = NOP/Person month

•Compute the effort in Persons-Months: When PROD is known, we

may estimate effort in Person-Months as:

NOP
Effort in PM = ------------
PROD
Developer’s Experience And PROD (NOP/PM)
Capability
Very low 4
Low 7
Nominal 13
High 25
Very high 50

Application point productivity

The early design model
• This model may be used during the early stages of a project, before a detailed architectural
design for the system is available.
• The early design model assumes that user requirements have been agreed and initial
stages of the system design process are underway.
• Your goal at this stage should be to make a quick and approximate cost estimate.

• Uses Unadjusted Function Points (UFP) as the measure of size.

• Early design estimates are most useful for option exploration where you need to compare
different ways of implementing the user requirements.
• The estimates produced at this stage are based on the standard formula for algorithmic
models, namely:
 Where
Effort = Effort of the project in person months
A = Constant representing the nominal productivity,
provisionally set to 2.94
B = Scale factor
Size = Software size

The Scaling Factors that COCOMO-II model uses for the calculation of B are:

❑ Precedentness (PREC)
❑ Development flexibility (FLEX)
❑ Architecture/ Risk Resolution (RESL)
❑ Team Cohesion (TEAM)
❑ Process maturity (PMAT)
• This results in an effort computation as follows:

There are 7 early design cost drivers and are given below:

• PERS: personnel capability

• PREX: personnel experience
• RCPX: product reliability and complexity
• RUSE: reuse required
• PDIF: platform difficulty
• SCED: schedule
• FSIL: support facilities

39
The reuse model
• The COCOMO reuse model is used to estimate the effort required to integrate reusable or
generated code.
• Most large systems include a significant amount of code that has been reused from
previous development projects.
• COCOMO II considers two types of reused code.
• BLACK-BOX CODE
• WHITE-BOX Code
Black-box code
• Black-box code is code that can be reused without understanding the code or
making changes to it.
• Examples of black-box code are components that are automatically generated from
UML models or application libraries such as graphics libraries.
• It is assumed that the development effort for blackbox code is zero.
• Its size is not taken into account in the overall effort computation.
White-box code
• White-box code is reusable code that has to be adapted to integrate it with
new code or other reused components.
• Development effort is required for reuse because the code has to be
understood and modified before it can work correctly in the system.
• White-box code could be automatically generated code that needs manual
changes or additions.
• Three factors contribute to the effort involved in reusing white-box code
components:
1.The effort involved in assessing whether or not a component could be reused in a
system that is being developed.
2.The effort required to understand the code that is being reused.
3.The effort required to modify the reused code to adapt it and integrate it with the
system being developed.
• The development effort in the reuse model is calculated using the COCOMO early
design model and is based on the total number of lines of code in the system.
• The code size includes new code developed for components that are not reused plus
an additional factor that allows for the effort involved in reusing and integrating
existing code.
• This additional factor is called ESLOC, the equivalent number of lines of new source
code.
• The formula used to calculate the source code equivalence is:

ESLOC: Equivalent new kilo Source Lines of Code.

ASLOC: Adapted kilo Source Lines of Code .

AT: the percentage of reused code that can be modified automatically.

AAM: an Adaptation Adjustment Multiplier that reflects the additional effort required to reuse components.
 • The Adaptation Adjustment Multiplier (AAM) adjusts the estimate to reflect the
additional effort required to reuse code. The COCOMO model documentation
discusses in detail how AAM should be calculated.
• Simplistically, AAM is the sum of three components:
1.An assessment factor (referred to as AA) that represents the effort involved in
deciding whether or not to reuse components. AA varies from 0 to 8 depending on
the amount of time you need to spend looking for and assessing potential
candidates for reuse.
2.An understanding component (referred to as SU) that represents the costs of
understanding the code to be reused and the familiarity of the engineer with the
code that is being reused. SU ranges from 50 for complex, unstructured code to 10
for well- written, object-oriented code.
3.An adaptation component (referred to as AAF) that represents the costs of making
changes to the reused code. These include design, code, and integration changes.
Once you have calculated a value for ESLOC, you apply the standard estimation formula
to calculate the total effort required, where the Size parameter = ESLOC. Therefore,
the formula to estimate the reuse effort is:
The post-architecture
level
• The post-architecture model is the most detailed of the COCOMO II models.
• It is used when you have an initial architectural design for the system.
• The starting point for estimates produced at the post-architecture level is the same basic
formula used in the early design estimates:

By this stage in the process, you should be able to make a more accurate estimate of the project size, as you know
how the system will be decomposed into subsystems and components. You make this estimate of the overall code
size by adding three code size estimates:
1. An estimate of the total number of lines of new code to be developed (SLOC).
2. An estimate of the reuse costs based on an equivalent number of source lines of code (ESLOC), calculated
using the reuse model.
3. An estimate of the number of lines of code that may be changed because of changes to the system
requirements.
The exponent term

✧ This depends on 5 scale factors (see next slide). Their sum/100 is added to
1.01
✧ A company takes on a project in a new domain. The client has not defined
the process to be used and has not allowed time for risk analysis. The
company has a CMM level 2 rating.
▪ Precedenteness - new project (4)
▪ Development flexibility - no client involvement - Very high (1)
▪ Architecture/risk resolution - No risk analysis - V. Low .(5)
▪ Team cohesion - new team - nominal (3)
▪ Process maturity - some control - nominal (3)
✧ Scale factor is therefore 1.17.

10/12/2014 Chapter 23 Project Planning 46

Scale factors used in the exponent computation in the
post-architecture model

Scale factor Explanation

Architecture/risk resolution Reflects the extent of risk analysis carried out. Very low means little
analysis; extra-high means a complete and thorough risk analysis.
Development flexibility Reflects the degree of flexibility in the development process. Very low
means a prescribed process is used; extra-high means that the client
sets only general goals.
Precedentedness Reflects the previous experience of the organization with this type of
project. Very low means no previous experience; extra-high means that
the organization is completely familiar with this application domain.
Process maturity Reflects the process maturity of the organization. The computation of
this value depends on the CMM Maturity Questionnaire, but an
estimate can be achieved by subtracting the CMM process maturity
level from 5.
Team cohesion Reflects how well the development team knows each other and work
together. Very low means very difficult interactions; extra-high means
an integrated and effective team with no communication problems.

10/12/2014 Chapter 23 Project Planning 47

Multipliers

✧ Product attributes
▪ Concerned with required characteristics of the software product being developed.
✧ Computer attributes
▪ Constraints imposed on the software by the hardware platform.
✧ Personnel attributes
▪ Multipliers that take the experience and capabilities of the people working on the project
into account.
✧ Project attributes
▪ Concerned with the particular characteristics of the software development project.

10/12/2014 Chapter 23 Project Planning 48

 The effect of cost drivers on effort estimates

Exponent value 1.17

System size (including factors for reuse and 128,000 DSI
requirements volatility)
Initial COCOMO estimate without cost 730 person-months
drivers
Reliability Very high, multiplier = 1.39

Complexity Very high, multiplier = 1.3

Memory constraint High, multiplier = 1.21

Tool use Low, multiplier = 1.12

Schedule Accelerated, multiplier = 1.29

Adjusted COCOMO estimate 2,306 person-months

10/12/2014 Chapter 23 Project Planning 49

 The effect of cost drivers on effort estimates

Exponent value 1.17

Reliability Very low, multiplier = 0.75

Complexity Very low, multiplier = 0.75

Memory constraint None, multiplier = 1

Tool use Very high, multiplier = 0.72

Schedule Normal, multiplier = 1

Adjusted COCOMO 295 person-months

estimate

10/12/2014 Chapter 23 Project Planning 50

Project duration and staffing

✧ As well as effort estimation, managers must estimate the calendar time

required to complete a project and when staff will be required.
✧ Calendar time can be estimated using a COCOMO 2 formula
▪ TDEV = 3 × (PM)(0.33+0.2*(B-1.01))
▪ PM is the effort computation and B is the exponent computed as discussed above (B is 1
for the early prototyping model). This computation predicts the nominal schedule for the
project.
✧ The time required is independent of the number of people working on the
project.

10/12/2014 Chapter 23 Project Planning 51

Staffing requirements

✧ Staff required can’t be computed by diving the development time by the

required schedule.
✧ The number of people working on a project varies depending on the phase of
the project.
✧ The more people who work on the project, the more total effort is usually
required.
✧ A very rapid build-up of people often correlates with schedule slippage.

10/12/2014 Chapter 23 Project Planning 52

Key points

✧ The price charged for a system does not just depend on its estimated development costs and
the profit required by the development company. Organizational factors may mean that the
price is increased to compensate for increased risk or decreased to gain competitive
advantage.
✧ Software is often priced to gain a contract and the functionality of the system is then adjusted
to meet the estimated price.
✧ Plan-driven development is organized around a complete project plan that defines the project
activities, the planned effort, the activity schedule and who is responsible for each activity.

10/12/2014 Chapter 23 Project Planning 53

Key points

✧ Project scheduling involves the creation of various graphical representations of part of the
project plan. Bar charts, which show the activity duration and staffing timelines, are the most
commonly used schedule representations.
✧ A project milestone is a predictable outcome of an activity or set of activities. At each
milestone, a formal report of progress should be presented to management. A deliverable is
a work product that is delivered to the project customer.
✧ The agile planning game involves the whole team in project planning. The plan is developed
incrementally and, if problems arise, it is adjusted so that software functionality is reduced
instead of delaying the delivery of an increment.

10/12/2014 Chapter 23 Project Planning 54

Key points

✧ Estimation techniques for software may be experience-based, where managers judge the
effort required, or algorithmic, where the effort required is computed from other estimated
project parameters.
✧ The COCOMO II costing model is a mature algorithmic cost model that takes project,
product, hardware and personnel attributes into account when formulating a cost estimate.

10/12/2014 Chapter 23 Project Planning 55