Software Estimation

► There is always a need to estimate resources, cost, and schedule in

software projects
► Estimation requires experience & access to good historical data
► Estimation is risky and uncertain
► Estimation success is dependent on:-
► Project complexity
► Project size
► Clarity of requirements, clearly defined scope
► Availability of historical data from past projects
► Nature of methodology (traditional versus agile- iterative)
 Some Cues in Estimation
Here are some suggested measures to get a more correct estimate
i. Delay estimation until late in the project (may not be practical)
ii. Base estimates on similar projects that have already been
completed (works well if the customer, business conditions, the
software engineering environment, deadlines are similar).
iii. Use relatively simple decomposition techniques to generate project
cost and effort estimates.
iv. Use one or more empirical models for software cost and effort
estimation
Conventional Methods

► Mostly used are LOC/FP

► LOC/FP are computed using information domain values
► Both use historical data to build estimates for the project
LOC/KLOC
► LOC: lines of code; KLOC: kilo lines of cone
► Most accurate estimate to measure labour costs
► But:
► How do we deal with comments or blank lines
► How do you compare low-level language with high-level
language LOCs?
► How can you know in advance the number of LOC?
► How do you handle code reuse
Function Oriented Metrics
► Mainly used in business applications
► Focus on system functionality
► Combine a measure of the information domain with domain
complexity
► Common Examples:
► Function points (we discuss this)
► Feature points
 Function Point Analysis(FPA)
► Focuses on the functionality and complexity of the application
► Independent of the Technology
► Avoids the problem of different programming languages or
technology platforms
► FP analysis is reliable in the sense that two developers
trained in FP analysis will obtain the same results within an
acceptable margin of error
► Breaks a system into its functional components

6
 Function Point Analysis
► A FPA is done at project onset based on the project’s scope followed by a
more detailed analysis during the analysis and design stage
► FPA can also be done to evaluate the functionality of an off the shelf
package.
► FPA is based on an evaluation of five primary elements that define the
application boundary
► The elements are:-
► Inputs
► Outputs
► Enquiries
► Logical Files
► Interfaces
(These 5 elements can be determined from DFDs & Use case diagrams)
7
The Application Boundary for Function Point Analysis

Elements of FPA

User

Other
Apps

FPA success is heavily dependent on a good understanding

8

of user requirements
Function Point Analysis – Defining the
elements
I. Data Function Types
i. Internal Logical File (ILF) – AN ILF is a file that stores data within the
application boundary.
► For example, each entity in an E-R diagram would be considered
an ILF. The complexity of an ILF can be classified as low, average,
or high based on the number of data elements and subgroups
(subclasses) of data elements maintained by the ILF.
► ILFs with fewer data elements (attributes) and subgroups will be
less complex than lLFs with more data elements and subgroups.

ii. External interface file (EIF)——An EIF is similar to an ILF; however,

an EIF is a file maintained by another application system. The
complexity of an EIF is determined using the same criteria used for an
ILF.
9
 Function Point Analysis Elements
II. Transactional Types
iii. External input (EIF)—An El refers to transactional data that originate
outside the application and cross the application boundary from outside to
inside. The data generally are added, deleted, or updated in one or more files
internal to the application (i.e., internal logical files).
► A common example of an EI would be an input screen.
► Data can, however, pass through the application boundary from other
applications.
► Based on its complexity, in terms of the number of internal files
referenced, number of data elements (i.e., fields) included, and any
other human factors, each EI is classified as low, average, or high.

iv. External output (EO)—Similarly, an EO is a transaction that allows data to

exit the application boundary.
► Examples of EOs include reports, confirmation messages, derived or
calculated totals, and graphs or charts. This data could go to screens,
printers, or other applications. After the number of EOs are counted,
they are rated based on their complexity, like the external inputs
10 (El).
 Function Point Analysis
Elements
Transactional Types ct’d
v. External inquiry (EQ)——An EQ is a process or transaction that
includes a combination of inputs and outputs for retrieving data from
either the internal files or from files external to the application.
► EQs do not update or change any data stored in a file. They only
read this information.
► Queries with different processing logic or a different input or
output format are counted as a single EQ. Once the EQs are
identified, they are classified based on their complexity as low,
average or high, according to the number of files referenced and
number of data elements included in the query

