Estimation Techniques : Function Point Analysis (FPA)

You can't control what you can't measure.

Software practitioners are frequently challenged to provide early and accurate software
project estimates. It speaks poorly of the software community that the issue of accurate
estimating, early in the life cycle, has not been adequately addressed and standardized.

The ability to accurately estimate the time/cost taken for a project to come to its
successful conclusion has been a serious problem for software engineers. The use of
repeatable, clearly defined and well understood software development process has in
recent years shown itself to be the most effective method of gaining useful historical data
that can be used for statistical estimation. In particular, the act of sampling more
frequently, coupled with the loosening of constraints between parts of a project, has
allowed more accurate estimation and more rapid development times.

Popular methods for estimation in software engineering include:

• Parametric Estimating
• Wideband Delphi
• Cocomo
• SLIM
• SEER-SEM Parametric Estimation of Effort, Schedule, Cost, Risk (based on
Brooks Law)
• Function Point Analysis
• Proxy Based Estimation (PROBE) (from the Personal Software Process)
• The Planning Game (from Extreme Programming)
• Program Evaluation and Review Technique (PERT)
• Analysis Effort method

NOTE: Brooks' law was stated by Fred Brooks in his 1975 book The Mythical Man-
Month as "Adding manpower to a late software project makes it later." Likewise, Brooks
memorably stated "The bearing of a child takes nine months, no matter how many
women are assigned."

The value to be gained from utilizing a functional sizing technique, such as Function
Points, is primarily in the capability to accurately estimate a project early in the
development process.

In words of Wikipedia

Function Point Analysis (FPA) is an ISO recognized method to measure the functional
size of an information system. The functional size reflects the amount of functionality
that is relevant to and recognized by the user in the business. It is independent of the
technology used to implement the system.

