1.	Adapting Function Points to Real-time Software
Alain Abran, Marcela Maya, Jean-Marc Desharnais, Denis St-Pierre
1.1	Abstract
A requirement for software productivity analysis and estimation is the ability to measure the size of a software product from the user’s viewpoint, that is, from a functional perspective rather than from a technical perspective. One example of such a measurement technique is Function Points (FP). FP are now widely used in the MIS domain, where it has become the ‘de facto’ standard in the industry.  However, FP have not enjoyed the same degree of acceptance in other domains, such as real-time software. This article reports on work carried out to adapt FP to the specific functional characteristics of real-time software.  The extension proposed, called Full Function Points (FFP), is described and the results of field tests are discussed.
1.1.1	Alain Abran Ph.D.
Software Engineering Management Research Laboratory
Département d'informatique
Université du Québec à Montréal
P.O. Box 8888 (Centre-ville)
Montréal (Québec) Canada, H3C 3P8
Phone:	514 - 987-3000 (8900)
Fax:	514 - 987-8477
E-mail: abran.alain@uqam.ca
Dr. Abran is the director of the Software Engineering Management Research Laboratory and a professor at Université du Québec à Montréal (Canada) where he teaches graduate courses in software engineering since 1993.  Dr. Abran also has over 20 years of industry experience in information systems development and software engineering. The maintenance measurement program he developed and implemented at Montreal Trust (Montreal, Canada) has received one of the 1993 Best of the Best awards from the Quality Assurance Institute (Orlando, Florida, USA).  Dr. Abran holds master degrees in Management Sciences (1974) and Electrical Engineering (1975) from University of Ottawa, and a Ph.D in Software Engineering (1994) from École Polytechnique de Montréal (Canada).  His research interests include software productivity and estimation models, risk management, functional size measurement models and econometrics models of software reuse.
1.1.2	Marcela Maya M.Sc., C.F.P.S.
Software Engineering Management Research Laboratory
Département d'informatique
Université du Québec a Montréal
P.O. Box 8888 (Centre-ville)
Montréal (Québec) Canada H3C 3P8
Phone:	514 - 987-3000 (6647)
Fax:	514 - 987-8477
E-mail:	maya.marcela@uqam.ca
Ms. Maya is currently a research assistant at the Université du Québec à Montréal, Montreal, Canada. With over 10 years of experience in management of information systems, she joined the Software Engineering Management Research Laboratory after receiving her Master's degree in software engineering at the same University. Her areas of interest are software metrics as applied to software maintenance processes and real-time systems, software reuse metrics and productivity models.  She is a Certified Function Points Specialist since 1996.
1.1.3	Jean-Marc Desharnais M.Sc., C.F.P.S.
Software Engineering Laboratory in Applied Metrics
7415 Beaubien East suite 509
Anjou (Québec) Canada H1M 3R5
Phone:	514 - 355-2872
Fax:	514 - 355-3600
E-mail:	desharnais.jean-marc@uqam.ca
Mr. Desharnais is a specialist in software engineering metrics. He has carried out a number of software engineering researches projects covering assessment, budgeting and productivity evaluation.  Mr. Desharnais has also evaluated productivity levels in several organizations and set up quantification programs to include the assessment, productivity, quality and budgeting of software maintenance. Mr. Desharnais holds master degrees in Computer Management and Public Administration. He is the owner of the Software Engineering Laboratory in Applied Metrics (SELAM). Certified Function Points Specialist since 1993, he has participated in several committees of the International Function Point Users Group (IFPUG). Actually, he is member of the IFPUG Education Committee.
1.1.4	Denis St-Pierre M.Sc., C.F.P.S.
Software Engineering Laboratory in Applied Metrics
7415 Beaubien East suite 509
Anjou (Québec) Canada H1M 3R5
Phone:	514 - 355-2872
Fax:	514 - 355-3600
E-mail:	Denis.St-Pierre@crim.ca
Mr. St-Pierre is an experienced Senior Software Metrics Consultant. Equipped with a Master's degree on Function Points, he has consulted widely to American, Asian and European firms.  Lately, he has developed an Integrated Corporate Measurement Framework as well as a Function Point Extension for Real-time Software. He founded and moderates the Internet Function Point Listserv comprising 700 members.  A significant number of industrial and scientific articles were published by him. Certified Function Points Specialist since 1993, he has participated in developing Case Studies and Guidelines to Software Measurement for the International Function Point Users Group (IFPUG).  Mr. St-Pierre is co-author of the IFPUG Standard, and is a member of the Counting Practices Committee since 1993.
1.2	Acknowledgments
This project was carried out by the Software Engineering Management Research Laboratory at the Université du Québec à Montréal and by its industrial partner, the Software Engineering Laboratory in Applied Metrics (SELAM).  We thank Nortel, Bell Canada, Hydro-Québec and a Japanese industrial partner for providing project funds, industrial data and valuable feedback from real-time software practitioners.
<a href="http://www.nortel.com"><img SRC="images/nortel.gif" ALT="NORTEL (Northern Telecom)" HSPACE=5 VSPACE=5 BORDER=0 height=41 width=95 align=ABSCENTER></a>
<a href="http://www.bell.ca"><img SRC="images/belllogo.gif" ALT="Bell Canada" HSPACE=5 VSPACE=5 NOSAVE BORDER=0 height=60 width=110 align=CENTER></a>
<a href="http://www.hydroquebec.com/"><img SRC="images/hydro.gif" ALT="Hydro-Québec" HSPACE=5 VSPACE=5 BORDER=0 height=50 width=112 align=CENTER></a>
<img SRC="images/jsr_logo.gif" ALT="JSR" height=42 width=98 align=ABSCENTER>
2.	Introduction
Software measurement is essential for effective software management.  Measures can be used to quantify the software product as well as the process by which it is developed.  Once these measures are obtained, they can be used, for example, to build cost estimation models, productivity models and cost-benefit models.  One important measure is the size of a software product.  There are basically two kinds of size measures: technical measures and functional measures.  Technical measures are used to measure software products and processes from a developer’s point of view.  They can be used in efficiency analysis to improve, for example, the performance of designs. Functional measures are used to measure software products and services from a user’s perspective. Being independent of technical development and implementation decisions, functional measures can therefore be used to compare the productivity of different techniques and technologies.
Function Points (FP), first introduced by Allan Albrecht of IBM in 1979 (Albrecht, 1979), are an example of a functional size measure.  FP measure the size of software in terms of its delivered functionality, measuring such objects as inputs, outputs and files.  Since FP were developed in an MIS environment, its concepts, rules and guidelines are adapted to software that is oriented toward that environment.  As a result, FP have gained a wide audience in this specific area of software applications and are now being used extensively to, among other things, analyze productivity and estimate project costs.  Nevertheless, FP have not achieved the same degree of acceptance in other software areas.
This article presents a measurement technique to extending FP to take into account functional characteristics specific to real-time software which is called Full Function Points (FFP).  FFP were designed with the objective of retaining the actual FP quality characteristics from a measurement technique perspective, including instrumentation, repetitiveness and applicability.  This extension takes into consideration current industry practices in the design of real-time software and of what is currently documented regarding the user requirements from a functional perspective.
FFP are based on the observation that real-time software has the following specific transactional and data characteristics:
•	Transactions:  The number of sub-processes of a real-time process varies substantially.  By contrast, processes of the same type in the MIS domain have a more stable number of sub-processes.
•	Data: There exist of a large number of single control data in a real-time software, that is, data characterized by the fact that there is one and only one occurrence of the data in the whole application.  This data is used to control, directly or indirectly, the behavior of an application or of a mechanical devices.
New data and transactional function types were therefore introduced to take into account these characteristics: four control transactional function types (Entry, Exit, Read and Write) and two control data function types (Updated Control Group and Read-Only Control Group).
To verify whether or not FFP have met their stated objective of measuring the user functional requirements and the quality characteristics required for measurement methods, field tests were conducted.  The results of the field tests were positive: according to the real-time specialists present at the field tests, FFP have met its stated objective of measuring the user’s functional requirements adequately.  They believe that this has been done objectively, precisely and in an auditable manner, and that someone else with the same set of rules would come up with the same results.  They also believe that FFP counting procedures and rules are based on current practices of what is really being documented at the present time.
FFP are now being promoted to IFPUG and to other national software metrics associations.  They were presented at the IFPUG 1997 Fall conference (St-Pierre et al, 1997c) and three public reports are now available: FFP definition and concepts (St-Pierre et al, 1997a), FFP counting procedures and rules (St-Pierre et al, 1997b) and a complete case study (Maya et al, 1997).  These reports can be found at the following web sites: http://saturne.info.uqam.ca/Labo_Recherche/lrgl.html and http://www.lmagl.qc.ca.
The remaining of this article presents the key highlights of the new measure developed (FFP). Section 2 presents a literature review, section 3 the project objectives and the project plan, section 4 the new proposal for an FP extension for real-time software and section 5 the observations of the field tests.
3.	Literature review
For this project, an extensive literature review on FP was carried out.  Most of the publications on FP do not deal with the application of FP to real-time software, and the datasets used in most publications originated from MIS software applications.  Furthermore, several authors (Jones, 1991; Reifer, 1990; Whitmire, 1992; Galea 1995) concur that FP, with its current structure, are not adequate for measuring processor-intensive software with a high number of control functions and internal calculations.
Six previous attempts to adapt FP to real-time software have been identified: Feature Points (Jones, 1991), Mark II (Symons, 1988), Asset-R (Reifer, 1990), 3D Function Points (Whitmire, 1992), Application Features (Mukhopadhyay and Kerke, 1992), IFPUG Case Study 4 (IFPUG, 1997 Draft version [Oups! pas de référence dans la bibliographie]).
These attempts can be classified into five types of solutions:
•	Addition of new function types: Feature Points, Asset-R, 3D Function Points
•	Adjustment of the final function point count: Asset-R
•	Approximation of the final function point count: Application Features
•	Continuous adjustment tables: Mark-II
•	Orthodox approach: IFPUG Case Study 4
However, it seems that none of these approaches has succeeded in gaining market acceptance.
AS the 3D function points proposal had often been referred to as a potential candidate for real-time software in the FP electronic discussion forum, the decision was made to pre-test it on some industrial applications in order to obtain empirical observations, and, perhaps, use it as the starting point for the project.
Two different software applications from two different domains (telecommunications and power supply) were measured; the following problems were encountered:
•	The concepts and a few examples in (Whitmire, 1992) and the procedures and rules in (Galea, 1995) were not detailed enough to allow the identification, without ambiguity, of the proposed new function types (Transformations, States and Transitions).
•	For the identification of the proposed States and Transitions function types, documentation for the finite state machines (FSM) was a prerequisite.  However, at the industrial sites where this proposal was tested, this type of documentation was not in use.  Based on feedback from many real-time designers at other organizations, it has been observed that even though practitioners all know about this type of notation system, they did not document FSM.  To our surprise, we found that FSM was not an industry practice and that it was felt that a measurement technique based on such a documentation requirement would not have been practical. The feedback from these field tests and from other contacts gave us an indication that industry might be very reluctant to endorse a measurement method based on the documentation of FSM as they were not even doing it for the design of their own software.
4.	Project objectives and project plan
The objective of the project was to propose an extension to FP that, on the one hand, would take into account the specific functional characteristics of real-time software, and, on the other, would retain the quality characteristics of FP as a ‘de facto’ standard for a measurement method in the MIS domain.
Since ‘real-time software’ is one of those generic expressions that often means different things to different people (indeed, there is not even a consensus on a single definition among researchers in the field), here this expression refers to software with the characteristics described in the following definitions:
.	‘A system in which computation is performed during the actual time that an external process occurs, in order that the computation results can be used to control, monitor or respond in a timely manner to the external process.’ (IEEE, 1990).
.	‘Any system in which the time at which the output is produced is significant.  This is usually because the input corresponds to some movement in the physical world, and the output has to relate to that same movement.  The lag from input time to output time must be sufficiently small for acceptable timeliness.’  (Illingworth, 1991).
The focus was therefore on software that reacts to an external process or event subject to very tight time constraints.
The proposed FP extension would have to retain the key quality characteristics of FP from a measurement perspective, such as:
•	Relevance: The measurement technique is perceived by practitioners to adequately measure the functional size of their applications.
•	Measurement instrumentation: Instrumentation is an essential factor in achieving one of the quality attributes of a good measurement technique: repetitiveness. This means that different individuals, in different contexts and at different times and following the same measurement procedures will obtain measurement results that are relatively similar, that have been obtained with minimal judgment and that can be auditable. With FP, the basis of the measurement instrumentation is the measurement standard published by the International Function Point Users Group. A measurement method in the public domain.
•	A measurement technique that is practical, that is, based on current software design practices and on the content of the software documentation.
•	Preferably, transfer ability to a standard setting and monitoring body (this has been a key concept in measurement and measurement instrumentation since the time of the pharaohs in ancient Egypt!). 
The following five major steps were followed for this project:
1.	Literature Review.  This step consisted in conducting a literature review on three aspects: utilization of FP to measure real-time software, identification of extensions that had been proposed to adapt FP to this type of software and analysis of these proposals.
2.	Proposal of an extension to FP for real-time software.  From the analysis of previous attempts to extend FP, a new approach to adapting FP for the measurement of real-time software was developed.
3.	Field tests of the proposal. The third step of the project consisted in measuring some real-time software applications.  Since this project was supported and financed by three large North American organizations (power supply and telecommunications areas) and a Japanese organization (automotive), the measurement of at least one real-time application from each partner was conducted.
4.	Analysis of the counting results. The fourth step of the project consisted in carrying out an analysis of the measurement results and of the measurement process including (Jacquet and Abran, 1997):
•	Perception of the application specialists participating in the measurement sessions with respect to the coherence between the counting results and the size of the application measured.
•	Time required to identify and measure the function types.
•	Difficulty in learning and applying the basic concepts as well as the counting procedures and rules of the proposal.
•	Comparison between the measurement procedures and results obtained with the proposal and the standard version of FP (IFPUG, version 4.0).
5.	Public release. The last step of the project consisted in preparing a public release of the proposed measurement method including a description of the extension proposed, the counting procedures and rules, an overview of the field tests and comments on the counting results from an measurement instrumentation perspective.
Figure ‘Project Steps, Inputs & Deliverables’ illustrates the project steps, their inputs and their deliverables.  It is important to note that steps 2 and 3 are strongly related and interactive, that is, as the field tests were progressing, the proposal was improved based on the feedback obtained from the participants at the counting sessions.
5.	Proposal of a Function Points Extension for real-time software
This section first identifies the characteristics of real-time software that are difficult to tackle with the standard version of FP.  Next, the proposal to adapt FP to real-time software is presented.
5.1	Characteristics of real-time software
To measure the functional size of software, FP consider two function types: the transactional function type and the data function type.  The following transactional and data characteristics specific to real-time software that are difficult to capture with the current version of FP were identified:
5.1.1	Transactional characteristics
According to FP rules, transactional function types are based on the concept of the elementary process.  However, the number and nature of the steps or sub-processes required to execute the elementary process are not taken into account. According to empirical observations, MIS processes of the same type have a relatively stable number of sub-processes.  For example, a process that generates data sent to the user has, in general, four sub-processes: (1) receive the request from the user, (2) read the information needed, (3) make some calculations, and (4) send the information to the user. In the MIS environment, the number of sub-processes does not add any important information to the functional size of a given process.
In real-time software processes, by contrast, the number of sub-processes varies substantially. To illustrate this, consider the following two control processes:
Example 1 - An engine temperature control process. The main purpose of the process of this first example is to turn on the cooling system of the engine when necessary.  A sensor enters the temperature in the application (sub-process 1).  The temperature is compared to the overheating threshold temperature (sub-process 2).  Finally, a turn-on message could be sent to the cooling system if needed (sub-process 3). The application is not in a consistent state until all sub-processes of the temperature control process are completed.  The temperature control process has, therefore, 3 sub-processes (Table 1). According to standard FP rules, only one transactional function would be identified, because there is only one elementary process. 
Process	Sub-process description	# of sub-processes	
Engine control	Temperature entry	1	
	Read threshold for comparison	1	
	Send turn-on message	1	
	Total	3	
