I0065

TOPIC TITLE: SOFTWARE PROJECT ESTIMATION

SPECIFIC OBJECTIVES:

At the end of the topic session, the students should be able to:

1. describe the process in software project estimation,

2. describe each estimation model,
3. enumerate the tools in automated estimation.

MATERIALS/EQUIPMENT:

o Computer with speakers

o LCD/OHP Projector
o File/s (04 Software Project Estimation)
• 04 LCD Slides 1
• 04 OHP Slides 1
• 04 LCD Slide Handout 1
• 04 OHP Slide Handout 1
o Software requirements
• MS PowerPoint

TOPIC PREPARATION:

o Prepare the student’s handout (3 copies) needed for the topic

presentation and have it photocopied.
o Prepare the computer unit for slide presentation.
o Prepare additional examples as supplementary materials on
discussing the topic.

PRESENTATION OVERVIEW:

A. Introduction 5 min
B. Instructional Input
Software Project Estimation 40 min
a. Define estimation
b. Discuss the software project estimation
c. Discuss decomposition techniques
d. Explain empirical estimation model
e. Explain the structure of software estimation
f. Discuss software equation
g. Discuss the six generic functions of automated estimation
tools
C. Generalization 10 min
D. Homework 5 min
Total duration 60 min

Software Project Estimation *Property of STI

Page 1 of 11
 I0065

TOPIC PRESENTATION:

A. Introduction

1. Start off the session with a brief review of the previous topic. You
may call on students to define terms that was taught during the
lecture.

2. Distribute the student’s handouts and proceed with the lecture.

B. Instructional Input

Software Project Estimation

Slide 1 1. Show Slide 1 of 04 LCD Slides 1. Present the topic coverage to the
class.

Slide 2 2. Show Slide 2. Introduce the topic on estimation, and then explain
the factors affecting it.

Estimation of resources, costs, and schedules for a software

development effort requires experience, access to good
historical information, and the courage to commit to
quantitative measures when all qualitative data exist.
Estimation carries inherent risk that leads to uncertainty.

There are three factors that affect estimation and these are
as follows:

• Project complexity – This has a strong effect on

uncertainty that is inherent in planning. Complexity
is a relative measure that is affected by familiarity
with past effort. A real-time application might be
perceived as “exceedingly complex” to a software
group that has previously developed only batch
applications. The same real-time application might
be perceived as “run-of-the-mill” for a software
group that has been heavily involved in high speed
process control.

• Project size – As size increases, the interdependency

among various elements of the software grows
rapidly. Problem decomposition, an important

Software Project Estimation *Property of STI

Page 2 of 11
 I0065

approach to estimating, becomes more difficult

because decomposed elements may still be
formidable.

• Degree of structural uncertainty – Structure refers

to the degree to which requirements have been
solidified, the ease with which functions can be
compartmentalized, and the hierarchical nature of
information that must be processed.

Risk is measured by the degree of uncertainty in the

quantitative estimates established for resources, costs, and
schedules. If project scope is poorly understood or project
requirements are subject to change, uncertainty and risk
become dangerously high. The software planner should
demand completeness of function, performance, and
interface definitions. The planner (and also the customer)
should recognize that variability in software requirements
means instability in cost and schedule.

Slide 3 3. Discuss about software project estimation. Mention the variables

affecting software cost and effort estimation. Then, explain the
different options for achieving reliable cost and effort estimates.
Show Slide 3.

In the early days of computing, software costs comprised a

small percentage of overall computer-based system cost.
An order of magnitude error in estimates of software cost
had relatively little impact. Today, software is the most
expensive element in most computer-based systems. A
large cost estimation error can make a difference between
profit and loss.

The following are the variables that affect software cost and
effort estimation:

• Human

• Technical

• Environmental

• Political

Here are the options for achieving reliable cost and effort
estimates:

1. Delay estimation until late in the project.

2. Base estimates on similar projects that have already

been completed.

Software Project Estimation *Property of STI

Page 3 of 11
 I0065

3. Use relatively simple “decomposition techniques”

to generate project cost and effort estimates.

4. Use one or more empirical models for software cost

and effort estimation.

The first option is not practical. Cost estimates must be

provided “up-front.” The second option can work
reasonably well if the current project is quite similar to past
efforts and other project influences are equivalent. The
remaining options are viable approaches to software
project estimation. The techniques noted for each option
should be applied in tandem, each used as a cross-check for
the other. Decomposition techniques take a “divide and
conquer” approach to software project estimation. By
decomposing a project into major functions and related
software engineering activities, cost and effort estimation
can be performed in a stepwise fashion. Empirical
estimation models can be used to complement
decomposition techniques and offer a potentially valuable
estimation approach in their own right. A model is based on
experience and takes the form:

d = f(vi)

