FUNCTION POINTS

Software Size Estimation - Graphical View Version

Table of contents
Introduction
 Definition
 FP are very popular
Components
 External Inputs (EI)
 External Outputs (EO)
 External Inquiries (EQ)
 External Interface Files (EIF)
 Internal Logical Files (ILF)
FP - How do they work?
 Step 1: Boundary Determination
 Step 2: Functional Classification
 1. External Inputs
 2. External Outputs
 3. Logical Internal Files
 4. External Files
 5. Queries
 Step 3: Unadjusted Total
 Step 4: Adjustements
 Step 5: Final Calculation
FP - Advantages
FP - Disadvantages
Conclusions
Other Interesting Links to the Topic

Introducción
En los proyectos software como en casi todos los otros proyectos de desarrollo es muy importante conocer tan
pronto como sea posible la cantidad de lo que vas a hacer. La importancia de la estimación de tamaño viene del
hecho de que todas las demás estimaciones (recursos, tiempo, costes) se deducen a partir de las estimaciones de
tamaño, es decir, las estimaciones en tamaño malas nos pueden llevar a grandes problemas después. Los métodos
más importantes de estimación del tamaño de un proyecto software son: el método de líneas de código Line-of_code
(LOC) y el método de Puntos de Función (FP). Se describe a continuación brevemente el Método de los Puntos de
Función con sus ventajas y desventajas principales. Este tema es muy extenso para ser tratado solo en unas páginas,
por lo que se proponen varios enlaces Internet para quien quiera profundizar.

En 1979, Allan Albrecht desarrolló una metodología que estima la cantidad de "funciones" que va a implementar el
software en términos de los datos que utiliza (absorbe) y que genera (produce)

Definición
Los Puntos de Función es una medida del tamaño de las aplicaciones software y de los proyectos que las construyen.
El tamaño se mide desde un punto de vista funcional o de usuario. Es independiente del lenguaje de utilizado, la
tecnología o la capacidad del equipo del proyecto utilizado para desarrollar la aplicación.

Tiene un soporte teórico muy fuerte basado en las fórmulas científicas de software de Halstead.
Los Puntos de Función son muy populares
En la actualidad los puntos de función han conseguido una gran popularidad y utilización. En la International
Conference on Applications of Software Measurement de 1993, se anunció que los Puntos de Función se habían
convertido en la métrica más utilizada a nivel mundial. Su éxito proviene del énfasis colocado en el punto de vista
externo. A causa de que la estimación de coste y esfuerzo basado en Puntos de Función no depende ni del lenguaje
ni de la tecnología, es posible realizar métricas en las primeras etapas del desarrollo.
En 1986, se constituyó la organización sin ánimo de lucro International Function Point Users Groups (IFPUG),
creada para controlar la estandarización y difusión de la métrica. La organización tiene su para realizar medidas: el
Counting Practices Manual. En 1994, IFPUG hizo la Release 4.0 de su Counting Practices Manual.

Componentes
Albrecht considera que los aspectos externos visibles del software que pueden ser enumerados con precisión constan
de cinco elementos: las entradas a la aplicación, las salidas de esta, las interrogaciones o consultas, los archivos de
datos que serían actualizados por la aplicación y las interfaces a otras aplicaciones.
Entradas. (External Inputs (EI)) son pantallas o formularios a través de los cuales el usuario humano de la
aplicación u otros programas añaden nuevos datos o actualizan los datos existentes. Algunos ejemplos podrían ser
los siguientes. pantallas de entrada, entradas interactivas, entradas hardware, entradas batch.
Salidas- (External Outputs (EO)) son pantallas o informes que la aplicación produce para utilización por el
usuario humano o por otras aplicaciones. Ejemplos: informes en pantalla, informes impresos, salidas en multimedia,
salidas para el software, salidas para el hardware.
Consulta. (External Inquiries (EQ)) son pantallas que permiten interrogar una aplicación y pedir asistencia o
información tales como: petición/respuesta, menús, ayudas sensibles al contexto, consultas empotradass.
Grupo de datos externo (GDE). (External Interface Files (EIF)) son ficheros compartidos con otras aplicaciones
e incluye ficheros en cinta entrantes o salientes y listas de parámetros. Algunos ejemplos. Reference Data, Fixed
Messages, Shared Data Files .
Grupo de datos Interno (GDI). (Internal Logical Files (ILF) ) son colecciones lógicas de registros que la
aplicación modifica o actualiza. Ejemplos: Application Data Groups, Data Tables, Data Base Files.

