SOFTWARE

EFFORT
ESTIMATION

S O F T WA R E P R O J E C T M A N A G E M E N T
UNIT II- CHAP – II
T Y. BS C . I T
-MANALI HALDANKAR
 INTRODUCTION
 Successful project is that the system is delivered
on time and within budget and with the required
quality.
 A project manager has to produce estimates of
effort, which affect costs and of activity durations,
which affect the delivery time.
 Planning & Estimating are iterative processes
which continue throughout the course of a project.
 For long life systems, maintenance costs will be
several times the development costs.
 The total cost for developing a software product
can be divided as: 60% development costs 40%
testing costs.
Difficulties in Software Estimation

 Subjective Nature of estimating

For ex. Some research shows that people tend to
underestimate the difficulty of small tasks & over-
estimate that of large ones.

 Political Implications
Different groups within an organization have different
objectives. The IOE information systems development
managers may, for ex. Want to generate work & will
press estimators to reduce cost estimates to encourage
higher management to approve projects.
 Changing Technology
Where technologies change rapidly, it is difficult to
use the experience of previous projects on new ones.

 Lack of homogeneity of project experience

Even where technologies have not changed,
knowledge about typical task durations may not be
easily transferred from one project to another because
of other differences between projects.
 STEPWISE FRAMEWORK OF COST
ESTIMATION

 The cost is estimated collectively by the

project manager, architectural team,
development team & test team.
 The estimated cost is acknowledged &
supported by all stakeholders.
 As the project work proceeds, the accuracy of
the estimates becomes clear because
knowledge about the project increases.
Step 1 : Define project scope & objectives
- Reasons for estimation.
- To determine & evaluate the estimated costs of a project before
authorizing implementation.
- To provide a basis for tracking & managing expenditures.
- To provide a tool for evaluating routine project decisions.
- To provide factual information to support investment analysis.
- to establish resources required & the resulting schedule.

Step 2 : Define project infrastructure

- How sponsor’s environment will have an impact on estimate.
- Technical factors that can affect estimates.
- What is unique about the project.

Step 3 : Select appropriate model

- Consider top-down model for high-level tasks or a proposal.
- Consider bottom-up model i.e. task –by –task approach for a detailed
accurate estimate.
Step 4 : Define estimation strategy and plan
- Identify estimators
- Develop a detailed plan for gathering estimates.
- Identify the type of estimation validation to be used.
- To provide a tool for evaluating routine project decisions.
-Review the history of similar projects.

Step 5 : Prepare the estimate

-For top-down model, use a selected model.
-For bottom-up model, generate detailed estimates, estimate administrative
support & project management effort & determine team size and duration.
- Initially, project manager defines the target cost of the software.
- To win the proposal
- To attain the internal corporate funding
- To achieve their goal.

Step 6 : Identify risks

- Include contingencies associated with risk response planning.
-The project manager checks the risks associated in achieving the target costs &
also discusses this problem with other stakeholders.
Step 7 : Validate and finalize estimate
- Validation includes
-Comparing & checking with similar projects.
-Scrutinizes the samples in selected areas of most risks.

Step 8 : Baseline estimate

-The project manager makes the estimate as a baseline & uses it in project
planning.
-Then he tracks & compares the actual expenditure to the estimate baselines
during project execution.
- Initially, schedule is created & it is referred to as the time baseline of the
project. Later it is used to compare updated baselines to the original baseline.
- The planned schedule dates for activities are called the baseline dates.

Step 9 : Execute the estimation plan

-The estimates affect the schedule, cost & profit as well as sponsor’s satisfaction.
-Good software cost estimation is based on the some well-defined models.
- Using similar methodologies, similar technologies, & similar environment with
similar type of stakeholders.
Entities of project estimation
 The four entities related to project estimation are:
1. Estimate the project/Software size:
- Prior to estimating effort, duration & cost of the planned
project, we first estimate the problem size.
- The project size is the amount of time & effort required to
develop the project.
- Size of the software totally depends upon : lines of code,
inputs, outputs, functions, transactions, features of the
module & etc.
- The metrics used to estimate the project size are:
i. Loc(Lines of Code)
ii. FP(Function Points)
2. Estimate the effort in person-hours:
The effort of different project tasks expressed in person-hours is affected by various
factors such as:
- Experience/Capability of the team members.
- Technical resources.
- Knowledge of development tools & technology platform.

