Measurement of Functional Reuse in Maintenance - CiteSeerX

SOFTWARE MAINTENANCE: RESEARCH AND PRACIICE. VOL. 7.263-277 (1995)

Research

Measurement of Functional Reuse in Maintenance ALAIN ABRAN Computer Sciences Department, Universitt! du Quebec ri Montrt!al, C. P. 8888, Succ. Centre-We, Montreal QuPbec H3C 3P8, Canada

JEAN-MARC DESHARNAIS Software Management Laboratory in Applied Metrics, 7415 rue Beaubien Est, suite 509, Anjou Quebec HIM 3R5, Canada

SUMMARY This paper is concerned with the identification and measurement of reuse within projects in which functional enhancements have been added to existing software applications. The proposed approach is based on the measurement of reuse from a functional perspective rather than from a technical perspective. Two key concepts are introduced: a reuse indicator and a predictor ratio. The reuse indicator is derived from an analysis of the function types as currently defined in Function Points Analysis. The predictor ratio is derived from an understanding of the avoided-cost concept and of how it can be captured using historical databases of function points from previous development projects. This paper indicates how, in functional enhancement projects, the predictor ratio can be combined into the reuse indicator to derive an alternative size measure which takes into account functions reused and not redeveloped. The paper also demonstrates how these ratios can then be integrated in a maintenance productivity model to analyse the benefits of reuse by taking into account the avoided cost of functions reused. A case study based on an industrial data set is provided to illustrate the measurement of functional reuse in an enhancement project and its impact in maintenance productivity analysis. KEY WORDS: functional reuse measurement; maintenance measurement; function points

1. INTRODUCTION 1.1. Maintenance productivity issue Many organizations which started to implement computer applications 20 to 30 years ago now have a major portfolio of applications to support their operations. Surveys indicate that 50% to 90% of an information system budget is spent on maintenance activities (Lientz and Swanson, 1980; Harrison, 1987). This distribution of resources is usually perceived negatively in the literature, and, when looked at from a traditional perspective, the industry seems to be drowning in maintenance. Furthermore, the few data published on maintenance productivity only compound the CCC 1040-550x/95/040263-15 @ 1995 by John Wiley & Sons, Ltd.

Received 3 October 1994 Revised 26 April 1995

264

A. ABRAN AND J.-M. DESHARNAIS

complexity of the analysis. For example, it is reported (Jones, 1988) that the unit cost of adding functionality to existing applications is significantly higher than the unit cost for new applications: a unit cost ratio of three to two has been reported for the top 5% performers in the US industry (Jones, 1988), suggesting a significantly lower productivity in maintenance. However, it should not be assumed that managers blindly allocate scarce corporate dollars to maintenance activity without considering the impact of such efforts (Anderson and Amoroso, 1992) versus the impact of dollars spent on development. There is, therefore, a dichotomy between the widely held belief that a high maintenance ratio is unfavourable relative to expert judgment within an industry that is spending an ever-increasing share of its budget on maintenance. The non-availability of appropriate measures and econometrics models might be at fault: for example, there is a lack of econometrics models capable of analysing and explaining this allocation of scarce resources to maintenance. Many corporations have already invested so much in fully automated and debugged software applications that any request for the addition of products and services triggers a thorough search through existing applications to identify reusable components, whether at the application, sub-application, function, program, routine, documentation or specification level. The informal corporate policy is often the following: if the user has already paid for it, he is entitled to reuse it and be charged only for the incremental costs. Measurement analysis results depend on the point of view on which the analysis is based and on the types of measures used. Some key aspects are not being considered by current measures and productivity models in software engineering: for example, the software engineering concept of reusability is not currently factored into traditional productivity models for functional enhancement of existing applications (Jones, 1988; Abran, 1994, pp. 200, 392-394).

