Role of Function Point as a Reuse Metric in a Software Asset Reuse Program

Transcription

1 Role of Function Point as a Reuse Metric in a Software Asset Reuse Program Johns T. Joseph 1 1 Department of Computer Science, Kent State University, Kent, Ohio, USA Abstract - The role of Function Point as a reuse metric in a software asset reuse program is analyzed in this paper. The paper takes a practical implementation as an example and walks through the issues faced by the developers and managers in using Function Point as a measure of software asset reuse. Productivity measures such as cost saving and actual reuse are generated to study the productivity of the software development firm. The author highlights the practical implementation issues, and recommends resolution options to overcome these issues. The paper also highlights the need of standardization of software reuse metrics as a step towards establishing software development as an engineering discipline teams working on project should consciously develop and design the software in a reusable fashion. This takes additional design and development effort. Another aspect of software reuse is an efficient way of maintaining the library of software, its various versions, and how they can be used. Organizations having a better software asset management system can reuse software better than others. There are other challenges such as political and psychological aspects that come into play during software reuse. Keywords: Software metrics, software reuse, function points, productivity, cost saving 1 Introduction A s the software development organizations are getting more competitive, there have been lots of research initiatives to identify and use efficient metrics to measure the productivity and quality of software development. Software reuse can be defined as the use of existing software artifacts to improve the productivity and quality of new software. There can be different types of software reuse. Following are some of the types of software reuse: a) Code Reuse The code snippet is reused in new software. It is easy to reuse; however, this practice does not scale well. b) Template Reuse Design and coding standard templates are reused. c) Library Reuse The library and software components are reused in a systematic fashion. d) Framework Reuse New functionality is developed over a reusable framework. Use of a framework allows a standardized way of addressing common issues as well as implementing good practices. e) Design Pattern Reuse Design patterns are published and used in software development. There are lots of challenges in effectively implementing a Software Reuse program in an organization. The technology changes quite frequently. For example, a software asset in DotNet technology cannot be used in Java technology. The Fig. 1. Summary of activities of a Software Asset Reuse Program Scott W. Ambler [22] depicted the software reuse in a very clear manner in Figure 1. The diagram summarizes the

2 reuse and management of a software asset. The following activities in software asset management are important to increase the productivity of the organization: Publish, categorize software assets Control asset versions and manage dependencies Locate assets Improve communication across teams Track usage & measure reuse As we all know, to measure an effective software reuse program, we need a very well defined reuse metric. Lots of research and papers ([8], [4], [9]) have highlighted that Function Point can be used as a software productivity measure. This paper highlights the issues in using Function Point as a unit of measure for software reuse in a practical environment, and proposes how it can be enhanced to an efficient usage. Some of the reuse metrics and models proposed by [8] are cost benefit analysis, maturity assessment, amount of reuse, failure modes analysis, reusability assessment and reuse library metrics. There are lots of ways of measuring reuse metrics; however, there is no standard accepted methodology in the industry. Everyone, however, does realize that software reuse improves the quality and productivity of the organization. 2 Software Reuse A Practical Study A software reuse metric using Function Points as the basis was used in an actual product development organization. This section summarizes the implementation of a software reuse program for a period of two years. The calculation of the Function Points was based on the IFUP Counting Practices Manual 4.1. One of the reasons for choosing FP as the metric was that it is a standard way of denoting the size of a software asset. It is better than LOC (Line of Code) to depict the size of the software [11]. It is easier to implement and less complex than other variants such as Feature Point, 3D Function Point, Mark II Function Point, Full Function Point, COSMIC Full Function Point as summarized in [1]. FP falls under direct measurement classification. The three different measurement classifications are described in [6]. The inter-rater reliability issue of Function Point was resolved through a practical study in [13]. A dedicated team was involved in developing reusable software assets. A software asset is certified for reuse after the component is reused in a product and passes Alpha testing. The Alpha testing was conducted by an independent team at the developer s site. The software asset is registered in an inhouse software asset management system. This helps in the discovery of the reusable assets by the developers. Once an asset is discovered the dependencies and location are retrieved from the system. This information is used by the users of the software asset. The reusable assets were developed using different technologies such as.net based web service, ASP.NET, C#, Microsoft SQL Server, Transbase database, Oracle database, Microsoft SQL Server Integration Service (SSIS, an ETL tool), Java Swing, Applet, Java J2EE, Adobe Flash, AIR (Adobe Integrated Runtime), JSP (Java Server Pages), XML, XQuery, Oracle Data Integrator (ODI, an ETL tool). Since Function Point metric is mostly technology agnostic, it helped the team to measure the reuse of the varied technology based assets in a common and efficient manner. Once a reusable asset is certified, the lead designer of the asset calculates the FP and its reuse percentage in the product. Refer [1] and appendix of [2] for details of the Function Point terminologies used below such as EI, EQ, EO, ILF, ELF, Degree of Influence. The author designed a template to calculate the FP in an efficient manner. The template has Excel based macros that enhances the ease of calculation. The process is broken into following steps: Step 1: Identify Use Cases or Functionality Step 2: Categorize Uses Cases as EI, EQ, EO, ILF, ELF Step 3: Derive the complexity of use cases and assign rating Step 4: Summarize all the uses cases in different categories and assign weight-age based on its category Step 5: Derive Degree of Influence Step 6: Generate Total Function Point of the reusable asset. Potential Reuse is the total FP of the reusable asset Step 7: Actual Reuse is calculated by identifying the percentage use case (FP) reused in a product Fig. 2. Step 2a - The uses cases or functionality is categorized as External Input Fig. 3. Step 3a Derive the complexity based on the table shown in the figure for EI (External Input) Figures 2 & 3 show a portion of the template that is used to calculate the FP. In these two figures the identification of use cases as External Input and assignment of the complexity to these uses cases is shown. There are similar portions in the template for External Inquiry, External Output, Internal Logical File and External Logical File categories. Figure 4 shows the portion of the template that summarizes all the use cases /functionality under the transactional function (EI, EQ, EO) and data function functions (ILF, ELF). Figure 5 shows the portion of the template where the degree of influence is derived by assigning a rating to each

