ISO/IEC 19515:2019

INTERNATIONAL ISO/IEC
STANDARD 19515
First edition
2019-05
Information technology — Object
Management Group Automated
Function Points (AFP), 1.0
Reference number
©
ISO/IEC 2019
© ISO/IEC 2019
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO/IEC 2019 – All rights reserved

Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
1.1 Purpose . 1
1.2 Applicability . 1
1.3 Limitations . 1
2 Conformance and Compliance . 1
2.1 Conformance . 1
2.2 Compliance . 2
2.3 Consistency with IFPUG CPM . 2
3 References . 3
3.1 Normative . 3
3.2 Non-normative . 3
4 Terms and Definitions . 3
5 Symbols (and abbreviated terms) . 5
6 Additional Information . 5
6.1 Overview of Function Points . 5
6.2 Function Point Usage Scenarios . 6
6.3 Inputs to Automated Function Point Counting . 7
6.4 Outline of the Function Point Counting Process . 7
6.5 The Application Model . 8
6.5.1 The Application Model Elements . 8
6.5.2 Detection of Data Functions . 9
6.5.3 Detection of Transactional Functions .14
6.5.4 Detection of Internal Versus External Logical Files .15
7 Determine Functional Size (Normative) .17
7.1 Entering Application Model Elements into Functional Sizing.17
7.1.1 Representation of the Application Model in KDM .17
7.1.2 Translating KDM Application Model Elements into SMM Inputs .18
7.2 Determine Data Function Size .18
7.3 Determine Transactional Function Size .19
7.4 Determine Function Point Size.22
7.5 Output Generation .22
7.6 Structured Metrics Meta-Model (SMM) Representation .23
7.6.1 Computing Automated Function Point Size .23
7.6.2 Computing External Output Size .24
7.6.3 Computing External Input Size .25
7.6.4 Computing Internal Logical File Size and External Interface File Size .26
8 References .27
© ISO/IEC 2019 – All rights reserved iii

Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that
are members of ISO or IEC participate in the development of International Standards through
technical committees established by the respective organization to deal with particular fields of
technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other
international organizations, governmental and non-governmental, in liaison with ISO and IEC, also
take part in the work.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of document should be noted (see www .iso .org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www .iso .org/patents) or the IEC
list of patent declarations received (see http: //patents .iec .ch).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso
.org/iso/foreword .html.
This document was prepared by the Object Management Group (OMG) (as the OMG specification for
Automated Function Points (AFP), v1.0) and drafted in accordance with its editorial rules. It was
adopted, under the JTC 1 PAS procedure, by Joint Technical Committee ISO/IEC JTC 1, Information
technology.
This document is related to:
— ITU-T Recommendation X.902 (1995) | ISO/IEC 10746-2:1995, Information Technology — Open
Distributed Processing — Reference Model: Foundations
— ITU-T Recommendation X.903 (1995) | ISO/IEC 10746-3:1995, Information Technology — Open
Distributed Processing — Reference Model: Architecture
— ITU-T Recommendation X.920 (1997) | ISO/IEC 14750:1997, Information Technology — Open
Distributed Processing — Interface Definition Language
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/members .html.
iv © ISO/IEC 2019 – All rights reserved

Introduction
The rapid growth of distributed processing has led to a need for a coordinating framework for this
standardization and ITU-T Recommendations X.901-904 | ISO/IEC 10746, the Reference Model of Open
Distributed Processing (RM-ODP) provides such a framework. It defines an architecture within which
support of distribution, interoperability and portability can be integrated.
RM-ODP Part 2 (ISO/IEC 10746-2) defines the foundational concepts and modeling framework for
describing distributed systems. The scopes and objectives of the RM-ODP Part 2 and the UML, while
related, are not the same and, in a number of cases, the RM-ODP Part 2 and the UML specification use the
same term for concepts which are related but not identical (e.g., interface). Nevertheless, a specification
using the Part 2 modeling concepts can be expressed using UML with appropriate extensions (using
stereotypes, tags, and constraints).
RM-ODP Part 3 (ISO/IEC 10746-3) specifies a generic architecture of open distributed systems,
expressed using the foundational concepts and framework defined in Part 2. Given the relation between
UML as a modeling language and Part 3 of the RM-ODP standard, it is easy to show that UML is suitable
as a notation for the individual viewpoint specifications defined by the RM-ODP.
This International Standard defines a method for automating the counting of Function Points that is
generally consistent with the Function Point Counting Practices Manual, Release 4.3.1 (IFPUG CPM)
produced by the International Function Point Users Group (IFPUG). Guidelines in this specification may
differ from those in the IFPUG CPM at points where subjective judgments have to be replaced by the
rules needed for automation. The IFPUG CPM was selected as the anchor for this specification because
it is the most widely used functional measurement specification with a large supporting infrastructure
maintained by a professional organization.
© ISO/IEC 2019 – All rights reserved v

INTERNATIONAL STANDARD ISO/IEC 19515:2019(E)
Information technology — Object Management Group
Automated Function Points (AFP), 1.0
1 Scope
1.1 Purpose
This International Standard defines a method for automating the counting of Function Points that is
generally consistent with the Function Point Counting Practices Manual, Release 4.3.1 (IFPUG CPM)
produced by the International Function Point Users Group (IFPUG). Guidelines in this International
Standard may differ from those in the IFPUG CPM at points where subjective judgments have to be
replaced by the rules needed for automation. The IFPUG CPM was selected as the anchor for this
International Standard because it is the most widely used functional measurement specification with a
large supporting infrastructure maintained by a professional organization.
1.2 Applicability
This International Standard is applicable to the functional sizing of transaction-oriented software
applications, and in particular those with data persistency. To be consistent with the IFPUG CPM, the
International Standard provides details on the support of applications using relational databases.
However, the International Standard can be used and extended for any type of transactional application
with data persistency.
1.3 Limitations
This International Standard does not address the sizing of enhancements to an application or
maintained functionality (often called Enhancement Function Points). Extensions of the automated
counting methods described in this International Standard such as Automated Enhancement Function
Points will be addressed in future addendums to this International Standard. This International
Standard does not address sizing for the non-functional components of a software application. Non-
functional components (as defined by IFPUG) include:
— Structural Quality Constraints Reliability, Security, Performance Efficiency, Maintainability, etc.
— Organizational Constraints locations for operations, target hardware, compliance to standards, etc.
— Environmental Constraints interoperability, security, privacy, safety, etc.
— Implementation Constraints development language, delivery schedule, etc.
2 Conformance and Compliance
2.1 Conformance
This International Standard is derived from IFPUG’s Function Point Counting Practices Manual, Release
4.3.1 (IFPUG CPM). However, explicit counting rules were specified in this International Standard
in order to provide for rigorous automation that may not be in strict conformance with guidance in
IFPUG’s manual. Therefore, there is no claim of strict conformance with the IFPUG CPM standard.
Additionally, this International Standard has made every attempt to conform to the extent possible with
international standards for functional measurement, in particular ISO/IEC 25010, ISO/IEC 20926:2009,
and NEN-ISO/IEC 24570. This International Standard conforms to OMG’s Knowledge Discovery Meta-
model (KDM) and Structured Metrics Meta-model (SMM) in its specification and representation of the
Automated Function Point counting and scoring process.
© ISO/IEC 2019 – All rights reserved 1

Conformance with this International Standard by Automated Function Point counting tools is
determined by analyzing the KDM elements that constitute the Application Model and produce the final
Automated Function Point count using the counting process specified in the SMM model presented in
this International Standard. Output from this automated process should conform to the list of output
artifacts listed in Clause 7.
2.2 Compliance
Implementations of this International Standard should be able to demonstrate the following attributes
in order to claim compliance:
— Automated — Although the initial inputs such as the source code, definition of application boundary,
and some naming conventions are provided manually to initiate Automated Function Point counting,
the analysis of the source code and the actual counting must be fully automated.
— Consistent — Two independent and separate functional sizings performed on the same application
source code using the same boundaries and other required manual inputs by different Automated
Function Point tools that conform to this International Standard must produce the same results in
terms of Automated Function Point size (i.e., the same number of Automated Function Points).
— Verifiable — Implementations that comply with this International Standard must clearly list each
and every input the implementation requires and list each and every output that the implementation
generates so that they can be audited by a third party. Implementations should provide a list of
assumptions/heuristics (to the extent that this does not disclose proprietary information) used to
transform the inputs to the outputs so that the calculations can be independently verified by third
parties.
2.3 Consistency with IFPUG CPM
This International Standard for Automated Function Points follows the steps for the counting process in
the IFPUG CPM to the extent possible for an automated system. An automated system relies on receiving
the correct and complete list of inputs to fulfill this step. Consequently the initial step in the Automated
Function Point counting process is the manual gathering of inputs and configuring them properly for
analysis by the Automated Function Point counting technology. The remainder of the analysis and
counting process is automated.
This International Standard prioritizes repeatability and consistency over consistency with the
IFPUG CPM counting guidelines. In some counting situations, IFPUG guidelines are vague, leaving the
interpretation to the judgment of the counter. Consequently, IFPUG certified Function Point counters
often differ by as much as 10 % or more in the counts they produce. In order to remove subjectivity,
this International Standard makes explicit decisions about counting techniques in situations where
the IFPUG guidelines were vague. Consequently we have introduced some variation from the IFPUG
guidelines in order to achieve the precision required for automation and repeatability.
Automated Function Point counts may differ from the manual counts produced by IFPUG Certified
Function Point counters. In fact, manual counts produced by different IFPUG Certified Function Point
counters on the same code base will typically differ because of different interpretations of the designer’s
or developer’s intent in creating various functional elements of an application. In the manual IFPUG
counting process, documentation, and expert knowledge are typically used in sizing an application.
These types of inputs are not available to an automated system. Hence, any automated approach will
be unable to capture information about the designer’s or developer’s intent that isn’t explicitly encoded
in the application’s source code. Since this International Standard relies exclusively on the application’s
source code as defined by its boundaries, it cannot capture any of the designer’s intentions that do
not leave an ‘imprint’ on the source code. Some of these intentions might make a difference in manual
counting. For this additional reason, the Automated Function Point counts produced by technology
that is compliant with this International Standard may differ from manual counts produced by IFPUG
Certified Function Point counters. The advantage of Automated Function Points is that a tool will
produce repeatable, consistent counts, attributes that are not characteristic of manual counting.
2 © ISO/IEC 2019 – All rights reserved

3 References
3.1 Normative
The following normative documents contain provisions which, through reference in this text, constitute
provisions of this Automated Function Point International Standard. For dated references, subsequent
amendments to, or revisions of, any of these publications do not apply.
— Structured Metrics Meta-model, version 1.0 (SMM), formal/2012-01-05
— Knowledge Discovery Meta-model, version 1.3 (KDM), formal/2011-08-04
— Unified Modeling Language, version 2.4.1 (UML), formal/2011-08-05
— MOF/XMI Mapping, version 2.4.1 (XMI), formal/2011-08-09
3.2 Non-normative
— Function Point Counting Practices Manual, Release 4.3.1. ISBN 978-0-9753783-4-2
— Function Point Analysis. ISBN 0-201-69944-3
4 Terms and Definitions
For the purposes of this International Standard, the following terms and definitions apply.
Application Model
abstract source code representation of an application that results from analysis of the source code.
It contains the minimum information required to measure Automated Function Points, that is, the
static elements of an application defined by associated KDM elements that are used in the Automated
Function Point counting process.
Boundary
the boundary is a conceptual interface between the software and the users. (IFPUG CPM)
Complete transaction
in the context of this International Standard, a transaction is considered as complete whenever the
static code analyzer can find one or several code paths starting from the user interface and continuing
down to the data entities.
Data Element Type (DET)
a data element type is a unique user recognizable, non-repeated attribute that is part of an ILF, EIF, EI,
or EO. (ISO/IEC 20926:2009)
Data Function
functionality provided to the user to meet internal or external data storage requirements. A data
function is either an ILF or EIF. (ISO/IEC 20926:2009)
Database Table
SQL data table or KDM’s data: RelationalTable.
External Inquiry (EQ)
a form of data that is leaving the system. However, since automated counting tools cannot distinguish
between External Inquiries and External Outputs, all External Inquiries will be included in and
counted as External Outputs. (ISO/IEC 20926:2009)
External Input (EI)
elementary process that processes data or control information sent from outside the boundary (ISO).
(ISO/IEC 20926:2009)
© ISO/IEC 2019 – All rights reserved 3

External Interface File (EIF)
a user recognizable group of logically related data or control information, which is referenced by the
application being measured, but which is maintained within the boundary of another application.
(ISO/IEC 20926:2009)
External Output (EO)
an elementary process that sends data or control information outside the boundary and includes
additional processing logic beyond that of an External Inquiry. (ISO/IEC 20926:2009)
File Type Referenced (FTR)
data function (IFL or EIF) read and/or maintained by a transactional function. (ISO/IEC 20926:2009)
Internal Logical File (ILF)
user recognizable group of logically related data or control information maintained within the
boundary of the application being measured. (ISO/IEC 20926:2009)
Library
a set of software components that are grouped together in the same physical container and that are
accessed via a dedicated API.
Logical File
either an Internal Logical File (ILF) or an External Interface File (EIF). (ISO/IEC 20926:2009)
Method
a method is a group of instructions that is given a name and can be called up at any point in a program
simply by quoting that name. In object oriented languages like Java and C++, methods are grouped in
classes. A method is referenced as code: MethodUnit in the KDM.
Physical File
physical files hold the actual data of a database file and are not required to have keyed fields. Where
the word ‘file’ is used alone without the modifier ‘logical,’ it refers to a physical file. Within the KDM,
such a physical file is described as a kind of data: DataContainer and contains a set of data: RecordFile.
Record Element Type (RET)
user recognizable sub-group of data element types within a data function. (ISO/IEC 20926:2009)
Service End Point
well known address that is used by an application to exchange data and events with other applications.
Typical examples include Remote Procedure Call interfaces and Message Queues.
Source Code Entities
elements of the source that can be detected during static analysis in order that they be used in the
Function Point counting process.
Structured Query Language (SQL)
a language used to query databases. (ISO/IEC 9075-1:2008)
Static Dependency
a directional relation that exists between a caller method and a called method.
Transaction End Point
user Interface End Point or a Service End Point. It identifies potential Transactional Functions.
Transactional Function
elementary process that provides functionality to the user to process data. A transactional function is
an External Input, External Output, or External Inquiry. (ISO/IEC 20926:2009)
User Interface End Point
there are two kinds of user interface end points: user interface inputs and user interface outputs.
4 © ISO/IEC 2019 – All rights reserved

User Interface Input
command that can be activated by humans using a mouse, keyboard, or equivalent interactions. (ISO/
IEC 20926:2009)
User Interface Output
set of visual elements that are composed by an application in order to present information or events to
the user (e.g., a form, report, or tab inside a screen). An elementary process that sends data or control
information outside the boundary. (ISO/IEC 20926:2009)
User Recognizable
refers to requirements for processes and/or data that are agreed upon, and understood by, both the
user(s) and software developer(s). (IFPUG CPM)
5 Symbols (and abbreviated terms)
APF Automated Function Point
CISQ Consortium for IT Software Quality
CPM Counting Practices Manual
DET Data Element Type
DFC Data Function Complexity
EQ External Inquiry
EI External Input
EIC External Input Complexity
EIF External Interface File
EO External Output
EOC External Output Complexity
FTR File Type Referenced
IFPUG International Function Point Users Group
ILF Internal Logical File
KDM Knowledge Discovery Meta-model
RET Record Element Type
SMM Structured Metrics Meta-model
SQL Structured Query Language
6 Additional Information
6.1 Overview of Function Points
The use of Function Points as a measure of the functional size of software was initially introduced in the
mid-1970s and today is used by organizations worldwide. Allan Albrecht of IBM was the first to publicly
release a method for functionally sizing software called Function Point Analysis (Albrecht, 1979, 1981).
© ISO/IEC 2019 – All rights reserved 5

Since its formation in 1986 the International Function Point Users Group (IFPUG) has continuously
maintained and enhanced the original Albrecht method for functionally sizing software (IFPUG CPM).
Function Points are a normalized metric that can be used consistently with an acceptable degree of
accuracy. The value of Function Point analysis centers on its ability to measure the size of any software
deliverable in logical, user-oriented terms. Function Point counts are technology agnostic in that they
do not depend on the type of technology or development language. Function Points simply measure the
functionality that an application delivers to an end user.
Function Point analysis evaluates a software deliverable and measures its size based on well-defined
functional characteristics of a software system. Function Point analysis accounts for four constituents
of an application:
1) External Inputs — Input data that is entering a system (logical transaction inputs, system feeds).
2) External Outputs and External Inquires — data that is leaving the system (on-line displays, reports,
feeds to other systems).
3) Internal Logical Files — data that is processed and stored within the system (logical groups of user
defined data).
4) External Interface Files — data that is maintained outside the system but is necessary to satisfy a
particular process requirement (interfaces to other systems).
Organizations can apply function points to measure the size of a software product. Along with selected
other measures, Function Points can be used in the following activities:
— Quality and productivity analysis.
— Estimating the costs and resources required for software development, enhancement, and
maintenance.
— Normalizing data used in software comparisons.
— Determining the size of a purchased application package (Commercial Off The Shelf or customized
system) by sizing all the functionality included in the package.
— Enabling users to determine the Return on Investment of an application by sizing the functionality
that specifically matches the requirements of their organization.
6.2 Function Point Usage Scenarios
There are three frequent scenarios of use for Function Points; estimating software size in order to
estimate effort and cost, normalization of other measures, and benchmarking for decision-making.
1) Function Points have been defined around components that can be identified in a well-written
specification. Consequently Function Points can be counted from the specification well before other
size measures such as lines of code become available. Because of this advantage many commercial
cost estimating formulas use Function Points in their calculations as the preferred size measure
from which effort and cost figures can be estimated. When the actual number of Function Points
becomes available from the delivered software, parameters in these formulas can be adjusted to
increase their accuracy.
2) Function Points are frequently used to normalize other measures. For instance, the total defects
detected in a software system can be normalized by Function Points to provide a measure of the
defect density per Function Point. This allows better comparison among systems that differ in size,
as well as programming language.
3) Because they are counted from constructs that are independent of the programming language,
Function Points are a preferred method for comparing software systems when benchmarking.
In particular they are frequently used to compare the past performance and productivity
6 © ISO/IEC 2019 – All rights reserved