3. Estimate the project schedule(duration) in calendar months:

- The project planners work closely with the technical leads, project manager & other
stakeholders & create a project schedule.
- Tight schedules may have an impact on the cost needed to develop the application.

4. Estimate the project cost in dollars(or other currency)

Based on the above information specified in the 1 st entity, the project effort is
expressed in dollars or any other currency.
SOFTWARE COST ESTIMATION TECHNIQUES

1. Expert Opinion:
It is also called as Delphi Cost method, proposed by Dr. Barry
Boehm. It is useful to assess differences between past
projects & new ones for which no historical pattern available.
Advantages:
 Little or no historical data needed.
 Suitable for new or unique projects.

Disadvantages:
 Very subjective.
 Experts may do partiality.
 Qualification of experts may be questioned.
2. Analogy:
- Estimates costs by comparing proposed programs with similar, previously completed
programs for which historical data is available.
- Actual costs of similar existing system are adjusted for complexity, technical or
physical differences to derive new cost estimates.
- Analogies are used early in a program cycle when there is insufficient actual cost data
to use as a detailed approach.
- Compares similarities & differences.
- Good choice for a new system is derived from an existing subsystem.

Advantages:
Inexpensive
Easily changed
Based on actual experience

Disadvantages:
Very subjective
Large amount of uncertainty
Similar projects must exist & it is difficult to find
Requires detailed technical knowledge of program & analogous system.
3. Parametric:
- Utilizes statistical techniques.
- It is used prior to development.

Advantages:
Can be excellent predictors when implemented correctly
Once created, CERs are fast & simple to use.
Easily changed
Useful early on in a program
Objective

Disadvantages:
Lack of data on software intensive systems for statistically significant CER.
It does not provides access to slight changes.
Top level, lower level may not be visible.
Need to be correctly validated & relevant to system.
4. Engineering:
- Also referred to as bottom up or detailed method.
- Start with component level & estimate the effort required for each component.
- Add these efforts to find a final estimate.
- Future costs of the system is predicated from historical costs of that system.
- It involves examining separate work segments in detail manner.
- Estimate is built up from the lower level of system costs.

Advantages:
Objective
Reduced uncertainty

Disadvantages:
Expensive.
Time consuming.
Not useful early on.
May leave out software integration efforts.
5. Actual:
- It decides future costs on recent historical costs of same system.
- Used later in development or production.
- Costs are calibrated to actual development or production productivity of the
organization.

Advantages:
Most accurate
Most objective of the five methodologies.

Disadvantages:
 Data not available early.
Time consuming.
Labour intensive to collect all the data necessary.
 SOFTWARE EFFORT ESTIMATION TECHNIQUES

1. Top-down estimation
 A top-down estimate is used in the initial stages of a project.
 A top-down estimate compares historical data with experience.
 This is sometimes called a guesstimate.
 System costs are first estimated & these include computing resources,
personnel required to develop the system, configuration management costs,
quality assurance, system integration, training & publications.
 Then the personnel costs are estimated with the help of previous project costs.
 Top-down estimating results in high-level estimates of projects or their
summary tasks based on expert judgment.
 It is less costly & less accurate than other techniques.
 It is a good approach when used during proposal phase especially when
detailed information & time are not available.
2. Bottom-up estimation
 A bottom-up cost estimate involves receiving estimates from all
estimators & then summarizing them into a cost estimate for the
project.
 This method could involve inflated pricing as estimators add
contingency to their estimate.
 The cost & accuracy are driven by the size of the individual work
items.
 Smaller work items increase both cost & accuracy to the project
estimate.
 Initially each module of subsystem is estimated.
 Then those costs are combined to prepare an overall estimate.
 These are helpful for estimating the costs of developing
individual components but they do not help in estimating system
costs, configuration management costs & quality control.
3. Expert Judgment
 This is the information provided by a group or a person with
specialized knowledge & training.
 It depends on the experience, background & business sense of
one or more key people in the organization.
 The biggest advantage of expert judgment can also be a danger
with overconfidence.
 Experts may overlook some factors, if he feels project is
similar to previous one & make estimate accordingly but the
project being different, there is a possibility estimate variation.
 The major disadvantage is Individuals in the expert group are
