Welcome

ICT Project
Management

_________________________________________
@ 2024 FTVT Institute All Rights Reserved

OF/FTI/ALL /18 Issue No: 1

PPT 1
 Chapter Four
Project Estimation

2
 Content
Introduction
Estimation Techniques
Metrics for Software Project Size Estimation
COCOMO-parametric Model

3
 Introduction
Estimation is attempt to determine how much money,
effort, resources & time it will take to build a specific project.
Effective software project estimation is one of the most
challenging and important activities in project development.
Proper project planning and control is not possible without a
sound and reliable estimate.
Under-estimating a project leads to under-staffing
 resulting in staff burnout

4
 Introduction(cont’d)
Setting too short a schedule
 resulting in loss of credibility as deadlines are missed.

Over-estimating a project can be just about as bad for the

organization.
 The project is then likely to cost more than it should
 Take longer to deliver than necessary
 resulting in lost opportunities and
 Delay the use of your resources on the next project

5
 Introduction(cont’d)
 Estimation includes:
 Project size: What will be problem complexity in terms of the effort
and time required to develop the product?
 Cost: How much is it going to cost to develop the project?
 Duration: How long is it going to take to complete development?
 Effort: How much effort would be required?(the amount of work done
to complete a task)

6
 Estimation Techniques
 Estimation of various project parameters is a basic project
planning activity.
 The important project parameters that are estimated include:
project size, effort required to develop the software, project
duration, and cost.
 These estimates not only help in quoting the project cost to the
customer, but are also useful in resource planning and
scheduling.
 There are several estimation techniques:
 Guesstimating
 Analogy
 top-down
 bottom-up
7
Estimation Tools and Techniques
 3 basic tools and techniques for cost estimates:
 analogous or top-down: use the actual cost of a
previous, similar project as the basis for the new estimate.
 If past projects show it costs $12,000 to fully equip and
configure a branch with network, and you're rolling out to
10 branches: Estimated Cost = 10 branches ×
$12,000/branch = $120,000

 Last year, your team developed an internal HR web portal

for $120,000. Now you're planning a similar portal for the
finance department with comparable features and
complexity. Based on the past project, you estimate the
new one will cost around $125,000, allowing for slight
adjustments.
8
Estimation Tools and Techniques
 bottom-up: Breaks the project down into individual tasks or
components, estimates each one, then adds them up.
 Example: You're building a new mobile app and break it down like
this:
 Requirements gathering: $8,000
 UI/UX design: $12,000
 Frontend development: $25,000
 Backend development: $30,000
 Testing and QA: $10,000
 Total estimate: $85,000

parametric: use project characteristics in a mathematical

model to estimate costs.

9
 Metrics for Project Size Estimation

Currently two metrics are popularly being used widely to

estimate size:
 lines of code (LOC),
 function point (FP) and

LOC: LOC measures the size of a software system based on the

number of lines of code written.
 The simplest. It is also the most controversial.
 Using this metric, the project size is estimated by counting the
number of source instructions in the developed program.
 While counting the number of source instructions, lines used for
commenting the code and the header lines should be ignored.
 In order to estimate the LOC count at the beginning of a project,
project managers usually divide the problem into modules, and each
module into submodules and so on, until the sizes of the different
leaf-level modules can be approximately predicted. 10
 Cont’d
Shortcomings of LOC
 LOC gives a numerical value of problem size that can vary widely
with individual coding style
 It should consider the local effort needed to specify, design, code,
test, etc. and not just the coding effort.
 It is very difficult to accurately estimate LOC in the final product
from the problem specification.
 could encourage programmers to write inefficient code, especially
when LOC are used as a productivity metric.

11
 Function Point(FP)
 Function point metric was proposed by Albrecht in 1979.
 Function Points measure the size of a software system based on
the functionality it delivers to the user, not the lines of code. It
evaluates the system by looking at its functional components, such as
inputs, outputs, user interactions, data files, and internal processes.
 Function points are a synthetic metric, similar to ones used every
day, such as hours, kilos, tons, degrees Celsius, and so on.
 Function points focus on the functionality and complexity of an
application system or a particular module.
 E.g. as a 20-degree Celsius day is warmer than a 10-degree
Celsius day, a 1,000-function point application is larger and more
complex than a 500-function point application
 The conceptual idea behind the function point metric is that the size of
