A Study of Software Reuse and Metric Models

Transcription

1 A Study of Software Reuse and Metric Models Prepared by: Thomas M. Ennis Drexel University Prepared For: Dr. William Evanco Info 630 Evaluation of Information Systems 1

2 Table Of Contents Introduction Part 1 Establishing a Software Reuse Program 1 What is software reuse? 2 What do we wish to accomplish through reuse? 3 Factors that affect the implementation of software reuse programs 3.1 Human Factors 3.2 Technology Factors 3.3 Organizational Factors 3.4 Political Factors 3.5 Economic Factors 4 Overcoming Outside Factors 4.1 Make Reuse Attractive 4.2 Make Reuse Available 4.3 Establish Ability to Implement Reuse Part 2 The Use of Metrics to Indicate Reuse Effectiveness 5 Why Metrics 6 Software Reuse Metrics 6.1 Cost / Benefit Metrics Cost / Productivity Metrics Quality of Investment Metrics Business Reuse Metrics Reuse Percent Reuse Cost Avoidance Reuse Value Added Additional Development Cost 6.2 Amount of Reuse Metrics Reuse Level 6.3 Summary of Reuse Metrics 2

3 Introduction Among numerous software technologies, reuse technology has gained great attention from academia, government, and industry over the last decade [16]. Software professionals have recognized reuse as a powerful means of overcoming the shortfalls of today s software development process. It has yet to emerge as a standard practice for software development; though, most likely due to the fact that there just is not enough data available for organizations to reasonable justify the initial expense of developing a reuse initiative. This is where metrics comes into play. There are business cases and success stories that lead us to believe the value of reuse, yet they lack the hard data across various software development processes that businesses truly need. But the use and documentation of software reuse metrics is growing, and so too will the implementation of reuse initiatives. This study is broken into two sections, beginning with a study of the current state of software reuse, and ending with an analysis of how metrics can be used to help identify the need for reuse and study the current state of a reuse initiative. 3

4 Part 1 Establishing A Software Reuse Program 1. What is Software Reuse? Software reuse is the process of implementing or updating software systems using software assets.[3] A software asset is much more than just lines of source code. It refers to anything that is produced by the software development process, including: components, requirements and proposal documents, specifications and designs, as well as user manuals and test procedures. All of these can be reused to produce a new software project. Reusability is the degree to which a thing can be reused. To achieve significant payoffs a reuse program must be systematic.[6] To implement a successful reuse program, companies must have measurements in place to track and measure their progress. 2. What Do We Wish To Accomplish Through Reuse? A good software reuse program facilitates the increase of productivity, quality, and reliability, and the decrease of costs and implementation time.[9] Reuse offers great benefits if used effectively in the right environment. Many success stories have been quoted from large, well-established companies: from Raytheon s 50% increase in productivity due to a reuse rate of 60%[10], to GTE s saving of $1.5 million from a reuse factor of 14%[14], to a Japanese software factories claim of annual productivity increases of 20% by implementing a software reuse program[11]. It is known that reuse works, and that it can become an effective way to maximize productivity, yet there still lies an uneasiness to take the initial jump towards developing a reuse program in many corporations. 4

5 3. Factors that Affect the Implementation of Software Reuse Programs? There are many issues, which are tied to technique, organization, politics and economics that have limited the promising potential of software reuse in real-world applications. 3.1 Human Factors Many times software designers and programmers are reluctant to use someone else s code or component because they either believe that it will take less time to simply build a new one from scratch, rather than locate, decipher and modify the existing one. This is especially true when it is not well documented, or if they lack the tools to do so efficiently. Many designers and programmers also often feel uncertain about the quality of existing code. Reuse can be problematic for management as well. Many managers believe that they may run into legal trouble down the line if defects are found in the reused components. Many times problems occur because it takes longer to do a thorough domain analysis (which is critical to the success of reused components) than it does to just build it from scratch. Managers may also be wary of reuse because it reduces the need for developers and programmers, which can lead to issues of authority. Without the availability of management who can efficiently coordinate a proven effective reuse plan, many companies find the chances for success to be very low. And after initial failure, most companies dare not to implement the software reuse strategy in the future.[12] 3.2 Technology Factor There is a fairly high failure rate when components are reused in a different domain and hardware platform from which the original component was designed for. Tools which support software reuse are still not widely available, and not all languages support software reuse technology. If a bug is found in a re-used component, it is sometimes 5