3 General System Characteristic (GSC). This section calculates the technical complexity of the software asset. The 9 th GSC is complex processing. This is however very loosely defined and impacts the overall Function Point in a very minor way. The Unadjusted Function Point (UFP) is derived in step 4. The UFP is the size of the software component that depicts only the data flow complexity; it does not take account of system characteristics such as end user efficiency or installation ease. FP = VAF * UFP (2) FP = Function Point VAF = Value Added Function Point UFP = Unadjusted Function Point Figure 7 shows that the use case percentage reused in a product was identified. The percentage usage is applied to the asset s Function Point to derive the actual reuse value. Fig. 4. Summary of the uses cases Fig. 6. Calculate the final function point. This value is termed as Potential Reuse Fig. 7. Calculate the actual reuse Fig. 5. Deriving the degree of influence by assigning ordinal rating to the General System Characteristics (GSCs) Figure 6 shows the formula used to calculate the overall function point. It is mentioned below, VAF = (TDI * 0.01) (1) VAF = Value Added Function Point TDI = Total Deg. of Influence based on GSC ratings The total Function Point is then derived by following formula Around 40 and 70 reusable software assets were tracked in the years 2009 and 2010, respectively. All the certified assets were termed as Potential Reuse. Potential Reuse measures the certified assets that are available for reuse. These assets can be used as many number of times. It can be seen that cumulative actual reuse is more than cumulative potential reuse since the actual reuse of the asset can take place more than once. Figures 8 and 9 show the reuse metrics for years 2009 and 2010 of the software development organization. The graphs in Figures 8 and 9 show the trend of reuse in the organization. The potential reuse and actual reuse were tracked on a monthly basis to derive the graphs. It helped the organization to evaluate the software asset reuse. The first year was used to study the trend and set the target. The potential reuse increased from 553 to 1917 FP (Function Points) in the year In the next year, the potential reuse increased from 1917 to 2911 FP. The organization set a cumulative yearly reuse target of 6000 FP. The graph depicts the actual reuse met by the development team to be 7801 FP in the year 2009 and 7185 FP in the year 2010.