1.2. Previous research Software maintenance is often defined as including all activities associated with changing, modifying or otherwise altering existing software applications (Sharpe et al., 1991), or alternatively as work done on a software system after it becomes operational (Gill and Kemerer, 1990, p. 8; Osborne, 1990). In software maintenance productivity studies in the literature, the models discussed do not take into account reuse concepts. In a paper on issues and research directions in software reuse, Kim and Stohr (1992) reported that software reuse is traditionally defined as the use of previously developed software artefacts in new applications.These authors identified the study of reuse in the maintenance area as a needed future research direction; although they reported on a significant number of papers on productivity gains from reuse in the development of new applications, they did not report on any papers on maintenance. Kim and Stohr (1992) suggested looking into maintenance from the reusability perspective and stressed the need to develop econometrics models to address this issue, but they identified it only as a research issue. Basili (1990) had also suggested this view of maintenance as reuse-oriented software development. Even for applications development where some measures of reuse have been proposed at the code level (Gaffney and Cruickshank, 1992), there is a scarcity of measures of reusability from a functional and user perspective. Similarly, in maintenance, reusability has not been studied from a business and econometrics perspective, and it is our opinion

3

FUNCTIONALREUSE

265

that reusability measurement models are required for relevant productivity analysis in maintenance, using appropriate statistical procedures as discussed in Matson et al. (1994).

1.3. Structure of the paper In this paper, we propose an approach to functional reuse measurement based on Function Points Analysis, and, from then on, we investigate means of integrating this reuse measurement approach into maintenance productivity models. Section 2 discusses the concepts of measurement boundary and external interface files (EIF) as currently defined in Function Points Analysis and explains how they can be used as a basis for the measurement of functional reuse by identifying and quantifying avoided functions that do not need to be redeveloped. This leads to the two new functional reuse measurement concepts that are introduced in section 3: a reuse indicator and predictor ratio. Section 3 also presents procedures for identifying the reuse indicator and the predictor ratio and shows how they can be combined to derive an alternative functional size which takes into account the functions reused and not redeveloped. Section 4 presents a case study based on data from an industrial database to illustrate how this alternative size with reuse can be used to quantify the benefits of major enhancement work in terms of a lower unit cost when functions not redeveloped are taken into account.

2. FUNCTIONAL REUSE MEASUREMENT 2.1. Approach Gaffney and Cruickshank (1992) have developed reuse econometrics models which can be used for possible tradeoff analyses between the cost of making reusable software components and the cost of reusing components in a ‘new’ application (e.g. using ‘old’ code in a ‘new’ application). These models do not address the more general issue of maintenance (e.g. adding ‘new’ code and/or modifying ‘old’ code in ‘old’ applications). What is needed is a model to identify the benefits of reuse in maintenance, as well as a methodology to identify the extent of this reuse. The reuse measurement approach proposed here takes the Kim and Stohr (1992) model of the system development process from a reusability perspective as the reusability model already instantiated in the maintenance process. Function Points Analysis is proposed here as one method for measuring functional reuse in maintenance projects. Function Points Analysis is also proposed for developing productivity models capable of factoring in some aspects of the reusability concepts, from a user’s perspective, in order to include the cost avoided in the productivity model and not only the incremental costs. It should also be noted that the measurement of reuse with Function Points Analysis, as proposed here, is based on an indirect process measure through the direct measure of products. This type of indirect measurement is similar to Gaffney and Cruickshank’s (1992) indirect measure of the reuse process through the direct measure of software products based on lines-of-code metrics. The Function Points Analysis technique, developed by Allan J. Albrecht of IBM, was

266

A. ABRAN AND J.-M. DESHARNAIS

first published in 1979 (Albrecht, 1979; and Albrecht 1983), and, in 1985, the International Function Point Users Group (IFPUG) was set up to clarify the rules, set standards and promote the use and evolution of Function Points. Function Points Analysis provides a standardized method for measuring the various functions of a software application. Function Points Analysis measures functionality from the user’s point of view, that is, on the basis of what the user requests and receives in return. The functional size in Function Points is obtained by measuring the application from two distinct perspectives:

(A)

(B)

The functional size, calculated by assigning weights to each individual function. Each function is classified into one of five function types: internal logical file (ILF), external interface file (EIF), external input (INP), external output (OUT) and external inquiries (INQ). These five function types are illustrated in Figure 1. The value adjustment factor, calculated by assessing the environment and processing complexity of the application us a whole through fourteen general system characteristics criteria.