a software product is directly dependent on the number of different
functions or features it supports. 12
 FP(cont’d)
Each function when invoked reads some input data and
transforms it to the corresponding output data.
The computation of the number of input and the output data
values to a system gives some indication of the number of
functions supported by the system.
Albrecht postulated that in addition to the number of basic
functions that a software performs, the size is also dependent
on the number of files and the number of interfaces.

13
 FP(cont’d)
 Function point analysis is based on an evaluation of five data and
transactional types that define the application boundary:
 Internal logical file (ILF) - is a logical file that stores data within the
application boundary
 External interface file (EIF) — An EIF is similar to an ILF; however, an EIF
is a file maintained by another application system.
 External input (EI) — refers to processes or transactional data that originate
outside the application and cross the application boundary from outside to
inside.
 External output (EO) — is a process or transaction that allows data to exit
the application boundary. E.g. reports, confirmation messages, derived or
calculated totals, and graphs or charts.
 External inquiry (EQ) — It is the number of distinct interactive queries which
can be made by the users.
 Inquiries are user commands such as print-account-balance
 EQs do not update or change any data stored in a file. They only read this
information.
 Complexity level of each parameter is graded as low, average and high.
14
FP(cont’d)

The Application Boundary for Function Point Analysis

15
 FP(cont’d)
The weight for the different parameter can be
compute based on the following table:

Function Units Weighting Factors

Low Average High
External Input 3 4 6
External Output 4 5 7
External Inquiries 3 4 6
Internal Logical Files 7 10 15
External Interface Files 5 7 10

Function point is computed in two steps. The first step

is to compute the unadjusted function point (UFP).

16
 FP(cont’d)
 Example Let’s say that after reviewing an application system, the
following was determined:
 ILF: 3 Low, 2 Average, 1 Complex
 EIF: 2 Average
 EI: 3 Low, 5 Average, 4 Complex
 EO: 4 Low, 2 Average, 1 Complex
 EQ: 2 Low, 5 Average, 3 Complex
First step: Calculate an unadjusted function point (UAF)
 Once all of the ILFs, EIFs, EIs, EOs, and EQs, are counted and
their relative complexities rated, an unadjusted function point
(UAF) count is determined.

17
 FP(cont’d)
Second step: compute a Value Adjustment Factor
(VAF). It is based on the Degrees of Influence (DI),
often called the Processing Complexity Adjustment
(PCA), and is derived from the fourteen General
Systems Characteristics (GSC)
FP= UFP * VAF
Where VAF is a complexity adjustment factor and is
equal to [0.65+0.01*∑Fi].
The Fi (i=1 to 14) are the degree of influence and are
based on responses to questions.

18
GSC and Total Adjusted Function Point

DI Rate

19
Why we use FP?
Function point count can be used to:
 Estimate productivity – number of function points that a
programmer can produce in a given amount of time, such as in
a day, a week, or a month.
 Convert to LOC. Conversion factor for some programming
languages are indicated on table below

20
 Example
 Consider a project with the following parameters:
i. External Inputs: 10 with low complexity, 15 with average complexity
and 17 with high complexity.
ii. External Output: 6 with low complexity and 13 with high complexity.
iii. External Inquiries: 3 with low complexity, 4 with average complexity.
and 2 with high complexity.
iv. Internal Logical Files: 2 with average complexity and 1 with high
complexity.
v. External Interface Files: 9 with low complexity.
 In addition to above, the system requires:
i. Significant data communication
ii. Performance is very significant
iii. Designed code may be moderately reusable
iv. System is not designed for multiple installation in different
organizations
v. Other adjustment factors are treated as average.
 Compute the function points for the project.
21
Cont’d

22
 Cont’d

23
 COCOMO (COnstructive COst MOdel)
 Introduced in 1981 by Barry Boehm
 COCOMO is a project cost estimation model that is used to estimate the
effort, time, and cost required to develop a software project.
 Based on LOC estimates, it is used to estimate cost, effort, and
schedule
 COCOMO is a parametric model
 Parametric estimating uses project characteristics (parameters) in a
mathematical model to estimate project costs
 E.g. a parametric model might provide an estimate of $50 per line of code