4 Fig. 8. Cumulative Potential Reuse versus Actual Reuse of all types of reusable assets for the year 2009 Fig. 10. Potential Reuse versus Actual Reuse in a non cumulative fashion for the year 2009 Fig. 9. Cumulative Potential Reuse versus Actual Reuse of all types of reusable assets for the year 2010 The graph in Figure 10 is a non cumulative graph of Potential Reuse versus Actual Reuse for the year Similar information is in Figure 11 for the year These graphs helped in identifying the reuse in each month clearly and helped the managers/directors to track and communicate the need of reuse to the organization. The cost saving was derived in a crude manner. First the Effort in Man Hours spent per FP was calculated by adding total number of potential reuse FP generated for six months period and dividing it by total effort spent in developing the assets. The author refers it as crude because the assets considered during the six months were of different technologies, some using 3 GL and others using 4 GL languages. The assets should have been categorized before calculating the cost saving. Without the asset categorization, the cost avoidance provides a rough number that can be used for management purposes. Once the effort per FP was calculated, the total actual reuse FP count was used to generate total reuse cost saving of the organization. Fig. 11. Potential Reuse versus Actual Reuse in a non cumulative fashion for the year 2010 The following formula shows how the effort per function point in man hours was calculated. Effort per FP (E FP ) = T Eff / T PFP (3) T PFP, Total FP of potential reuse asset created in 6 months T Eff, Total effort spent to develop the potential reuse asset The Effort per Function Point was used to generate the total cost saving or cost avoidance. The following formula shows how the cost avoidance was calculated. Cost Saving for the year = T AFP * E FP * C HR (4) T AFP, Total FP reused in products released in a year E FP, Effort per Function Point C HR, Average cost of a developer to the organization

5 3 Issues in using Function Point as as Reuse Metric This section highlights some of the issues in the implementation of the software reuse program. They are described in following subsections. 3.1 Complexity depiction Functional Point depicts the Data flow complexity of various types of use cases. However, it does not depict the implementation algorithm complexity. So a software asset that requires a highly complex algorithm and another software asset that requires less complex processing may have similar FP count. As part of the implementation of the reuse program, the author saw many such instances Introduce McCabe & Halstead Complexity measures in Function Point calculation The author is proposing to use McCabe and Halstead complexity measures in the calculation of Function Point to overcome this issue. It was applied on some sample software assets indentified in section II of this paper. The result showed that the new metric gave higher modified FP value for complex software assets than others. There are tools available that can auto generate McCabe and Halstead complexity measurements. A challenge is that these tools are not available for all the technology and not all solutions are affordable. This metric did produce improved results, but the company is not yet ready to make the details of this metric public. 3.2 ETL based components showed high cost savings ETL (Extract, Transform & Load) based software asset has lots of data elements that flow across its boundaries. Based on the FP count, such assets generated high FP counts. However, the cost saving was based on a general category. Applying the cost saving formula on these assets resulted in very high cost saving. Cost savings on such assets did not reflect the reality Introduce asset categorization and refine the Effort per Function Point metrics per category The author proposes to categorize the assets based on their functionality and technology, and to generate the Effort per Function Point for each category. The cost saving should be calculated based on the reuse category. 3.3 Subjectivity in certain areas of FP calculation The developers/designers complained to the author about the subjectivity in GSC and the degree of influence calculation while implementing the software reuse program. This topic is also highlighted by Symons in [18] & by other authors in [1] Introduce concepts of Mark II proposed by Symons in [18] The author attempted to implement some of the Mark II enhancements on sample assets to study the impact of the calculation and the ease of use. The author filtered out some of the complexity involved in Mark II based calculations. The use of additional five GSC such as interfaces, security and privacy, user training, third party use and documentation provides more clarity in the size of the software asset. The concept introduced by authors in [1] is interesting. However, there are no standards and tools available to support this concept. It will take time and effort to implement the concept of the training database and refinement of ordinal scale conversion to absolute scale. 3.4 FP metric is not distributed at a use case level The FP count of a software asset is not distributed at a use case level. It is a final count assigned to the whole software asset. When the actual reuse takes place, some of the use cases are reused in a product. There is not an easy way to assign the FP count for a use case and count it when it is used. In the practical approach depicted in Section II, the total FP is equally distributed to all the use cases of the software asset. This is not a precise manner to calculate the actual reuse Perform additional step to generate FP count for each use case The author proposes to introduce additional step after step 5 to generate FP count for each use case. The derived degree of influence is applied to each use case instead of the standard way of applying the degree of influence on the total Unadjusted Function Point. The author implemented this concept in some sample assets and found it is quite reliable. There is a need to apply it for the organization and study the reliability of this step. 3.5 Developers complain about the effort spent to calculate The developers and designers complained the author about the effort spent to calculate the metric Automate collection of metrics The author proposes to automate the collection of metrics. However this will involve in-house time and effort to automate FP generation. The practical implementation illustrated in section II of this paper identifies that it is not too time consuming to calculate the FP. It could be the psychological aspect of developers who have to pause their daily development activities and engage in metric collection.