of contractors or outsourcers during contract award. Subsequent management of contract
performance is frequently performed using Function Point-based measures.
6.3 Inputs to Automated Function Point Counting
The following is a list of the required inputs that must be collected prior to conducting an automated
Function Point analysis. Inputs 1 and 2 are required for compliance with the International Standard.
1) Input 1 — The complete, current, and correct source code for the application including at a
minimum elements ‘a.’ to ‘d.’ below:
a) Source code — including all elements that span from GUI to the database.
b) List of files to exclude from the source code — files that don’t belong to the application.
c) List of libraries to exclude from the source code — libraries that don’t belong to the application.
d) Data definition files — for example, SQL scripts used to generate the database model, and/or
mainframe database definition files.
e) Flat files — the files that contain user maintained data, but are not stored in a relational
database such as CSV-files, tab-separated files, or user maintained XML files.
2) Input 2 — A list of the application naming conventions clearly described and itemized:
a) Database naming conventions;
b) Flat file naming conventions;
c) Additional naming conventions used in the application;
d) Patterns in the source code that are to be identified as transaction entry points.
The following are additional normative instructions for determining the complete application source
code, for drawing the right application boundaries, and for ensuring auditability.
— It is mandatory to define the application boundary at the user interface level and, when applicable,
at the web-services level or the batch level. Incorrect identification of an application boundary may
produce results that do not accurately reflect the size of the target domain being measured.
— Do not assume that all source code required is inside the boundary. External source code can be
used to infer relevant behavior for the application. In such cases, the relevant parts of the source
code external to the application shall be included, but shall be marked clearly as external.
— Implementations compliant with this International Standard must list all inputs to the Automated
Function Point counting technology that are provided by Subject Matter Experts (SMEs). The report
of Automated Function Point counts shall include a list of SME-provided inputs.
6.4 Outline of the Function Point Counting Process
An automated function point counting implementation shall proceed by taking the following steps and
producing the following outputs.
1) Gather and access the list of inputs used by the system implementing this International Standard as
set out in the list above and determine the application boundary.
2) Create the application model.
3) Detect the Data functions:
a) Detect the logical files in relational databases;
© ISO/IEC 2019 – All rights reserved 7

