Figure 1: FPA components
Alain Abran and Marcela Maya
Université du Québec à Montréal
P.O. Box 8888 (Centre-Ville)
Montréal (Québec), Canada
H3C 3P8
Tel: (514) 987-3000 ext. 8900, 6647; Fax: (514) 987-8477
Email:
abran.alain@uqam.ca,
maya.marcela@uqam.ca
This position paper addresses the measurement of software reuse from a functional perspective rather than from a technical perspective. Many studies have observed that the potential for reuse in software goes far beyond the reuse of source lines of code and includes data, architecture, design, program and common subsystem modules, documentation, test data and various intangibles. These issues are not tackled by reuse metrics based only on lines of code as the unit of measurement. In 1995, Abran and Desharnais proposed the first version of functional reuse metrics based on the Function Point Analysis (FPA) technique. They illustrated how these metrics could be used to take into account the benefits of reuse in a cost-benefit analysis. We are currently working on the refinement and extension of these functional reuse metrics. This empirical research project includes three phases: (1) test of the proposed functional metrics with other industrial datasets; (2) exploration of its limitations and potential extensions, through the design of much more complex simulated case studies using the data collected in the first phase of the project; and (3) design and test of an improved version of the proposed metrics. In this position paper we will present our current work in progress on this subject.
Keywords: Reuse measurement, Functional reuse, Reuse metrics, Function Point Analysis.
Workshop Goals: Learn and exchange information about reuse measurement.
Working Groups: Validation of Reuse Economic Models: Issues and Actions.
Software metrics constitute an important tool in effective software management. Metrics can be used to measure the software product as well as the process by which it is developed. Once the metrics are obtained, they can be used, for example, to build cost estimation models, productivity models and cost-benefit models. However, metrics and models for these purposes, as often discussed in the literature, do not take into account the reusability concepts. When these concepts are taken into account, it is with some measure of reusability at the code level. There is therefore a scarcity of measures of reusability from a management and user perspective. In this position paper, we present our current research in reuse metrics that are not based on the technical perspective of the software, but on its functional perspective.
A review of reuse metrics and reuse cost-benefit models shows that these metrics and models are mostly based on the technical perspective of software [1], with the lines of code being the measurement unit par excellence. In [1] it is reported that, although lines of code have well-known deficiencies as a unit of measure, they are simple to understand, easy to collect and compare, and difficult to distort. However, a number of studies have observed that the potential for reuse in software goes far beyond the reuse of source lines of code and includes data, architecture, design, program and common subsystems modules, documentation, test data and various intangibles [2]. These issues are not tackled by reuse metrics based only on lines of code as the unit of measurement.
Another unit used in software measurement is Function Point Analysis (FPA). FPA gives a measure of the functionality provided by a software application to the user. It measures functionality from the user's point of view, that is, on the basis of what the user requests and receives in return. In 1995, Abran and Desharnais proposed the first version of functional reuse metrics based on FPA, and we are interested in the refinement and extension of these metrics.
Subsection 2.1 presents an overview of FPA. Subsection 2.2 describes the functional reuse metrics introduced by Abran and Desharnais [3]. It shows how FPA can be used to identify and quantify functions which do not have to be redeveloped. Subsection 2.3 presents our current work to refine and extend these functional reuse metrics. Finally, section 3 compares our research project with similar work done by other researchers.
FPA, was first published in 1979 [4], and in 1984 the International Function Point User Group (IFPUG) was set up to clarify the rules, write the standards and promote their use and evolution. Since then, four major releases of the rules and standards have been published. In this paper, all references to FPA definitions and measurement rules will be based on the most recent version published in 1994 [5].
The first step in calculating Function Points (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. Figure 1 illustrates the boundary between an application and the user and other applications. It is important to note that the concept of a ``user'' is not equivalent to, nor restricted to, a human being. Other types of users such as mechanical devices are also admissible.
The next step consists in determining the unadjusted function point count (UFPC) which reflects the specific countable functionality provided to the user by the project or application. Calculation of the UFPC begins by counting five function types: Two data function types and three transactional function types. The five function types counted are (see Figure 1):
The complexity of these function types is then classified as relatively low, average or high, according to a set of standards which defines complexity in terms of objective guidelines. After classifying each of the five function types, the UFPC is computed using predefined weights for each component.
The last step involves assessing the environment and the processing
complexity of the project or application as a whole. The impact
of fourteen general system characteristics is rated on a scale from 0
to 5 in terms of the likely effect of these characteristics on the
project or application. We obtain the value adjustment factor
that will adjust the UFPC by a maximum of 
% to produce the
FP.
The basis of the Abran and Desharnais proposal on the measurement of functional reuse is formed by the FPA definitions of Boundary and EIF. As explained in the previous section, the boundary determines what function types should be measured or not measured. This boundary is specific to FPA and does not necessarily map to the physical boundaries in terms of lines of code, routines, programs and software applications.
In the same way, the FPA definition of an EIF does not map to the traditional view of an interface. The traditional view would classify all interactions across the physical boundaries of the measured application as interfaces, either manual or automated. In FPA, an EIF is defined as ``a user identifiable group of logically related data or control information referenced by the application, but maintained within the boundary of another application'', that is, data or control information is maintained outside the boundary of the project or application being measured. Based on this definition of an EIF, none of the conventional inter-application interfaces belongs to this function type. In FPA, such interactions are classified as transactional function types (EI, EO or EQ).
According to these FPA definitions, only data read from other applications which are not updated by the measured application qualify as EIFs. Only data files that have already been created with an updating mechanism computerized outside the measured application qualify as EIFs. This concept is explicitly stated in one of the identification rules of an EIF which says: ``The group of data is counted as an ILF for at least one other application". In figure 1, this concept is represented by the dotted line.
When the definition of the EIF is analyzed taking into account the reuse concepts used in software engineering, there is an interesting mapping between the EIF definition and the conventional interpretation of data reused ``as is'', without modification, which is called ``black-box reuse''. We can then say that an EIF is a reuse logical file. Therefore, FPA definitions and rules provide a means to identify and measure some specific dimensions of reuse, that is, black-box data reuse. This concept is referred to as the reuse indicator [3].
However, FPA does not allow the direct identification of transactions that are reused, that is, the identification of transactions that do not have to be re-developed because they already exist in the application that maintains the reused data. To address this issue, Abran and Desharnais introduced the concept of the predictor ratio. Based on information on previous projects about the distribution of the function points by function type, the avoidance of the development of transactions is derived. This is called the predictor ratio of the reference database. When the transaction predictor ratio is combined with the data reuse indicator, it provides an indication of the size in FP of the avoided transactions or the transactions reused and not redeveloped. The FP of the avoided transactions can then be added to the FP of the application, to obtain an alternative functional size that takes into account the transactions avoided and not redeveloped.
In their paper, Abran and Desharnais analyzed a dataset from a single industrial site using these functional reuse metrics. Using a case study, they also illustrated how to take into account the benefits of functional reuse in a cost-benefit analysis by deriving the unit cost per function delivered including reusable functions utilized but not developed within a project or application.
The literature on the benefits of software reuse is fairly extensive. However, most of the published work in the areas of cost-benefit analysis and productivity gains with software reuse consists, in fact, of statements of hypotheses, and validated results are rare [6]. He says that more empirical and experimental work is required on software reuse, but, at the same time, there is a lack of validated measurements tools and techniques to support not only the experimental work, but also the design of reuse models. Measurement tools and techniques are needed to quantify the impact of reuse through the derivation of reuse value metrics.
The functional reuse metrics proposed by Abran and Desharnais has good potential for use as a tool to support experimental work and the design of reuse models. As mentioned before, the actual measures of reuse are based on the technical perspective of the content of software, basically lines of code, even though its limits are well known. The Abran and Desharnais proposal is based on the functional perspective of the software, that is, on the basis of WHAT the user requests and receives in return, and not on the basis of HOW it was developed and implemented. This measure of reuse can then be integrated into productivity analysis to analyze the impact of functional reuse on development cost, as illustrated by Abran and Desharnais.
However, the work of Abran and Desharnais has only been used to analyze a dataset from a single industrial site. It was also illustrated with the simulation of a single case study. More empirical evidence is needed, therefore, in order to demonstrate its usefulness with empirical data.
Our current work-in-progress includes three phases designed to improve these metrics:
There are other reports on reuse metrics available [1, 7]. However, these metrics, in general, use lines of code as the unit of measurement. These types of metrics are useful to measure reuse from a technical perspective and from a developer's point of view. They can be used for efficiency analysis to improve the performance of the designs, for example.
Functional measures that are independent of the technical development and implementation processes are needed to measure the performance of products and processes, from a management and from a user's perspective. They are also needed for productivity analysis. FPA is a functional measure with these characteristics. If reuse can be measured from a functional perspective, as proposed by Abran and Desharnais, this measure of reuse can then be integrated into productivity models to analyze the impact of functional reuse.
We are not aware of other reuse metrics using functional units as the unit of measurement, as does the one proposed here. In some reuse models [1, 7], it is possible to substitute lines of code with FPA in the formulas. This requires, however, that the reused functions have already been identified, and that this process be carried out correctly and accurately. The proposed method addresses these prerequisites through the identification of reused data functions (reuse indicator), as well as avoided functions (predictor ratio of avoided transactional functions).
Alain Abran is the Director of the Software Engineering Management Research Laboratory and a professor at the Université du Québec à Montréal (Canada) where he has been teaching graduate courses in software engineering since 1993. With over 20 years of industry experience in information systems development and software engineering, Dr. Abran has consistently applied the concepts of reusability in order to achieve the project goals of quality and productivity. He has conducted extensive research in software measurement, software maintenance and software reuse. Dr. Abran holds Masters degrees in Management Sciences (1974) and Electrical Engineering (1975) from the University of Ottawa, and a Ph.D in Software Engineering (1994) from the École Polytechnique de Montréal (Canada). His research interests include software productivity and estimation models, risk management, functional size measurement models and econometric models of software reuse.
Marcela Maya is currently a research assistant at the Université du Québec à Montréal (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. One of her areas of interest is software reuse metrics and she is actively involved in the on-going work of the project presented in this paper. Her areas of interest are software metrics as applied to software maintenance processes and real-time systems, software reuse metrics and productivity models.