being affected by interpersonal group dynamics.
 To overcome these disadvantages, Delphi Technique is used.
4. Analogy(estimate based on similar completed
project)
 It is also called as ‘Case Based Analogy’ i.e. effort of the source
case is used as base estimate for the target.
 Estimates costs by comparing proposed programs with similar,
previously completed programs for which historical data is
available.
 Angel software tool is used for estimating by analogy.
 Actual costs of similar existing system are adjusted for
complexity, technical or physical differences to derive new cost
estimates.
 Compares similarities & differences.
 Good choice for a new system is derived from an existing
subsystem.
 COST ESTIMATION PARAMETERS

1. Size
 The size of the proposed software product is
weighed in terms of components i.e. in terms of
the number of source code instructions or the
number of functions required to develop the
proposed product.

2. Process
 The process includes:
 Phases
 Activities carried out in each phase
3. Personnel
 It means capabilities & experience of software engineering personnel in the field of
Computer science & the applications of the project.
 It also depends upon the personnel’s familiarity with the Development Tools &
 Technology Platform.

4. Environment
 The environment contains the tools & techniques that are required to develop efficient
Software & to automate the process.

5. Quality
 The expected quality of the proposed product depends upon:
 Features
 Performance
 Reliability
 Adaptability

The above mentioned five parameters size, process, personnel, environment & quality can
be related with each other to calculate the estimated cost for the proposed software
development.
Effort/Cost = (Personnel)(Environment)(Quality)(Size^
Process)
- Input by a user.

- Output like reports, screens

 COCOMO MODEL
 Boehm proposed COCOMO (Constructive Cost Estimation Model) in 1981.
 COCOMO is one of the most generally used software estimation models in the
world.
 COCOMO predicts the efforts and schedule of a software product based on
the size of the software.

The necessary steps in this model are:

 Get an initial estimate of the development effort from evaluation of
thousands of delivered lines of source code (KDLOC).
 Determine a set of 15 multiplying factors from various attributes of the
project.
 Calculate the effort estimate by multiplying the initial estimate with all the
multiplying factors i.e., multiply the values in Step 1 and Step 2.
 The initial estimate (also called nominal estimate) is determined by an
equation of the form used in the static single variable models, using KDLOC
as the measure of the size. To determine the initial effort Ei in person-months
the equation used is of the type is shown below
Ei=a*(KDLOC)b
In COCOMO, projects are categorized into three types:
 Organic
 Semidetached
 Embedded

1.Organic: A development project can be treated of the organic type, 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 methods of
projects. Examples of this type of projects are simple business systems, simple
inventory management systems, and data processing systems.

2. Semidetached: A development project can be treated with semidetached type if the

development consists of a mixture of experienced and inexperienced staff. Team members
may have finite experience in related systems but may be unfamiliar with some aspects of
the order being developed. Example of Semidetached system includes developing a new
operating system (OS), a Database Management System (DBMS), and complex
inventory management system.

3. Embedded: A development project is treated to be of an embedded type, if the software

being developed is strongly coupled to complex hardware, or if the stringent regulations on
the operational method exist. For Example: ATM, Air Traffic control.
According to Boehm, software cost estimation
should be done through three stages:
Basic Model

Intermediate Model

Detailed Model
1. Basic COCOMO Model: The basic COCOMO model provide an accurate size of the project parameters. The following
expressions give the basic COCOMO estimation model:
Effort=a1*(KLOC)^a2PM
Tdev=b1*(efforts)^b2 Months
Where
KLOC is the estimated size of the software product indicate in Kilo Lines of Code,
a1,a2,b1,b2 are constants for each group 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).

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

For the three classes of software products, the formulas for estimating the development time based on the effort are
given below:
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
Some insight into the basic COCOMO model can be obtained by plotting the estimated characteristics for different
software sizes. Fig shows a plot of estimated effort versus product size. From fig, we can observe that the effort is
somewhat superliner in the size of the software product. Thus, the effort required to develop a product increases very
rapidly with project size.
The development time versus the product size in KLOC is plotted in fig. From fig it can be observed that
the development time is a sub linear function of the size of the product, i.e. when the size of the product
increases by two times, the time to develop the product does not double but rises moderately. This can
be explained by the fact that for larger products, a larger number of activities which can be carried
out concurrently can be identified. The parallel activities can be carried out simultaneously by the
engineers. This reduces the time to complete the project. Further, from fig, it can be observed that the
development time is roughly the same for all three categories of products. For example, a 60 KLOC
program can be developed in approximately 18 months, regardless of whether it is of organ
semidetached, or embedded type.
Productivity (P) = Size/Effort
Staff Size (SS) = E/D
Where E = Effort, D = Development time
Example 1: Suppose a project was estimated to be 400 KLOC. Calculate the
effort and development time for each of the three model i.e., organic, semi-
detached & embedded.