The unit of measurement is "function points". So, FPA expresses the functional size of an
information system in a number of function points (for example: the size of a system is
314 fp's).

The functional size may be used:

• To budget application development or enhancement costs

• To budget the annual maintenance costs of the application portfolio
• To determine project productivity after completion of the project
• To determine the Software Size for cost estimating

All software applications will have numerous elementary processes or independent

processes to move data. Transactions (or elementary processes) that bring data from
outside the application domain (or application boundary) to inside that application
boundary are referred to as external inputs. Transactions (or elementary processes) that
take data from a resting position (normally on a file) to outside the application domain (or
application boundary) are referred as either an external outputs or external inquiries.
Data at rest that is maintained by the application in question is classified as internal
logical files. Data at rest that is maintained by another application in question is classified
as external interface files .

Types of Function Point Counts:

Development Project Function Point Count

Function Points can be counted at all phases of a development project from requirements
up to and including implementation. This type of count is associated with new
development work. Scope creep can be tracked and monitored by understanding the
functional size at all phase of a project. Frequently, this type of count is called a baseline
function point count.

Enhancement Project Function Point Count

It is common to enhance software after it has been placed into production. This type of
function point count tries to size enhancement projects. All production applications
evolve over time. By tracking enhancement size and associated costs a historical database
for your organization can be built. Additionally, it is important to understand how a
Development project has changed over time.

Application Function Point Count

Application counts are done on existing production applications. This “baseline count”
can be used with overall application metrics like total maintenance hours. This metric can
be used to track maintenance hours per function point. This is an example of a
normalized metric. It is not enough to examine only maintenance, but one must examine
the ratio of maintenance hours to size of the application to get a true picture.

Productivity:

The definition of productivity is the output-input ratio within a time period with due
consideration for quality.

Productivity = outputs/inputs (within a time period, quality considered)

The formula indicates that productivity can be improved by (1) by increasing outputs
with the same inputs, (2) by decreasing inputs but maintaining the same outputs, or (3) by
increasing outputs and decreasing inputs change the ratio favorably.

Software Productivity = Function Points / Inputs

Effectiveness vs. Efficiency:

Productivity implies effectiveness and efficiency in individual and organizational

performance. Effectiveness is the achievement of objectives. Efficiency is the
achievement of the ends with least amount of resources.

Software productivity is defined as hours/function points or function points/hours. This is

the average cost to develop software or the unit cost of software. One thing to keep in
mind is the unit cost of software is not fixed with size. What industry data shows is the
unit cost of software goes up with size.

Average cost is the total cost of producing a particular quantity of output divided by that
quantity. In this case to Total Cost/Function Points. Marginal cost is the change in total
cost attributable to a one-unit change in output.

There are a variety of reasons why marginal costs for software increase as size increases.
The following is a list of some of the reasons

• As size becomes larger complexity increases.

• As size becomes larger a greater number of tasks need to be completed.
• As size becomes larger there is a greater number of staff members and they
become more difficult to manage.

Function Points are the output of the software development process. Function points are
the unit of software. It is very important to understand that Function Points remain
constant regardless who develops the software or what language the software is
developed in. Unit costs need to be examined very closely. To calculate average unit cost
all items (units) are combined and divided by the total cost. On the other hand, to
accurately estimate the cost of an application each component cost needs to be estimated.
 • Determine type of function point count
• Determine the application boundary
• Identify and rate transactional function types to determine their contribution to the
unadjusted function point count.
• Identify and rate data function types to determine their contribution to the
unadjusted function point count.
• Determine the value adjustment factor (VAF)
• Calculate the adjusted function point count.

To complete a function point count knowledge of function point rules and application
documentation is needed. Access to an application expert can improve the quality of the
count. Once the application boundary has been established, FPA can be broken into three
major parts

1. FPA for transactional function types

2. FPA for data function types
3. FPA for GSCs

Rating of transactions is dependent on both information contained in the transactions and

the number of files referenced, it is recommended that transactions are counted first. At
the same time a tally should be kept of all FTR’s (file types referenced) that the
transactions reference. Every FTR must have at least one or more transactions. Each
transaction must be an elementary process. An elementary process is the smallest unit of
activity that is meaningful to the end user in the business. It must be self-contained and
leave the business in consistent state

Function Point calculation

The function point method was originaly developed by Bij Albrecht. A function point is a
rough estimate of a unit of delivered functionality of a software project. Function points
(FP) measure size in terms of the amount of functionality in a system. Function points are
computed by first calculating an unadjusted function point count (UFC). Counts are made
for the following categories

• Number of user inputs

Each user input that provides distinct application oriented data to the software is
counted.

• Number of user outputs

Each user output that provides application oriented information to the user is
counted. In this context "output" refers to reports, screens, error messages, etc.
Individual data items within a report are not counted separately.

• Number of user inquiries

 An inquiry is defined as an on-line input that results in the generation of some
immediate software response in the form of an on-line output. Each distinct
inquiry is counted.

• Number of files

Each logical master file is counted.

• Number of external interfaces

All machine-readable interfaces that are used to transmit information to another

system are counted.

Once this data has been collected, a complexity rating is associated with each
count according to Table

TABLE 1: Function point complexity weights.

Measurement parameter Weighting factor
Simple Average Complex
Number of user inputs 3 4 6
Number of user outputs 4 5 7
Number of user inquiries 3 4 6
Number of files 7 10 15
Number of external interfaces 5 7 10

Each count is multiplied by its corresponding complexity weight and the results
are summed to provide the UFC. The adjusted function point count (FP) is
calculated by multiplying the UFC by a technical complexity factor (TCF) also
referred to as Value Adjustment Factor (VAF). Components of the TCF are listed
in Table 2

Table 2. Components of the technical complexity factor.

F1 Reliable back-up and recovery F2 Data communications

F3 Distributed functions F4 Performance
F5 Heavily used configuration F6 Online data entry
F7 Operational ease F8 Online update
F9 Complex interface F10 Complex processing
F11 Reusability F12 Installation ease
F13 Multiple sites F14 Facilitate change

Alternatively the following questionaire could be utilized

1. Does the system require reliable backup and recovery?

 2. Are datacommunications required?
3. Are there distributed processing functions?
4. Is preformance critical?
5. Will the system run in an existing, heavuly utilized operational
enviroment?
6. Does the system require on-line data entry?
7. Does the on-line data entry require the input transaction to be build over
multiple screens or operations?
8. Are the master files updated online?
9. Are the input, outputs, files or inquiries complex?
10. Is the internal processing complex?
11. Is the code designed to be reusable?
12. Are conversions and installation included in the design?
13. Is the system designed for multiple installations in different organizations?
14. Is the applications designed to facilitate change and ease of use?

Each component is rated from 0 to 5, where 0 means the component has no

influence on the system and 5 means the component is essential (Pressman, 1997).
The VAF can then be calculated as:

VAF = 0.65 + (Sum of GSCs x 0.01) Where Sum of GSCs = SUM(Fi)

The factor varies from 0.65 (if each Fi is set to 0) to 1.35 (if each Fi is set to 5)
(Fenton, 1997). The final function point calculation is:

Final Adjusted FP = UFC x VAF

Convert AFP into SLOC using appropriate conversion factor.

The following calculations depends on the scenario applicable

SLOC = 16 x SLOC/AFP [NOTE: 16 is the conversion factor]

EFFORT = EAF x A x (SLOC)EX

EAF = CPLX x TOOL

A = 3.2= Constant based on the development mode.

EX = 0.38= Constant based on the development mode.

CPLX = 1.3 = Constant based on the development language.

TOOL = 1.1 = Constant based on the development Tool.

 TDEV = 2.5 x (EFFORT) EX in months

Abbreviations
AFP : Adjusted Function Point
UFP : Unadjusted Function Point
GSC : General System Characteristics
FTR : File Types Referenced
FP : Function Point
ILF : Internal Logical File.
EIF : External Interface file
EI : External Inputs
EO : External Outputs
EQ : External Enquiries
RET : Record Element Type
DET : Data Element Type
FTR : File Type Reference
GSC : General System Characteristic
VAF : Value Adjustment Factor
LOC : Line of code
EAF : Effort Adjustment Factor
SLOC : Source Lines of Code
CPLX : Development/Technical Complexity Factor
TOOL : Development/Technical Tool Complexity Factor
TDEV : Development Time