CSIT214/CSIT883

IT Project Management

Project cost and effort management

Project management framework
(review)
Week 6 Lab Test
Information regarding the Week 6 Lab Test:
1) Duration 1 hour 10 minutes
2) Type of questions: MCQ, Short Answer, Calculation (No software will be required)
3)For calculative questions, you will be asked to upload a file containing your work at
the end. You may upload the file in PDF, doc, jpg, png, or any other permissible
format. You may calculate on paper and upload a photo, or you may upload
a screenshot. You need to upload it within 1 hour and 10 minutes.
4) Number of Attempts 1
5) Syllabus: Week 1 to Week 5 Lectures
6)The lab test will be held during Week 6 Lab. You can attend the quiz from anywhere.
7) Venue: Moodle
8) Open Book Quiz.
8) There will be no other activities apart from Quiz.
9) Due to the holiday, for AUTM-CSIT214-WG-OC-CL/07 -2024 (Monday 10:30 Lab),
the lab test will be held during week 7 lab.
The Importance of Project Cost
Management
 IT projects have a poor track record of
meeting budget goals
◼ Cost overrun is the additional percentage or
dollar amount by which actual costs exceed
estimates
◼ A 2011 Harvard Business Review study
reported an average cost overrun of 27
percent
 The most important finding was the discovery of a
large number of gigantic overages or “black swans”;
a high-impact event that is rare and unpredictable,
but not improbable in retrospect
What Went Wrong?
 The United Kingdom’s National Health
Service IT modernization program was
called the greatest IT disaster in history
with an estimated $26 billion overrun
◼ Program had problems due to incompatible
systems, resistance from physicians, and
arguments among contractors about who’s
responsible for what
◼ Scrapped in 2011
What is Cost?
 Cost is a resource sacrificed or foregone to
achieve a specific objective or something
given up in exchange
◼ Usually measured in monetary units like
dollars that must be paid to acquire goods and
services
What is Project Cost Management?
(1 of 2)
 Project cost management includes the processes required
to ensure that the project is completed within an approved
budget
◼ Planning cost management: determining the policies,
procedures, and documentation that will be used for
planning, executing, and controlling project cost
◼ Estimating costs: developing an approximation or
estimate of the costs of the resources needed to
complete a project
◼ Determining the budget: allocating the overall cost
estimate to individual work items to establish a baseline
for measuring performance
◼ Controlling costs: controlling changes to the project
budget
Basis for successful estimating
 Information about past projects
◼ Need to collect performance details about past
project: how big were they? How much
effort/time did they need? What is the team’s
productivity?
 Need to be able to measure the amount of
work involved
◼ Traditional size measurement for software is
‘lines of code’ .

8
A taxonomy of estimating methods
 Bottom-up: activity based, analytical
 Parametric or algorithmic models (top-down)
◼ e.g. function points, COCOMO
 Expert opinion - just guessing?
 Analogy - case-based, comparative

9
Bottom-up estimating
1. Break the 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 the
estimate by adding estimates for lower
levels

10
Top-down estimates

 Produce overall
Estimate estimate using
overall 100 days
effort driver(s)
project
 Distribute
proportions of
overall estimate to
design code test components
30% 30% 40%
i.e. i.e. i.e. 40 days
30 30 days
days
11
Algorithmic/Parametric models
Number
of file types

‘system
model
size’

Numbers of input
and output transaction types

System
Estimated effort
size

Productivity factors
(from historical project data)

12
Expert judgement
 Asking someone familiar with and
knowledgeable about the application area
and the technologies to provide an
estimate
 Particularly appropriate where existing
code is to be modified (i.e. change impact
analysis)
 Research shows that an expert 's
