ISO/IEC 29881:2010
(Main)Information technology — Systems and software engineering — FiSMA 1.1 functional size measurement method
Information technology — Systems and software engineering — FiSMA 1.1 functional size measurement method
ISO/IEC 29881:2010 specifies the set of definitions, conventions and activities of FiSMA 1.1. The target audience of ISO/IEC 29881:2010 includes anyone who applies FiSMA 1.1 to measure the functional size of a piece of software. FiSMA 1.1 is intended for use by those persons associated with the acquisition, development, use, support, maintenance, and audit of software. FiSMA 1.1 is based on an assessment of the Functional User Requirements. It measures the functional size of a piece of software from the perspective of the users.
Technologies de l'information — Ingénierie des systèmes et du logiciel — Méthode de mesure de la taille fonctionnelle FiSMA 1.1
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO/IEC
STANDARD 29881
Second edition
2010-08-15
Information technology — Systems and
software engineering — FiSMA 1.1
functional size measurement method
Technologies de l'information — Ingénierie des systèmes et du
logiciel — Méthode de mesure de la taille fonctionnelle FiSMA 1.1
Reference number
ISO/IEC 29881:2010(E)
©
ISO/IEC 2010
---------------------- Page: 1 ----------------------
ISO/IEC 29881:2010(E)
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2010
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO/IEC 2010 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC 29881:2010(E)
Contents Page
Foreword .iv
Introduction.v
1 Scope.1
1.1 Field of application for FiSMA 1.1.1
1.2 Limitations of FiSMA 1.1.1
1.3 Scope of FSM for FiSMA 1.1.1
2 Normative references.1
3 Terms and definitions .2
4 BFC Classes and BFC Types of FiSMA 1.1 .3
4.1 Interactive end-user navigation and query services (q).4
4.2 Interactive end-user input services (i).5
4.3 Non-interactive end-user output services (o).6
4.4 Interface services to other applications (t).6
4.5 Interface services from other applications (f) .6
4.6 Data storage services (d).7
4.7 Algorithmic and manipulation services (a).8
5 FiSMA 1.1 Measurement process .8
6 Counting rules for each BFC type class .10
6.1 Interactive end-user navigation and query BFC's (q).10
6.2 Interactive end-user input BFC's (i).10
6.3 Non-interactive end-user output BFC's (o).11
6.4 Interface BFC's to other applications (t) .11
6.5 Interface BFC's from other applications (f) .11
6.6 Data storage services (d).12
6.7 Algorithmic and manipulation services (a).12
7 Functional size measurement unit .12
8 Calculation of the FiSMA 1.1 functional size of a piece of software.12
9 Measurement reporting.13
10 Convertibility from FiSMA 1.1 to other FSM Methods .13
Annex A (informative) Glossary of terms relevant to FiSMA 1.1.14
Bibliography.16
© ISO/IEC 2010 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/IEC 29881:2010(E)
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. In the field of information
technology, ISO and IEC have established a joint technical committee, ISO/IEC JTC 1.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of the joint technical committee is to prepare International Standards. Draft International
Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication as
an International Standard requires approval by at least 75 % of the national bodies casting a vote.
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.
ISO/IEC 29881 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software and systems engineering.
This second edition cancels and replaces the first edition (ISO/IEC 29881:2008), of which it constitutes a
minor revision.
iv © ISO/IEC 2010 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC 29881:2010(E)
Introduction
Functional size is an essential measure for comparisons of software development activities and development
alternatives. Besides its uses in estimating and productivity analysis, functional size has proven to be useful in
project planning, tracking, control and contracting. Because Functional Size Measurement (FSM) works best
when there is a complete list of functional user requirements and services, it makes scope management and
change management effective, reliable and relatively easy to understand even to the end-user.
The correctness of counting parameters and thus the usefulness of an FSM method can be evaluated based
on the correlation between functional size and effort under similar environmental and technical circumstances
and quality requirements. This kind of evaluation may indicate a need to justify the counting parameters used
to derive functional size. FiSMA Functional Size Measurement Method Version 1.1 (referred to throughout this
International Standard as simply FiSMA 1.1) is a general, parameterized FSM method for all types of
software. It was developed by a working group of Finnish Software Measurement Association (FiSMA), to
replace the previous FSM method Experience 2.0 Function Point Analysis (FPA), which has been applied
largely in Finland since 1997. More than 600 software development projects were measured using that
method between 1997 and 2003.
The current values of constraints used in FiSMA 1.1 are derived from its predecessor Experience 2.0 FPA,
and were confirmed statistically to be correct. They may be updated in future releases of the FiSMA FSM
Method if the data collection and analysis demonstrate the need to do so.
For readers who are unfamiliar with FSM terminology, a review of terms is provided in Annex A, together with
definitions and explanations of the most important terms.
Results from FiSMA 1.1 and Experience 2.0 FPA are largely convertible with each other, if the source data
has been collected at the recommended detail level.
FiSMA 1.1 is based purely on Functional User Requirements (FUR). User requirements can be thought of as
functional (what the software does) and non-functional (how the software must perform, including quality
requirements). For FiSMA 1.1, the Functional User Requirements are the object of measurement. While some
FSM methods are process oriented, FiSMA 1.1 is service oriented. Process-oriented methods require the
identification of all functional processes supported by the piece of software. In contrast, service-oriented
methods, such as FiSMA 1.1, require identification of all different services provided by the piece of software.
The FiSMA 1.1 relationship chain between users and the developed piece of software involves user needs
and services as presented in Figure 1.
© ISO/IEC 2010 – All rights reserved v
---------------------- Page: 5 ----------------------
ISO/IEC 29881:2010(E)
Figure 1 — Links between user and a piece of software
While each audience may have its own reasons for size measurement, the typical user viewpoint is to
estimate the effort for a software project. Other important industry uses of FSM are presented in Figure 2.
Figure 2 — Common purposes of Functional Size Measurement
vi © ISO/IEC 2010 – All rights reserved
---------------------- Page: 6 ----------------------
INTERNATIONAL STANDARD ISO/IEC 29881:2010(E)
Information technology — Systems and software engineering —
FiSMA 1.1 functional size measurement method
1 Scope
This International Standard specifies the set of definitions, conventions and activities of FiSMA 1.1.
The target audience of this International Standard includes anyone who applies FiSMA 1.1 to measure the
functional size of a piece of software. FiSMA 1.1 is intended for use by those persons associated with the
acquisition, development, use, support, maintenance, and audit of software. FiSMA 1.1 is based on an
assessment of the Functional User Requirements. It measures the functional size of a piece of software from
the perspective of the users.
1.1 Field of application for FiSMA 1.1
FiSMA 1.1 is applicable to measure all software in any functional domain.
1.2 Limitations of FiSMA 1.1
FiSMA 1.1 has no limitations related to the type or quality of software to be measured.
1.3 Scope of FSM for FiSMA 1.1
The scope of the Functional Size Measurement for FiSMA 1.1 is determined by the purpose for measuring the
software. When using FiSMA 1.1, the set of FUR to be included depends on the purpose of the count and thus
may include the FUR for one piece of software or a set of pieces of software. Each piece of software within
the scope is measured separately and if more than one piece of software is included within a project, all of the
functional sizes may be added together. The scope of the FSM instance is always a subset of the overall user
requirements and includes purely the Functional User Requirements, in other words, “what” in terms of
services and tasks that the software must perform. The purpose of the FSM determines which FUR will be
included in the FSM instance.
NOTE 1 For example, if the purpose of the FSM is to determine the size of the first release of a piece of software, then
the size using FiSMA 1.1 will include only the FUR for the first release of the software.
NOTE 2 As another example, if the purpose of the FSM is to determine the supported size of an installed package,
only those functional user requirements in the package that are used by the organization will be included in the instance of
the FSM.
NOTE 3 FiSMA 1.1 only measures the size of the Functional User Requirements included within the scope as outlined
above.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO/IEC 14143-1:2007, Information technology — Software measurement — Functional size measurement —
Part 1: Definition of concepts
© ISO/IEC 2010 – All rights reserved 1
---------------------- Page: 7 ----------------------
ISO/IEC 29881:2010(E)
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply. Whenever a term is already
defined by ISO/IEC, such as “Functional Size Measurement”, the ISO definition has been adopted for this
method.
NOTE For users who are unfamiliar with Functional Size Measurement terminology, and to increase the usability of
this International Standard, a review of terms is provided in Annex A, together with definitions and explanations of the
most important terms.
3.1
BFC class
defined group of BFC types
3.2
boundary
conceptual interface between the software under study and its users
[ISO/IEC 14143-1:2007, definition 3.3]
NOTE The boundary of a piece of software to be sized using FiSMA 1.1 conceptually separates the piece and the
environment in which it operates, perceived from the external user perspective. The boundary provides the measurement
analyst(s) with a solid delimiter to distinguish, without ambiguity, what is included inside the measured software from what
is part of the measured software's operating environment.
3.3
data element
unique, user-recognizable, non-repeated field in a BFC
NOTE 1 A data element can be a character string, or a digital or graphical element in a BFC.
NOTE 2 The number of data elements is always greater than 0.
3.4
data store
organized and persistent collection of data and information that allows for its retrieval
[ISO/IEC 15939:2007]
3.5
end-user
any person that communicates or interacts with the software at any time
3.6
functional services
base functional components (BFC) defined by FiSMA 1.1
3.7
operation
arithmetic or logical operation performed in an algorithmic and manipulation BFC
NOTE The number of operations is always greater than 0.
3.8
reading reference
data storage entity or record, or interface record from another software or system containing data retrieved in
a BFC
NOTE The number of reading references is greater than or equal to 0 for all BFC types where it is applicable.
2 © ISO/IEC 2010 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/IEC 29881:2010(E)
3.9
user
any person or thing that communicates or interacts with the software at any time
3.10
writing reference
data storage entity or other record, or interface record to another software or system to which data is written in
a BFC
NOTE The number of writing references is greater than 0 with all BFC types where it is applicable.
4 BFC Classes and BFC Types of FiSMA 1.1
FiSMA 1.1 identifies seven distinct BFC classes:
• Interactive end-user navigation and query services (q)
• Interactive end-user input services (i)
• Non-interactive end-user output services (o)
• Interface services to other applications (t)
• Interface services from other applications (f)
• Data storage services (d)
• Algorithmic and manipulation services (a)
Each BFC class of FiSMA 1.1 further decomposes into several BFC types. All together there are 28 BFC
types. Figure 3 shows the relationships between the BFC classes and their component BFC types. Each BFC
Class is explained in the clauses that follow.
NOTE For ease of presentation, the following short form conventions have been used:
• Each of the seven BFC classes is denoted by a single alphabetic character as shown in Figure 3;
• Each BFC type is prefixed by its BFC class alphabetic character and an integer number that has been assigned
to it as denoted in Figure 3.
© ISO/IEC 2010 – All rights reserved 3
---------------------- Page: 9 ----------------------
ISO/IEC 29881:2010(E)
Interactive end user
navigation and query Interactive end user Non-interactive end
services (q) input services (i) user output services (o)
Entities/classes d1
Functional Services
Data storage services
(d)
of FiSMA 1.1
Other records d2
Interface services from Interface services to Algorithmic and
other applications (f) other applications (t) manipulations services (a)
Figure 3 — FiSMA 1.1 BFC classes and BFC types
Each of the 28 BFC types describes a unique and self-contained Functional User Requirement from the
perspective of the user. A service represents an independent FUR.
If the BFC classification of a service becomes a matter of opinion between the user(s) and developer(s), the
user viewpoint should prevail.
4.1 Interactive end-user navigation and query services (q)
This class of BFC involves data and/or services crossing the boundary into or out of the software. Interactive
end-user navigation and query services specify all parts of the interactive user interface where there is no
maintenance of persistent data stored in the system. Maintenance refers to any service where data is
changed as a result of the service and includes, for example, creating, updating or deleting.
The number of functional size units for each navigation and query service depends on the number of data
elements of the BFC and the number of unique entities that need to be referenced. (There is an indirect
relationship between the entities identified in this step as being referenced and the BFC types identified within
the BFC Class called data storage services. Each independent entity identified as a reference in this BFC type
must also be explicitly counted once in the software application stored data.)
In FiSMA 1.1, the BFC class “Navigation and query services” is divided into seven BFC types:
• Function designators (q1) are services that provide a uniquely identifiable visual way for a user to
indicate the specific service(s) to be performed.
NOTE End users may refer to function designators as “Icons”; however, this does not imply any particular design.
Function designators are an important part of interactive end-user navigation and query services, especially in the
case of graphical user interface (GUI).
4 © ISO/IEC 2010 – All rights reserved
Function
designator q1
Log-in, log-out
functions q2
Messages in f1
Function List q3
Batch records in f2
Selection lists q4
Signals in f3
Data inquiries q5
Generation
indicators q6
Browsing lists q7
1-functional i1
Messages out t1
2-functional i2
Batch records out t2
3-functional i3
Signals out t3
Security routines a1
Forms o1
Calculations a2
Reports o2
Simulations a3
Emails or text
messages o3
Formatting alg. a4
Monitor screens o4
Db cleaning a5
Other routines a6
---------------------- Page: 10 ----------------------
ISO/IEC 29881:2010(E)
• Log-in and log-out functions (q2) usually do not update persistent data. They control users' access and
prevent illegal use.
• Function lists (q3) are services to provide a set of pre-defined alternatives to enable a user to indicate
the specific service(s) to be performed.
NOTE End users may refer to these as “menus”; however, this does not imply any particular design.
• Selection lists (q4) show a list of acceptable parameter values to the end-user. Often they are very
simple, showing values of one single data item, but they may be more complicated.
NOTE There are many different ways to implement selection lists in practice, but there is no design implied. In
practice end users will refer to these functions as “drop-down lists”, “pop-up windows”, “combo boxes”, “list boxes”,
etc.
• Data inquiries (q5) show the specific contents of data store(s) to the end-user.
NOTE Inquiries are also called enquiries or queries.
• Generation indicators (q6) help the user to prepare the data and/or control information for a subsequent
service. Very often they are connected to some other type of functional services, such as a report or
manipulation routine.
NOTE End users may refer to generation indicators as “generation dialogs”; however, this does not imply any
particular design.
• Browsing lists (q7) show a list of similar data element groups, typically the most important details to help
filter the entities for further operations.
4.2 Interactive end-user input services (i)
This class of BFC involves data and/or services crossing the boundary into the software. Interactive end-user
input services specify all parts of the interactive user interface where there is maintenance of data store(s) of
the software. Data storage consists of logical entities (data records). Maintenance refers to any service where
data is changed as a result of the service, and includes, for example, creating, updating and deleting.
From a user's point of view, interactive end-user services perform those business tasks which change the
data contents of the software. From the information system point of view end-users manipulate system data
using interactive end-user services.
The number of functional size units of input functions depends on the number of different data elements of the
BFC measured, and the number of needed reading and writing references to unique entities.
(There is an direct relationship between the entities identified in this step as writing references and the BFC
types identified within the BFC Class: data storage services. Each independent entity identified as a writing
reference in this BFC type must also be explicitly counted once as stored data.)
In FiSMA 1.1, end-user input services are divided into three BFC types:
• 1-functional input dialogs (i1) support only one of the three maintenance types create, update or delete.
• 2-functional input dialogs (i2) support two of the three maintenance types create, update and/or delete.
• 3-functional input dialogs (i3) support all three maintenance types create, update and delete.
© ISO/IEC 2010 – All rights reserved 5
---------------------- Page: 11 ----------------------
ISO/IEC 29881:2010(E)
4.3 Non-interactive end-user output services (o)
This class of BFC involves data and/or services crossing the boundary out of the software. Non-interactive
end-user output services specify all parts of the user interface which are non-interactive and do not maintain
data store(s) of the software.
The number of functional size units of output functions depends on the number of different data elements of
the BFC and the number of needed reading references to entities.
(There is an indirect relationship between the unique entitites identified in this step as being referenced and
the BFC types identified within the BFC Class: data storage services. Each independent entity identified as a
reference in this BFC type must also be explicitly counted once as stored data.)
FiSMA 1.1 output services are divided into four BFC types:
• Output forms (o1) are services resulting in printed or displayed documents, which always present the
same layout (e.g a receipt).
• Reports (o2) are services resulting in printed or displayed documents, whose layout may vary within the
specified framework according to the presented data (e.g. product list or sales report).
• E-mails and text messages (o3) are services resulting in electronically transmitted output documents,
which have a standardised structure. The structure often contains title fields, data fields and optional
attachments.
• Monitor screen output (o4) services involve continuously displayed documents, which are updated
regularly in consequence of data changes (e.g. measurement display of a process).
4.4 Interface services to other applications (t)
This class of BFC involves data and/or services crossing the boundary out of the software. Interface services
to other applications specify all automatic data transfers that move data from the measured piece of software
to another application or any device.
The number of functional size units of outbound interface functions depends on the number of different data
elements of the BFC measured (i.e. the number of attributes) and the number of needed reading references to
entities.
(There is an indirect relationship between the entities identified in this step as being referenced and the BFC
types identified within the BFC Class: data storage services. Each independent entity identified as a reference
in this BFC type must also be explicitly counted once as stored data.)
FiSMA 1.1 outbound interface functions are divided into three BFC types:
• Messages to other applications (t1) are services where data groups are sent on-line, usually in
real-time, to any other application.
• Batch records to other applications (t2) are services where data groups are written to a temporary file
for transfer to another application.
• Signals to devices or other applications (t3) are services where data strings or single pieces of
information are sent to any other application or device (e.g. a LED).
4.5 Interface services from other applications (f)
This class of BFC involves data and/or services crossing the boundary into the software. Interface services
from other applications specify all automatic data transfers that receive data groups that are provided and sent
by another application or any device.
6 © ISO/IEC 2010 – All rights reserved
---------------------- Page: 12 ----------------------
ISO/IEC 29881:2010(E)
The number of functional size units of inbound interface services from other applications depends on the
number of different data elements of the BFC measured, and the number of reading and writing references to
entities.
(There is an indirect relationship between the entities identified in this step as being referenced and the BFC
types identified within the BFC Class: data storage services. Each independent entity identified as a writing
reference in this BFC type must also be explicitly counted once as stored data.)
FiSMA 1.1 divides this BFC class into three BFC types:
• Messages from other applications (f1) are services where data are received on-line, usually in real-time
from any other application.
• Batch records from other applications (f2) are services where data are received in groups or “batches”
from any other application.
• Signals from devices or other applications (f3) are services where data strings or single pieces of
information are received from any other application or device (e.g. a sensor).
4.6 Data storage services (d)
This class of BFC involves data storage associated with data crossing the boundary by means of another BFC
class into the software.
Data storage services specify a group or collection of related and self-contained data in the real world, about
which the user requires the software to provide one or more data stores. Data storage services are functional
services provided by the piece of software to satisfy these data storage requirements. These “groups or
collections of related and self-contained data” are often called entities, data groups, data classes or objects of
interest, depending on the terminology used in the development environment.
Data storage services result in data stores and make data available for maintenance, inquiry, or output.
NOTE Data storage services are typically implemented as tables in relational databases, or as records in data files in
general.
The number of functional size units of data storage services depends on the number of different data
ele
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.