6 The effort spent approximately matches with 1 work hour per 100 FP s identified in [13] 3.6 Refine FP complexity calculation step The complexity calculation recommended by International Function Point Users Group (IFPUG) is based on values proposed by Albrecht after the concept was used in IBM. This is referred as step 3 and step 4 in section II of this paper. These values have not been revised for many years. Also the ordinal ratings are applied to derive the complexity. There is a need to identify absolute ratings. This limitation is highlighted in [1], [14], and by Symons in [18] 4 Function Point & Weyuker s complexity measure analysis If we carefully analyze the Function Point Analysis (FPA) methodology, we can see that it generates the data flow complexity of the system by assigning complexity of the use cases under various categories of EI, EQ, EO, ILF and ELF. The data flow complexity is calculated by identifying the FTR s (File Types Records) and DET s (Data Element Types) that move across the system boundaries in transactional functionality of the system, as well as RET s (Record Element Types) and DET s (Data Element Types) in Data Storage functionality of the system. The assigned complexity is further used in calculating the UFP (Unadjusted Function Point) and finally the FP (Function Point). We can safely state that Function Point reflects the complexity of the system. The classification of Function Point as a complexity measure is also mentioned in [9]. However the methodology does not analyze the full complexity of the system such as algorithm and implementation complexity. In this section the author argues that FP is also a measure of complexity apart from a measure of size. He attempts to analyze Function Point metrics in a similar fashion that Weyuker analyzed other complexity measures such as McCabe s Cyclomatic number, Halstead s programming effort, statement count (LOC Line of Count) and Oviedo s data flow complexity in [19]. Following are subsections elaborate the findings. 4.1 Property 1 ( P) ( Q) ( P Q ) There exist two software assets whose Function Points are different. This has been observed in the 70 components mentioned in the previous section. Almost all the software assets had different FPs. 4.2 Property 2 Let c be a non negative number. Then there are only finitely many programs of c complexity If we extend the argument of Cyclomatic complexity or data flow complexity not following this property, it is equally arguable that FP does not follow this property. Since FP does not depict the implementation and algorithm complexity, there could be infinite software assets that may have complexity c defined above. 4.3 Property 3 There are distinct programs P and Q such that P = Q Even though the author did not find any of the 70 components that were studied having same FP, it is possible that two assets may have same FP. The functionalities provided by these two assets might be different however the formulae used to generate the FP may have same input values. 4.4 Property 4 ( P) ( Q) (P ( Q & P Q ) Since program equivalence is an undecidable question [19], it is quite possible that that two equivalent assets providing similar functionality have different FP values. 4.5 Property 5 ( P) ( Q) (P P;Q & Q P;Q ) This property is not valid for FP metrics in all cases. When two assets are combined to give a single asset, it is not always necessary that the FP of the combined asset will be greater than or equal to the original assets. This is due to the fact that the use cases will change, either increase or decrease, after combining two assets. However, since the FP is directly dependent on the use case and its data flow, the inequalities in this property are true. 4.6 Property 6a ( P) P)( Q)( Q)( R)( P = Q & P;R Q;R ); Property 6b ( P) ( Q)( R)( P = Q & R;P R;Q ) If we consider three software assets, two assets have the same FP and the third asset is combined to the two assets, it is quite likely that the FP will be different in the combined assets. This is because once the asset is combined the use cases will change, either increase or decrease, hence the combined FP can be lesser or greater. So this property follows for Function Point complexity measure. 4.7 Property 7 There are program bodies P and Q such that Q is formed by permuting the order of the statements of P, and P Q Function Point does not depend on the order of the statements of a reusable asset. It is dependent on the supported use case and the data flow for these cases between the system and the interacting world. The reordering of assets will not change the use case and the functionality. Hence FP does not follow this property. 4.8 Property 8 If P is a renaming of Q, then P = Q Function Point does not change if an asset is renamed. This property holds true for FP.