where d is one of a number of estimated values (e.g., effort,

cost, project duration) and vi are selected independent
parameters (e.g., estimated LOC or FP).

Automated estimation tools implement one or more

decomposition techniques or empirical models. When
combined with an interactive human — machine interface,
automated tools provide an attractive option for estimating.

Slide 4 4. Show Slides 4-7. Discuss each decomposition techniques.

Software project estimation is a form of problem solving,

and in most cases, the problem to be solved (i.e.,
developing a cost and effort estimate for a software project)
is too complex to be considered in one piece. For this
reasons, the problem is decomposed, re-characterizing it as
a set of smaller (and hopefully more manageable) problems.

There are three techniques used for estimating a project

and these are software sizing, problem-based estimation,
and process-based estimation.

Software Project Estimation *Property of STI

Page 4 of 11
 I0065

Software Sizing

The accuracy of a software project estimate is predicated on

a number of things such as:

1. the degree to which the planner has properly

estimated the size of the product to be built

2. the ability to translate the size estimate into human

effort, calendar time, and money (a function of the
availability of reliable software metrics from past
projects)

3. the degree to which the project plan reflects the

abilities of the software team

4. the stability of product requirements and the

environment that supports the software
engineering effort

Putnam and Myers suggest four different approaches to the

sizing problem and these are:

• “Fuzzy-logic” sizing – This uses the approximate

reasoning techniques that are the cornerstone of
fuzzy logic. To apply this approach, the planner
must identify the type of application, establish its
magnitude on a qualitative scale, and then refine
the magnitude within the original range.

• Function point sizing - The planner develops

estimates of the information domain characteristics
as discussed in Software Process and Project
Metrics.

• Standard component sizing – Software is composed

of a number of different “standard components”
that are generic to a particular application area. For
example, the standard components for an
information system are subsystems, modules,
screens, reports, interactive programs, batch
programs, files, LOC, and object-level instructions.

• Change sizing – This is used when a project includes

the use of existing software that must be modified
in some way as part of a project. The planner
estimates the number and type of modifications
that must be accomplished.

Software Project Estimation *Property of STI

Page 5 of 11
 I0065

Problem-based Estimation
Slide 5
During the software project estimation, LOC and FP data are
used in two ways:

1. as an estimation variable used to “size” each

element of the software, and

2. as baseline metrics collected from past projects and

used in conjunction with estimation variables to
develop cost and effort projections

LOC and FP estimation are different estimation techniques,

but have several characteristics in common. The project
planner starts with a bounded statement of software scope
which is decomposed into problem functions that can be
estimated each individually. Then, LOC or FP is estimated
for each function. On the other hand, the project planner
can choose another component for sizing such as classes or
objects.

Baseline productivity metrics, such as LOC/pm or FP/pm,

are applied to the appropriate LOC or FP, and cost or effort
for the function is derived. Function estimates are
combined to produce an overall estimate for the entire
project.

The LOC and FP estimation techniques differ in the level of

detail required for decomposition and the target of the
partitioning. When LOC is used as the estimation variable,
decomposition is completely necessary and often taken to
considerable levels of detail. The greater the degree of
partitioning, the more likely that reasonably accurate
estimates of LOC can be developed.

For FP estimates, decomposition works differently. Instead

of focusing on function, each of the information domain
characteristics such as inputs, outputs, data files, inquiries,
and external interfaces are estimated.

No matter what estimation variable is used, the project

planner starts by estimating a range of values for each
function or information domain value. By means of
historical data, the planner estimates an optimistic and
pessimistic size value for each function or count for each
information domain value. When a range of values is
specified, an implicit indication of the degree of uncertainty
is provided.

Software Project Estimation *Property of STI

Page 6 of 11
 I0065

Example of LOC-based and FP-based Estimation

Slide 6
Consider a software package to be developed for a
computer-aided design (CAD) application for mechanical
components. A review of the system specification indicates
that the software is to execute on an engineering
workstation and must interface with various computer
graphics peripherals including a mouse, digitizer, high-
resolution color display, and laser printer.

Following the three-point estimation technique for LOC, the

table shown in the Table 4.1.

Table 4.1 Estimation Table for LOC Method

Decomposition for FP-based estimation focuses on

information domain values, rather than software functions.
In the Table 4.2, the project planner estimates inputs,
outputs, inquiries, files, and external interfaces for the CAD
software.

Table 4.2 Estimating Information Domain Values

Slide 7 Process-based Estimation

The commonly used technique for estimating a project is

basing the estimate on the process that will be used – the
process is decomposed into a relatively small set of tasks
and the effort required to complete each task is estimated.

Similar to problem-based estimation, process-based

estimation starts with a description of software functions

Software Project Estimation *Property of STI

Page 7 of 11
 I0065