The value adjustment factor in (B) adjusts the functional size determined in (A) by a maximum of + 35% to produce the Function Points (FPs). Function Points Analysis has considerably evolved since Albrecht’s publications through the significant and continuous involvement of industry experts under the sponsorship of the International Function Point Users Group (IFPUG) organization. Four major releases of the rules and standards have been published by IFPUG since 1986. In this article, all future references to Function Points Analysis definitions and measurement rules will be based on the most recent 1994 IFPUG publication rather than on the outdated 1979 and 1983 descriptions of Function Points Analysis.

INFORMATION PROCESSING

USER

Figure 1. Function Poinl boundary definitions in an enhancement project

FUNCTIONALREUSE

267

2.2. Measurement boundary: IFPUG definition The basis for this proposal on the measurement of functional reuse in maintenance is the 1994 IFPUG definitions of what should be measured, or not measured, and is precisely defined in chapter 4, ‘Boundaries’, of the IFPUG official counting guide (IFPUG. 1994). This process of defining the boundaries of the application being measured has been modelled, and is shown in Figure 1, which illustrates that input, output and inquiry function types originate from and/or go to both the user and to other software applications already developed. The same boundary definition process prevails when measuring the functional size of an enhancement project according to IFPUG rules which state that only transaction-type functions added, modified and deleted will fall within the boundary, while all unmodified transactions will be considered as outside the measurement boundary. In Figure 1, what falls within the IFPUG boundary definition in referred to as the ‘measured application’, and what falls outside it is referred to as ‘other applications’. This boundary definition is therefore specific to Function Points and does not map to the physical boundaries in terms of lines of code, routines, programs and software applications. Readers must be reminded that Function Points Analysis measures software from the user’s perspective, independently of the technology. It measures software considered from a functional perspective and does not address HOW it was developed and implemented. Therefore, this paper does not discuss the measurement of the reuse process in terms of code reuse, documentation, test data, test plans etc. The perspective selected for this approach is the measurement of functions reused, as defined in Function Points Analysis.

2.3. Interfaces: IFPUG definition There is currently no overlap between the traditional view of an interface and the Function Points view of the external interface file function type. In the IFPUG Counting Practice Manual, the external interface file function type is defined in the following way: ‘An External Interface File (EIF) is a user identifiable group of logically related data or control information utilized by the application, but maintained by another application’. The IFPUG view of an interface does not map to the traditional view of an interface. Figure 1 is used to illustrate these distinct definitions of interfaces. A traditional view would classify all interactions across the physical boundaries of the measured application as interfaces, either manual interfaces when the user is directly involved, or automated interfaces when the interactions are with the other applications. Based on the IFPUG EIF definition, none of the conventional inter-application interfaces illustrated in Figure 1 belongs to this FP function type. In Function Points Analysis, such interactions with either the users or other applications are classified into three transaction function types: external input, external output and external inquiry. For example, data from other applications coming in automatically to update the internal logical files of the enhancement are not counted as external interface files, but as input. Similarly, data going out to other applications are not defined as interfaces according to Function Point counting rules, but as output. According to Function Points definitions, only the data used in the measured application which are neither created nor modified qualify as being of the external interface file function type. In fact, only data read from other applications and without direct updating

268

A. ABRAN AND J.-M. DESHARNAIS

in the measured application (Figure 1) qualify as an EIF according to IFPUG rules. Only data files that have already been created with an updating mechanism already computerized outside of the measured application qualify as external interface files. This concept is explicitly stated in one of the identification rules of an EIF (IFPUG, 1994, bullet 4, pp. 5-6): ‘The group of data is counted as an ILF for at least one other application’. Therefore, in Figure 1 the box labelled External Interface Files in the measured application could be considered as the virtual (or conceptual) map of data residing in Internal Logical Files (ILF) outside the boundary: this virtual map corresponds to the Function Points concept of the EIF. Figure 1 represents this conceptual map through the dotted line. It could be argued, and rightly so, that the Function Points definition does not follow the conventional view. However, since the concept is clearly spelled out in IFPUG manuals, the difficulty for readers not familiar with Function Points measurement objects and concepts, resides not with the concept described, but mostly with the unconventional labelling of this concept, the IFPUG EIF function type. Any study on Function Points must use the very narrow definition of EIF specific to its measurement model.