b) Detect the logical files in flat files.
4) Detect the transactional functions.
5) Detect and distinguish internal versus external logical files.
6) Calculate the total number of function points in the application.
7) Generate the following outputs:
a) A complete list of all inputs used by the counting algorithm(s) including context-related and
SME-provided inputs.
b) A list of all instances where a pattern specified in the input matches a pattern detected in the
application.
c) A list of all instances where a pattern specified in the input is matched but ignored and the
reason why the instance was ignored.
d) A list of all transaction entry points, and their weights, in the application.
e) A list of all data functions, and their weights, for the application.
f) For each transaction:
i) A list of the Data functions — External Interface Files (EIFs) and Internal Logical Files
(ILFs) — contained in that transaction and their locations in the source code.
ii) For each Data Function (EIFs and ILFs), a count of the Data Element Types (DETs) and
Record Element Types (RETs) and their locations in the source code.
iii) For each transactional function (EIs and EOs), a count of the number of DETs and Files
Types Referenced (FTRs) and their locations in the source code.
g) Total number of data function points in the application.
h) Total number of transactional function points in the application.
i) The mapping between the data and transactional functions.
j) Total number of Function Points in the application.
Step 1 of this procedure for Automated Function Point counting is performed manually, frequently with
the aid of a Subject Matter Expert in the application being sized. The determination of the application
boundary must be done with the concurrence of the application user/owner. Once the application
boundary has been established and the inputs have been gathered and properly configured for use
by the Automated Function Point counting technology, the remainder of the process should proceed
without additional manual intervention.
6.5 The Application Model
6.5.1 The Application Model Elements
The Application Model is produced by analyzing the source code of the application to be sized. It
shall contain the static elements of the application that are used in the Automated Function Point
counting process. The Application Model is defined as the list of all application’s code entities and their
dependencies as listed in Table 6.1. Application Model elements are stated in terms that are consistent
with the IFPUG CPM.
The application functional size is the sum of the functional size of each data and transactional function.
The functional size of each data and transactional function is determined by evaluating their individual
complexities and then using this complexity result to assign a size to each function.
8 © ISO/IEC 2019 – All rights reserved