11
 Conducting an FPA - Steps
1. Determine the function type count to be conducted; can be:-
► Development –new system from scratch,
► Enhancement- maintenance of a system or
► Application – inventory of an existing system or off the shelf
system.

2. Define the boundary of the application- identify system scope using

DFDs and Use case diagrams.

3. Define all data functions and their degree of complexity-i.e. identify

the data to be updated and queried by the system.
Data functions are ILFs & ELFs
Define their complexity based on their record types (subclass) (RETs) &
fields (DETs) 12
Determining ILFs & ELFs Complexity

Record

Field

Example complexity rating of a

record type Student.
There are 2 RETs & 6 DETs,
therefore complexity is Low from
Table A2
13
 FPA steps ct’d
4. Define all transactional functions and their complexity.
These perform data processing;
► Can be EIs, EOs, or EQs
► EIs control data originating externally, their complexity is given
by the number of file types referenced and the DETs in the files
(refer to Table A3)
► EOs perform data output, complexity determined as EIs
complexity using Table A4
► EQs update, retrieve or query the data in ILFs & ELFs
Determine complexity using Table A5

14

Table A5: EQ Complexity

 FPA Steps ct’d
5. Calculate the Unadjusted Function Point Count using table.

15
FPA Steps ct’d
6. Calculate the Value Adjustment Factor based on a set of General System
Characteristics. Assuming shown values for degree of influence, TDI is
computed as sum of degrees of influence

0 = not present/no
influence
1 = incidental influence
2 = moderate influence
3 = average influence
4 = significant influence
5 = strong influence

16
 FPA Steps

► 7. Calculate the final Adjusted Function Point Count

Adjusted Function Point = VAF * UAF
Gives the FP count
This can be used to give the SLOC based on programming
language to be used.
For an FP = 210 we have

17
 Function Point Analysis Example
► Suppose the following elements & their properties have been
determined after reviewing an application system:-

► ILF: 3 low, 2 average and 1 complex

► ELF: 2 average
► EI: 3 low, 5 average and 4 complex
► EO: 4 low, 2 average and 1 complex
► EQ: 2 low, 5 average and 3 complex
► Unadjusted function points can be computed using the table:
Low Average High Total
ILF 3* 7 = 21 2* 10 = 20 1 * 15 = 15 56
ELF 0*5=0 2 * 7= 14 0 * 10 = 0 14
EI 3*3=9 5* 4 = 20 4 * 6 = 24 53
EO 4 * 4 = 16 2 * 5 = 10 1*7=7 33
EQ 2*3=6 5* 4 = 20 3 * 6 = 18 44
18
UFP Sum of all computations 200
 Computing the Value Adjustment Factor
► (VAF)
The next step is to compute a Value Adjustment Factor (VAF)
► It is based on the Degrees of Influence (DI), often called Processing
Complexity Adjustment (PCA)
► Derived from the 14 General Systems Characteristics (GSC), use MS Word
Insert for this
► To determine the total DI, each GSC is rated based on the following
0 = not present or no influence
1 = incidental influence
2 = moderate influence
3 = average influence
4 = significant influence
5 = strong influence 19
Computing TDI & VAF Assuming characteristics given
General System Characteristic Degree of Influence
Data Communications 3

Distributed Data Processing 2

4
Performance
Heavily Used Configuration 3
3
Transaction Rate
4
On-line Data Entry
4
End User Efficiency
3
Online Update
Complex Processing 3
2
Reusability
Installation Ease 3
Operational Ease 3
Multiple Sites 1
Facilitate Change 2
Total Degrees of Influence 40
Value Adjustment Factor VAF = (40 * .01) + .65 =
VAF = (TDI * 0.01) + .65 1.05
20

Total Adjusted Function Points = FP = UAF * VAF FP = 200 * 1.05 = 210

 Function Point Analysis
► After reviewing the application, the Total Adjusted Function
Points (TAFP) is computed to be 210. (TAFP = UAF + VAF)

► That number can be transformed into development estimates

► Productivity – how many function points can a programmer
produce in a given period of time
► Can be based on lessons learned from prior project
experience
► LOC – convert function points into lines of code based on the
programming language
► Accuracy not high due to individual programming styles but
can be used to create a FP inventory of an organization’s
project portfolio

21