2.4. Reuse concepts in IFPUG file-type definitions When the EIF file-type definition is looked at taking into account the reuse concepts as described in software engineering, there is then an interesting map between the IFPUG EIF definition and the conventional interpretation of data reused ‘as is’ without modification, which is called ‘black box reuse’. It might then be more appropriate to qualify this function type as a reused logical fife (‘reused’ in its purest sense, i.e. it is not modified in the process, but is reused ‘as is’). For ease of understanding in software engineering it could be argued that the IFPUG EIF label should be changed to ‘Reused Logical File’. It would then become evident that the Function Points definitions and measurement rules provide a means to identify and measure some specific dimensions of reuse, that is, black-box data reuse. This concept will be referred to as the reuse indicator. The identification of this reuse measurement feature in Function Points is the basis for the model of functional reuse measurement proposed here. It must be further emphasized that the current definition of EIF, and the re-labelling proposed, is very limiting and does not allow the identification either of data that are being modified or of transactions that are reused both ‘as is’ or ‘with modifications’, nor does it allow for input, output or inquiry transactions that did not have to be re-developed (since they have already been developed). However, Function Points Analysis, like most other software product measures, does not actually directly capture and measure the transactions avoided due to reuse. This issue is discussed below.

2.5. Identification of avoided costs In the Gaffney and Cruickshank (1992) reuse econometrics model, the cost associated with reuse is derived from the cost of integrating the lines of code reused, while the cost avoided by not having to develop the reused lines of code, is derived from the cost that would have been incurred in the development of these lines of code in the initial application, referred to here as a new application. This avoided cost is derived from the

269

FUNCTIONAL REUSE

identification and the measurement of the alternative without reuse and its related size and redevelopment cost. However, for projects adding or modifying functions to existing applications, practitioners rarely identify and cost the alternatives formally, perhaps based on their belief that the maintenance alternative is the obvious, most cost-effective solution or that there was really no alternative to look at. They therefore do not formally identify the functions that would have had to be re-developed in second-best alternatives. In fact, this means that most of the time for enhancement projects there is no analysis done on the costing of alternatives, and therefore no process in place or means of identifying the benefits of maintenance strategies derived from costs avoided with the alternatives (not identified or measured). The approach proposed in this paper will present a strategy for identifying and measuring, on the one hand, the transactions that did not have to be re-developed and, on the other hand, for quantifying the benefits derived from the re-development costs avoided. This approach requires the additional concept that is discussed in this section: the predictor ratio of transactions avoided and its use in the computation of the size of the alternative without reuse (e.g. size plus avoided transactions). This approach was first identified in Abran and Desharnais (1992) in a discussion on a research methodology for investigating the measurement of reuse from a functional perspective. It was suggested there that an analysis of the external interface files, as defined in Function Points Analysis, provides a first-degree approximation of data function types reused in an enhancement project. This was referred to previously as the reuse indicator. It was also suggested that the avoided development of transactions and related avoided cost could be derived from information on previous projects, referred to here as the predictor ratio of the reference database. This information from previous projects can be integrated into maintenance productivity models by combining the reuse indicator measured within the enhancement project to the reuse predictor ratio derived from the reference database. This will be described in further detail in the next section.

3. FUNCTIONAL REUSE MEASUREMENT MODEL 3.1. FP equation In Function Points Analysis, the total number of function points is obtained by adding the points for each of the five function types. The FP equation with the five functiontype subtotals is the following (the abbreviations are described in Table 1): FP = FPILF + FPn,r + FP,NP+ FPour +

F&NO

(1)

For enhancement projects, each of the five function-type subtotals is further subdivided into points added, modified and deleted, but the structure of equation (1) remains the same for both new applications (FPN) and enhancements (FPE).

A. ABRAN AND J.-M. DESHARNAIS

270

Table 1. List of abbreviations Description

Abbreviation FP FPi ILF EIF INP OUT

INQ FPN FPE FPER

