Software Effort Estimation - 1

Yogesh Sharma, Ph.D., P.Eng.

Week 6, Lecture 1 Software Engineering

October 03, 2023 Management (ENSE 374)
Agenda
• Recap
• Introduction to Software Effort Estimation
• Difficulties related to Software Effort Estimation
• Software Estimation Parameters
• Software Effort Estimation Techniques
• Summary
Learning Outcomes
After the lecture, students should be able to answer the following
questions
• Why do we need a formal framework to the project planning?
• Why is it important to ask questions and simplify the
requirements during the project planning stage?
Recap: Stepwise Approach for Project
Planning
• Based on PRINCE2, a project management standard developed and used
intensively by British government for its ICT and other projects.
• PRINCE stands for Projects IN Controlled Environments.
• Stepwise approach tries to answer the following questions

What do I do now? What should I start?

• Provided stepwise framework is applicable to the projects of any scale and type
of application.
Recap: Stepwise
Approach
Recap: Case Study
Regina College is a higher education institution which used to be managed by the
University of Saskatchewan (UofS) authority but has now become autonomous. It
has been renamed as University of Regina (UofR). However, its payroll is still
administered by the UofS authority and pay slips and other output are produced in
the UofS’s computer center. The UofS now charges the UofR for their service. The
UofR management thought that it would be cheaper to develop its own payroll
software.

The project is to implement an independent payroll processing software

system for the UofR.
Introduction: Software Effort Estimation
What makes a successful Software Engineering Project?

Delivering the agreed functionality on time at the agreed cost with the required
quality.
This implies that the project manager has set the reasonable targets by performing
‘effort’ estimates.

What if the estimates are wrong?

This will affect

• Cost An estimate is not really a prediction, it is a management goal.
• Activity durations
• Delivery time
Difficulties of Performing Estimation

• Experience on one project may not be

• Different groups within an organization
• When technology changesapplicable
rapidly, ittoisanother.
• It may be difficult to produce evidence
have different
to objectives.
difficult to use the experience of previous
• Knowledge about typical task durations
support your precise target. • Example: Managers want to reduce
projects on new ones. may not be directly or easily transferred
• Example: Generally, small targetsestimated
are costs to win support for
• This brings uncertainties from
in theone project
early days to another.
under-estimated and large targetsacceptance
are over- of a project proposal. Whereas
of a project, when there •isThis
a learning
generally occurs when a same term is
estimated. a project developer want to increase the
curve. interpreted differently according to the
estimates to create a comfort zone.
context of a project.
Over- and Under-Estimates
Over-estimation causes the projects to take longer than it would otherwise.
Parkinson’s Law: ‘Work expands to fill the time available’.

Brook’s Law: ‘Putting more people on a late job makes it later’.

Under-estimation effects the quality.

Weinberg’s Zeroth Law of Reliability: ‘If a system does not have to be reliable, it can meet any other
objective ’.

A good estimate is if the software development cost remains within 20% of the
estimated cost.
Basis (Foundation) for Software Estimating
• Need for historical data: • Measure of work (Project size):
Information about past Should be able to measure the
projects is required for amount of work involved. This
estimation. However, attention gives the information about the
should be paid to the possible size of the project. Following
differences while selecting the this the development effort and
past projects. duration are estimated. It is
measured in Source Lines of
Code (SLOC) and Function
Point (FP).
Parameters to be estimated
• Project size is a fundamental measure of work.
• Based on the estimated size, two parameters are estimated:
• Effort
• Duration
• Effort is measured in person-month (pm) aka work-month (wm)
• One person-month is the effort an individual can typically put in a month.
• Implicitly, takes productivity losses because of time lost in holidays, weekly offs, coffee breaks,
sick leaves and other metrics.
• PM is better than person-days or person-years because developers are assignment
to project based on months.
Mythical Person-Month
Brook’s Law: ‘Putting more people on a late job makes it later’.

For tasks with complex interrelationship, addition of manpower to a late project

does not help.
Measure of Work
• The project size is a measure of the problem complexity in terms of the effort
and time (duration) required to develop the product.
• Two metrics are used to measure project size:
• Source Lines of Code (SLOC) generally factorized as KLOC.
• Function point (FP)
• FP is favored over SLOC because of the following shortcomings of SLOC
• No precise definition
• Difficult to estimate at start of a project
• Only a code measure
• Programmer-dependent
• Does not consider code complexity
Software Effort Estimation Techniques

• Components are identified and

• Uses effort drivers representing • Effort of a similar and
• Overall estimate of the project
corresponding effort is
• Based on advise of knowledge
characteristics of the target completed project is used
is broken
as thedown into effort estimated. These individual
staff.
system. basis. required for component tasks.estimates are aggregated.
• Just guessing.
• Function points. • Case based and comparative.
• Uses past project data. • Applicable when no past data is
available.
Bottom-up Estimation
1. Break project into smaller and smaller
components.
2. Stop when you get to what one person
can do in one/two weeks.
3. Estimate costs for the lowest level
activities.
4. At each higher level calculate estimate
by adding estimates for lower levels.

Bottom-up for software development activity

Top-down Estimation
• Produce overall estimate using effort driver(s)
• Distribute proportions of overall estimate to components.
• Normally associated with parametric (or algorithmic) models.
Parametric Models
• Generally, have one or more formulae in the following
form

Component 1, assesses the amount of work needed to finish the task.

Component 2, assesses the rate of work at which the task can be done.
Example
• The Log-in, Log-out module of the payroll system system has been estimated to be constructed in 2
KLOC. You as a project manager has two developers i.e. D1 and D2 in your team with following
characteristics
• Development speed (development rate) of D1 = 40 days per KLOC
• Development speed (development rate) of D2 = 55 days per KLOC

D1 Days to completed the task (effort): 2 x 40 = 80 days

D2 Days to completed the task (effort): 2 x 55 = 110 days

Expert Judgement
• Asking someone who is familiar with and knowledgeable about the application
area and the technologies to provide an estimate

Particularly used when estimating the effort needed to change the existing
piece of software.

• Estimator examines the existing code to judge the proportion of code effected
and from that derive the estimate.
• Research shows that experts judgement in practice tends to be based on
analogy.
• It is supplemented by bottom-up estimation.
Estimating by Analogy
Use effort from source as
• Also called case-base reasoning. estimate
• Algorithm Source cases

1. Estimator identifies the completed projects

(source cases) with similar characteristics to Target case
the new projects (target case).
Attribute Values ???
2. Obtains the recorded efforts corresponding to
source cases and use them as base estimate.
3. Identifies the difference between the target
and source and adjust the base estimate.
Select a case with closes
attribute
Estimating by Analogy
How to select the closes case from the source cases?

Euclidean + …

Example
• Cases for Log-in, Log-out module of the payroll system system are matched on the basis of number
of inputs to and the number of outputs from the system.
The new project is known to require 7 inputs and 15 outputs.
One of the source case has 8 inputs and 17 outputs.
The Euclidian distance between the source and target case is
(7-8)2 + (17-15)2 = 2.24
Summary
• A framework for project planning to represent the following
activities has been discussed
• Establishment of project objectives.
• Analysis of characteristics of the project.
• Establishment of infrastructure consisting of appropriate
organization and set of standards, methods and tools.
• Identification of the products of the project and activities to
produce the products.
• Allocation of resources to the activities.
• Establishment of quality controls.