An Introduction to Function Point Analysis

An Introduction to Function Point Analysis
by Roger Heller

The purpose of this article is to provide an introduction to FunctionPoint Analysis and its application in non-traditional computingsituations. Software engineers have been searching for a metric that isapplicable for a broad range of software environments. The metric shouldbe technology independent and support the need for estimating, projectmanagement, measuring quality and gathering requirements. Function PointAnalysis is rapidly becoming the measure of choice for these tasks.

Function Point Analysis has been proven as a reliable method formeasuring the size of computer software. In addition to measuringoutput, Function Point Analysis is extremely useful in estimatingprojects, managing change of scope, measuring productivity, andcommunicating functional requirements.

There have been many misconceptions regarding the appropriateness ofFunction Point Analysis in evaluating emerging environments such as realtime embedded code and Object Oriented programming. Since functionpoints express the resulting work-product in terms of functionality asseen from the user's perspective, the tools and technologies used todeliver it are independent.

The following provides an introduction to Function Point Analysis and is followed by further discussion of potential benefits.

Introduction to Function Point Analysis
One of the initial design criteria for function points was to provide amechanism that both software developers and users could utilize todefine functional requirements. It was determined that the best way togain an understanding of the users' needs was to approach their problemfrom the perspective of how they view the results an automated systemproduces. Therefore, one of the primary goals of Function Point Analysisis to evaluate a system's capabilities from a user's point of view. Toachieve this goal, the analysis is based upon the various ways usersinteract with computerized systems. From a user's perspective a systemassists them in doing their job by providing five (5) basic functions.Two of these address the data requirements of an end user and arereferred to as Data Functions. The remaining three address the user'sneed to access data and are referred to as Transactional Functions.

The Five Components of Function Points

Data Functions

• Internal Logical Files
• External Interface Files

Transactional Functions

• External Inputs
• External Outputs
• External Inquiries

Internal Logical Files - The first data functionallows users to utilize data they are responsible for maintaining. Forexample, a pilot may enter navigational data through a display in thecockpit prior to departure. The data is stored in a file for use and canbe modified during the mission. Therefore the pilot is responsible formaintaining the file that contains the navigational information. Logicalgroupings of data in a system, maintained by an end user, are referredto as Internal Logical Files (ILF).

External Interface Files - The second Data Function asystem provides an end user is also related to logical groupings ofdata. In this case the user is not responsible for maintaining the data.The data resides in another system and is maintained by another user orsystem. The user of the system being counted requires this data forreference purposes only. For example, it may be necessary for a pilot toreference position data from a satellite or ground-based facilityduring flight. The pilot does not have the responsibility for updatingdata at these sites but must reference it during the flight. Groupingsof data from another system that are used only for reference purposesare defined as External Interface Files (EIF).

The remaining functions address the user's capability to access the datacontained in ILFs and EIFs. This capability includes maintaining,inquiring and outputting of data. These are referred to as TransactionalFunctions.

External Input - The first Transactional Functionallows a user to maintain Internal Logical Files (ILFs) through theability to add, change and delete the data. For example, a pilot canadd, change and delete navigational information prior to and during themission. In this case the pilot is utilizing a transaction referred toas an External Input (EI). An External Input gives the user thecapability to maintain the data in ILF's through adding, changing anddeleting its contents.

External Output - The next Transactional Functiongives the user the ability to produce outputs. For example a pilot hasthe ability to separately display ground speed, true air speed andcalibrated air speed. The results displayed are derived using data thatis maintained and data that is referenced. In function point terminologythe resulting display is called an External Output (EO).

External Inquiries - The final capability provided tousers through a computerized system addresses the requirement to selectand display specific data from files. To accomplish this a user inputsselection information that is used to retrieve data that meets thespecific criteria. In this situation there is no manipulation of thedata. It is a direct retrieval of information contained on the files.For example if a pilot displays terrain clearance data that waspreviously set, the resulting output is the direct retrieval of storedinformation. These transactions are referred to as External Inquiries(EQ).

In addition to the five functional components described above there aretwo adjustment factors that need to be considered in Function PointAnalysis.

Functional Complexity - The first adjustment factorconsiders the Functional Complexity for each unique function. FunctionalComplexity is determined based on the combination of data groupings anddata elements of a particular function. The number of data elements andunique groupings are counted and compared to a complexity matrix thatwill rate the function as low, average or high complexity. Each of thefive functional components (ILF, EIF, EI, EO and EQ) has its own uniquecomplexity matrix. The following is the complexity matrix for ExternalOutputs.

1-5 DETs 6 - 19 DETs 20+ DETs 0 or 1 FTRs L L A 2 or 3 FTRs L A H 4+ FTRs A H H
Complexity UFP L (Low) 4 A (Average) 5 H (High) 7
Using the examples given above and their appropriatecomplexity matrices, the function point count for these functions wouldbe:

Function Name

Function Type

Record
Element Type

Data
Element Type

File Types
Referenced

Unadjusted
FPs

Navigational
data

ILF

3

36

n/a

10

Positional
data

EIF

1

3

n/a

5

Navigational
data - add

EI

n/a

36

1

4

Navigational
data - change

EI

n/a

36

1

4

Navigational
data - delete

EI

n/a

3

1

3

Ground speed
display

EO

n/a

20

3

7

Air speed
display

EO

n/a

20

3

7

Calibrated air
speed display

EO

n/a

20

3

7

Terrain clearance
display

EQ

n/a

1

1

3

Total unadjusted count

50 UFPs

All of the functional components are analyzed in this way and added together to derive an Unadjusted Function Point count.