6 much harder to fix. Unless the proper reuse system is in place, these technical issues can become a nightmare for developers and management. 3.3 Organizational Factors Although the size of an organization does not have a direct effect on the rate of software reuse success, many small organizations believe they lack the resources needed to implement it correctly. Usually the greatest organizational factor affecting successful reuse is the communication or lack there of among group members and between levels of hierarchy in an organization. 3.4 Political Factors The old saying not invented here is a common worry among the political heads of a corporation. The misconception persists that customers will look at their reuse as an indication that their systems cannot be counted on, or that they lack competence in building systems from scratch. 3.5 Economic Factors Although it is widely accepted that software reuse reduces cost, it is still very difficult to convince sponsors that the initial costs (which are usually high) are going to be worth the final outcome. The benefits of such a program are rarely seen immediately, and are usually not seen for a longer period of time if a company does not commit entirely to the program. 4. Overcoming Outside Factors We have established what software reuse is, and what we wish to accomplish by implementing a reuse program. We have also identified the external factors that inhibit a reuse program. So how does an organization overcome these factors to successfully implement a reuse program? 6

7 4.1 Make Reuse Attractive The first, and most important step is to gain the support of top-level management for the reuse program.[1] Gaining top-level support is crucial because the introduction of a reuse program affects all parts of a software production process in the company. The support of the high level management in charge of all aspects of development must be gained to allow changes to be supported and implemented, and to allow changes to company policy to be made, if needed.[8] A typical way to gain this type of support is to give presentations on reuse, identifying the benefits to the company, and how it could best be utilized. Presenting it in this way allows for positive feedback of what management expects from a reuse program, and what their long-term goals for the future are. 4.2 Make Reuse Available To make reuse available, it is important to establish a strategy for adopting a software reuse technique. In most cases an incremental approach to implementation of the reuse strategy is stressed. This is because an incremental approach to reuse allows reuse techniques to be tried and proven on a small scale before introducing major changes to the company[15]. This also allows target areas to be identified, where reuse will be the most effective. Some other structured techniques for establishing a strategy are listed below: Planning and Reviews These meetings can first serve as a communication tool between levels in the company, as the program progresses they can serve as technical and implementation review meetings. Design It is recommended that the design of your program should be introduced from the beginning stages. Resource Management It is important to establish exactly what tools will be used to collect the reused material, e.g. central repository. Documentation This should be a high priority from the very beginning of your program, good documentation is what can make or break a reuse strategy. 7

8 4.3 Establish Ability to Implement Reuse Tight standards are to be identified to express the company s ability, and dedication to the implementation of a software reuse program. Goals should be set, a commitment should be established, and the ability to perform should be reaffirmed. Activities to be performed, measurement and analysis, and implementation conditions should be indicated. The Carnegie Mellon Software Engineering Institute has set forth guidelines which are shown in Figure 1. [2] Figure 1. Set Goals To get strict attention from management, high-level goals must be established. The overall goals of a reuse program are: 1. To incorporate reusable software assets into new or existing applications. 2. To collect, evaluate, and make available to software projects reusable software assets. Establish a Commitment to Perform Commitment 1: The organization and project follow a written policy for performing the software reuse activities. This policy typically specifies that: 1. The software reuse tasks are performed in accordance with the organization and project s defined software process. 2. Appropriate methods and tools are used to identify, build, acquire, and/or incorporate reusable software assets. 3. Reusable assets are maintained and made available to the organization and projects. Commitment 2: The organization maintains the reusable software assets. Maintenance of reusable software assets includes: 1. Storage of the physical asset or reference to the physical asset. 2. Identification of assets for subsequent retrieval. 8

