Measurement of Functional Reuse Alain Abran and Marcela Maya Universite du Quebec a Montreal P.O. Box 8888 (Centre-Ville) Montreal (Quebec), Canada H3C 3P8 Tel: (514) 987-3000 ext. 8900, 6647; Fax: (514) 987-8477 Email:
[email protected],
[email protected]
Abstract 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 rst 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 bene ts of reuse in a cost-bene t analysis. We are currently working on the re nement 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 rst 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.
Abran- 1
1 Background Software metrics constitute an important tool in e ective 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-bene t 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.
2 Position A review of reuse metrics and reuse cost-bene t 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 de ciencies as a unit of measure, they are simple to understand, easy to collect and compare, and dicult 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 rst version of functional reuse metrics based on FPA, and we are interested in the re nement 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 re ne and extend these functional reuse metrics. Finally, section 3 compares our research project with similar work done by other researchers.
2.1 FPA overview FPA, was rst 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 de nitions and measurement rules will be based on the most recent version published in 1994 [5]. The rst 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 Abran- 2
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. User
Inquires (EQ)
Measured Application User
Inputs (EI)
ILF EIF
Outputs (EO)
User
Other Applications
ILF
Boundary
Figure 1: FPA components The next step consists in determining the unadjusted function point count (UFPC) which re ects the speci c countable functionality provided to the user by the project or application. Calculation of the UFPC begins by counting ve function types: Two data function types and three transactional function types. The ve function types counted are (see Figure 1):
Data function types: Internal Logical File (ILF) and External Interface File (EIF). Transactional function types: External Input (EI), External Output (EO) and External Inquiry (EQ).
The complexity of these function types is then classi ed as relatively low, average or high, according to a set of standards which de nes complexity in terms of objective guidelines. After classifying each of the ve function types, the UFPC is computed using prede ned 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 e ect of these characteristics on the project or application. We obtain the value adjustment factor that will adjust the UFPC by a maximum of 35% to produce the FP.
2.2 Functional reuse measurement The basis of the Abran and Desharnais proposal on the measurement of functional reuse is formed by the FPA de nitions 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 speci c to Abran- 3
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 de nition 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 de ned as \a user identi able 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 de nition of an EIF, none of the conventional inter-application interfaces belongs to this function type. In FPA, such interactions are classi ed as transactional function types (EI, EO or EQ). According to these FPA de nitions, only data read from other applications which are not updated by the measured application qualify as EIFs. Only data les 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 identi cation rules of an EIF which says: \The group of data is counted as an ILF for at least one other application". In gure 1, this concept is represented by the dotted line. When the de nition of the EIF is analyzed taking into account the reuse concepts used in software engineering, there is an interesting mapping between the EIF de nition and the conventional interpretation of data reused \as is", without modi cation, which is called \black-box reuse". We can then say that an EIF is a reuse logical le. Therefore, FPA de nitions and rules provide a means to identify and measure some speci c 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 identi cation of transactions that are reused, that is, the identi cation 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 bene ts of functional reuse in a cost-bene t analysis by deriving the unit cost per function delivered including reusable functions utilized but not developed within a project or application.
2.3 Re nement and extension of the functional reuse metrics The literature on the bene ts of software reuse is fairly extensive. However, most of the published work in the areas of cost-bene t 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 Abran- 4
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:
The rst phase of the empirical research consists in testing the proposed metrics with other
industrial datasets. We are currently working on this phase. The second phase will consist in exploring the limitations and potential extension of these metrics through the design of further analytical tools, based on much more complex simulated case studies. The data collected at other industrial sites during the rst phase of the project will help to build these case studies. Based on the observations and lessons learned in the rst two phases of this empirical research, the third phase will consist in designing an improved version of the proposed metrics and their test through the design of another empirical data collection process with industrial data.
3 Comparison 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 eciency 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 identi ed, and that this process be carried out correctly and accurately. The proposed method addresses these prerequisites through the identi cation of reused data functions (reuse indicator), as well as avoided functions (predictor ratio of avoided transactional functions). Abran- 5
4 References References [1] J. Poulin, D. Hancock, and J. Caruso, \The Business Case for Software Reuse," IBM Systems Journal, vol. 32, no. 4, pp. 567{594, 1993. [2] R. Banker, R. Kau man, C. Wright, and D. Zweig, \Automating Output Size and Reuse Metrics in a Repository-Based Computer Aided Software Engineering CASE Environment," IEEE Transactions on Software Engineering, vol. 20, pp. 169{187, March 1994. [3] A. Abran and J. Desharnais, \Measurement of functional reuse in maintenance," Journal of Software Maintenance: Research and Practice, vol. 7, no. 4, pp. 263{277, 1995. [4] A. Albrecht, \Measuring Application Development Productivity," in Proceedings IBM Applications Development Symposium, pp. 34{43, October 1979. [5] IFPUG, Function Point Counting Practice Manual Release 4.0. International Function Point User Group, Westerville, OH, 1994. [6] W. Frakes, \Software Reuse Empirical Studies," in Software Reusability (W. Schafer, R. PrietoDiaz, and Y. Matsumoto, eds.), (New York, Toronto), Ellis Horwood, 1994. [7] J. Ga ney and R. Cruickshank, \A General Economics Model of Software Reuse," in Proceedings of 14th International Conference on Software Engineering, (New York), pp. 327{337, ACM Press, 1992.
5 Biography Alain Abran is the Director of the Software Engineering Management Research Laboratory and
a professor at the Universite du Quebec a Montreal (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 E cole Polytechnique de Montreal (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 Universite du Quebec a 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. 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.
Abran- 6