Solution: The basic COCOMO equation takes the form:

Effort=a1*(KLOC) a2 PM
Tdev=b1*(efforts)b2 Months
Estimated Size of project= 400 KLOC

(i)Organic Mode
E = 2.4 * (400)1.05 = 1295.31 PM
D = 2.5 * (1295.31)0.38=38.07 PM
(ii)Semidetached Mode
E = 3.0 * (400)1.12=2462.79 PM
D = 2.5 * (2462.79)0.35=38.45 PM
(iii) Embedded Mode
E = 3.6 * (400)1.20 = 4772.81 PM
D = 2.5 * (4772.8)0.32 = 38 PM
Example 2: A project size of 200 KLOC is to be developed.
Software development team has average experience on
similar type of projects. The project schedule is not very
tight. Calculate the Effort, development time, average
staff size, and productivity of the project.

Solution: The semidetached mode is the most appropriate

mode, keeping in view the size, schedule and experience
of development time.
Hence E=3.0(200)1.12=1133.12PM
D=2.5(1133.12)0.35=29.3PM
P = 176 LOC/PM
2. Intermediate Model: The basic Cocomo model considers that the effort is only a function of the number of lines
of code and some constants calculated according to the various software systems. The intermediate COCOMO
model recognizes these facts and refines the initial estimates obtained through the basic COCOMO model by
using a set of 15 cost drivers based on various attributes of software engineering.
Classification of Cost Drivers and their attributes:
(i) Product attributes –
 Required software reliability extent
 Size of the application database
 The complexity of the product

Hardware attributes -
 Run-time performance constraints
 Memory constraints
 The volatility of the virtual machine environment
 Required turnabout time

Personnel attributes -
 Analyst capability
 Software engineering capability
 Applications experience
 Virtual machine experience
 Programming language experience
Project attributes -
 Use of software tools
 Application of software engineering methods
 Required development schedule

Intermediate COCOMO equation:

E=ai(KLOC)bi*EAF
D=ci (E)di
3. Detailed COCOMO Model: Detailed COCOMO incorporates
all qualities of the standard version with an assessment of the cost
driver’s effect on each method of the software engineering
process. The detailed model uses various effort multipliers for
each cost driver property. In detailed COCOMO, the whole
software is differentiated into multiple modules, and then we
apply COCOMO in various modules to estimate effort and then
sum the effort.
The Six phases of detailed COCOMO are:
 Planning and requirements
 System structure
 Complete structure
 Module code and test
 Integration and test
 Cost Constructive model
DELPHI COST ESTIMATION – OLD APPROACH

 The Delphi technique was developed at Rand Corporation to gain expert

consensus without introducing the adverse side effects of group
meetings.
 The following step-by-step process shows how the Delphi technique can
be adapted for estimation:
1. The coordinator provides each estimator with system definition
document & a cost estimate form for recording the estimate.
2. No discussion takes place about estimates among the estimators. They
only ask questions to the coordinator after studying the definition &
completing the estimate.
3. The coordinator after including estimator’s unusual rationales prepares
& distributes summary of estimator’s responses.
4. Estimators, by using previous estimate’s results prepare another
estimate anonymously. If their estimate varies from the group’s
estimate, they are asked to provide justification for their estimates.
5. Process Iteration takes place for many rounds & no group discussion is
allowed during this process.
 DELPHI COST ESTIMATION – NEW
APPROACH

 This new approach increases communication while

preserving ambiguity:
1. Coordinator provides estimation form & system definition
to each estimator.
2. After study of the definition, the estimators discusses the
estimation issues with the coordinator & within the group..
3. Then Estimators complete estimates without disclosing
their identity.
4. The coordinator prepares estimate summary but does nor
record any facts.
5. Finally, the coordinator after finding out the variations in
estimates calls a group meeting to focus on those issues.
The process is iterated for as many rounds as necessary.
 RAYLEIGH CURVE

 The Putnam-Norden-Rayleigh curve, also known as the PNR