9 Indicate Ability to Perform Ability 1: Adequate resources and funding are provided for performing the software reuse tasks. 1. Skilled individuals are available to perform the different software reuse tasks. 2. Tools to support the software reuse tasks are made available. 3. Incentives are in place for the development of as well as the use of reusable assets. Ability 2: Members of the software engineering staff receive required training to perform their technical assignments associated with software reuse. Ability 3: The project manager and all software managers receive orientation in the technical and non-technical aspects of software reuse. Activities Performed Activity 1: Software product and/or process requirements are evaluated to determine if existing software assets exist that can fulfill the requirements. (i.e., matching needs to capabilities) Activity 2: Assets are identified and evaluated for reuse. Considerations for reuse should include: Activity 3: Asset certification requirements are established to determine asset completeness, quality, and/or history. Activity 4: A library(ies)/repository(ies) of reusable software assets is established and maintained. Activity 5: The software reuse activities are maintained, managed, and controlled as part of the organizations and project's defined software process. Activity 6: Incorporation and/or development of reusable assets are included in the project's software costing and sizing practices. Measurement and analysis Measurement 1: Measurements are made and used to determine the effectiveness of the organization and project's software reuse activities. 9

10 Verifying implementation Verification 1: The software quality assurance group reviews and/or audits organization's and projects' activities and work products for software reuse and reports the results. Part 2 - The Use of Metrics to Indicate Reuse Effectiveness 5. Why Metrics? There are four reasons for measuring software processes, products and resources[13]: To characterize To evaluate To predict To improve Software reuse is not unlike any other software development process in that in order to correctly establish its usefulness, we must have methods to quantify it. Quantifying reuse s effectiveness in order to justify the initial cost of implementing a program may very well be the greatest factor as to why it is not more widely put into practice. The most important software reuse measurement problem at present, is the lack of data collection. This statement should not be taken out of context, since measurement data should not be collected without first defining the purpose of measurement (e.g., Goal- Question-Metric approach)[16]. Based on ongoing research in the field of software reuse. The [Reuse 97 Software Reuse Metrics Working Group Summary] addressed the Reuse Data Collection Problem [16], and summarized their research with the following problem observations and recommendations: 10

11 Problem 1: The software reuse community is rapidly growing in terms of information and knowledge, yet it is uncoordinated in terms of sharing and collaborating its experiences.[16] - The group found that there are indeed many conferences, publications, industry and government research initiatives in the reuse field, yet they seem to fairly uncoordinated. There have been many applications of reuse spread throughout a diverse variety of software projects, which makes data collection and interpretation all the more difficult. Recommendation 1: The Reuse 97 RMWG recommends the development of a topology for software reuse measurement community to assist in the collaboration and coordination of research, data collection, data interpretation, and sharing of information and knowledge[16]. Problem 2: Many organizations are unable to develop a credible software reuse business case that is convincing enough to win management approval for committing resources and funding for a software reuse program[16]. - As noted earlier, this lack of data is a great cause for the lack of development of reuse programs. Management simply cannot buy-in to a development program until they see the hard data for its effectiveness in the same business area as their company. Many companies have heard the success stories, and believe that there is a valid case for a positive return on investment from reuse, they just lack credible data. Recommendation 2: The Reuse 97 RMWG recommends the development of a business case for software reuse that addresses ROI for organizations attempting to develop a software product line. This ROI should be based on industry data[16]. Problem 3: The collection of software reuse data has the same issues as other software measurement activities[16]. 11

12 - Reuse metrics are needed in the same way that metrics are needed for all other aspects of software development. They need to be applicable across various software organizations and domains. Recommendation 3: The Reuse 97 RMWG recommends the software reuse community to collectively consider the problem of data collection for a software reuse data and generate a plan that would utilize an existing software metrics repository. IT is highly recommended that the plan be incremental with the early implementation being low cost to demonstrate benefits and more easily secure sponsorship[16]. Problem 4: S software architecture and design metrics that are related to software reuse are needed[16]. - There is a lack of metrics as a whole throughout the reuse community. High-level metrics are available, but industry-specific metrics across a wide-variety of software development programs are difficult to find. Recommendation 4: The Reuse 97 RMWG recommends that the software reuse community encourage and support the development of software architecture and design metrics[16]. 6. Software Reuse Metrics We have studied the usefulness of software reuse, the factors that affect reuse, and the need for metrics to validate a reuse program. So what metrics can be used effectively in a software reuse program? 6.1 Cost / Benefit Metrics Cost / benefit analysis metrics include economic cost-benefit metrics and quality and productivity payoff analysis[7]. For our analysis, we will categorize these metrics into: cost/productivity, quality of investment, and business reuse metrics. 12