Table 1 - Sub-processes of example 1
Example 2 - An engine diagnostic process: The main purpose of the process of this second example is to turn on an engine alarm when necessary.  Fifteen engine sensors (all different) send data to the diagnostic process (15 sub-processes, one unique sub-process for each kind of sensor).  For each sensor, the set of external data received is compared to threshold values read from an internal file, one unique file for each kind of sensor (15 other sub-processes, one unique sub-process for each kind of sensor).  Depending on a number of conditions, an alarm on the dashboard may be turned on (1 sub-process). In this example, the engine diagnostic process consists of 31 sub-processes (Table 2). The application is not in a consistent state until all sub-processes of the diagnostic process are completed. According to IFPUG rules, only a minimum of transactional points would be counted because transactional function types are based on elementary processes rather than on sub-processes.  Therefore, when the IFPUG rules are used, examples 1 and 2 would have approximately the same number of points related to transactions even though the real-time community would strongly disagree that these two processes would have similar functional sizes.
Process	Sub-process description	# of sub-processes	
Engine diagnostic	Sensor data entry	15	
	Read thresholds for comparison	15	
	Send alarm message	1	
	Total	31	
Table 2 - Sub-processes of example 2
There is a strong case to be made that an adequate functional measure of real-time software should take into account the fact that some processes have only a few sub-processes, while others have a large number of sub-processes.
5.1.2	Data characteristics
The typical MIS logical file has the following data structure: multiple occurrences of a record with each record having one or more fields. For example, an engine control application could have a group of data containing information on each cylinder (cylinder number, ignition timing, pressure, etc.).  The cylinder record is repeated more than once. This kind of group of data, called a multiple occurrence group of data here, has, therefore, the same typical structure as an Internal Logical File (ILF) or an External Interface File (EIF) in FP.
Real-time software typically contains a large number of single occurrence control data, that is, data used to control, directly or indirectly, the behavior of an application or of a mechanical device.  These data are characterized by the fact that there is one and only one occurrence of the data in the whole application. For example, the navigational system of an airplane calculates periodically the airplane’s position according to data received from external signals. These data are then used to control the airplane’s position. The airplane’s position is a single control datum with only one occurrence in the whole application, assuming the system does not store old positions.  The number of single control data in real-time software can be very important.  However, these kinds of data are very difficult to group into an ILF or EIF.  An extension of the ILF/EIF rules is therefore necessary to adequately measure single occurrence control data.
5.2	FP Real-time Extension: Full Function Points
To measure these functional characteristics of real-time software adequately, it is necessary to consider both the sub-processes executed by a control process as well as the single occurrence control data. The extension proposed, called Full Function Points (FFP), introduces new transactional function types (Entry, Exit, Read and Write) and data function types (Updated Control Groups and Read-only Control Groups) to measure these characteristics (St-Pierre et al., 1997a, 1997b).  Definitions of these new function types are presented in Box B.
The new function types are only used to measure real-time control data and processes. The other types of data and processes, called management data and processes in FFP, are measured with the standard IFPUG rules, as illustrated in figure ‘FFP Framework’.
Thus, the unadjusted count of an application using the proposed extension can be expressed as follows:
	FFP	=	Management FP + Control FP
		=	(FP - Control information) + Control FP