curve.
 It is an equation which specifies the relationship between
applied effort & delivery time for a software project.
 A PNR curve can be used to determine the least cost time for
delivery t0 up to the limit tmin, the absolute minimal amount
of time required to complete the project.
 The PNR curve was used to derive the Software equation.
 STAFFING PATTERN
 Along with the effort estimation, managers must also
estimate the calendar time required to complete a
project & also when will the staff will be required. This
can be calculated using a COCOMO – formula.

 PM is the effort computation & B is the exponent. This

computation predicts the nominal schedule for the
project.
 The duration required to complete the project is
independent of the number of people working on the
project.
 Staff required can’t be computed by calculating the
development time.
 The number of people working on a project varies from phase to
phase.
 More the people work on the project, more the total effort is
required.

Effect of Schedule Compression

 Schedule compression is a project management technique used
to shorten an already developed schedule.
 This is done so as to update the delivery date or delay the
delivery date.
 It’s done without changing the scope of the program.
 There are two techniques used for schedule compression are:
Crashing & Fast Tracking
 Crashing assigns more resources to an activity to
decrease the overall time to complete it.

 Fast tracking is the process of executing the activities in

parallel that were originally scheduled in sequential.
Activities can be overlapped, started earlier than
scheduled, start activities that require different resources
or combine the activities in the schedule.
 CAPERS JONES ESTIMATING RULES OF
THUMB

Rule 1: SLOC Function Point Equivalence

1 FP is 125 SLOC for procedural languages, 300 SLOC for
assembly languages & <20 for some OOP languages.
Rule 2: Project Duration Estimation
(FPs)^0.4 predicate the approximate development time in
calendar months.
Rule 3: Rate of Requirements Creep
User requirements creep in at average rate of 2% per month
from the design through coding phases.
Rule 4: Defect Removal Efficiency
Each software verification technique such as reviews,
inspections or test step will find & remove 30% of the
bugs that are present.
Rule 5: Project ManPower Estimation
Size of the software/150 = approximate number of the
personnel required for developing the applications.

Rule 6: Software Development Effort Estimation

Approximate number of staff months of effort required to
develop a software = software development time *
number of personnel required.

Rule 7: Function Points

FP/s500 = approximate number of personnel required for
regular maintenance activity.
 QUESTIONS
 Describe the cost estimation process.
 Write short note on Cost estimation techniques.
 List and describe the cost estimation parameters.
 Write short note on Rayleigh curve.
 State Capers Jones rules of thumb for software estimation.
 Explain Staffing Pattern in detail with its two techniques.
 Explain Delphi Cost Estimation with its New & Old Approach.
 Explain COCOMO Model in detail with suitable example.
 Explain the five major components of Albrecht Function
Point Analysis.
 Write short note on Entities of Project Estimation.
 Write short note on Effort estimation techniques.
 Sums
1. A new project with estimated 40 KLOC has to be
developed. Calculate the effort, development time,
average staff and productivity of the project.
2. A new project with estimated 200 KLOC has to be
developed. Calculate the effort, development time,
average staff and productivity of the project.
3. A new project with estimated 350 KLOC has to be
developed. Calculate the effort, development time,
average staff and productivity of the project.
 A new project with estimated 40 KLOC has to be developed. For development of
project also requires
i. Low Software reliability(0.88)
ii. High product complexity(1.15)
iii. Low application experience(1.13)
iv. Low programming language experience(0.95)
v. Calculate the effort, development time, average staff & productivity of the
project.

 A project estimated for 251 KLOC has to be developed. For development of

project also requires
i. High Software reliability(1.15)
ii. High product complexity(1.15)
iii. High Analyst capability(0.86)
iv. Low programming language experience(1.07)
v. Remaining all drivers are treated as nominal
vi. Calculate the effort, development time, average staff & productivity of the
project.
 A project estimated for 350 KLOC has to be developed.
For development of project also requires
i. High Software reliability(1.16)
ii. High product complexity(1.15)
iii. High Analyst capability(0.85)
iv. Low programming language experience(1.07)
v. Remaining all drivers are treated as nominal
vi. Calculate the effort, development time, average staff &
productivity of the project.