judgement in practice tends to be based
on analogy
13
Estimating by analogy (case-based reasoning)
Use effort
source cases (i.e.
completed projects from source as
estimate
attribute values effort

attribute values effort target case

attribute values effort attribute values ?????
attribute values effort

attribute values effort

attribute values effort Select case

with closet attribute
values
14
Parametric models
We are now looking more closely at
parametric models:
1. Albrecht/IFPUG function points
2. COCOMO81 and COCOMO II

15
Albrecht/IFPUG function points
 Developed by Allan Albrecht in 1979 at IBM

 A large user group led by the International

Function Point Users Group (IFPUG
http://www.ifpug.org)

 The original function point counting

technique was refined over time. The latest
version is IPUG’s Function Point Counting
Practices Manual 4.3 (Released in 2010)
 It has become an ISO standard.
16
Albrecht/IFPUG function points - continued
 Five function types are classified into 2
groups:
◼ Data Functions:
 Internal Logical Files (ILFs): represent user-
identifiable data that is stored within your
application.
▪ E.g. Tables in relational databases, flat files.

 External Interface Files (EIFs): represent the data

that your application will use/reference but the
data is not maintained by your application.
▪ EIFs are the list of ILFs maintained by other
applications.

cont… 17
Albrecht/IFPUG function points - continued
◼ Transaction Functions:
 External Inputs (EIs): input transactions which
update ILFs.
▪ E.g. Data entry by users, data or file feeds by external
applications.
 External Outputs (EOs): transactions which extract
and display data from ILFs.
▪ E.g. Reports created by your application where the
reports include derived information (i.e. your
application needs to do some computation)
 External Queries (EQs): user initiated transactions
which provide information but do not update ILFs.
▪ E.g. Reports created by your application but the reports
do not contain any derived data. (i.e. your application
does not do any computation)

18
Albrecht/IFPUG function points - continued
 Data functions:
◼ Internal Logical Files (ILFs)
◼ External Interface Files (EIFs)

 Transactional functions:
◼ External Inputs (EIs)
◼ External Outputs (EOs)
◼ External Queries (EQs)
How to count function points
Albrecht complexity multipliers

Low complexity Medium complexity High complexity

EI 3 4 6

EO 4 5 7

EQ 3 4 6

ILF 7 10 15

EIF 5 7 10
21
Examples
Payroll application has:
 A transaction of medium complexity to input, amend and
delete employee details
◼ an EI that is rated of medium complexity
 A transaction of high complexity that calculates and
updates pay details from timesheet data that is input
◼ an EI of high complexity
 A transaction of medium complexity that computes and
prints out pay-to-date details for each employee
◼ an EO of medium complexity
 A file of payroll details for each employee (medium
complexity)
◼ assessed as of medium complexity ILF
 A simple personnel file maintained by another system is
accessed for name and address details
◼ a simple, i.e. low-complexity, EIF
22
What would be the FP counts for these?
 Low Medium High
complexity complexity complexity

FP counts EI
EO
3
4
4
5
6
7
EQ 3 4 6
ILF 7 10 15
EIF 5 7 10
1. Medium EI 4 FPs
2. High complexity EI 6 FPs
3. Medium complexity EO 5 FPs
4. Medium complexity LIF 10 FPs
5. Simple EIF 5 FPs
Total 30 FPs

 If previous projects delivered 5 FPs a day, implementing

the above should take 30/5 = 6 days

23
Albrecht/IFPUG function points
How to assess complexity?
 For data functions, the rating is based on:
◼ RET: the number of Record Element Types (i.e.
subgroup of data elements) in an ILF or EIF
 E.g. a customer file that contains Name, Address, and
so on. In addition, all the credit cards and credit card
numbers of the customer are contained in the file.
Hence, there are two RETs in the Customer File.
◼ DET: the number of Data Element Types (i.e.
unique, non-repeated field) in an ILF or EIF.
Data Element Types (DETs)
RETS
1-19 20-50 51+
1 Low Low Medium
2 to 5 Low Medium High
6 or more Medium High High
Example
 An internal logical file contains data about purchase orders.
These orders are organized into two separate record types:
the main purchase order details (including purchase order
number, supplier reference and purchase order date) and
details for each Purchase-Order-Item specified in the order
(including product code, unit price, and number ordered).

◼ What is the number of record element types for this file?

◼ What is the number of data element types?
◼ What is the function point count for this file?
 Albrecht/IFPUG function points
How to assess complexity? (cont.)
 For transactional functions, the rating is
based on:
◼ FTR: the number of File Type References (ILFs
or EIFs) in a transaction
◼ DET: the number of Data Element Types in a
transaction
Data Element Types (DETs) Data Element Types (DETs)
FTRs FTRs
1-5 6-19 20+ 1-4 5-15 16+
0-1 Low Low Medium 0-1 Low Low Medium
2-3 Low Medium High 2 Low Medium High
4 or 3 or
Medium High High Medium High High
more more
For EO and EQ For EI
Pen and paper exercise
 How many data elements (DETs) are there in this input screen?
 If this screen updates one internal logical file (ILF) , how many
function points does this screen represent?

Note:
1. This screen is used to add a new customer to an application. The OK
command button and the Next command button both add the new customer
to the database.
2. In GUI applications, a data element (DET) is information that is stored on an
internal logical file or that is used to invoke a transaction
Pen and paper exercise
 Application A receives input from running a batch input file. The
batch file is one physical file but contains many different types of
records. The first field is a record identifier number. The record
identifier number can range from 1-75. The second field describes
if the record is new and adds to the file, changes a previous
batch input or a deletes a previous batch input (add, change and
delete).
Depending on the record identifier number there is a
unique set of data elements, a different set of files are
updated and referenced, and different processing logic is
followed.
Every single record identifier number updates more than 3 files
(has more than 3 FTRs) and contains more than 5 data elements.

How many function points does this one batch input represent?
How to count function points
Determine Value Adjustment Factor

 Previously, we have computed the UFP (Unadjusted Function

Points)
 The last step involves assessing the environment and
processing complexity of the application as a whole.
 In this step, the impact of 14 general system characteristics is
rated on a scale from 0 to 5 in terms of their likely effect on
the project or application
Determine Value Adjustment Factor
General System Characteristic Brief Description
1. Data communications How many communication facilities are there to aid in the transfer or
exchange of information with the application or system?

2. Distributed data processing How are distributed data and processing functions handled?

3. Performance Did the user require response time or throughput?

4. Heavily used configuration How heavily used is the current hardware platform where the application
will be executed?
5. Transaction rate How frequently are transactions executed daily, weekly, monthly, etc.?

6. On-Line data entry What percentage of the information is entered On-Line?

7. End-user efficiency Was the application designed for end-user efficiency?

8. On-Line update How many ILF’s are updated by On-Line transaction?

9. Complex processing Does the application have extensive logical or mathematical processing?

10. Reusability Was the application developed to meet one or many user’s needs?

11. Installation ease How difficult is conversion and installation?

12. Operational ease How effective and/or automated are start-up, back up, and recovery
procedures?
13. Multiple sites Was the application specifically designed, developed, and supported to
be installed at multiple sites for multiple organizations?

14. Facilitate change Was the application specifically designed, developed, and supported to
facilitate change?
Determine Value Adjustment Factor (VAF)
 The calculation of VAF is based on the TDI
(Total Degree of Influence of the 14
General system characteristics)
◼ TDI = Sum of (DI of 14 General System
Characteristics) where DI stands for Degree of
Influence.
◼ VAF = 0.65 + (0.01 * TDI)
 Finally, the Adjusted Function Points or
Function Points are
◼ FP = UFP * VAF
 where UFP is Unadjusted Function Points.
Example

Note: Average = Medium

 VAF = 52 * 0.01 + 0.65

= 1.17
 FP = 318 x 1.17
= 372
Pen and paper exercise
1. What is the value adjustment factor if all of the general system
characteristics scored a value of 5 (strong influence)?
2. An application has a base unadjusted function point count of
500, a value adjustment factor of 1.10. What is the adjusted
function point count?
3. An application has the following: 10 Low External Inputs, 12
High External Outputs, 20 Low Internal Logical Files, 15 High
External Interface Files, 12 Medium External Queries, and a
value adjustment factor of 1.10.
◼ What is the unadjusted function point count?
◼ What is the adjusted function point count?
Constructive Cost Model
(COCOMO)
 Developed by Barry Boehm first in 1981
(COCOMO 81).
◼ Latest version is COCOMO II (published in 2000)
 Basic model
effort = c x sizek
◼ c and k depend on the type of system: organic,
semi-detached, embedded
◼ Size is measured in KLOC (i.e. thousands of
lines of code)
◼ Effort is measured in person-months

36
Further source: Barry Boehm et al. Software estimation with COCOMO II, Prentice-Hall 2002
 The COCOMO constants
System type c k
Organic (broadly, information 2.4 1.05
systems)
Semi-detached 3.0 1.12
Embedded (broadly, real- 3.6 1.20
time)

 Organic: a small team develops a small system with flexible

requirements in a highly familiar in-house environment
 Embedded: the system has to operate within very tight constraints
and changes to the system very costly.
 Semi-detached: This combines elements of the organic and the
embedded types or has characteristics that came between the two.
Example: what is the estimated effort of developing an organic system
with 50,000 lines of code? 37

effort = c x sizek
COCOMO II
An updated version of COCOMO:
 There are different COCOMO II models for
estimating at the ‘early design’ stage and the
‘post architecture’ stage when the final system is
implemented. We’ll look specifically at the first.
 The core model is:
pm = A(size)(sf) ×(em1) ×(em2) ×(em3)….
where:
pm = person months,
A is 2.94,
size is number of thousands of lines of code,
sf is the scale factor, and 38
em is an effort multiplier
COCOMO II Scale factor
Based on five factors which appear to be particularly sensitive to
system size
1. Precedentedness (PREC): degree to which there are past
examples that can be consulted
2. Development flexibility (FLEX): degree of flexibility that
exists when implementing the project
3. Architecture/risk resolution (RESL): degree of uncertainty
about requirements
4. Team cohesion (TEAM): degree to which there is a large
dispersed team (e.g. in different locations) as opposed to
there being a small tightly knit team.
5. Process maturity (PMAT): degree to how structured and
organized the way the software is produced.

39
 COCOMO II Scale factor values

Driver Very Low Nominal High Very Extra

low high high

PREC 6.20 4.96 3.72 2.48 1.24 0.00

FLEX 5.07 4.05 3.04 2.03 1.01 0.00

RESL 7.07 5.65 4.24 2.83 1.41 0.00

TEAM 5.48 4.38 3.29 2.19 1.10 0.00

PMAT 7.80 6.24 4.68 3.12 1.56 0.00 40

Example of scale factor

 A software development team is developing an

application which is very similar to previous ones
it has developed.
◼ PREC is very high (score 1.24).
 A very precise software engineering document
lays down very strict requirements.
◼ FLEX is very low (score 5.07).
 The good news is that these tight requirements
are unlikely to change
◼ RESL is high with a score 2.83.
 The team is tightly knit
◼ TEAM has high score of 2.19
 Processes are informal
41
◼ So PMAT is low and scores 6.24
Scale factor calculation
The formula for sf is
sf = B + 0.01 × Σ scale factor values

E.g. sf = 0.91 +0.01 × (1.24 + 5.07 + 2.83 + 2.19 + 6.24)

= 1.0857

If system contained 10 KLOC then

Estimated Effort = 2.94 x 101.0857
= 35.8 person months

42
Effort multipliers
As well as the scale factor effort multipliers
are also assessed:
RCPX Product reliability and complexity
RUSE Reuse required
PDIF Platform difficulty
PERS Personnel capability
FCIL Facilities available
SCED Schedule pressure

43
 Effort multipliers
Extra Very low Low Nominal High Very Extra
low high high
RCPX 0.49 0.60 0.83 1.00 1.33 1.91 2.72

RUSE 0.95 1.00 1.07 1.15 1.24

PDIF 0.87 1.00 1.29 1.81 2.61

PERS 2.12 1.62 1.26 1.00 0.83 0.63 0.50

PREX 1.59 1.33 1.12 1.00 0.87 0.74 0.62

FCIL 1.43 1.30 1.10 1.00 0.87 0.73 0.62

SCED 1.43 1.14 1.00 1.00 1.00

44
Example
 Say that a new project is similar in most characteristics to
those that an organization has been dealing for some time
 except
◼ the software to be produced is exceptionally complex
and will be used in a safety critical system.
 Product reliability and complexity (RCPX) is very high.
◼ the software will interface with a new operating system
that is currently in beta status.
 Platform difficulty (PDIF) is very high
◼ to deal with this the team allocated to the job are
regarded as exceptionally good, but do not have a lot of
experience on this type of software.
 Personnel experience (PREX) is ranked nominal.
 Personal capability (PERS) is ranked extra high.

45
Example -continued
RCPX very high 1.91
PDIF very high 1.81
PERS extra high 0.50
PREX nominal 1.00
All other factors are nominal

Say unadjusted estimate is 35.8 person months

With effort multipliers this becomes

Adjusted Estimated Effort = 35.8 x 1.91 x 1.81 x 0.5
= 61.9 person months

46
Pen and paper exercise
A new project has “average” novelty for the software supplier
that is going to execute it and is thus given a nominal rating on
this account for precedentedness. Development flexibility is
high, but requirements may change radically and so the risk
resolution exponent is rated very low. The development team
area all located in the same office and this leads to team
cohesion being rated as very high. The software company as a
whole tends to be very informal in its standards and procedures,
and the process maturity driver has therefore been given a
rating of low.
 What would be the scale factor (sf) in this case?
 What would be the (unadjusted) estimate of effort of the size
of the application was estimated as around 2000 lines of
code?