Total of function points for all five function types Sub-total of function points for function type i Internal Logical File function type External Interface File function type External Input function type External Output function type External Inquiry function type Total of function points for a NEW application Total of function points for an ENHANCEMENT project Total of function points for an ENHANCEMENT project with REUSED functions

3.2. Functional reuse measures Two new concepts were defined in the previous section: the reuse indicator for data reused and for transactions avoided, and the predictor ratio from a reference database. This section describes how to calculate these. The reuse indicator provides a measure of the data reused in the measured application, data already developed and data which already exists outside the boundary of the measured application. This reuse indicator is derived from the subtotal of EIF points. This is referred to as the reuse indicator: Reuse indicator = FPR (Indicator) = FPgrF

(2)

This reuse indicator provides information on the data function types reused, but does not say anything about the transaction type functions that were required to create them in the first place. A thorough analysis of the existing applications would be required to identify all such functions. However, in the current state of the documentation of legacy applications this is not feasible most of the time. A predictor model is therefore required to estimate the number of reused transactions. This predictor model can be derived from historical Function Point databases by identifying how many Function Points of the transaction function type were required, on average, for each internal data function type in the reference database. This predictor ratio provides information on the transactions that did not have to be developed in the enhancement because it already had been developed outside the measured application. This predictor ratio, as defined here, will provide the information to compute the avoided transaction costs of the data reused in the enhancement. The predictor ratio of transactions is derived from the reference database of new applications by calculating the ratio of the FPr of the other four function types (excluding FPfl,) over the number of FPr&:

271

FUNCTIONALREUSE

Reuse predictor ratio = FPR (Predictor) = FP& + FP$ + FP&_,-r + FP& FPL

(3) (4)

3.3. FP equation with functional reuse equation Both the data reuse indicator and the transaction predictor ratio are required to take into account the transactions avoided and the related avoided cost, when determining the correct productivity of the addition of functions in maintenance projects. Provided that information is available on the distribution of the five function-type ratios from previous development projects and their development costs, it is possible to quantify both the functions avoided due to reuse and their related costs. When the transaction reuse predictor ratio of the reference database for new applications is combined into the data reuse indicator of an enhancement project, it provides an indication of the size of the avoided transactions or the transactions reused and not redeveloped. Avoided transactions = Reused transactions

(5)

= Reuse indicator x Reuse predictor ratio

(6)

= FPR (indicator) x FPR (predictor)

(7)

When (4) is added to (1) for enhancement projects, the resulting equation FPER then takes the avoided transactions into account in the measurement of the size of the functionalities delivered to the user and becomes: FPER = FPE + Avoided transactions FPER = FPE + (FPR (Indicator) x FPR (Predictor))

(9) (10)

4. CASE STUDY 4.1. Reference data set The approach proposed here to measure functional reuse is illustrated through the analysis of an industrial data set from a major Canadian financial institution. Productivity measures in their corporate database are segregated into new applications and major enhancements to existing applications, as recommended in (IFPUG, 1990, p. 5; Jones, 1988). Table 2 presents their average Function Point distributions by the five function types: new application distribution of the industrial data set in the left-hand column, the major

272

A. ABRAN AND J.-M. DESHARNAIS

Table 2. Average distribution of Function Points Function types

New applications and high inter-application interaction (Abran and Robillard, 1990)

Major enhancements (Abran and Robillard, 1990)

27%

13%

3 6 %

14%

38%

1%

22% 21%

9% 31%

31% 21%

17%

9%

9%

Internal Logical Files W-F) External Interface Files (EIF) External Input (INP) External Output (OW External Inquiries

New applications and low inter-application interaction (Dreger, 1989)

’

UNQ) enhancement distribution in the middle column (Abran and Robillard, 1990, p. 241). Another data set from Dreger (1989, p. 7) is in the right-hand column. In the left-hand column, the 14% ratio in external interface files for new applications would indicate that at this industrial site there is a significant degree of inter-application interaction. When there is little inter-application interaction, the ratio of points of EIFs is very small, at