In order to measure the complexity of each data and transactional function, all data and transactional
functions are identified and connected using a directed graph representing the direct dependencies of
several objects between the data elements and the transactional functions. Such a graph is built from
analysis of the application code and data schema (both explicit from data definitions and implicit from
inferences made about data files). The following sub clauses provide guidelines for conducting these
analyses.
Table 6.1 — Application Model Elements
Application Model Elements
Application Data
Relational form Database tables
Database table attributes
Database primary keys & unique indexes
Database foreign key constrains
Hierarchical form
Unstructured form
Application Logic
Classes & Methods
Functions & Procedures Stored procedures
Stored functions
Triggers
Views from databases
User Interface Reports
Dependencies
Field use
State change
Method & Function Invovation
Class Inheritance and Interface Implementations (when needed to resolve
object-oriented calls using polymorphism)
6.5.2 Detection of Data Functions
IFPUG Data Functions shall include Internal Logical Files (ILFs) and External Interface Files (EIFs).
These Data Functions are intended to represent the functionality provided to a user to meet internal
and external data requirements. The term logical file as used here refers to a logically related group
of data and not the physical implementation of those groups of data. The method elaborated in this
International Standard describes how to identify logical groupings of data. Logical files are detected in
the following ways:
— Detection of Logical Files in Relational Databases
— Detection of Logical Files in Flat Files
— Detection of Logical Files in hierarchical databases
— Detection of Logical Files through SME-provided contextual information
6.5.2.1 Detection of Logical Files in Relational Databases
The function point counting model assumes that all data elements are recognizable by the end-user
as logical pieces of information, named Data Functions. Due to the prevalence of the relational model,
often these entities correspond to a table (either in a database, file, or memory location). The problem
is that this mapping is not always one-to-one. For any of several reasons, a user-recognizable or atomic
© ISO/IEC 2019 – All rights reserved 9