The identification of the new control transactional function types of an application includes the following major steps (St-Pierre et al., 1997b):
1.	Look for the different processes executed by the application from a functional perspective;
2.	Determine if the process is a management process or a control process. If it is a management process, the FP transactional function types are identified using IFPUG counting procedures and rules.  If it is a control process, the following steps are followed:
3.	Identify the different sub-processes, from a function perspective, executed by the process;
4.	For each sub-process, determine whether to count it as an Entry, Exit, Read or Write function type, according to their definitions and counting rules;
5.	Assign the corresponding points.
The complete set of FFP counting procedures and rules, as well as a counting example, can be found in (St-Pierre et al., 1997b).
5.3	Comparing FFP and FP function types
To illustrate the key differences between FFP and FP function types, let us compare two of them which seem similar: Entries from FFP and Inputs from FP.  An Entry refers to a group of control data received by a process from a user outside the application boundary (Figure ‘FFP - External Control Entry’), that is, the action (or sub-process) of receiving a group of data from the user.  An Input, in contrast, refers to a whole process that receives a group of data from the user and updates a logical file in some cases (depending on the type of data).  An Input, as defined by IFPUG, can also read a logical file and send information to the user (Figure ‘FP - External Input’).  In FFP, the sub-processes of updating logical files, reading logical files and sending information to the user are counted as separate function types.
We can say that FFP take into account a finer level of granularity, the sub-process level, while FP only consider only the process level.  A finer level of granularity is important in real-time software, since its processes have a variable number of sub-processes compared to MIS software, and, as is illustrated in section ‘Characteristics of real-time software’, this is an important element to consider in the measurement of the functional size of real-time software.
6.	Field tests of the extension proposal
6.1	Field test context
The objective of the field tests was to measure some real-time software applications to verify in an empirical way the applicability of the concepts proposed, answering the following questions:
•	Do the users of the measurement technique agree that the proposed measure has met its stated objective of measuring the functional size of real-time software?
•	Is the proposed measure ‘good enough’ from the users’ own perspective in the sense that it is achieving the right balance of multiple simultaneous goals, even though any one goal might not have been achieved optimally (Bach, 1997)?
•	Do the users agree that the extension proposal has been desgined objectively, precisely and in an auditable manner, and that someone else with the same set of rules would come up with the same results (relatively, and again ‘good enough’) ?
•	Do the users agree that the proposed measurement procedures are based on current practices of what is effectively documented at the present time?
To answer these questions, it was mandatory that an application specialist be present at the counting sessions. Due to the typical industrial constraints, such as the availability of application specialists, site measurement sessions were kept to two-day sessions.  Therefore, the industrial partners had to select small applications or a self-contained portion (± 25.000 LOC) of a medium or large application. The software applications were measured with the extension proposed as well as with the standard version (IFPUG version 4.0) to be able to make some comparisons.
Three field tests were conducted between December 1996 and March 1997. For the measurement of these three applications, at least three people participated in the counting sessions: at least one application specialist and two certified function point specialists who were members of the design team of FFP.
6.2	Analysis of the counting results
Table 3 presents the FP and FPP counting results for the transactional function types.  It can be observed that in the presence of multiple sub-processes of a single process, FP produce less points than FFP.  Indeed, FP have been criticized for generating, in a real-time environment, low FP counts (Jones, 1991; Galea, 1995) which seem unrelated to the perceived functional size of the software measured (Galea, 1995).  Since FFP take into account the sub-processes integrated within in a single control process by identifying the different groups of data received, sent, read and written, they will generate more points than the standard FP, as is the case here.  In fact, real-time specialists strongly agree that a measure not taking into account user requested sub-processes, like FP, cannot be a ‘good enough’ functional size measure of their applications.  Therefore, FFP results will represent for them a more relevant measure of the functional size of their applications.
<!-- Mise en commentaire, les tableaux un peu sophistiqués ne sont pas (encore) bien rendus
	Application  A	Application  B	Application C	