l%, as illustrated in the data set reported in Dreger (Table 2, right-hand column). Productivity ratios from this database indicate a higher unit cost per function point for major enhancement projects in comparison to projects to develop new applications. This finding is consistent with available comparative figures from Jones (1988). The middle column of Table 2 indicates a ratio of 38% of Function Points of the EIF function type for major enhancements, versus a ratio of 14% for new applications at this industrial site. This 38% of EIF points was perceived as the added costs that the users were willing to pay in order to have these new functionalities integrated within current applications (Abran and Robillard, 1990, p. 243). However, the cost of EIFs should not be considered only as the incremental costs incurred for integrating the major enhancements into existing applications. If the EIFs were looked at from a reuse perspective, as discussed in sections 2 and 3, they could be considered rather as an indicator of the level of data reused in the measured application, or as data functions that did not have to be designed and programmed. These data functions already exist within the other measured applications (outside the boundaries of the measured application), and, from that point of view, all the supporting functions already exist in terms of external input, output and inquiry function types. It could be that only the costs are visible and that the benefits of the reused data being passed back and forth in the external interface files are not taken into account, i.e. the avoided functions are not currently identified, measured or taken into account in either the measurement process or in productivity and estimation models.

4.2. Illustrative example An example of the proposed approach for the measurement of functional reuse and the assessment of its economic benefits in major enhancement projects will use the following information, for illustrative purposes only:

, ’

I

’

273

FUNCTIONALREUSE

-

Addition of 200 Function Points (FPE) to an existing application of 3000 FP; Average unit cost of 2 days per FPN added in new applications; Average unit cost of 3 days (three to two ratio) per FPE added in major enhancements, based on Jones (1988); Distribution of FP by function types as per Table 2, Abran’s datasets, for new applications FPN and major enhancements FPE.

Using the above figures, the cost of this enhancement project would be 600 days (200 FPE x 3 days/FPE). For comparative analysis, this cost should be compared with the cost of the alternative strategy, which would have been to build a new application to meet these requirements instead of integrating them into an existing application. The proposed approach, presented in sections 2 and 3, can be used to identify this alternative, to measure the avoided transactions and to derive the avoided costs.

4.3. Alternative functional size The method for calculating the alternative size which takes reuse into account was described in section 3. This requires identification of the reuse indicator FPR (Indicator) from equation (2) and calculation of the reuse predictor ratio FPR (Predictor) from equation (4), followed by their combination to obtain the functional size of the avoided transactions from equation (8) and then its addition to the base functional size, from equation (10). For the example proposed here, the reuse indicator is obtained by applying the EIF ratio in Table 2 to the size of this functional enhancement project: FPR (Indicator) = FPE x FP& (ratio)

(11)

= 200 FPE x 38%

(12)

= 76 FPgrF

(13)

This reuse indicator of 76 FPs of EIFs represents internal files which already exist outside the boundaries of the measured application; these data function types do not, therefore, have to be redeveloped in this enhancement project since they are reused without modification. To figure out the number of transaction types (input, output and inquiries) that would have been required to create these reused data function types, the concept of the predictor ratio is called upon. The predictor ratio is obtained by using equation (3), and the required information is derived from the information on the distribution of points by function types from Table 2 for the development of new applications. Based on this information, the denominator is derived from the distribution of points for ILFs, that is, 27%, and the numerator from the distribution of the other four function types, that is, 73%. This could be interpreted in the following way: each point in the ILFs represents 27% within the average distribution of the reference data set of new applications, and, as a corollary, 73% is the proportion of points for the other function types required to create, update, delete and link them with other applications. On average, each point in an internal logical

A. ABRAN AND J.-M. DESHARNAIS

274

file is, therefore, a predictor of another of 2.7 points (1 point for the ILF (27% ) and 2.7 points for the other four function types (73%)). This was previously defined in equation (3) as the predictor of points required to maintain the files created. The points for the avoided transactions can then be identified using the concepts described in equations (5) to (8). The application of the predictor of 2.7 to the 76 FPs of the reuse indicator in this example gives 205 transaction points which do not have to be developed. The size of the alternative can now be calculated from equation (9) by adding the number of points of the avoided transactions to the functional size of the enhancement project as calculated in the conventional manner. FPER = FPE f avoided transactions