Value Adjustment Factor - The Unadjusted FunctionPoint count is multiplied by the second adjustment factor called theValue Adjustment Factor. This factor considers the system's technicaland operational characteristics and is calculated by answering 14questions. The factors are:

1. Data Communications
The data and control information used in the application are sent or received over communication facilities.

2. Distributed Data Processing
Distributed data or processing functions are a characteristic of the application within the application boundary.

3. Performance
Application performance objectives, stated or approved by the user, ineither response or throughput, influence (or will influence) the design,development, installation and support of the application.

4. Heavily Used Configuration
A heavily used operational configuration, requiring special design considerations, is a characteristic of the application.

5. Transaction Rate
The transaction rate is high and influences the design, development, installation and support.

6. On-line Data Entry
On-line data entry and control information functions are provided in the application.

7. End -User Efficiency
The on-line functions provided emphasize a design for end-user efficiency.

8. On-line Update
The application provides on-line update for the internal logical files.

9. Complex Processing
Complex processing is a characteristic of the application.

10. Reusability
The application and the code in the application have been specificallydesigned, developed and supported to be usable in other applications.

11. Installation Ease
Conversion and installation ease are characteristics of the application.A conversion and installation plan and/or conversion tools wereprovided and tested during the system test phase.

12. Operational Ease
Operational ease is a characteristic of the application. Effectivestart-up, backup and recovery procedures were provided and tested duringthe system test phase.

13. Multiple Sites
The application has been specifically designed, developed and supportedto be installed at multiple sites for multiple organizations.

14. Facilitate Change
The application has been specifically designed, developed and supported to facilitate change.

Each of these factors is scored based on their influence on the systembeing counted. The resulting score will increase or decrease theUnadjusted Function Point count by 35%. This calculation provides uswith the Adjusted Function Point count.

An Approach to Counting Function Points
There are several approaches used to count function points. Q/PManagement Group, Inc. has found that a structured workshop conductedwith people who are knowledgeable of the functionality provided throughthe application is an efficient, accurate way of collecting thenecessary data. The workshop approach allows the counter to develop arepresentation of the application from a functional perspective andeducate the participants about function points.

Function point counting can be accomplished with minimal documentation.However, the accuracy and efficiency of the counting improves withappropriate documentation. Examples of appropriate documentation are:

• Design specifications
• Display designs
• Data requirements (Internal and External)
• Description of user interfaces

Function point counts are calculated during the workshop anddocumented with both a diagram that depicts the application andworksheets that contain the details of each function discussed.

Benefits of Function Point Analysis
Organizations that adopt Function Point Analysis as a software metricrealize many benefits including: improved project estimating;understanding project and maintenance productivity; managing changingproject requirements; and gathering user requirements. Each of these isdiscussed below.

Estimating software projects is as much an art as a science. While thereare several environmental factors that need to be considered inestimating projects, two key data points are essential. The first is thesize of the deliverable. The second addresses how much of thedeliverable can be produced within a defined period of time. Size can bederived from Function Points, as described above. The secondrequirement for estimating is determining how long it takes to produce afunction point. This delivery rate can be calculated based on pastproject performance or by using industry benchmarks. The delivery rateis expressed in function points per hour (FP/Hr) and can be applied tosimilar proposed projects to estimate effort (i.e. Project Hours =estimated project function points FP/Hr).

Productivity measurement is a natural output of Function PointsAnalysis. Since function points are technology independent they can beused as a vehicle to compare productivity across dissimilar tools andplatforms. More importantly, they can be used to establish aproductivity rate (i.e. FP/Hr) for a specific tool set and platform.Once productivity rates are established they can be used for projectestimating as described above and tracked over time to determine theimpact continuous process improvement initiatives have on productivity.

In addition to delivery productivity, function points can be used toevaluate the support requirements for maintaining systems. In thisanalysis, productivity is determined by calculating the number offunction points one individual can support for a given system in a year(i.e. FP/FTE year). When compared with other systems, these rates helpto identify which systems require the most support. The resultinganalysis helps an organization develop a maintenance and replacementstrategy for those systems that have high maintenance requirements.

Managing Change of Scope for an in-process project is another keybenefit of Function Point Analysis. Once a project has been approved andthe function point count has been established, it becomes a relativelyeasy task to identify, track and communicate new and changingrequirements. As requests come in from users for new displays orcapabilities, function point counts are developed and applied againstthe rate. This result is then used to determine the impact on budget andeffort. The user and the project team can then determine the importanceof the request against its impact on budget and schedule. At theconclusion of the project the final function point count can beevaluated against the initial estimate to determine the effectiveness ofrequirements gathering techniques. This analysis helps to identifyopportunities to improve the requirements definition process.

Communicating Functional Requirements was the original objective behindthe development of function points. Since it avoids technicalterminology and focuses on user requirements it is an excellent vehicleto communicate with users. The techniques can be used to direct customerinterviews and document the results of Joint Application Design (JAD)sessions. The resulting documentation provides a framework thatdescribes user and technical requirements.

In conclusion, Function Point Analysis has proven to be an accuratetechnique for sizing, documenting and communicating a system'scapabilities. It has been successfully used to evaluate thefunctionality of real-time and embedded code systems, such as robotbased warehouses and avionics, as well as traditional data processing.As computing environments become increasingly complex, it is proving tobe a valuable tool that accurately reflects the systems we deliver andmaintain.

About the author
Roger Heller, Vice President Q/P Management Group, Inc., wrote thisarticle. The article was originally published in the STC Crosstalkpublication.

© Copyright 2000-2002. Q/P Management Group, Inc. Proprietary and Confidential. All Rights Reserved.