Function Type	Occurrences	Points	Occurrences	Points	Occurrences	Points	
Function Points (IFPUG 4.0)							
   - External Input (EI)	40	202	6	21	15	50	
   - External Output (EO)	2	14	2	11	17	73	
   - External Inquiry (EQ)	12	40	1	6	0	0	
  Total Points	54	256	13	69	32	123	
Full Function Points (FFP)							
   - External Control Entry (ECE)	123	123	10	10	67	69	
   - External Control Exit (ECX)	93	97	8	10	136	139	
   - Internal Control Read (ICR)	395	403	14	18	100	103	
   - Internal Control Write (ICW)	142	154	8	8	165	168	
  Total Points	753	777	45	83	468	479	
Table 3 - FFP and FP counting results for transactional function types
Ci-dessous la version modifiée à la main -->
<!-- la table manuelle -->
<TABLE BORDER=2 ALIGN=center WIDTH=100%>
<CAPTION><P><A NAME="_Ref394205771"></A><A NAME="_Ref394205758"></A>Table 3 <A NAME="_Ref394205774"></A>- FFP and FP counting results for transactional function types</P></CAPTION>
<TR>
<TD ROWSPAN=2 VALIGN=bottom><P><b>Function&nbsp;Type</b></P>
</TD><TD COLSPAN=2 ALIGN=center><P><b>Application&nbsp;&nbsp;A</b></P>
</TD><TD COLSPAN=2 ALIGN=center><P><b>Application&nbsp;&nbsp;B</b></P>
</TD><TD COLSPAN=2 ALIGN=center><P><b>Application&nbsp;C</b></P>
</TD><TR>
<TD ALIGN=center><P><b>Occurrences</b></P>
</TD><TD ALIGN=center><P><b>Points</b></P>
</TD><TD ALIGN=center><P><b>Occurrences</b></P>
</TD><TD ALIGN=center><P><b>Points</b></P>
</TD><TD ALIGN=center><P><b>Occurrences</b></P>
</TD><TD ALIGN=center><P><b>Points</b></P>
</TD><TR>
<TD COLSPAN=7><P><b>Function&nbsp;Points&nbsp;(IFPUG&nbsp;4.0)</b></P>
</TD><TR>
<TD><P>&nbsp;&nbsp;&nbsp;-&nbsp;External&nbsp;Input&nbsp;(EI)</P>
</TD><TD ALIGN=center><P>40</P>
</TD><TD ALIGN=center><P>202</P>
</TD><TD ALIGN=center><P>6</P>
</TD><TD ALIGN=center><P>21</P>
</TD><TD ALIGN=center><P>15</P>
</TD><TD ALIGN=center><P>50</P>
</TD><TR>
<TD><P>&nbsp;&nbsp;&nbsp;-&nbsp;External&nbsp;Output&nbsp;(EO)</P>
</TD><TD ALIGN=center><P>2</P>
</TD><TD ALIGN=center><P>14</P>
</TD><TD ALIGN=center><P>2</P>
</TD><TD ALIGN=center><P>11</P>
</TD><TD ALIGN=center><P>17</P>
</TD><TD ALIGN=center><P>73</P>
</TD><TR>
<TD><P>&nbsp;&nbsp;&nbsp;-&nbsp;External&nbsp;Inquiry&nbsp;(EQ)</P>
</TD></TD><TD ALIGN=center><P>12</P>
</TD><TD ALIGN=center><P>40</P>
</TD><TD ALIGN=center><P>1</P>
</TD><TD ALIGN=center><P>6</P>
</TD><TD ALIGN=center><P>0</P>
</TD><TD ALIGN=center><P>0</P>
</TD><TR BGCOLOR=Silver>
</TD><TD><P><b>&nbsp;&nbsp;Total&nbsp;Points</b></P>
</TD><TD ALIGN=center><P><b>54</b></P>
</TD><TD ALIGN=center><P><b>256</b></P>
</TD><TD ALIGN=center><P><b>13</b></P>
</TD><TD ALIGN=center><P><b>69</b></P>
</TD><TD ALIGN=center><P><b>32</b></P>
</TD><TD ALIGN=center><P><b>123</b></P>
</TD><TR>
<TD COLSPAN=7><P><b>Full&nbsp;Function&nbsp;Points&nbsp;(FFP)</b></P>
</TD><TR>
</TD><TD><P>&nbsp;&nbsp;&nbsp;-&nbsp;External&nbsp;Control&nbsp;<b>Entry</b>&nbsp;(ECE)</P>
</TD><TD ALIGN=center><P>123</P>
</TD><TD ALIGN=center><P>123</P>
</TD><TD ALIGN=center><P>10</P>
</TD><TD ALIGN=center><P>10</P>
</TD><TD ALIGN=center><P>67</P>
</TD><TD ALIGN=center><P>69</P>
</TD><TR>
<TD><P>&nbsp;&nbsp;&nbsp;-&nbsp;External&nbsp;Control&nbsp;<b>Exit</b>&nbsp;(ECX)</P>
</TD><TD ALIGN=center><P>93</P>
</TD><TD ALIGN=center><P>97</P>
</TD><TD ALIGN=center><P>8</P>
</TD><TD ALIGN=center><P>10</P>
</TD><TD ALIGN=center><P>136</P>
</TD><TD ALIGN=center><P>139</P>
</TD><TR>
<TD><P>&nbsp;&nbsp;&nbsp;-&nbsp;Internal&nbsp;Control&nbsp;<b>Read</b>&nbsp;(ICR)</P>
</TD><TD ALIGN=center><P>395</P>
</TD><TD ALIGN=center><P>403</P>
</TD><TD ALIGN=center><P>14</P>
</TD><TD ALIGN=center><P>18</P>
</TD><TD ALIGN=center><P>100</P>
</TD><TD ALIGN=center><P>103</P>
</TD><TR>
<TD><P>&nbsp;&nbsp;&nbsp;-&nbsp;Internal&nbsp;Control&nbsp;<b>Write</b>&nbsp;(ICW)</P>
</TD><TD ALIGN=center><P>142</P>
</TD><TD ALIGN=center><P>154</P>
</TD><TD ALIGN=center><P>8</P>
</TD><TD ALIGN=center><P>8</P>
</TD><TD ALIGN=center><P>165</P>
</TD><TD ALIGN=center><P>168</P>
</TD><TR BGCOLOR=Silver>
<TD><P><b>&nbsp;&nbsp;Total&nbsp;Points</b></P>
</TD><TD ALIGN=center><P><b>753</b></P>
</TD><TD ALIGN=center><P><b>777</b></P>
</TD><TD ALIGN=center><P><b>45</b></P>
</TD><TD ALIGN=center><P><b>83</b></P>
</TD><TD ALIGN=center><P><b>468</b></P>
</TD><TD ALIGN=center><P><b>479</b></P>
</TD></TABLE>
<!-- le tableau manuel -->
The results of the field tests also confirmed that the number of sub-processes of a real-time process varies substantially.  For example, there were processes with only 3 sub-processes, while others had over 50 sub-processes.
One of the project’s industrial partners conducted a fourth field test without the assistance of the FFP specialists.  The feedback obtained from this industrial partner can be summarized as follows:
•	Concepts and counting procedures in the FFP counting manual were relatively clear and easy to understand. It was not difficult to count without the assistance of a FFP specialist.
•	FFP counted 79 processes out of the 81 they expected were there to be counted, with an adequate functional size measure.  At the end of the field test they concluded that FFP failed to count only 2 of the 81 processes, and this was because FFP do not count processes containing only internal algorithms.  The FFP count coverage rate was therefore 97% of their optimal coverage target.
Based on feedback from the counting sessions, the following observations were also made:
6.2.1	Ease of understanding
One criticism often made of FP is that the set of definitions and procedures are complex and time consuming, and that it takes a FP expert to produce an accurate FP count.  The new function types have been designed to be simpler to learn and master. This was confirmed during the field tests counting sessions where once the application specialists understood the definitions of the new function types, they had no problem identifying them.  Indeed, after a full day of FFP counting, they were able to count with limited assistance. According to application specialists participating in the counting sessions, this is mostly due to the fact that it is much easier to identify function types that only refer to one type of action (for example, receiving data) as in FPP, than to identify function types that potentially refer to more than one, as in FP (some mandatory and some optional, and multiple possible combinations, some of which qualify as EIs, and others that do not). Furthermore, if the software is almost entirely real-time (with no MIS-type functions), the specialists do not even need to know about the much more complex IFPUG FP rules.
In addition, application specialists believed that the definitions, counting procedures and rules were clear and detailed enough, that different people would be able to come up with fairly similar results. They also believed that the proposed concepts and measurement procedures and rules were based on current practices of what is documented at the present time.
6.2.2	Counting effort
Regarding the effort required to measure an application, the FFP and FP counting efforts are found to be similar.  Even though more function types had to be counted with FFP, they were easily identified and therefore no greater effort was required.  Indeed, the application specialists seem to require less counting assistance from FP experts when counting with FPP than with FP, so the identification of more function types does not increase the counting effort.
6.2.3	Attribution of points
The counting results showed that the total number of points assigned to a particular function type is almost the same as the number of occurrences of the given function type (Table 3). This is explained by the fact that the majority of the function types are located in the first range of the table used to assign the points according to the number of fields (St-Pierre et al., 1997b).  One can therefore question the usefulness of the attribution of points.  It is important to note that the weights assigned to a particular function were chosen with the purpose of aligning the sizes of the new function types as much as possible with the FP weight assignment structure.  The weights may need to be re-calibrated later by a standard-setting body.
6.2.4	Early FFP counts
FP is often use to build estimation models based on the functional size of the project.  One can therefore inquire about the possibility of counting the new function types at an early stage of development (feasibility, for example) since they seem to require detailed specifications.  In practice, the FFP levels of detail (Entry, Exit, Read and Write) are similar to the FP ones (DET, FTR, RET: IFPUG, 1994).  To use FP at an early stage of development, the count must usually be approximated because not all the information is available. Over the years, a number of early count approximation methods have been developed for IFPUG FP.  Similar approximation methods can be developed for FFP.  Of course, FFP approximation methods should not be expected to be as mature as FP ones.
7.	Conclusion
The development of a FP extension for the measurement of real-time software was a challenge. It had to take into account not only the specific functional characteristics of real-time software in an adequate way, but also to retain the quality characteristics of FP as a measurement technique as well as to consider current industry practices in the design and documentation of this type of software.
Feedback from the industry about the extension proposed, Full Function Points (FFP), was positive. We are confident that this FFP measurement technique will expand the domain of applicability of FP and increase its relevance to industry.
8.	Box A: Function Points (FP) Overview
FP are a measurement technique for measuring the functional size of a software product.  It was introduce in 1979, and, in 1984, the International Function Point Users Group (IFPUG) was set up to clarify the rules, set standards and promote their use and evolution.  Since then, four major releases of the rules and standards have been published.  In this article, all references to FP definitions and measurement rules will be based on the most recent version (IFPUG, 1994).
The first step in calculating FP is to identify the counting boundary, that is, the border between the application or project being measured and the external applications, or the user domain.  A boundary establishes what functions are included in the function point count.
The next step consists in determining the unadjusted function point (UFP) count which reflects the specific countable functionality provided to the user by the application being measured.  Calculation of the UFP begins with counting five components or function types of the application: Internal Logical Files - ILF (files as conceived by the user, not physical files), External Interface Files – EIF (files accessed by the application, but not updated), Inputs (e.g. transactions), Outputs (e.g. reports) and Inquiries (e.g. on-line inquiries).  These function types are classified into two groups: data function types (ILF and EIF) and transactional function types (Inputs, Outputs and Inquiries).  The complexity of these function types is then classified as relatively low, average or high, according to a set of prescriptive standards based on the Data Element Types – DET (like fields), File Types Referenced – FTR (files used by the function types) and Record Element Types – RET (record types of a file).  After making this classification for each of the five function types, the UFP is computed using predefined weights.
The last step involves assessing the environment and processing complexity of the project or application as a whole.  The impact of fourteen general systems characteristics is rated on a scale of 0 to 5 in terms of their likely effect on the project or application.  A value adjustment factor is obtained which will adjust the UFP by a maximum of ±35% to produce the Adjusted Function Points (AFP).
A complete description of the FP, including definitions, procedures, counting rules and examples, is found in the Function Point Counting Practices Manual, Release 4.0, published by IFPUG (IFPUG, 1994).
9.	Box B: Full Function Points (FFP) New Function Types
9.1	New control data function types
•	Updated Control Group (UCG): A UCG is a group of control data updated by the application being counted.  It is identified from a functional perspective.  The control data live for more than one transaction.
•	Read-Only Control Group (RCG): An RCG is a group of control data used, but not updated, by the application being counted.  It is identified from a functional perspective.  The control data live for more than one transaction.
9.2	New control transactional function types
•	External Control Entry (ECE): An ECE is a unique sub-process identified from a functional perspective.  An ECE processes control data coming from outside the application’s boundary.  It is the lowest level of decomposition of a process acting on one group of data.  Consequently, if a process enters two groups of data, there are at least two ECEs.  In example 2 section 4.1, 15 sensors send data to the application (control data cross the application boundary).  Since there is a unique sub-process for each sensor, there are 15 ECEs.
•	External Control Exit (ECX): An ECX is a unique sub-process identified from a functional perspective.  An ECX processes control data going outside the application boundary.  It is the lowest level of decomposition of a process acting on one group of data.  Consequently, if a process exits two groups of data, there are at least two ECXs. In example 2, the sub-process that sends a message to the dashboard (control data sent outside the application boundary) is an ECX.
•	Internal Control Read (ICR): An ICR is a unique sub-process identified from a functional perspective.  An ICR reads control data.  It is the lowest level of decomposition of a process acting on one group of data.  Consequently, if a process reads two groups of data, there are at least two ICRs In example 2, 15 unique sub-processes read different kinds of threshold values at different times for comparison purposes.  Therefore, there are 15 ICRs.
•	Internal Control Write (ICW): An ICW is a unique sub-process identified from a functional perspective.  An ICW writes control data.  It is the lowest level of decomposition of a process acting on one group of data.  Consequently, if a process writes on two groups of data, there are at least two ICWs.
10.	References
Albrecht, A. J. (1979), ‘Measuring Application Development Productivity’, Proceedings of Joint Share, Guide and IBM Application Development Symposium, October 1997, pp. 83-92.
Bach, J. (1997), ‘Good Enough Quality: Beyond the Buzzword’, Computer, Vol. 30, No. 8, August 1997, pp. 96-98.
Galea, S. (1995), The Boeing Company: 3D Function Point Extensions, V2.0, Release 1.0, Boeing Information and Support Services, Research and Technology Software Engineering, June 1995.
IEEE, (1990).  IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE Std 610-1990, The Institute of Electrical and Electronics Engineers, Inc., New York, NY, 1990.
IFPUG (1994). Function Point Counting Practices Manual, Release 4.0, International Function Point Users Group - IFPUG, Westerville, Ohio, 1994.
Illingworth, V. (1991) (editor), Dictionary of Computing, Oxford University Press, 3rd edition, 1991, 510 pages.
Jacquet, J.-P. and Abran, A. (1997), ‘From Software Metrics to Software Measurement Methods: A Process Model’, presented at the Third International Symposium and Forum on Software Engineering Standards, ISESS ‘97, Walnut Creek (CA), 1997.
Jones, C. (1991), Applied Software Measurement - Assuring Productivity and Quality, McGraw-Hill, 1991, 493 pages.
[Oups! Pas cité dans le document]Jones, C. (1996), Applied Software Measurement - Assuring Productivity and Quality, McGraw-Hill, 1996, 618 pages.
Maya, M., St-Pierre, D. Abran, A. and Bourque, P. (1997), Full Function Points: Function Points Extension for Real-Time Software – Case Study, Software Engineering Management Research Laboratory, Université du Québec à Montréal, Technical Report 1997-05, September 1997, 17 pages.
Mukhopadhyay, T. and Kekre, S. (1992), "Software Effort Models for Early Estimation of Process Control Applications", IEEE Transactions on Software Engineering, Vol. 18, No. 10,  October 1992, pp. 915-924.
Reifer, D. J. (1990), ‘Asset-R: A Function Point Sizing Tool for Scientific and Real-Time Systems’, Journal of Systems and Software, Vol. 11, No. 3, March 1990, pp. 159-171.
St-Pierre, D., Maya, M., Abran, A. and Desharnais, J-M. (1997a), Full Function Points: Function Points Extension for Real-Time Software - Concepts and Definitions, Software Engineering Management Research Laboratory, Université du Québec à Montréal, Technical Report 1997-03, March 1997, 18 pages.
St-Pierre, D., Maya, M., Abran, A. Desharnais, J-M. and Bourque, P. (1997b), Full Function Points: Function Points Extension for Real-Time Software - Concepts, Definitions and Procedures, Software Engineering Management Research Laboratory, Université du Québec à Montréal, Technical Report 1997-04, September 1997, 43 pages.
St-Pierre, D., Abran, A., Araki, M. and Desharnais, J-M. (1997c), Adapting Function Points to Real-Time Software, IFPUG 1887 Fall Conference, Scottsdale, AZ, September 15-19, 1997.
Whitmire, S. A. (1992), ‘3-D Function Points: Scientific and Real-Time Extensions to Function Points’, Proceedings of the 1992 Pacific Northwest Software Quality Conference, June 1, 1992.
Whitmire, S. A. (1995), ‘An Introduction to 3D Function Points’, Software Development, April, 1995, pp. 43-53.