(14)

FPER = FPE + (FPz,r x FPR (Predictor))

(15)

= 200 FPE + 205 reused FPR

(16)

= 405 FPsER

(17)

From a reusability standpoint, the alternative project size is therefore 405 FPER, instead of 200 FPE when the transactions avoided and not redeveloped are taken into account.

4.4. Productivity analysis In maintenance projects, the traditional IFPUG measurement view of functional size

does not take reused functions into consideration. Therefore, a maintenance project of 200 FPEs would take 600 days to complete at a unit cost of 3 days/FPE. For enhancement projects, the project cost stays the same, at 600 days, whether or not the size is measured with FPE or FPER. However, when the avoided transactions are taken into account in measuring the functional size of the enhancement, the maintenance unit cost then decreases to 1.5 day per FPER (600 days/405 FPER) instead of 3.0 days per FPE when reuse is not factored in. These calculations are summarized in Table 3. Table 3. Case study: measurement with and without reuse REUSE concept

WITHOUT (traditional FP functional size measurement)

Type of project

Unit cost

New application

at 2 days per FPN at 3 days per FPE

Enhancement

Enhancement WITH (including the avoided transactions)

Alternative (if built as a new application)

at 1.5 day per FPER at 2 days per FPN .

Size in FPS

Total cost 400

200

600

600 405

810

FUNCTIONALREUSE

275

The alternative, a new application which would have required the redevelopment of the 205 FPR avoided in the enhancement project, would have had a total size of 405 FPN. Based on a cost structure of 2 days / FPN for new applications, this alternative project to develop 405 FPN would have cost 810 days (405 FPN x 2 days/FPN = 810 days). When looked at from this perspective, the above example gives an economic advantage of 210 days (810 days - 600 days) for a major enhancement project over its alternative, a new application project. This compares well with the initial disadvantage of 200 days (400 days versus 600 days) which was based on an average unit cost of 3 days per FPE for major enhancements and 2 days per FPN for new applications (from Jones, 1988).

5. CONCLUSION This paper proposed a measurement model to identify and to quantify the reused trans-

actions and the related costs which that are then avoided. In this paper two key concepts were introduced: a reuse indicator and a predictor ratio. The reuse indicator was derived from an analysis of the function types as currently defined in Function Points Analysis. The predictor ratio was derived from an understanding of the avoided-cost concept and how it can be captured using historical databases of function points from previous development projects. This paper indicated how, in functional enhancement projects, the predictor ratio can be combined with the reuse indicator to derive a functional enhancement size measure which takes into account the functions reused and not redeveloped. It was also suggested that the avoided development of transactions and related avoided cost can be derived from information on previous projects, referred to here as the predictor ratio of the reference database. This information from previous projects can be integrated into maintenance productivity models by combining the reuse indicator measured within the enhancement project and the reuse predictor ratio derived from the reference database. The case study described in section 4 illustrates that practitioners must be aware of the limitations of productivity and cost models when functional reuse is not taken into account. In software maintenance projects for functional enhancements, the reused functions not included in the measurement model may have a significant impact on the results of a productivity analysis. In the proposed example, the initial 3 to 2 economic disadvantage of maintenance turns into a 3 to 4 economic advantage when what does not need to be redesigned and reprogrammed is also taken into account (i.e. what is reused),

Acknowledgements We extend thanks to Revenue Canada for providing research funds, to the Journal’s reviewers for helpful suggestions, and to Ned Chapin for encouraging us to pursue research in the field of software maintenance.

References Abran, Alain (1994) ‘Analyse du processus de mesure des Points de Fonction’, Ph.D. Diss., Jkole Polytechnique de Montreal, Quebec, Canada, 405 pp. Abran, Alain and Desharnais, Jean-Marc (1992) ‘Drowning in costly maintenance or leveraging assets?‘, in WISR.92: 5th Annual Workshop on Software Reuse, L. Latour (Ed.), University of Maine, Orono, ME, pp. Abran l-10.

276

A. ABRAN AND J.-M. DESHARNAIS

,.