FP - ¿Cómo funcionan?
Cada una de estas categorías de entrads, salidas, .... mencionadas se cuentan y se les da un peso específico mediante
números que reflejan el valor relativo de la función para el usuario/cliente. La suma ponderada de las entradas ,
salidas, ... se la llama "puntos de función"
El release 4.0 del Counting Practices Manual para Puntos de Función del IFPUGtiene aproximadamente 200
páginas, y es necesario recibir formación para poder utilizarlo..

As it is described here, function point calculation originated at IBM, where it is used extensively.

Step 1: Boundary Determination

A project may include one or more applications or subsystems. Applications or subsystems should be measured as
they will ultimately be used. As an example, Microsoft Office includes Word for Windows, PowerPoint, Excel, and
Access, all of which are separate applications or subsystems. Once the subsystem boundaries are established, the
process for counting each subsystem can be implemented.
Step 2: Functional Classification
1. External Inputs
Count the unique types of user input. These include transactions from the user, transactions from other applications,
and data and control input types. Do not include input files or the input part of queries.
An input is unique if it has a different format or requires different processing logic than other inputs.
As the types of input are being counted, classify their complexity as low, average, or high. Low complexity has few
data element types, references few internal file types, and has small or no human factoring concerns in the design.
High complexity inputs have many data element types, reference many internal file types, and have a significant
amount of human factor considerations in the design. Average is between the two.
Calculate an aggregate complexity factor for input as the sum of: three times the number of low complexity types;
four times the number of average complexity input types; and six times the number of high complexity types.
2. External Outputs
Count the unique types of user output. These include transactions to the user, transactions to other applications, and
data and control output types. Do not include output files or the output response to queries.
An output is unique if it has a different format or requires different processing logic than other outputs.
As the types of output are being counted, classify their complexity as low, average, or high. Low complexity has few
data element types, references few internal file types, and has small or no human factoring concerns in the design.
High complexity outputs have many data element types, reference many internal file types, and have a significant
amount of human factor considerations in the design. Average is between the two.
If the output is a report, low complexity means one or two columns and simple data
transformations; medium is multiple columns with subtotals and multiple data transformations, and high is multiple
and intricate data element transformations and/or multiple and complex file references.
Calculate an aggregate complexity factor for output as the sum of: four times the number of low complexity types;
five times the number of average complexity output types; and seven times the number of high complexity types.
3. Logical Internal Files
Count the logical internal files (not the physical files), including each logical file within a database and each logical
group of data from the viewpoint of the user. Do not count logical internal files that are not accessible to the user
through external input, output, or queries.
As the internal files are being counted, classify their complexity as low, average, or high. Low complexity logical
files have few record types, few data element types, and no significant performance or recovery considerations. High
complexity files have many record types, many data element types, and significant performance and/or recovery
considerations. Average is between the two.
Calculate an aggregate complexity factor for internal files as the sum of: seven times the number of low complexity
types; 10 times the number of average complexity file types; and 15 times the number of high complexity types.
4. External Files
Count the external files with which the application interfaces, including input files, output files, and data and control
information. If a file is passed between or shared by multiple applications, it should be counted for each application.
If a file is used by the application and also shared with other applications, it should be counted as both a logical
internal and an external file.
As the external files are being counted, classify their complexity as low, average, or high. Low complexity files have
few record types, few data element types, and no significant performance or recovery considerations. High
complexity files have many record types, many data element types, and significant performance and/or recovery
considerations. Average is between the two.
Calculate an aggregate complexity factor for internal files as the sum of: five times the number of low complexity
types; seven times the number of average complexity file types; and 10 times the number of high complexity types.
5. Queries
Count the unique queries (combination of input and output), including queries from the user and queries form other
applications. Do not include transactions that update a file.
A query is unique if it has a different format or requires different processing logic than other queries.
As the types of query are being counted, classify their complexity as low, average, or high. Low complexity has few
data element types, references few internal file types, and has small or no human factoring concerns in the design.
High complexity queries have many data element types, reference many internal file types, and have a significant
amount of human factor considerations in the design. Average is between the two.
If the output is a report, low complexity means one or two columns and simple data
transformations; medium is multiple columns with subtotals and multiple data transformations, and high is multiple
and intricate data element transformations and/or multiple and complex file references.
Calculate an aggregate complexity factor for queries as the sum of: three times the number of low complexity types;
four times the number of average complexity file types; and six times the number of high complexity types.
Example :
Basic Counts Function Types Weights Total
8 Inputs 8*4 32
12 Outputs 12 * 5 60
4 Inquiries 4*4 16
2 Logical Files 2 * 10 20
1 Interfaces 1*7 7

Step 3: Unadjusted Total

