Software Effort Estimation - 2

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

Week 6, Lecture 4 Software Engineering

October 05, 2023 Management (ENSE 374)
Agenda
• Recap
• Parametric Models
• Albrecht Function Points Model
• Symons Mark II Function Points Model
• Summary
Learning Outcomes
After the lecture, students should be able to answer the following
questions
• How to calculate the function points?
• How to calculate the effort and duration for a project using
function points?
Recap: 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
Recap: Difficulties of Performing Estimation
Recap: 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.
Recap: 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
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

Various Parametric Models
Albrecht/IFPUG function points
• First suggested by Allan J. Albrecht in 1979 at IBM and further improved by
International Function Point Users Group (IFPUG.)
• Proposes a way of measuring the size of an application without counting lines
of code.
• Identifies five types of component or functionality (function points) in an
information system.
• Counts the occurrences of each type of functionality in order to get an
indication of the size of an information system
Function-point Types

EQ
 Case Study as example (assume each module generates a file)
• Over-time Calculation Module of Payroll Software
Function-point Types •

•
Module A: Log in-Log out recorder
Module B: Total overtime working hours calculator
• Module C: Public holiday checker plugin
• Module D: Overtime salary calculator

• Data is retrieved and sent to a data store• Transactions which extract and •display
• File used by the system or application. User initiated transactions which provide
• Input transactions which update internal
which is actually maintained by differentdata from internal computer files.information but do not update computer
• Refers to a group of data items that isapplication. computer files.
Generally involves creating or printing
files
usually accessed together. • For e.g., Updates madereports.
in the internal files
• For e.g., Payroll software will retrieve
• For e.g., Module A, B and C will be information about the of payroll software by an input given by • For e.g., Display total working hours for
employees from an• For e.g., Overtime salary report printed on
accessed together by Module D. the user to Log in-Log out recorder. an employee.
external data-base. a paper.
Albrecht Complexity Multipliers
Each component is classified as having either high, average or low complexity.

External user types 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

Analysts identifies each instance of each component, determine its complexity

(varies with organization) and uses the multipliers to obtain an overall FP count.
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.
Function point Calculation
Operation Component Complexity FP Count
Type
Transaction to input, amend and delete employee details. EI Medium 4
A transaction that calculates pay details from timesheet EI High 6
data that is input.
A transaction that prints out pay-to-date details for each EO Medium 5
employee
A file of payroll details for each employee. ILF Medium 10
A personnel file maintained by another system is accessed EIF Low 5
for name and address details

Total FP Count = 30 FPs (system size)

Previous projects are delivered at 5 FPs/day (productivity rate). The payroll

software should take 6 days (effort).
Determining the complexity is intuitive?
Earlier, yes but IFPUG defined rules to access it.
Number of record types Number of Data Types
<20 20-50 >50
1 Low Low Average
2 to 5 Low Average High
>5 Average High High

Case Study as example

• Enrich the Over-time Calculation Module code component of PDF with more detailed sub-
components, for example
• Module A: Log in-Log out recorder
• Module B: Total overtime working hours calculator
• Module C: Public holiday checker plugin
• Module D: Overtime salary calculator
 Calculation using IFPUG Table
Case Study as example: Payroll software has an Over-time Calculation Module which further has following sub-modules.
Their associated information is available in a logical internal file.
• Module A: Log in-Log out recorder
• Module B: Total overtime working hours calculator
• Module C: Public holiday checker plugin
• Module D: Overtime salary calculator
Number of Record Types = 4

Each sub-module maintains a separate record in the form of a file with attribute details
• Module A: Log in-Log out recorder: inTime, outTime (2 data types)
• Module B: Total overtime working hours calculator: overtime (1 data type)
• Module C: Public holiday checker plugin: day, month, year (3 data types)
• Module D: Overtime salary calculator: minWageAmount, topupWageAmount, publicHolidayWageAmount (3 data types)

Number of Records = 4
Number of Data types = 9
Component type = Logical internal file (ILF)
Obtained Complexity = Low
FP Count = 7
Function points to Lines of Code
Tables are available to convert FPs to lines of code for various languages.
Java: 53 lines of code (average) per FP
Visual C++: 34 lines of code (average) per FP

How many average lines of code should be needed to develop overtime calculation module of
payroll software system using Java programming language?

371 lines of code

Assuming, the productivity rate of 10 lines of code a day. Calculate the effort (number of days)?

3.71 days
Various Parametric Models
Function Points Mark II
• Developed by Charles R. Symons
• Builds on work by Albrecht
• Work originally for CCTA (Central Computer and Telecommunications
Agency):
• Has developed in parallel to IFPUG FPs
• A simpler method

Information processing size is initially measured in unadjusted function points

(UFPs) to which a technical complexity adjustment can then be applied (TCA).
Function Points Mark II
#entities
• For each transaction, count accessed
• Number of input data element types (N i)
• Number of input data elements types (N o)
• Number of entity types accessed (Ne)
• Wi, We and Wo are adjustment weights with
#input #output
following industry average values items
items
• Wi = .58
• Wo = 1.66
• We = .26
FP count = Ni * Wi + Ne * We + No * Wo
Summary
• Estimates are really management targets.
• Function points are more efficient method for Software
Effort Estimation than Lines of Code.
• Lines of Code can be calculated by using Function points.
However, not recommended.
• Cosmic Function Points is designed for the Embedded
Software Systems.