acquired from the project scope. For each function there is

a series of software process activities performed. Once
problem functions and process activities are melded, the
planner estimates the effort that will be required to
complete each software process activity for each software
function. Then, average labor rates are applied to the effort
estimated for each process activity.

The last step is to compute the costs and effort for each
function and software process activity. If process-based
estimation is performed independently of LOC or FP
estimation, there are two or three estimates for cost and
effort that can be compared and reconciled. If both sets of
estimates show reasonable agreement, the estimates are
reliable. However, if the results of these techniques show
little agreement, investigation and analysis must be
performed.

For computer software, an estimation model uses

empirically derived formulas to predict effort as a function
of LOC or FP.

The empirical data that support most estimation models is

derived from a limited sample of projects. For this reason,
no estimation model is appropriate for all classes of
software and in all development environments.

Slide 8 5. Show Slide 8. Explain structure of estimation model.

A typical estimation model is derived using regression

analysis on data collected from past software projects. The
overall structure of such models takes the following form:

E = A + B x (ev)C

where A, B, and C are empirically derived constants, E is

effort in person months, and ev is the estimation variable
(either LOC or FP).

Slide 9 6. Show Slide 9. Discuss software equation.

The software equation is multivariable that assumes a

specific distribution of effort over the life of a software
development project. The model has been derived from
productivity data collected for over 4000 contemporary
software projects. Based on these data, an estimation
model of the form:

E = [LOC x B0.333/P]3 x (1/t4)

Software Project Estimation *Property of STI

Page 8 of 11
 I0065

where:

E = effort in person-months or person-years

T = project duration in months or years

B = “special skills factor” that increases slowly as “the need

for integration, testing, quality assurance, documentation,
and management skills grow”.

P = “productivity parameter” that reflects:

• overall process maturity and management practices

• the extent to which good software engineering

practices are used

• the level of programming languages used

• the state of the software environment

• the skills and experience of the software team

• the complexity of the application

Typical values might be P = 2000 for development of real-

time embedded software; P = 10,000 for
telecommunication and systems software; and P = 28,000
for business systems applications. The productivity
parameter can be derived for local conditions using
historical data collected from past development efforts.

Take note that there are two independent parameters in

software equation:

• an estimate of size (in LOC)

• an indication of project duration in calendar months

or years

Slide 10 7. Show Slide 10. Discuss the six generic functions of automated
estimation tools.

These automated estimation tools allow the planner to

estimate cost and effort and to perform “what if” analyses
for important project variables such as delivery date or
staffing. Although many automated estimation tools exist,
all exhibit the same general characteristics and all perform
the following generic functions:

1. Sizing of project deliverables – The size of one or

more software work products is estimated. These

Software Project Estimation *Property of STI

Page 9 of 11
 I0065

work products are external representation of

software, software itself, functionality delivered,
and descriptive information.

2. Selecting project activities – The appropriate

process framework is selected and the software
development task set is specified.

3. Predicting staffing levels – The number of people

who will be available to do the work is specified.
Since the relationship between people available and
work is highly nonlinear, this is an important input.

4. Predicting software effort – Estimation tools use

one or more models relating the size of the project
deliverables to the effort required to produce them.

5. Predicting software cost – Given the results of step

4, costs can be computed by allocating labor rates
to the project activities noted in step 2.

6. Predicting software schedules – Once effort,

staffing level, and project activities are identified, a
draft schedule can be produced by allocating labor
across software development activities based on
recommended models for effort distribution.

When different estimation tools are applied to the same

project data, a large variation of estimated results is
encountered. Sometimes predicted values are significantly
different from actual values. This reinforces the idea that
the output of estimation tools should be used as one data
point from which estimates are derived.

C. Generalization

1. Have a recap and summary of the previous sub-topic discuss during

the session.

D. Homework

Ask the student to have an advanced reading on Software Engineering

Metrics Basic Measurement.

Software Project Estimation *Property of STI

Page 10 of 11
 I0065

GRADUATE ATTRIBUTES CHECKLIST

Creative Conscientious Emotionally Mature

Fluency Orderly Self-awareness

Flexibility Dutiful Self-management

Originality Self-disciplined Social Awareness

Elaboration Relationship Management

Effective Team Player Critical Thinker

Communicator Networking Challenged Thinker
Speaking
Coordinating Beginning Thinker
Listening
Cooperating Practicing Thinker
Body Language
Collaborating
Reading
Writing

Proactive Lifelong Learner

Anticipatory Self-motivated
Plan-oriented Self-regulated
Action-directed Self-directed

REFERENCES:

Pressman, R S. (2010). Software engineering: a practitioner's approach

(7th ed.). McGraw-Hill/Higher Education

Software Project Estimation *Property of STI

Page 11 of 11