for a software development project based on the programming language
the project is using, the level of expertise of the programmers, the size and
complexity of the data involved, and so on.
 In COCOMO, projects are categorized into three types:
 Organic project
 Embedded projects
 Semi-detached projects 24
 COCOMO(cont’d)
 Organic projects:
 These are routine projects where the technology, processes, and
people are expected all to work together smoothly. One may view
these types of projects as the easy projects, where few problems are
expected.
 Small, simple software developed by a small team with good
experience, working in a familiar environment.
 Example: Building a basic employee attendance tracking system for
your own company using familiar tools and methods.
 Embedded projects:
 a challenging project. The people may be less experienced, and the
processes and technology may be less mature.
 Complex, high-risk software that must operate within tight constraints, often
tied to hardware or real-time systems.
 Example: Creating software for a medical device or aircraft control system
where safety, speed, and accuracy are critical.

25
 COCOMO(cont’d)
Semi-detached projects:
 These projects may not be simple and straightforward, but the
organization feels confident that its processes, people, and
technology in place are adequate to meet the challenge.
 Team members may have limited experience on related systems
but may be unfamiliar with some aspects of the system being
developed.
 Medium-sized projects with a mix of experienced and less
experienced team members, and some complexity or unfamiliar
parts.
 Example: Developing a web-based customer service portal that integrates
with an existing Customer Relationship Management system system and
requires learning a new web framework.

26
Summary of Project Types and Their Characteristics:

27
 COCOMO(cont’d)
 For the three classes of software products, the formulas for
estimating the effort based on the code size are shown below:
 Organic: Person-Months = 2.4 × KDSI1.05 PM
 Semi-Detached: Person-Months = 3.0 × KDSI1.12 PM
 Embedded: Person-Months = 3.6 × KDSI1.20 PM
 Where:
 KDSI = Thousands of delivered source instructions, i.e., LOC
 PM -A person-month can be thought of as a one-month effort by one
person; 1 PM = 152 hours

 Estimation of development time(Total Development time or

TDEV)
 Organic: Duration= 2.5(Effort)0.38 Months
 Semi-detached: Duration= 2.5(Effort)0.35 Months
 Embedded: Duration= 2.5(Effort)0.32 Months
 People Required = Effort ÷ Duration
28
 COCOMO: Example
 Suppose that a project was estimated to be 400 KLOC.
Calculate the effort and development time for
semidetached project.
 Effort Duration
= 3.0 * KDSI1.12 =2.5 * Effort0.35
= 3.0 * 4001.12 =2.5 * 2462.790.35
= 2462.79 PM = 38.45 M
 People Required: Effort/Duration
= 2462.79/38.45
= 64.05
What will be the effort for organic and embedded
projects?
29
 Automated Estimating Tools
Some of the automated tools available include:
 COCOMO II http://softwarecost.org/tools/COCOMO/
 SLIM
 CHECKPOINT
 Knowledge Plan

30
 Assignment one
Suppose that a project was estimated to be 500 KLOC.
Calculate the effort and development time for
 Organic project
 Embedded projects
 Semi-detached projects

Let's assume a project is estimated to have 32,000 lines of

code (LOC)
 Organic project
 Embedded projects
 Semi-detached projects

31
 Earned Value Management (EVM)
Earned Value Management (EVM) is a project performance
measurement technique that integrates scope, time, and
cost data to evaluate project progress and performance.
It allows project managers to objectively assess how much
work has been completed, whether the project is on
schedule and within budget, and to forecast future
performance trends.
EVM helps project managers track performance and
progress using three key data points. Planned Value (PV)
,Earned Value (EV) and Actual Cost (AC) it answers:
Are we ahead or behind schedule?
Are we under or over budget?

32
 Core Concepts and Terminology

 EVM revolves around a few key performance metrics. These are:

 Planned Value (PV) – Also known as Budgeted Cost of Work Scheduled
(BCWS). It represents the estimated value of the work planned to be
done at a specific point in time.
 Earned Value (EV) – Also known as Budgeted Cost of Work Performed
(BCWP). It is the value of the actual work completed at a point in time,
based on the original budget.
 Actual Cost (AC) – Also known as Actual Cost of Work Performed
(ACWP). This is the real cost incurred for the work performed.

33
 Earned Value Management

Term Meaning Formula

Budgeted cost of work
PV = % Planned × Total
PV (Planned Value) planned to be done by
Budget
now