Abran, Alain and Robillard, P. N. (1990) ‘Software management based on software deliverables’, in Proceedings CIPSICATA Congress 90, Canadian Information Processing Society, Ottawa, Ontario, Canada, pp. 237-245. Albrecht, Allan J. (1979) ‘Measuring application development productivity’, in Proceedings IBM Applications Development Symposium, Monterey, CA, 14-17 October, GUIDE Int. and SHARE Inc., Chicago, IL, pp. 83-92. Albrecht, Allan J. and Gaffney, J.E. (1983) ‘Software function, source lines of code, and development effort prediction: a software science validation’, IEEE Transactions on Software Engineering, SE-9(6), 639-648.

Anderson, Thorbjom and Amoroso, Donald L. (1992) ‘Steering the maintenance costs: an exploration of the maintenance construct’, Proceedings of the 25th Hawaii International Conference on Systems Sciences, Vol. 3, IEEE Computer Society Press, Los Alamitos, CA, pp. 348-357. Basili, Victor R. (1990) ‘Viewing maintenance as reuse-oriented software development’, IEEE Software, 7(l), 19-25. Dreger, J. Brian (1989) Function Points Analysis, Prentice Hall, Englewood Cliffs, NJ, 1985 pp. Gaffney, John E. and Cruickshank, R. D. (1992) ‘A general economics model of software reuse’, in Proceedings of 14th international Conference on Software Engineering, ACM Press, New York, pp. 327-337. Gill, Geoffrey K. and Kemerer, Chris F. (1990) ‘Productivity impacts of software complexity and developer experience’, MIT Industrial Liaison Program Report 34&90, Sloan School of Management, MIT, Cambridge, MA, 36 pp. Harrison, Richard (1987) ‘Maintenance giant sleeps undisturbed in Federal data centers’, Computerworld, 21(10), 81, 86.

IFPUG (International Function Point Users Group) (1994) ZFPUG Function Point Counting Practice Manual Release 4.0, IFPUG, Westerville, OH, 293 pp. IFPUG (International Function Points Users Group) (1990) Function Points us an Asset-Reporting to Management, IFPUG, Westerville, OH, 49 pp. Jones, T. Capers (1988) ‘Building a better metric’, Computerworld Exrru, 22(25a), 38-39. Rim, Yongbeom and Stohr, Edward A. (1992) ‘Software reuse: issues and research directions’, in Proceedings of the 25th Hawaii International Conference on Systems Sciences, Vol. 3, IEEE Computer Society Press, Los Alamitos, CA, pp. 612-623. Lien& Bennet P. and Swanson, E. Burton (1980) Software Maintenance Management, AddisonWesley, Reading, MA, 214 pp. Matson, Jack E., Barret, Bruce E. and Mellichamp, Joseph M. (1994) ‘Software development cost estimation using Function Points’, IEEE Transactions on Software Engineering, 20(4), pp. 275-287. Osborne, Wilma M. (1990) ‘Executive guide to software maintenance (NBS Special Publication 500-130)‘, in Longstreet, David H. (Ed.), Softwure Maintenance and Computers, IEEE Computer Society Press, Los Alamitos, CA, pp. 2-14. Sharpe, Shane, Haworth, Dwight A. and Hale, David (1991) ‘Characteristics of empirical software. maintenance studies: 1980-1989’, Journal of Software Maintenance, 3(l), 1-15. Authors’ biographies:

Alain Abran is currently professor at Universite du Quebec a Montreal, Montreal, Canada. He is the director of the Research Lab. on Software Engineering Management and teaches graduate courses on Software Engineering. Dr Abran 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 Besr of the Besr awards from the Quality Assurance Institute (Orlando, Florida, USA). Dr Abran received his MBA and Master of Engineering degrees from University of Ottawa, and his Ph.D. from Ecole Polytechnique de Montreal.

P

FUNCTIONAL REUSE

277

Jean-Marc Desharnais has a master degree in Management Information System

from Universite du Quebec a Montreal and a master degree in Public Administration from &ole Nationale d’Administration Publique (Quebec). Mr Desharnais has extensive industry experience in software measurement programs. He has given presentations across North America and Europe. His research interest includes software estimation, productivity measurement and risk analysis.