Sum the complexity factors of the five function types to arrive at a total number of unadjusted function points.
Example:
Unadjusted Function Points Total 135
Step 4: Adjustments
Apply a degree of influence factor for each of 14 application characteristics. Degree of influence
ranges from zero (factor not present) through five (strong influence throughout).
1. Data or control information is sent via communication links
2. The application has distributed data and/or processing
3. Performance goals, such as response time, influence the design, development, installation, and/or support
of the application
4. The application design is influenced by plans to run it on heavily used existing equipment
5. The application is influenced by a high transaction rate
6. The application has on-line data entry or control functions.
7. The design emphasizes end user efficiency
8. There is on-line updating of internal files
9. The application has complex processing, such as complex logic, extensive computation, or heavy exception
or control processing
10. The design or code is to be used in other applications
11. The complexity is increased by ease of installation or conversion, or requires that conversion be tested
during the system test phase
12. The complexity is increased by ease of operation requirements such as startup, backup, recovery, or
minimizing operator intervention
13. The application will be installed at multiple sites
14. The application is designed to facilitate change with features such as flexible queries or user-maintainable
tables
Sum the 14 degree of influence factors. Calculate a General Characteristics Adjustment as .65 plus one percent of
the sum of the degree of influence factors.
Factor Influence
Data communication 2
Distributed functions 0
Performance objectives 3
Heavily used configuration 3
Transaction rate 4
On line data entry 4
End-user efficiency 3
On line update 2
Complex processing 3
Reusability 2
Installation ease 3
Operational ease 4
Multiple sites 5
Facilitate change 3
Sum of influence factors 41
General Characteristic Adjustment = 0.65+0.01*(Sum of Influence Factors 1.06
Step 5: Final Calculation
Calculate the final function points by multiplying the total unadjusted function points by the General Characteristics
Adjustment.
Example:
Function Points = General Characteristic Adjustment * Unadjusted Function Points 143
What this number means? Alone, of course it doesn't mean anything, but considering other previous projects
measurement and other data (e.g. the productivity measured in FP/month/person) this can make an idea about the
software project size
Back to Table of Contents

FP - Advantages
The benefits of function points derive from their technology independence, standardization and representing the
user's view. These benefits include:
  Measures objectively, consistently and can be audited.
Studies by Chris Kemerer of MIT show that function points' consistency is +/- 12% between counters.
 Normalizes data for ready comparisons between projects, applications and organizations.
To put them in perspective, other measures frequently require the size in function points. For example, 100 delivered
defects on a 100 function point system is not good news. The same 100 delivered defects on a 10,000 function point
system are much easier to take.
The same for productivity measurement. Many executives have come to the conclusion that regardless of their core
business, they are also in the software business. Calculating several variations on the function points produced per
month theme tells them how well they are doing in this regard.
 Provides one size measurement for all types of applications and businesses.
Function points are applied the same way in a bank's information system using COBOL as a military satellite in
Ada.
 Size is available early in the project life cycle and through out the application's life.
When can you count function points? Like voting, you should count early and often! The sooner you can quantify
what a project is delivering, the sooner it is under control. Under IFPUG 4.0, there are rules and guidelines that
make it possible to count function points once the requirements have been finalized.
 Measure is easily understood, applied, used and obtained by both the software engineers and the customer.
Companies must analyze their portfolios of applications and projects. The size in function points is an attribute that
needs to be tracked for each application and project. Along with other data, this will allow decisions regarding the
retaining, retiring and redesign of applications to be made.
 Represents what is delivered to the customer and are easily interpreted in business terms
Very often, users and project managers horse-trade change requests, features, costs and schedules throughout this
time. Function points can be used to quantify these negotiations. However, they must be used properly. It is not wise
to exchange a 100 function point enhancement for a 100 function point reduction in functionality. The work already
expended on the 100 function points to be dropped must also be considered. Again, using enhancement function
points can make this process easier on all participants.
 Provides a basis of communication with the customer
The customer doesn't need to know C++ or Java, or what technique the software engineer use to do the project. FP
offers a common language for both: the client and the contractor.

Other advantages
Back to Table of Contents

FP - Disadvantages
The lack of tools, inability to perform automated FP, and "unsuitability for project tracking" are often cited as the
major disadvantages of FP methodology. Some of its disadvantages are:
 The definitions are sometimes confusing
It is often difficult to identify the components of an application. For example, what is a logical file?
 Untrained/inexperienced people have trouble developing consistent FP counts.
For a large organization, a small group involved with function point counting and other estimating activity is ideal.
 Some judgments are rather subjective than objective
Albrecht had assigned weights to function point components based on "debate and trial." Function points are used to
determine or express the complexity of an application, as well as for metrics of development productivity. Although
the calculation is precise, many of the judgments required are more subjective. An organization may consider
defining quantitative boundaries for the sake of internal consistency.
 Need special application when counting embedded systems
When small systems are combined into larger applications, Albrecht's approach makes the total function point count
less than the sum of the components.
 Not easily automated
Due to the number of factors that needed to be considered it is very difficult to make an application which can count
all these factors for calculating the corresponding number of function points.
 Some factors (aspects) cannot be accounted
Albrecht did not provide a means of accounting for internal complexity. This is the same problem regarding
algorithms that the feature points technique was developed to address.
There are also other methods based on Function Points algorithm which try to improve some of this weaknesses or
to customize the method for other kinds of applications. The presentation of other methods is beyond the scope of
this presentation but if you are interested you can find something about them following the next links:
What are Feature Points?
What are Mk II function points?
What are 3D function points?
What are Engineering Function Points?

Back to Table of Contents

Conclusions
One question arises after this presentation. How accurate are this methods? The answer is very difficult to formulate
due to the large number of factors (more or less objective) which can interfere. One thing is sure: PEOPLE MAKE
DECISIONS AND NOT THESE METHODS. It means that the result of one of these methods should be only an
factor and in making a decision other factors can be consider such as: experience, intuition, specialists' advise, etc.
One example in this sense is the Wide Band Delphi Technique, which allows many specialist opinions to converge
in an acceptable estimates range.
However, if Function Points method is applied correctly, it can be of great help in making a decision regarding the
software size estimation.

References
Albrecht, A. J. (1983). Software Function, Source Lines of Code, and Development Effort Prediction: A Software
Science Validation, IEEE Transactions on Software Engineering, SE-9(6), pp. 639 - 647 Bernstein, L. and
Lubashevsky A. Living with Function Points. A. T. & T. Bolling, H. How to Calculate Function Points. Questicon.
Function Points Analysis and Its Uses. Predicate Logic, Inc. How are Function Points Useful.Longstreet Consulting,
Inc. Humphrey, W.(1989). Managing the Software Process. Addison - Wesley Publishing. Humphrey, W.(1995). A
Discipline for Software Engineering. Addison - Wesley Publishing. International Function Point Users Group Jones,
C. What are Funtion Points ? ,Software Productivity Research, Inc. Kellen, V. Estimating and Tracking Software
Projects. , Kallista, Inc. Kemerer, C. F. (1993). Reliability of Function Points Measurement, Communications of
the ACM, 36(2), pp. 85 - 97. < Vienneau, R. Function Points, DACS/Kaman Sciences Corporation.

Go to: Software Size Estimation Software Inspections Software Cost Estimation Defining the Software Process
Software Testing
index.htmlSoftware Configuration Management Software Process Data Gathering and Analysis Managing
Software Quality Defect Prevention
PUNTOS DE FUNCION, EJEMPLO

Introducción

En los proyectos software como en casi todos los otros proyectos de desarrollo es muy importante conocer tan
pronto como sea posible la cantidad de lo que vas a hacer. La importancia de la estimación de tamaño viene del
hecho de que todas las demás estimaciones (recursos, tiempo, costes) se deducen a partir de las estimaciones de
tamaño, es decir, las estimaciones en tamaño malas nos pueden llevar a grandes problemas después. Los métodos
más importantes de estimación del tamaño de un proyecto software son: el método de líneas de código Line-of_code
(LOC) y el método de Puntos de Función (FP). Se describe a continuación brevemente el Método de los Puntos de
Función con sus ventajas y desventajas principales. Este tema es muy extenso para ser tratado solo en unas páginas,
por lo que se proponen varios enlaces Internet para quien quiera profundizar.

En 1979, Allan Albrecht desarrolló una metodología que estima la cantidad de "funciones" que va a implementar el
software en términos de los datos que utiliza (absorbe) y que genera (produce)
Definición
Los Puntos de Función es una medida del tamaño de las aplicaciones software y de los proyectos que las construyen.
El tamaño se mide desde un punto de vista funcional o de usuario. Es independiente del lenguaje de utilizado, la
tecnología o la capacidad del equipo del proyecto utilizado para desarrollar la aplicación.

Tiene un soporte teórico muy fuerte basado en las fórmulas científicas de software de Halstead.

Los Puntos de Función son muy populares

En la actualidad los puntos de función han conseguido una gran popularidad y utilización. En la International
Conference on Applications of Software Measurement de 1993, se anunció que los Puntos de Función se habían
convertido en la métrica más utilizada a nivel mundial. Su éxito proviene del énfasis colocado en el punto de vista
externo. A causa de que la estimación de coste y esfuerzo basado en Puntos de Función no depende ni del lenguaje
ni de la tecnología, es posible realizar métricas en las primeras etapas del desarrollo.
En 1986, se constituyó la organización sin ánimo de lucro International Function Point Users Groups (IFPUG),
creada para controlar la estandarización y difusión de la métrica. La organización tiene su para realizar medidas: el
Counting Practices Manual. En 1994, IFPUG hizo la Release 4.0 de su Counting Practices Manual.

Componentes

Albrecht considera que los aspectos externos visibles del software que pueden ser enumerados con precisión constan
de cinco elementos: las entradas a la aplicación, las salidas de esta, las interrogaciones o consultas, los archivos de
datos que serían actualizados por la aplicación y las interfaces a otras aplicaciones.
Entradas. (External Inputs (EI)) son pantallas o formularios a través de los cuales el usuario humano de la
aplicación u otros programas añaden nuevos datos o actualizan los datos existentes. Algunos ejemplos podrían ser
los siguientes. pantallas de entrada, entradas interactivas, entradas hardware, entradas batch.
Salidas- (External Outputs (EO)) son pantallas o informes que la aplicación produce para utilización por el
usuario humano o por otras aplicaciones. Ejemplos: informes en pantalla, informes impresos, salidas en multimedia,
salidas para el software, salidas para el hardware.
Consultas. (External Inquiries (EQ)) son pantallas que permiten interrogar una aplicación y pedir asistencia o
información tales como: petición/respuesta, menús, ayudas sensibles al contexto, consultas empotradass.
Grupo de datos externo (GDE). (External Interface Files (EIF)) son ficheros compartidos con otras aplicaciones
e incluye ficheros en cinta entrantes o salientes y listas de parámetros. Algunos ejemplos. Reference Data, Fixed
Messages, Shared Data Files .
Grupo de datos Interno (GDI). (Internal Logical Files (ILF) ) son colecciones lógicas de registros que la
aplicación modifica o actualiza. Ejemplos: Application Data Groups, Data Tables, Data Base Files.

FP - ¿Cómo funcionan?
Cada una de estas categorías de entrads, salidas, .... mencionadas se cuentan y se les da un peso específico mediante
números que reflejan el valor relativo de la función para el usuario/cliente. La suma ponderada de las entradas ,
salidas, ... se la llama "puntos de función"
El release 4.0 del Counting Practices Manual para Puntos de Función del IFPUGtiene aproximadamente 200
páginas, y es necesario recibir formación para poder utilizarlo..
Esquema resumido de los pasos

Paso 1. Determinar las fronteras del proyecto (Boundary Determination)

Paso 2. Identificar los componentes y su complejidad (Functional Classification)

Paso 3. Totalizar los Funtos de Función sin Ajustar. (Unadjusted Total)

Paso 4. Calcular el factor de ajuste. (Adjustments)

Paso 5. Cálculo de los Puntos de Función ajsutados. (Final Calculation)

Enunciado del problema

Tenemos un proyecto ya bien determinado (es decir las fronteras bien delimitadas). Una empresa subcontratada por
nuestro cliente ha determinado que el proyecto tiene los siguientes componentes:

De complejidad sencilla De complejidad media De complejidad alta

Entradas 12 8 2

Salidas 5 4 1

Consulta 10 3 0

Grupo de datos Interno 10 8 1

GDI
Grupo de datos externo 3 2 0
GDE

A) Utilizando la tabla de pesos por complejidad siguiente, calcular el numero de puntos de función no ajustados
NPFNA

TABLA DE PESOS De complejidad sencilla De complejidad media De complejidad alta

Entradas 3 4 6

Salidas 4 5 7

Consulta 3 4 6

Grupo de datos Interno 7 10 15

GDI
Grupo de datos externo 5 7 10
GDE
B) Calcular el valor de ajuste teneiendo en cuenta que

Factor Influence
Data communication 2
Distributed functions 0
Performance objectives 3
Heavily used configuration 3
Transaction rate 4
On line data entry 4
End-user efficiency 3
On line update 2
Complex processing 3
Reusability 2
Installation ease 3
Operational ease 4
Multiple sites 5
Facilitate change 3

Sabiendo que el Factor de ajuste se calcula de la siguiente manera:

VFA(Valor del Factor de Ajuste)= 0.65+0.01*(Suma de los Factores de Influencia)

C) Calcular en Número de Puntos de Función ajustados (PFA=VFA*NPFNA)