Metrics and Function
Point in Italian
Function points measure the size of an application's functionality,
defined as a cohesive collection of procedures and data supporting a
business objective. Each application is separated from the others and from
the user since it is marked by a boundary. The boundary acts as a
"membrane" through which the data processed by the Input,
Output, and Inquiry transactions pass. The boundary should be seen from
the business's point of view, and is not based on technical or physical
considerations. Functional size is a standard conventional measurement
regardless of the technology used to develop the
Functional size is one of the main variables of the software's price,
which is also affected by the complexity and quality of the product, of
the technology used for development, of reuse that is made, etc. Therefore,
by taking specific productivities into account, function points are an aid
for estimating, a priori, the effort needed to develop a project and for
calculating, a posteriori, the value of the product and of the software.
The concepts related to functional size measurement (FSM) are defined and
the principles for applying a FSM method are described in the ISO/IEC
14143-1 standard of 1997 entitled "Information Technology - Software
measurement - Functional size measurement - Definition of concepts."
FSM method must have the following features:
is based on a user requirements representation seen from the user's
point of view;
may be applied immediately, as soon as the user's functional
requirements have been defined and are available;
derives functional size from the functional requirements, regardless
of the technical requirements or the quality.
size is also independent of the effort needed for development or
maintenance, from the methods employed, from the physical supports used,
and from the technological components. A FSM method should indicate the
degree of convertibility with other sizing methods.
Other parts of the standard are being produced with regard to: compliance,
checks, reference model, software domains.
Function points take concrete form in a set of scores assigned in
accordance with the counting rules to Inputs (EI), Inquiries (EQ), Outputs
(EO), and Logical files (ILF and EIF) evident from examining the
application and its documentation.
In the world of Information Technology, function point metrics are
gradually replacing LOC (Lines Of Code, formerly called "cards",
derived from punched cards, read by a special
hardware). Although the functions under
consideration are both equal, LOC vary depending on the type of language used
and are harder to quantify.
Although the method was defined by Allan Albrecht at IBM in the late
1970s, interest in function points began in the United States in the 1980s
and made inroads into Italy in the 1990s. The most-used LOC measurement is
the number of lines minus the comments, but an international standard has
never been achieved. Function points, on the other hand, thanks to
associations like IFPUG (International Function Point User Group) and
ISO (International Organization for Standardization), are a standardized
size measurement. GUFPI (Gruppo Utenti Function Point Italia) is Italy's
reference for function point users. IFPUG 4.1 Unadjusted Function Point
Method was approved by the ISO/IEC Joint Technical Committee 1 (JTC1) and
became PAS (Publicly Available Specification) in 2001. The International Standards
issued by JTC1, after a series of approvals, are considered the most authoritative
standards in the field of Information Technology.
Capers Jones defined the average correspondence between LOC and FPs as
"backfire". For example, according to Jones or David Consulting Group, 1 FP is equal to:
320 Assembler LOC or 575
128 C or 225
107 Cobol or 220
91 Cobol II or 175
55 C++ or 80
35 Java and Visual Basic-4 or 80
It is evident that there is a difference between different sources. (For B. Boehm 1 FP is equal to 53 LOC C++ and Java).
For publishing-type web sites developed with a large
amount of text written within HTML instructions, we may approach the
average correspondence of 15 LOC for 1 FP, without considering the LOC of
the texts. An appropriate benchmarking should be used to check the "backfire"
values in their own environments.
"Forward" function point counting (and not in "reverse"
using the "backfire" technique), assumes the knowledge of
precise rules, and is the object of new professions (CFPS - Certified
Function Point Specialists). One can become certified as a counting
specialist through GUFPI and IFPUG.
In truth, Function Points are more than a counting technique, since they
help to thoroughly examine the functionalities, thereby improving analysis of
- and making it possible to quantify - requirements. They produce better
estimates, support acceptance testing, and improve the general
documentation of the software. Function points also provide an excellent
opportunity for perform a variety of censuses about the applications
existing in the information system.
They may therefore be used to support the development process, and make
it possible to manage some important level 2 key activities of the CMM
(Capability Maturity Model) published in 1991 by SEI (Software
Engineering Institute, Carnegie Mellon University), which became in
2000 CMMI (Capability Maturity Model Integration), in a highly
organized manner and integrated with certain ISO international
standards and industry documents.The model has 5 levels of process
(managed in terms of requirements, planning, control, measurement,
quality assurance, data, and configuration)
(with full consideration of the user requirements, integrated,
organized, and managed taking the risks into account)
(quantitatively managed in all the aspects of quality and process)
(with cause-and-effect analyses and problem resolution, highly
counting method applied with the required criteria has the
- being sensitive to the magnitude perceived by the user by means of elementary
process and complexity;
- comparability with other methods;
- learnability (with about 1 month of theory and 2 of practise);
- usability (it takes from a few hours to 2-3 days to size an average
- sharing with the user.
In very simple terms, the technique may be said to provide a
quantification of the information, from a logical point of view, that
enters, leaves, and is stored in a computer by running a software
application. By using the terms "internal" and "external"
we assume that a limit has been determined - a boundary distinguishing the
application to be quantified from other applications of the system. The
elements being counted relate to one another. In brief, the files inside
or outside the application (ILFs and EIFs) are referenced differently from
the elementary activities of Input (EI), Inquiry (EQ), and Output (EO);
the following are their primary purposes (the non-primary purposes are in
|External Input (EI)
|External Output (EO)
An example of
Input (EI) is provided by data acquisition, while an Inquiry (EQ)
is provided by simple answer to a question, and an example of Output (EO) is achieved
by printing out the calculated data; these activities make up the elementary
processes - the smallest units of action meaningful to the user.
Some verbs that indicate the elementary processes for an EI and generally
connected with one or more ILFs are: acquire, enter, add, send (by the
user), set up, import, populate, assign, plan, schedule, delete,
eliminate, modify, update, alter, accept, vary, review, check, validate,
The following list of verbs identify an EO and reference ILFs or EIFs:
provide (*), print (*), display (*), produce (*), transmit (*), export
(*), send (by the computer) (*), present (*), publish (*), calculate;
the verbs marked by asterisks (*) may also be EQs if they do not
Other verbs that indicate an EQ and reference ILFs or EIFs are: query,
search, decode, read, access, list.