entity sometimes may be split into a master and one or more detail entities. For instance an entity
may be split when a field can have more than one value attached, such as a field that contains a user’s
email addresses when the user has several. This often leads to a detail entity that links the fields with
multiple values to a single master entity. This process is also known as normalization of a relational
database.
Although the normalization of a relational database leads to multiple entities or tables in a database,
function point analysis requires that only user-recognizable or atomic entities are counted. So in order
to perform a function point analysis on the source code of a system we need to reverse the normalization
of the relational database, a process known as de-normalization.
To identify Data Functions from a set of database tables, each database table shall be visited in order
to determine if it is a detail table of a master table. Each table shall only be visited once in order to
determine if the table is a master database table or a detail table of a specific table.
In order for a data table to be grouped under a master data table, the following tests must be checked in
sequence:
1) The table has primary key with a foreign key constraint to another table. This is a table extension
pattern.
2) The table has a unique index over a foreign key to another table. This is another table extension
pattern.
3) The table is exclusively composed by 2 or 3 foreign key attributes and, optionally, a primary key.
This is an associative table. Associative tables are always aggregated with another table. One of the
related tables is picked based on the best match algorithm. Associative tables are never considered
master tables.
4) The table has a set of mandatory foreign keys with a cascade delete constraint. This is a classical
master detail relation. The master table is chosen based on the best name match.
5) The table has a set of foreign keys with other tables with similar names (similar suffix and prefix).
The master table is chosen based on the best name match.
The best match algorithm shall be picked based on:
— the longest prefix or suffix (biggest prefix/suffix matches are more relevant).
— the last criteria to ensure a reproducible algorithm is simply the first occurrence in the sorted
names of the entities.
It is possible, although not frequent, for a master table A to be considered a detail table of another
table B. In this case, both clusters of detail and master tables shall be aggregated under table B.
6.5.2.1.1 Filtering Temporary and Technical Data Tables
Some data tables, namely temporary data tables and technical data tables, need are ignored in the
sizing process in order to match the automated counting process with IFPUG rules (see “A Framework
for Functional Sizing” [IFPUG, 2003].)
This International Standard defines two ways to identify temporary or technical data tables in the
following two sub clauses:
1) Matching database tables with lookup structure.
2) Matching database tables code data naming conventions.
Database tables identified as temporary or technical shall be marked as such to be presented in the
final report, and shall be ignored in the rest of this process.
10 © ISO/IEC 2019 – All rights reserved

6.5.2.1.2 Database tables with lookup structure
Database tables with a lookup structure must match the following conditions:
— Have one primary key.
— Optionally, have (only) one integer attribute to support order (a single integer attribute is allowed
to support indexing and sorting the lookup data).
— Have no other database table with a cascade delete relation to it.
— Have less than three text attributes or have a set of text attributes whose names match name,
message, type, code, description, desc, or label.
6.5.2.1.3 Code data naming convention matching
This detection shall be done as a result of naming conventions provided as user inputs. These are
parameters that can be customized at initiation based on required user inputs. What are displayed here
are default values. Each naming convention pattern is defined by a label to describe the intention, and a
regular expression using Perl 5 case insensitive regular expression syntax. Default naming conventions
for English databases tables are:
— Lookup entities — ^(lkp_.+|.+types?|.+_t)$
— Status entities — ^(.+status)$
— Translation extension entities — ^(.+_l|.+_lang)$
— Temporary data entities —
^(.+temp|.*session.*|.*error.*|.*search.*|.*login.*|.*logon.*|.*filter.*)$
— Template data entities — ^
...