Budgeted cost of work EV = % Completed ×

EV (Earned Value)
actually done Total Budget
Actual cost spent for the (Given directly from
AC (Actual Cost)
work performed records)
BAC (Budget at Total approved project
(Given at the start)
Completion) budget

34
Earned Value Formulas

35
 Earned Value Formulas
Formula Description Interpretation

Cost Variance (CV) = EV - Shows if you're over or under Positive = under budget;
AC budget Negative = over budget

Schedule Variance (SV) = Shows if you're ahead or Positive = ahead of schedule;

EV - PV behind schedule Negative = behind

Cost Performance Index

Cost efficiency of the project CPI > 1 is good
(CPI) = EV / AC

Schedule Performance SPI > 1 means ahead of

Schedule efficiency
Index (SPI) = EV / PV schedule

Estimate at Completion Forecasted total cost of the Lower EAC = more efficient
(EAC) = BAC / CPI project spending

Variance at Completion Expected cost variance at the

Positive = under budget
(VAC) = BAC - EAC end

36
 Hands-On Example
Scenario:
Total project budget (BAC) = birr 100,000
Planned Value (PV) at Month 3 = birr 60,000
Earned Value (EV) at Month 3 = birr 50,000
Actual Cost (AC) at Month 3 = birr 55,000

37
 Hands-On Example
 CV = EV - AC = 50,000 - 55,000 = -5,000 birr
→ Interpretation: Over budget by birr 5,000
 SV = EV - PV = 50,000 - 60,000 = -10,000 birr
→ Interpretation: Behind schedule by birr 10,000
 CPI = EV / AC = 50,000 / 55,000 ≈ 0.91
→ Interpretation: Getting only birr 0.91 of value per birr 1 spent
 SPI = EV / PV = 50,000 / 60,000 ≈ 0.83
→ Interpretation: Only 83% of scheduled work is complete
 EAC = BAC / CPI = 100,000 / 0.91 ≈ birr 109,890
→ Interpretation: Project will likely cost ~birr 109,890
 VAC = BAC - EAC = 100,000 - 109,890 = -birr 9,890
→ Interpretation: Expecting a cost overrun of nearly birr 10k

38
Rules of Thumb for Earned Value Numbers

Negative numbers for cost and schedule variance

indicate problems in those areas. The project is
costing more than planned or taking longer than
planned
Cost performance index (CPI) and schedule
performance index (SPI) less than 100% indicate
problems

39
Class Exercise: Earned Value Management Analysis

Project Scenario
You are managing a 6-month project with the following
details:
Total Budget (BAC) = Birr 120,000
You are now at the end of Month 3 (midpoint of the
project).
According to the original plan, by now you should have
completed 60% of the work.
In reality, only 50% of the work has been completed.
The Actual Cost so far is Birr 70,000.

40
 Class Exercise: Earned Value Management
Analysis
Based on the data provided, calculate the following EVM metrics:
1.Planned Value (PV)
2.Earned Value (EV)
3.Cost Variance (CV)
4.Schedule Variance (SV)
5.Cost Performance Index (CPI)
6.Schedule Performance Index (SPI)
7.Estimate at Completion (EAC)
8.Variance at Completion (VAC)

Then, answer these two questions:

•What do these values tell you about the current state of the project?
•What actions would you recommend as the project manager?

41
 Answer Key
Let’s compute step-by-step:
Planned Value (PV) = 60% × $120,000 = $72,000
Earned Value (EV) = 50% × $120,000 = $60,000
Actual Cost (AC) = $70,000

42
 Answer Key
Metric Formula Calculation Result
CV EV - AC 60,000 - 70,000 –10,000 birr (Over budget)

SV EV - PV 60,000 - 72,000 –12,000 birr (Behind schedule)

CPI EV / AC 60,000 / 70,000 0.857 (Cost inefficiency)

SPI EV / PV 60,000 / 72,000 0.833 (Schedule inefficiency)
EAC BAC / CPI 120,000 / 0.857 ~birr 140,047

–birr 20,047 (Forecasted

VAC BAC - EAC 120,000 - 140,047
overrun)

Discussion Questions (Group or Class-Wide)

•What does a CPI < 1 and SPI < 1 tell us?
•Is the project in trouble? What are your top 2 recommendations to fix this?

43