13 6.1.1 Cost / Productivity Metrics Gaffney and Durek [1989] propose two cost and productivity models for software reuse[7]. They break the models into what they call a simple model, which demonstrates the cost of reusing software components, and a cost-of-development model, which adds to this by representing the cost of developing reusable components[7]. For the simple model: C is the cost of software development for a product relative to all new code. (C = 1) R is the proportion of reused code in the product. (R 1) b is the cost relative to that for all new code, incorporating reused code into the product (b = 1 for all new code) Relative cost for software development: C = (1) (1 R) + (b)(r) = [(b 1) R] + 1 Relative Productivity: P = 1/C = 1/((b 1) R + 1) * For the reuse to be cost effective, b must be < 1. For the cost-of-development model: E will represent the cost of developing a reusable component (E > 1) n is the number of uses which the cost will be amortized. New cost for software development: C = (b + (E/n) 1) R Quality of Investment Metrics A study by Barnes and Bolinger [1991] examined the cost and risk features of software reuse and suggested an analytical approach for making good reuse investments[7]. This example is a high-level analysis of the net financial loss/gain. We represent the total benefit by estimating the reuse benefit for all activities that profit from the reuse investment. 13

14 Q is the Quality of Investment B represents the Reuse Benefits R represents reuse investments Quality of Investment: Q = B / R * If Q < 1, the reuse effort resulted in a net financial loss, if the Q > 1, the reuse effort resulted in a net financial gain Business Reuse Metrics Poulin et al. [1993] present a set of metrics used by IBM to estimate the effort saved by reuse. The measures used in the study are similar to the cost / productivity measures used by Gaffney and Durek[1989], but they are further broken down for more exact calculations. The data elements used for the metrics are shown in the table below: Figure 2: Observable Data [Poulin et al. 1993] Data Element Shipped source instructions Changed source instruction Reused source instruction Source instruction reused by others Software development cost Software development error rate Software error repair cost Symbol SSI CSI RSI SIRBO Cost per LOC Error rate Cost per error Reuse Percent The reuse percent represents how much of the product can be attributed to reuse. This can be divided into individual products, certain product releases, or the entire organization. Product Reuse Percent: = RSI / (RSI + SSI) * 100 percent 14

15 Reuse Cost Avoidance This measures reduced total product costs as a result of reuse[7]. It is estimated by Poulin et al. that the financial benefit attributable to reuse during the development phase is 80 percent of the cost of developing new code. This is accounted for in the metrics: Development Cost Avoidance: = RSI * 0.8 * (new code cost) Service Cost Avoidance: = RSI * (error rate) * (new code cost) Reuse Cost Avoidance: = Development cost avoidance + Service cost avoidance Reuse Value Added This metric includes source code that is reused within the product and source code that is reused by others. Reuse Value Added: = (SSI + RSI + SIRBO) / SSI Additional Development Cost This metric estimates the cost of additional effort at 50 percent of the cost of new development. Additional Development Cost: = (relative cost of reuse 1) * code written for reuse by others * new code cost 15

16 6.2 Amount of Reuse Metrics Amount of reuse metrics are used to assess and monitor a reuse improvement effort by tracking percentages of reuse of life cycle objects over time[7]. The metric in its most generic form: amount of life cycle object reused / total size of life cycle object The generic metric based on lines of code: lines of reused code in system or module / total lines of code in system or module Reuse Level The basic dependant variable in software reuse improvement efforts is the level of reuse[4]. Reuse level measurement assumes that a system is composed of parts at different levels of abstraction. The levels of abstraction must be defined to measure reuse[7]. The quantities in Figure 3 can be calculated given a higher-level item composed of lower level items. These quantities are used to define the metrics given[5]: Figure 3 [7]: L = the total number of lower level items in the higher level item E = the number of lower level items from an external repository in the higher level item I = the number of lower level items in the higher level item that are not from an external repository M = the number of items not from an external repository that are used more than once External Reuse Level: E / L Internal Reuse Level: M / L 16