7 4.9 Property 9 ( P) P)( Q)( P + Q Q)( P + Q < P;Q ) This property holds true for Function Point. For some of the assets the sum of the FP of two assets will be lesser than the FP of the combined asset. The property says that this is applicable for some assets. For all assets this might not hold true. It has been observed that for some asses after adding additional functionality and refactoring the code, the total Function Point value decreased. Fig. 11. Summary of the Weyuker Property analysis with the Function Point metric included A complexity measure for which all the properties of Weyuker hold does not indicate that it is the best complexity measure. One should understand the intent of the measure and apply adequate weights to these properties before comparing the measures. For example the comparison shown in Figure 11 does not mean that Data Flow complexity measure is better than Function Point simply because the former measure satisfies more properties. 5 Conclusions Implementation of an efficient software asset reuse program is very important to a software development organization to be competitive. The program allows the organization to effectively manage their resources and increase the productivity of the associates. There is a need for the development society to standardize the method and metrics for software reuse. It will be another milestone for the software development methodology to be qualified as an engineering discipline. 6 Acknowledgement Johns T. Joseph is grateful to Professor Dr. Austin C. Melton for the guidance, feedback and critiques provided while working on this paper. He also thanks the classmates for attending his presentation, and providing valuable and critical feedback. He acknowledges his family in providing indispensable support that enabled him to spend time and effort to research on the topic. 7 References [1] M. A. Al-Hajri, A. A. A. Ghani, M. N. Sulaiman, M. H. Selamat, Modification of standard Function Point complexity weights system, The Journal of Systems and Software 74, 2005 [2] A. J. Albrecht and J. E. Gaffney, Software Function, Source Lines of Code, and Development Effort Prediction: A Software Science Validation, IEEE Transactions on Software Engineering, Vol. SE-9, No. 6, November 1983 [3] J. S. Collofello, S. N. Woodfield, and N. E. Gibbs, Software Productivity Measurement, National Computer Conference, 1983 [4] C. J. Dale, Software Productivity Metrics who needs them?,ec2 Publications, 1992 [5] J. J. Dolado, A study of relationships among Albrecht and Mark II Function Points, Line of Codes 4GL and Effort, J. Systems Software, 1997 [6] N. Fenton and Austin Melton, Measurement Theory and Software Measurement, in A. Melton, editor, Software Measurement: Understanding Software Engineering, International Thomson Computer Press, 1995 [7] N. Fenton, Software Measurement, IEEE Transactions on Software Engineering, Vol. 20, No. 3, March 1994 [8] W. Frakes and C. Terry, Software Reuse: Metrics and Models, ACM Computing Surveys, Vol. 28, No. 2, June 1996 [9] S. Furey, Why we should use Function Points, CounterPoint, IEEE March/April 1997 [10] T. Hall and N. Fenton, Implementing effective software metrics program, IEEE Software 1997 [11] D. R. Jeffrey, G. C. Low, and M. Barnes, A Comparison of Function Point Counting Techniques, IEEE Transactions on Software Engineering, Vol. 19, No. 5, May 1993 [12] C.F. Kemerer and B.S. Porter, Improving the reliability of Function Point Measurement: An empirical study, IEE Transactions on Software Engineering, Vol. 18, No. 11, November 1992 [13] C. F. Keremer, Reliability of Function Points Measurement A Field Experiment, Communication of the ACM, Vol 36, No. 2, February 1993 [14] B. Kitchenham, The Problem with Function Points, CounterPoint, IEEE Software 1997 [15] G. C. Low and D. R. Jeffery, Function Points in the Estimation and Evaluation of the Software Process, IEEE Transactions on Software Engineering, Vol. 16, No. 1, January 1990 [16] T. J. McCabe, "A Complexity Measure" Transactions on Software Engineering, Vol. SE-2, No. 4, December 1976 [17] L. M. Ott. The Early Days of Software Metrics: Looking Back After 20 Years, in A. Melton, editor, Software Measurement: Understanding Software Engineering, International Thomson Computer Press, 1995 [18] C. R. Symons, Function Point Analysis: Difficulties and Improvements, IEEE Transactions on Software Engineering, Vol 14, No. 1, January 1988 [19] E. J. Weyuker, Evaluating Software Complexity Measures, IEEE Transactions on Software Engineering, Vol. 14, No. 9, September 1988 [20] A. C. Melton, D. A. Gustafson, J. M. Bieman and A. L. Baker, A Mathematical perspective for software measures research, IEE/BCS Software Engineering Journal, 1990 [21] S. AMBLER, The Strategic Reuse Discipline: Scaling Agile Software Development, html