17 Total Reuse Level: External Reuse Level + Internal Reuse Level * These metrics will produce values between 0 and 1. The more reuse occurs, the closer to 1 the value will be. This model was enhanced to add a variable reuse threshold level[17]. The quantities are shown in Figure 4 and Figure 5. These quantities will be used to produce the updated reuse level metrics and the reuse frequency metrics below. Figure 4 [17]: ITL = internal threshold level, the maximum number of times an internal item can be used before it is reused. ETL = external threshold level, the maximum number of times an external item can be used before it is reused. IU = number of internal lower level items that are used more than ITL. EU = number of external lower level items that are used more than ETL. T = total number of lower level items in the higher level item, both internal and external. Internal Reuse Level: IU / T External Reuse Level: EU / T Total Reuse Level: (IU + EU) / T Figure 5[17]: IUF = number of references in the higher-level item to reused internal lower level items. EUF = number of references in the higher-level item to reused external lower level items. TF = total number of references to lower level items in the higher level item, both internal and external. Internal Reuse Frequency: IUF / TF 17

18 External Reuse Frequency: EUF / TF Total Reuse Frequency: (IUF + EUF) / TF 6.3 Summary of Reuse Metrics These are just a few of the metrics that can be used to measure the reuse implemented in the software reuse development process. As reuse is more widely adapted, more and more metrics become available, and the quality and business case proof becomes more evident. Software reuse is still growing, and will continue to as long as its benefits can be quantified. 18

19 References [1] Biggerstaff, T.J., Perlis, A.J., (ed.); Software Reusability. Applications and Experience, vol. II ; ACM Press, Addison-Wesley, Reading, Mass.; 1989 [2] Carnegie Mellon Software Engineering Institute: Software Reuse; July 2003; Carnegie Mellon University [3] Department of Defense. Software Reuse Executive Primer, Falls Church, VA, April, [4] Frakes, W Software reuse as industrial experiment. Am. Program. (Sept.), [5] Frakes, W An empirical framework for software reuse research. In Proceedings of the Third Workshop on Tools and Methods for Reuse (Syracuse, NY). [6]Frakes, W.and Isoda, S Success factors of systematic reuse. IEEE Softw. 11, 5, [7] Frakes, W. and Terry, C.; Software Reuse: Metrics and Models; In ACM Computing Surveys, Vol 28, No. 2, June 1996 [8] Hooper, J.W., Chester, R.O.; Software Reuse: Guidelines and Methods ; Plenum Press, New York; 1991 [9] Jordan, Kimberly; Software Reuse Term Paper [10] Lanergan, R.G., Grasso, C.A.; Software Engineering with Reusable Design and Code ; IEEE Transactions on Software Engineering; Sept 1984; Vol.10 No.5 P [11] Matsumoto, Y.; Some Experiences in Promoting Reusable Software: Presentation in Higher Abstract Levels ; In: Software Reusability. Concepts and Models, vol. II; [12] Orenstein, David; Code reuse: reality doesn t match promise; Vol. 32 Issue 34 pp; 8 in ComputerWorld August 1998 [13] Park et al. Goal-Driven Software Measurement A Guidebook; SEI Handbook CMU SEI-96-HB-002; August [14] Prieto-Diaz, R.; Implementing Faceted Classification for Software Reuse ; In: Proc.of 12th International Conference on Software Engineering; IEEE, Nice, France; Mar 1990; P [15] Prieto-Diaz, R.; Making Software Reuse Work: An Implementation Model ; Software Engineering Notes; Jul 1991; Vol.16 No.3 P

20 [16] Reuse 97: Software Reuse Metrics Working Group Summary, Proceeding for Sixth Annual Workshop of Software Reuse Education and Training, August [17] Terry, C Analysis and implementation of software reuse measurement. Virginia Polytechnic Institute and State University, Master's Project and Report. 20