Master Thesis Software Engineering Thesis no: MSE-2010-38 12 2010 Measuring Cost Avoidance Through Software Reuse A model to measure costs avoided through software reuse and guidelines to increase profits through software reuse Mohsin Irshad School of Computing Blekinge Institute of Technology SE-371 79 Karlskrona Sweden This thesis is submitted to the School of Computing at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Master of Science in Software Engineering. The thesis is equivalent to 20 weeks of full time studies. Contact Information: Author: Mohsin Irshad 840930-1531 E-mail: [email protected] Industrial advisor: Martin Wallin Ericsson AB,Karlskrona, Sweden University advisor: Prof. Richard Torkar School of Computing School of Computing Blekinge Institute of Technology SE-371 79 Karlskrona Sweden Internet : www.bth.se/com Phone : +46 455 38 50 00 Fax : +46 455 38 50 57 Abstract Context. Software Reuse is considered as silver-bullet for software development. However, measuring benefits of software reuse is difficult and cumbersome task because of varying number of factors involved in it. Different reuse cost models already exist in literature which measure various different attributes of software reuse. Mainly these models are used for calculating return over investment or cost-benefit analysis. Objectives.We have investigated that very few cost economic models have been proposed for measuring costs avoidance,degree of empirical validation, assumptions, types of artifacts they can measure and whether they provide guidelines on collection of metrics for measuring reuse benefits. Methods.In this research, a systematic review was conducted. Based on the results of systematic review, a model was proposed which can measure cost avoided by reuse of every kind of artifact. In a systematic all major article sources were used. Studies were selected after reading titles and abstracts. Three cost avoidance models were found and an analysis of these models was performed. Based on the analysis, a new model was proposed to fill the gap left by these studies. Results. New model measures every kind of reuse artifact and provides guidelines on how and what to measure in order to calculate reuse benefits. This model was then validated in the industry and technology was transferred to the industry for future usage. Guidelines for improved savings were developed. Conclusions. We conclude that many models are related to each other and use similar techniques to measure the cost avoidance however they can not measure all kinds of reuse artifacts. New model performed well in industry. However, we found that the new model should accommodate maintenance costs since these are major savings by software reuse. Moreover, we conclude that there is a need for further validation of guidelines and model in industry. Keywords:Cost Avoidance, Software Reuse, Maintenance Costs, Dynamic Validation, Guidelines, Savings, Benefits Contents Abstract i 1 Introduction 1 2 Related Work (Systematic Literature Review) 2.1 Generation of search strategy . . . . . . . . . . 2.1.1 Search Terms Construction . . . . . . . . 2.1.2 Electronic Database . . . . . . . . . . . 2.2 Study selection criteria . . . . . . . . . . . . . . 2.2.1 Exclusion Criteria . . . . . . . . . . . . . 2.2.2 Inclusion Criteria . . . . . . . . . . . . . 2.3 Quality Assessment Criteria . . . . . . . . . . . 2.4 Data Extraction . . . . . . . . . . . . . . . . . . 2.5 Conducting the review . . . . . . . . . . . . . . 2.6 Analysis and Discussion . . . . . . . . . . . . . 2.6.1 Available Models for Cost Avoidance: . . 2.6.2 Metrics required . . . . . . . . . . . . . . 2.6.3 Limitations of Models . . . . . . . . . . 2.6.4 Validation in Industry . . . . . . . . . . 2.6.5 Quality Assessment . . . . . . . . . . . . 2.7 Conclusions and Discussion . . . . . . . . . . . 2.8 Limitations . . . . . . . . . . . . . . . . . . . . 2.9 Summary of Literature Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Background Work 3.1 A Survey on an organizations reuse process: Results 3.1.1 Research objectives and methodology . . . . 3.1.2 Questionnaire . . . . . . . . . . . . . . . . . 3.1.3 Data Collection . . . . . . . . . . . . . . . . 3.1.4 Results Obtained . . . . . . . . . . . . . . . 3.1.5 Patterns of Reuse . . . . . . . . . . . . . . . 3.1.6 Cost Factor . . . . . . . . . . . . . . . . . . 3.1.7 Interpretation and analysis of results . . . . 3.1.8 Recommendations . . . . . . . . . . . . . . . ii . . . . . . . . . . . . . . . . . . 3 4 4 4 6 6 7 7 8 8 12 12 14 15 15 16 16 17 18 and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 19 19 20 21 21 22 25 26 27 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 3.3 3.1.9 Future work . . . . . . . . . . . . . . . . . . . . . . . . 3.1.10 Validity . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.11 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . Literature Survey on Reuse Practices of 5 Large organizations 3.2.1 Industrial Review . . . . . . . . . . . . . . . . . . . . . 3.2.2 Analysis and Discussion . . . . . . . . . . . . . . . . . 3.2.3 Recommendations . . . . . . . . . . . . . . . . . . . . . 3.2.4 Validity . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . Reuse of a black-box component An Industrial Experience . . 3.3.1 Factors and Discussion . . . . . . . . . . . . . . . . . . 3.3.2 Recommendations . . . . . . . . . . . . . . . . . . . . . 3.3.3 Future work . . . . . . . . . . . . . . . . . . . . . . . . 3.3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 4 Research Methodology 4.1 Research Design . . . . . . . . . . . . . . . . . 4.2 Conducting the Study . . . . . . . . . . . . . 4.2.1 Phase 1: Preliminary investigation . . 4.2.2 Phase 2: Model Creation . . . . . . . . 4.2.3 Phase 3: Testing in industrial settings 4.2.4 Phase 4: Release of complete solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 29 29 30 30 37 39 39 40 40 41 45 45 46 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 48 49 50 51 53 55 5 Model for calculating Cost Avoidance 5.1 Software reuse metric plan . . . . . . . . . . . . . . . 5.2 The Model . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Third party Reuse products . . . . . . . . . . 5.2.2 Hourly Rate . . . . . . . . . . . . . . . . . . . 5.2.3 Guidance in data collection . . . . . . . . . . 5.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Coverage . . . . . . . . . . . . . . . . . . . . . 5.3.2 Number of reuse instances . . . . . . . . . . . 5.3.3 Cost Time relationship . . . . . . . . . . . . 5.3.4 Productivity . . . . . . . . . . . . . . . . . . . 5.3.5 Validity of Model on Different Reuse Artifacts 5.3.6 Generic Model . . . . . . . . . . . . . . . . . . 5.3.7 Risks Associated . . . . . . . . . . . . . . . . 5.4 Dynamic Validation . . . . . . . . . . . . . . . . . . . 5.4.1 Initiation . . . . . . . . . . . . . . . . . . . . 5.4.2 Data Analysis . . . . . . . . . . . . . . . . . . 5.4.3 Results . . . . . . . . . . . . . . . . . . . . . . 5.4.4 Evaluation of Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 56 57 57 57 58 58 58 58 59 59 59 59 60 60 61 62 62 63 iii . . . . . . . . . . . . . . . . . . 6 Guidelines for introducing reuse culture 6.1 Initial Strategy . . . . . . . . . . . . . . . . . . . . . . 6.1.1 Small scale domain analysis . . . . . . . . . . . 6.1.2 Introduction of component library . . . . . . . . 6.1.3 Contact person for reusable artifact . . . . . . . 6.2 Short-term Strategy (1 to 3 years time) . . . . . . . . . 6.2.1 Encourage Object Oriented based design . . . . 6.2.2 Optimize component library . . . . . . . . . . . 6.2.3 Store medium size components . . . . . . . . . 6.2.4 Encourage black-box reuse . . . . . . . . . . . . 6.2.5 Design applications keeping in mind their reuse 6.2.6 Documentation, groups, forums on reuse . . . . 6.2.7 Incentive on Reuse . . . . . . . . . . . . . . . . 6.3 Long-term Strategy (3 to 5+ years time) . . . . . . . . 6.3.1 Development language and framework . . . . . 6.3.2 Refactoring Contents of Component Library . . 6.3.3 Product Line Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 65 66 66 66 66 67 67 67 67 68 68 68 68 69 69 69 7 Conclusion 70 A Appendix A 72 B Appnedix B 74 C Appendix C 76 D Appendix D 78 E Definitions 79 References 80 iv Chapter 1 Introduction Software organizations are always looking for methods in order to reduce costs, improve quality and decrease development time. Software reuse has been focus of most organizations as it can help in decreasing cost, achieving quality product and reducing time to market a product. However, introducing reuse culture in an organization is difficult because software reuse is concerned with various aspects of software development. Technical, management and business aspects of software reuse are still under investigation and myths related to software reuse are described in literature  .There are no agreed upon guidelines which can help organizations in introduction of reuse culture, measuring benefits through reuse, using methods which can measure amount of software reuse present inside the organization and in solving other problems related to software reuse. In software engineering software reuse has been claimed as an important source of saving costs . Activities in software reuse vary from management aspects to complex development aspects, increasing its complexity and value to the software development process. Software Reuse can be an important source of avoiding costs and to increase savings for any software development organization. Measuring costs saved through software reuse is challenge because of its dependency on management, technical and organizational factors. Variety of software reuses cost models already exist in literature  . These models were categorized by Poulin  into three different categorize. These categorize were based on the nature of these models and type of problems they address. According to Poulin  reuse economic models can be divided into three main types: Return on Investment models (ROI models), Cost Benefit Analysis models and Cost Avoidance models. These models look similar but they provide solution to different problems. Return on Investment models are applicable on organizations which have already invested in reuse processes and now trying to measure the benefits they have gained. Cost-Benefit models are used for making decisions on reuse investments. These types of models are useful for management as they help in making optimal decisions before any artifact is reused. Cost avoidance models are least discussed in literature. They have limited scope as they can only be applied after the artifact has been reused and are simple enough to apply. An important factor in cost avoidance is that it does not impose any restriction on 1 Chapter 1. Introduction 2 reuse practices. Cost avoidance does not require any investment up front in order to yield benefits; organizations can measure benefits through reuse without any major initial investments. Benefits are measured regardless of investment done in software reuse. In this study, aim was to find a method which can help organizations in measuring cost avoidance and provide them guidelines for increasing profitability without major changes in organization structure. As evident from literature review, present in Chapter 2, measuring benefits through all kinds of software reuse artifacts and guidelines on how and what to measure are missing. Literature and industrial experiences usually focus on code reuse only and calculate costs avoided through code reuse. In this study we wanted to develop method to measure cost avoided through every kind of reuse artifact. Apply our developed method in any large organization and analyze the results. Therefore this study is focused on cost avoidance models which can measure software reuse and guidelines which can improve profitability through software reuse. A systematic literature review was conducted on cost avoidance models in software reuse. Results from this review showed three different models which support measuring of cost avoidance through software reuse. Observations made by author inside a very large telecommunication organization helped in producing guidelines for increasing profits. These guidelines are in the form of step-wise process .Further description of systematic review is present in Chapter 2. In Chapter 2 of the study already existing models are described. Their flaws and limitations are also discussed. Chapters 2 and 3 discuss need of new model. In Chapter 5 a new model is proposed which tries to address the issues found in previous models. Same chapter discusses validation of new model in industry. Chapter 6 discusses guidelines for increasing profitability through software reuse .Conclusions and suggestions are summed up later . Chapter 2 Related Work (Systematic Literature Review) Systematic literature review helps in identification and analysis of studies relevant to this topic. Kitchenham described steps for performing the systematic literature review . Benefits of a systematic literature review were listed by Kitchenham . In order to carry out this study, steps defined by Kitchenham were followed. This section describes all the necessary steps related to our study, as outlined by Kitchenham . Kitchenham’s method was selected because it was widely used by research community. Each step is well defined and many systematic reviews are based on this method. In order to analyze the pros and cons, of reuse cost avoidance model, following questions were formulated. Main aim was to limit scope of this study to cost avoidance only as numbers of economic models are already present in literature     R.Q.1: What reuse economic models are present in literature which measure costs avoided through software reuse? Research questions below are based on outcome of R.Q.1 R.Q.2: How many reuse cost related models calculate the cost avoided through reuse in a direct way? R.Q.3: What assumptions are made by each of these models? R.Q.4: What metric is required in order to apply each of these models? R.Q.5: What are the limitations associated with each of these models? The population in this study is managers seeking the financial benefits of software reuse. Intervention includes application of cost estimation models to estimate cost avoided through software reuse or determents caused by it. Research questions are not based on comparison. The outcome of study will be the 3 Chapter 2. Related Work (Systematic Literature Review) 4 identification of flaws in current reuse cost estimation models (addressing cost avoidance) and suggestions in order to improve the models. We have not forced any restrictions on context and experimental design. 2.1 Generation of search strategy Following steps were followed in order to generate the search strategy. 2.1.1 Search Terms Construction A two phase search strategy was used in order to create the search terms. Both phases are combined in Fig 2.1. In the first phase following steps were followed in order to construct the search terms used for the study. • Develop the search terms from research questions. All possible terms which relate to the research questions were listed. • From the above list of terms, the synonyms of terms were added in list of search terms. Intention was to add as many search terms as possible. • New search terms were created by changing the plurals to singular forms and singular to plural forms. • By gathering keywords from abstracts and conclusions of relevant research papers. • New search terms were gathered by browsing through grey literature (technical reports, articles etc.). • By using Boolean OR with synonyms of search keywords. • By using Boolean AND for combining different search terms. In second phase search terms were piloted on an IEEE database. Each term was queried on database, based on the results obtained from the query few search terms were removed. This piloting of search string helped in improving the quality of search terms. These terms , used with different combinations, are listed in Table 2.1 . 2.1.2 Electronic Database Electronic databases are useful resource to find out relevant literature. Several different databases are present online with their own area of specialization. This study was concerned with software engineering therefore it was decided to select relevant databases only. Following databases were selected to perform this study: Chapter 2. Related Work (Systematic Literature Review) 5 Figure 2.1: Phases of search strategy • ACM Digital Library • IEEE Xplorer • Springer Link • Science Direct • Engineering Village • Willey Inter Science • ISI web of Science Search strings were searched in the document titles. Motivation behind this choice was to simplify of our search results and in order to get as many relevant results as possible. Chapter 2. Related Work (Systematic Literature Review) No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Search Term Software Reuse Cost Model Models Measurements measuring framework estimation Savings Measuring benefits Economics Benefits Avoidance No. 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 6 Search Term return investment Finance Assessment Business Reusability measurement technique reduction price Tracking Monitoring Cost-benefit Financial ROI Table 2.1: Search Terms 2.2 Study selection criteria Reuse economic models have been focus of researchers for over two decades and variety of models are already present in literature. Frakes  and Poulin  categorize the reuse economic models into different categorize. These categorize are based on the solution provided by each of reuse economic model. In order to limit the scope of this study, a reuse economic model category called Cost Avoidance  was selected as main focus of this research .Criterion was formulated and this criterion is further divided into exclusion criteria and inclusion criteria. Inclusion criterion describes the rules by which articles are included in the study. An exclusion criterion was developed in order to exclude the irrelevant studies in the initial phase. 2.2.1 Exclusion Criteria These guidelines were followed while excluding studies from initial search results. • Studies which do not relate to software engineering • Studies which do not relate to Software reuse. • Studies which do not relate to cost aspects of software reuse. • If full text of the study was not available. Chapter 2. Related Work (Systematic Literature Review) 7 • Exclude the studies which are in language other than English and English translation is not available. 2.2.2 Inclusion Criteria In order to increase the credibility of study, inclusion criterion was made very flexible. It was made to accommodate every type of reuse economic model. Motivation was to search for models which can in-directly calculate cost avoidance. Following are the rules developed for including a study. • Study discusses cost related aspects of software reuse. • Study describes any software reuse cost model. • Study should be available in full text. • Study should discuss cost avoidance related topics • Study should be published in some reputable journal and peer reviewed. • Study describes validation of any reuse cost estimation model. • Study evaluates or analyzes reuse cost estimation process or method. • Study compares or discusses attributes of any reuse cost estimation model. • Literature review, systematic review, industrial experience, case study, experience report on reuse cost estimation models will be included as well. 2.3 No. 1 2 3 4 5 6 7 8 Quality Assessment Criteria Quality Assessment Checklist Does the article clearly define the context of study? Is the introduction and background provided in detail? Is this article cited by other articles? Is the research methodology defined in detail? Are the findings closely related to each other? Do the objectives of research and conclusion relate to each other? Is this research useful for Software engineering industry? Does the article report the negative findings? Table 2.2: Quality Criteria To judge the quality of the included studies, a quality assessment criterion was developed.Quality criterion will help the study during analysis and synthesis Chapter 2. Related Work (Systematic Literature Review) 8 phase. It will be easy to differentiate between a quality study and an average study. Furthermore it will provide justification for providing more importance to selected studies based on its higher quality as recommended by . This criterion is shown in Table 2.2. Table 2.2 is based on check list and each field will be answered with yes or no. However, this quality criterion is not in very rigid and detailed. This is an exploratory study where objective is to locate all the economic models which can measure cost avoidance. This study was not designed to judge the quality of reuse economic models present in the literature 2.4 Data Extraction Dyba and Dingsoyr  have described procedure for the management of citations. This procedure  was followed during this study. Endnote was used for storing the citations in the initial phases of study. Separate endnote library was maintained for each step of the study. During the last stages of study an excel sheet was maintained in parallel with Endnote citations. That sheet was used for applying inclusion and exclusion criteria for the purpose of narrowing down the study results. Endnote was also used to find the duplicate studies and remove these studies in the initial phase. A data collection form was developed for extracting the information from the selected studies. A pilot study was conducted in order to check the usefulness of the data collection form, based on the input received, from the pilot study, this form was modified slightly. Data extraction form is present in Table 2.3 2.5 Conducting the review After defining the review objectives and review protocol next step was to conduct the review. Conducting the review was several step processes. The conducting of review is shown in figure 2.2. In the first stage, each database was searched for relevant studies. All the defined search terms were used one by one and results were collected in Endnote. In order to get maximum results all results obtained were included in this phase. These seven databases generated 9348 results. Several copies of each article were present in the initial search results. Table 2.4 shows results obtained from each individual database. In second stage duplicate entries were removed. There were multiple copies of articles. This removal was a two step process. In the first step articles were removed based on exactly similar titles. Endnote was used for that purpose. In the next step articles were sorted with respect to authors name and then manual reading of titles took place. In total 7388 articles were removed from the initial search result. Chapter 2. Related Work (Systematic Literature Review) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 9 General Information Date of data extraction Article title Authors Names No of references Journal/conference/conference proceedings Date of publication Specific information Study context (Academia or Industry) Research methodology Literature review / Systematic review / Case study/Experiment / Survey/ Action research Study subjects Professional / Student Research Questions Name of the presented model How was the model presented Equation / diagrams / description On what grounds model is constructed What were the aims of the article? Is this model an extended form of any other model? Can the model calculate costs avoided through quality improvements? What metrics need to be collected in order to apply the model? Does the model provide guidelines on how to collect the metrics? What is the basic formula used by this model? Can the model calculate costs avoided through artifacts other than software code? How can model calculate costs avoided through artifacts other than code reuse? What different types of software artifacts were considered in the article? Was the model validated in Industry? Was the model validated in academia? Does the model provide details of validation in industry? Is the model dependent on organizational, technical or managerial processes in the industry? Is the model dependent on systematic reuse processes? Any assumption which model makes? Table 2.3: Data Extraction Form Chapter 2. Related Work (Systematic Literature Review) 10 Figure 2.2: Multi-step filtering of studies and final number of primary studies Third stage involved application of exclusion and inclusion criteria. First the exclusion criterion was applied in order to eliminate irrelevant studies so that remaining studies were only on software reuse. Inclusion criteria were then applied in order to narrow down the studies to economic models of software reuse. Generic studies on various topics of software reuse were eliminated. Only title was considered while applying inclusion, exclusion criteria. However in some studies it was difficult to judge the content of study based on its title, these studies were included for further review. Abstracts are good way to describe an article. Abstracts from 497 studies were reviewed. After reading the abstracts 77 studies were shortlisted for further investigation. These studies either contain reuse economic model or their abstract was inconclusive and demanded further review of studies. Conclusions of these 77 studies were reviewed. After reviewing the conclusion 29 reuse economic models Chapter 2. Related Work (Systematic Literature Review) Database ACM Digital Library IEEE Xplorer Springer Link Science Direct Engineering Village Willey Inter Science ISI Web of Science Total 11 Total Results 195 6324 140 82 1944 23 640 9348 Table 2.4: Databases Results were found. These 29 studies are present in Appendix B. Full Text of 15 studies was not available. These studies were eliminated from the review. List of these studies is present in Appendix C Objective of this review was to find reuse economic models which can measure cost avoided through reuse. The focus was not on general reuse economic models. Therefore these 29 studies were manually reviewed by reading their content. Finally 3 models were found which directly address the cost avoided through software reuse. These three studies are listed in the table 2.5 . These articles are focused on cost avoidance and provide mechanism to measure the costs avoided through reuse. In review some models were categorized as cost benefit model or return on investment models but these models were flexible enough to calculate cost avoidance as well. Measuring cost avoidance was not a focus of such models but they were generic enough to accommodate cost avoidance measurements. Since these models were not made for measuring cost avoidance therefore these were excluded from this study. These studies are listed in table 2.6. No 1 Ref  2 3   Article Title A reuse measurement and Return on Investment Model Software Reuse Metric Plan Measuring benefits of Software Reuse; Examining three different approaches to software reuse. Table 2.5: Final Models Year 1993 1993 2005 Chapter 2. Related Work (Systematic Literature Review) No 1 2 Ref   3  4  5  Article Title Making Reuse Cost Effective Economics of software reuse revisited Cost-benefit analysis for software reuse A decision procedure Cost Estimation Model for reuse based software products Evaluating software reuse alternatives A model and its application to an industrial case study 12 Year 1991 1993 1994 2008 2004 Table 2.6: Models which are not developed for Cost Avoidance 2.6 Analysis and Discussion After conducting the review and collecting the data, next phase was to focus on the analysis of models. Limited numbers of models were developed for calculating cost avoidance. Models which calculate the cost avoidance indirectly and were not made for measuring cost avoidance were excluded in this analysis phase. These models are listed in table 2.6. Reason for eliminating these models was simple, this study focus only on the models which are made for calculating cost avoidance. Any model which was not made for calculating cost avoidance was removed from the analysis and discussion part. In this section some main characteristic of models are highlighted and effect of these characteristics is discussed. 2.6.1 Available Models for Cost Avoidance: Following research questions deal with this section. R.Q.1: What reuse economic models are present in literature which can measure costs avoided through software reuse? R.Q.2: How many reuse cost related models calculate the cost avoided through reuse in a direct way? In this section a brief description of these three models is provided Poullin and Carusos Model Model  proposed by Poullin and Caruso is applicable on individual project or individual team. This model is divided into two phases. One phase in concerned with costs avoided during development and the other phase focus on costs avoided during maintenance. According to this model costs avoided during maintenance can be measured by following equation: Chapter 2. Related Work (Systematic Literature Review) 13 DCA = RSI x (1-RCR) x New Code Cost Here, DCA = Development Cost Avoided RSI = the total lines not written but included in the source files.RSI includes only completely unmodified reused software units . RCR = Relative cost of Reuse i.e. 0.2 This model assumes that users will be aware of cost per lines of code. Model is based on lines of code therefore no other software artifact can be measured with this model. Maintenance costs avoided by this model are termed as service costs. These costs take into consideration error rates and number of errors occurred after the new artifact has been in use. Defense Information Systems Agency United States department of defense information systems proposed a model similar to Poulins model . In fact this model is a more complex form of Poulins model. This model measured the total effort in labor hours to develop a project with reuse. This is shown in following equation: CA = R x (En Er) - CCOTS Where: CA = Cost Avoided En = Estimated Effort without reuse Er = Estimated Effort with reuse CCOTS = Commercial Off the shelf Component R = Costs of New custom code (in person hours) It has similar limitations as previous model. This model is also based on lines of code and do not take into consideration any other forms of software reuse. Measuring the benefits of software reuse - Examining three different approaches to software reuse This is new and comprehensive models on cost avoidance through software reuse . In this model authors, Amar and Coffey, provided three different models for measuring reuse savings. They take into consideration the processes present in the organization (ad-hoc or systematic) and based on the processes any of the provided formula is used. Basic unit for this model is person-hour. Authors proposed the basic formula as: (TLR+U)*N + i*SR*MOD + i*(1-SR)*BUILD ¡ i*BUILD Chapter 2. Related Work (Systematic Literature Review) 14 After simplifying for ad-hoc reuse, percent savings = [SR - (TLR+U)*(N/i)/BUILD SR*(MOD /BUILD)] *100 TLR = Time to locate each potentially reusable item U = Time to understand suitability of each potentially reusable item for current task N = Number of items that were examined, including each of the items that finally get reused i = number of attempted instances of reuse SR = Search hit rate. Percentage of i that yielded a positive search result MOD = Time to integrate/modify the reused item for current purposes BUILD = Time to build an element from scratch Here they assumed that organizations collect metrics such as search hit rate, time to understand suitability etc. Secondly this method provides the value of search hit rate as 20 percent but failed to explain the rationale or any reason behind this decision. This limits the models application as most of the organizations are not interested in collecting complex metrics (like search hit rate, time to integrate etc) and it can be consider as an overhead for the organization. This model lacked clarity and necessary details such as how to collect date, what should be counted as reuse are missing. Focus of the article is to provide model for cost avoidance and validating in the industry is not discussed. 2.6.2 Metrics required This section deals with the following research question: R.Q.4: What metric is required in order to apply each of these models? Two models were based on the lines of code  . In order to apply these models, one has to know the number of lines of codes reused and total size of the product in terms of lines of code. Third model  was based on person-hour as a basic metric. This model was based on several other factors such has search hit rate and number of attempted instance of reuse. Table 2.7 shows the metric used in each of the short-listed model No 1 2 3 Model    Metric Used Lines of Code Lines of Code Person-hour Table 2.7: Metrics Used Chapter 2. Related Work (Systematic Literature Review) 2.6.3 15 Limitations of Models Research questions 3 and 5 deals with this section. R.Q.3: What assumptions are made by each of these models? R.Q.5: What are the limitations associated with each of these models? Reuse artifacts, present in literature, are of various different types . First thing to consider about the limitation of any model was to investigate kind of artifact it can measure. Table 2.8 shows artifacts and the models    and checks that if models can measure these software artifacts. Yes or No answers are made when artifacts can be measured or cannot be measured. However, in some cases it was difficult to know whether the artifact can be measured or not. In such cases May Be was used and further investigation is required. Artifact Algorithms Archtecture Data Design Documentation Estimates Humand Interfaces Knowledge Models Plans Requirements Service Contracts Test Cases Code Measurable by  No No No No No No No Measurable by  No No No No No No No Measurable by  No No No No No No No No No No May Be Yes Yes Yes Yes No Yes No Yes Yes Yes May Be Yes Yes Yes Yes May Be Yes Table 2.8: Artifacts measured by Models 2.6.4 Validation in Industry Software reuse yields its benefits for the industry and all studies related to software reuse should preferably be validated in industry. By validating a study in the industry researchers can find out the limitations and advantages of their studies. Final studies were checked for their validation in the industry. Table 2.9 describes the validation aspect of the short listed models. Chapter 2. Related Work (Systematic Literature Review) No 1 2 3 Model    16 Metric Used Yes Yes No Table 2.9: Validation of models in industry 2.6.5 Quality Assessment Quality assessment allows us to judge the quality of study. Quality criteria were developed and selected studies were passed through these criteria. Table 2.10 shows the results after applying the quality criteria. It was interesting to note that no study reported any negative findings from their proposed model Quality Assessment Checklist Article  Does the article clearly define the context of Yes study? Is the introduction and background provided in Yes detail? Is this article cited by other articles? Yes Is the research methodology defined in detail? No Are the findings closely related to each other? Yes Do the objectives of research and conclusion re- Yes late to each other? Is this research useful for Software engineering Yes industry? Does the article report any negative findings? No Article  Yes Article  Yes Yes No No Yes Yes No No Yes Yes Yes Yes No No Yes Table 2.10: Quality Assessment Checklist 2.7 Conclusions and Discussion In previous section discussion on various findings of this systematic literature review is present. Following conclusions were drawn from this study: Conclusion 1: Lines of code, as metrics for calculating cost avoidance, cannot measure different types of reuse artifacts. Therefore, any other metric should be introduced in order to measure all kinds of reuse artifacts. Most common reuse artifact was the code. Nearly all models are based consider it as an only artifact which can be reused therefore these models are based on lines of code. However, a study by Bhargav  listed 14 different artifacts which can be reused. This study was based on artifacts which are present in literature. Lines of code cannot be a measure which could be applied on any reused Chapter 2. Related Work (Systematic Literature Review) 17 artifact. Hence, all these models have questions marks on their applicability on artifacts other than code. Conclusion 2: Basic formula, for measuring cost avoided through software reuse, remains the same in all models i.e. Cost without Reuse Cost with reuse. All models calculate reuse cost avoidance by same basic formula. However, metrics used in the formula differs in models. Most models used lines of code as a basic measure while one article used person-hour as basic measure for calculating software reuse. No time value of costs was included, which is usually the case with cost-benefit reuse models. Formula in all the models was sub-divided into integration, testing, searching and other costs related to reuse. All these costs sum up as a cost with reuse. Cost without reuse was generally calculated from historical data. Conclusion 3: New models are not validated in industry yet. Literature contains validation experiences of older models only. The most recent model on cost avoidance was not validated in industry. No experience of validation was presented in the article. However, old models, based on lines of code, were validated in the industry. They have been used in the industry for number of years. Conclusion 4: No negative findings were reported by the models. None of the models described any negative findings related to it. Literature lacks any articles which reports negative experience of these models. Negative findings help the practitioners in evaluating a model before its usage. Therefore its a major drawback associated with these models. Conclusion 5: No guidelines on what to collect and how to collect metrics related to model. Collection of metrics can cause problems for industry practitioners. Guidelines should be provided on what to collect and how to collect. None of the models described these guidelines. 2.8 Limitations There were studies of which no full text was available. These studies were very old and hard to locate. This has been a problem which can affect the validity of study.  has arleady reported this problem in literature and its affect. These studies were not used in this literature review since it was not possible to locate these. Therefore its a major drawback associated with this review. These studies can contain useful information on cost avoidance. Research focused on models which only deal with cost avoidance. There are models which can calculate return on investment, cost-benefit analysis and cost avoidance within a single solution. However these models are complex to apply and metrics are hard to collect. Therefore these were skipped in this study. However, list of these models is available in Appendix c. Chapter 2. Related Work (Systematic Literature Review) 2.9 18 Summary of Literature Review Cost avoidance is categorized as a category of software reuse economic models. However, in literature very little information is present on this topic. Aim of this study was to investigate about all the economic models built specifically for calculating cost avoidance through reuse. This study was conducted by Kitchmans method of systematic literature review. Results show that there are only three models which are developed for calculating software reuse. Two models are based on lines of code as a basic metric while third model is based on person-hour as a basic unit for measuring software reuse. Study found some limitations related to these models and these are listed in previous sections. Major problems found in these models are related to their application for industry, complexity level and lack of guidelines on collecting software metrics. Limitations are mentioned in Section 2.8, the main limitation was the lack of full text available for some articles. Chapter 3 Background Work This chapter contains description of background work done on this thesis. Three different studies are described and their details are narrated. Conclusion section of each chapter describes final outcome of each study. 3.1 A Survey on an organizations reuse process: Results and Analysis A brief study was conducted on software reuse practices and benefits associated with reusable artifacts. In this study a web-survey was performed inside an organizations products. This survey was sent to the designers in the form of a web-link, where they have to fill out the questionnaire. In the sections below author has gathered the results and analyzed the results. These results were formed on the basis of the feedback received from 6 designers. These designers had experience of developing large telecommunication systems. This study focused on two aspects of reuse. One was related to the patterns and general trends of reuse practices inside organization and second was cost aspects of software reuse. This was an exploratory study and aim was to find out problems faced by the designers for reusing a software artifact. 3.1.1 Research objectives and methodology This study describes basic trends and patterns present of reuse practices inside an organization. These trends and patterns can be helpful for the future research inside an organization and may point out the discrepancies present in the reuse process. Main research objectives of this study were: • To find the patterns of reuse and level of reuse inside orgnaziational unit. • To measure savings because of software reuse, identify method used by designers and problems associated with that. 19 Chapter 3. Background Work 20 Research method used for conducting this particular study was a survey. This method was selected because it was easier to reach the designers at remote location with the help of this method. A web survey was accessible by everyone on the intranet. Moreover, this study was meant to be a starting point for future research on same topic. In order to get the basic ideas of activities taking place inside an organization, a survey was quick and easiest method. This is categorized as qualitative research method. Reuse activities are more concerned with the staff present at grass root level of software projects. Software designers were selected as the focal point for this survey. Major development and management activities related to the software reuse take place at the design level . Therefore, for this survey the only focus were designers of different products. Following steps were followed to perform this study: • Identify the areas related to reuse which needs to be investigated. These areas were patterns of reuse activities, nature of reuse products and costs saved because of reuse. • Questions were developed • Questions were sent to the domain experts for review and feedback. • Questionnaire was updated with the changes, based on the feedback received from the experts • Request to the managers about the intended audience of survey questionnaire • Publish the survey over a web pool, which is accessible for audience in focus. • Receive results and analyze them. • Compare the results with the literature and come up with the suggestions. During analysis phase, results were divided into sections. Each section describes a particular research question. 3.1.2 Questionnaire Designing the questionnaire, which can help to find the answer of research questions, was an important part. Questions related to the first research questions were influenced by the following literature studies    . These studies helped to figure out what sort of questions needs to be asked from the designers. Questions were also designed keeping in view the different types of artifacts which can be reused by designers. These questions not only focused on code reuse but they were also directed towards reuse process itself. Chapter 3. Background Work 21 Second research objective demanded numbers which can illustrate the cost savings because of reused products. Designing questions for a study about costs was difficult because no previous knowledge and figures were present inside the organization. Since this was an exploratory study, from which other studies can benefit, therefore questions were developed to understand the awareness level of designers about cost savings. These questions were mostly about identification of process used to calculate cost savings. After preparing the questionnaire it was sent to the researchers for review. Basic aim was to make this study more useful and to maximize the benefits of this limited study. After getting the feedback from three active researchers, questionnaire was updated with the changes suggested by them. Questions prepared were mixture of close ended and open ended questions. Close ended questions were mostly related to the patterns of reuse activities carried out by designers. Close ended questions were in form of selecting the best choice out of given choices. Open ended questions were aimed at finding the reasons behind any particular pattern. Some of open ended questions were left optional for the interviewee in order to limit the time for filling out survey. Questionnaire was divided into two sections. One section was focusing on reuse patterns, level of reuse inside the products and awareness about effectiveness of reuse process. This section comprises major part of questionnaire. Second section was related to cost benefits associated with reuse process. Basic aim was to find costs saved by reuse process. However, since it was expected to be very hard for the designers to quote any figures therefore main focus was to find the process of calculating cost savings inside organization products. 3.1.3 Data Collection Collection of data was done using the organizations internal web tool. Survey was published on web resource. All the designers received an email with a link to that resource. They can fill there choices and write there comments on asked questions. These comments were then stored and managed by a web based tool. Owner of the survey was able to see results in different forms. A basic summary was shown in statistics form. However, if someone wants to see the detail results and which interviewee posted what kind of reply, further advanced options were also available. Data received from the interviewees could also be imported in an *.xls format and can be stored locally for analysis. 3.1.4 Results Obtained Feedback received from the designers was enough to show the patterns of reuse practices. Results obtained from the survey are present in this section. These are listed Chapter 3. Background Work 22 under two main categories, pattern of reuse and cost factor. Each result is elaborated in the respective paragraph. 3.1.5 Patterns of Reuse Identified patterns of reuse are discussed under their respective headings Reuse Culture From the feedback received from designers it can be concluded that reuse culture is ad-hoc. Normally designers try to look for reusable artifacts while designing a new product but often end up developing their own because of various issues. Efforts of reuse are at individual level and do not have proper procedure present which can assist the designers in searching for the required component. According to literature such a reuse culture is called opportunistic reuse . Searching for proper component is part and parcel of the reuse process. It often requires a lot of effort. All designers complained about this issue. Such complaints showed the lack of facilities at organizational level Open-source components are popular When asked about the favorite artifact, nearly all the designers preferred Opensource components for reuse. Reason behind this unanimous choice can be the support available for open-source components. Normally, OSS has wikis and forums available for the support. It has experts available who are willing to help the user if he has some queries related to the reuse. Access to these forums is easy and queries posted on these forums receive a quick reply most of the time. Therefore most designers prefer OSS. Literature also points out the success of OSS when reused. Middleware is preferred inside product family Nearly all designers used middleware as a preferred reuse artifact. Here at An organization most of telecom products run as a service in application servers. They can be labeled as Domain Specific applications . In literature these are classified as most used artifacts in a code reuse . They fall under the category of middleware. These are easily reused several times without any major changes and that can be the reason behind the popularity of middleware components. Secondly, developing a middleware component from scratch is a troublesome job; therefore most of the designers like to reuse an old one. Chapter 3. Background Work 23 GUI is least preferable Surprisingly GUI components are least likely by the designers to reuse. Designers think that they had to modify a lot of code in order to reuse any GUI component. Possible reason behind this is that the requirements are different for each GUI therefore one standard GUI cannot be reused several time. However, middleware and other artifacts most of the time remain same throughout the domain. Problems because of lack of owner-ship While describing the problems related to reuse, nearly all the designers mentioned lack of support present for the reusable artifacts. Designers do not know whom to contact when they want to inquire about any problem in reusable artifact. There is no central owner present who can answer the queries related to the issues. Literature is full of experiences where owner-shop of artifact caused revolutionary changes reuse process.    Test cases are favorite artifact other than code Ease with test cases are understood and modified, made them the favorite artifact of designers, other than code. Normally, test cases are in human understandable language and require fewer changes in order to reuse them. Therefore, designers interest is justifiable. Multiple factor affecting reuse Since reuse activities inside an organization are ah-hoc based therefore every designer faced different problem than other. Some reported problems concerning the lack of support while some reported about badly written components. No single factor was pointed out which was affecting the reuse activities inside an organization. Therefore, multiple factors are affecting the reuse activities. No central repository is present No central repository was reported by the designers. Each designer named different software applications to store any component for future reuse. Repositories used by the designers were locally accessible for their developers however they were not accessible for rest of organization employees. Modification of Classes Most of the designers reported that they do not have to modify large parts of artifacts in order to reuse. Modification in less than 15 percent of classes was needed in order to integrate the reusable artifact. These values were estimated by the designers in a reply to a question. Chapter 3. Background Work 24 This means not much effort was wasted on tweaking and modifying the components, which is good thing for reuse. Similarly this shows lack of black box reuse which is recommended practice in literature. No experience of sharing own component None of the designers shared any experience about their own component which was reused. When asked about the possible ways they can provide support for their own components everyone considered Email as easiest solution. However, author thinks that multiple different ways should be used to provide support for the reuse artifacts. Some of them are wikis, documentation and product owner. This practice is also reported in literature . Figure 3.1: Sharing own component Ideal reusable artifact When asked about the property which makes an artifact as an ideal reusable artifact, majority of the designers were of the view that easy to use and well defined interfaces should be present in the artifact. This reduces the time for understanding an artifact and makes reuse easy for designers. Figure 3.2: Ideal reusable artifact Chapter 3. Background Work 3.1.6 25 Cost Factor Study about cost saving possibilities showed interesting result. Since this study was made at designers level, initial expectations were that designers know about the cost benefits. However, data received from the survey pointed out that designers have no knowledge about cost factors. They do not consider cost savings as a major reason for reuse. When asked about their reason behind reusing any artifact, they pointed out short development time as main incentive. Although this shorter development time indirectly reduces cost but designers should be aware of the costs related to the reuse itself. This will further support the reuse activities and will help in making the decisions related to reuse. Designers can see two dimensional aspects, one related to shorter development time and one related to cost savings. In decisions where more development time but less costs (because of lesser resources required) are involved then designers can get the benefit out of this two dimensional approach. An example of such scenarios can be an Research project which sometime has limited resources assigned to it but have not clear end time. Second interesting finding was lack of any procedure in order to calculate cost benefits of reusable component. Designers do not know about any procedure through which they can judge the feasibility of any reusable artifact. Figure 3.3: Knowledge about Cost Estimation Presence of a proper procedure, to estimate the cost savings and development time saved by reusing any artifact, is necessary thing for reuse activities. In literature different cost models like COCOMO and its variants are present. Research articles also described different cost models to estimate the costs saved and financial aspects of reuse   . These can be used by the organization in order to get the maximum benefits from reuse and keeping track of costs. No organizations can be fully sure of the benefits it is getting from reuse unless there are metrics and measures present for calculating costs and savings. By having costs in a documented form it will be easy for management to set goals and analyze the productivity of the organization. Chapter 3. Background Work 3.1.7 26 Interpretation and analysis of results Patterns of reuse depicted in the survey feedback indicate that reuse activities are taking place at individual level. Designers tend to think about reuse activities and how can they reuse any artifact in a new release or new product. Awareness and intent is present but lack of guidance and procedure often make it hard for them to reuse any artifact. Such a reuse is known as opportunistic reuse . This is a most basic form of software reuse and does not yield proper benefits for the organization. In such a reuse procedure, chances of producing quality product in a shorter time development time are rare. Usually the organizations aim for a systematic reuse process . Open Source software artifacts were considered as favorites by the designers. This indicates a lack of support or lack of internal artifacts present for reuse. Concept of a software reuse is a two dimensional concept . One dimension deals with actual reuse of the artifact while the other dimension is for producing a reusable artifact for the future reuse. By indicating there interests in open source software artifacts designers have pointed out two major problems present inside the organization. Firstly, there are either no internal producers of reusable artifact or there is no support provided by them. This analysis is confirmed by another interview question when asked about characteristic of an ideal reusable artifact some of the designers were interested in availability of product owner. In some of other questions when asked about sharing experience with us about their own reusable artifact, designers fail to describe any of their experience. This indicates that producers of reuse artifacts are not present. Lack of systematic reuse was also evident when designers complained about multiple factors which affect reuse. They were unable to list a single common factor which makes life tough for the consumer of reusable artifact. Factors varied from the management related activities to technical activities. Therefore; we can conclude that reuse activities can flourish with presence of product owner and by following a proper procedure for producing a reusable artifact . Feedback regarding modification of code indicates that White Box  reuse is the general trend inside the organization. There are no ready to use artifacts which are present in the organization, as recommended by the literature.  . White Box reuse is often troublesome and do not guarantee a shorter development time and low costs. Even after integrating the reusable artifact by the means of white box reuse, the product needs rigorous testing. Chances of introducing a defect in a reusable artifact increase with the white box reuse. However, Black box reuse is easy to introduce in a new product and guarantees a quality product in a shorter development time. Black box reuse is the standard practice present in the literature . Black box reuse can only be possible when there is a systematic way of producing the reusable artifact internal to the organization. Otherwise, search for the third party reusable artifact takes a lot of resources and time. Chapter 3. Background Work 27 An interesting finding was related to reuse of GUI components as the least preferable reusable artifact. All the designers think that GUI are there lest favorites. Reason behind this phenomenon can be the lack of standardize GUI components present. GUI components may vary from application to application and that makes it hard for the designers to reuse them in their own product. Usual expectations from this question were that the GUI components should be the favorite of designers since most of the organization products belong to the same application family. GUIs in these products use the standard look and feel therefore reuse should be very easy. But the results indicate that many other factors are also driving this design decision. When asked about the favorite way of providing support for your own component most of the designers supported Email as there preferable tool. Since, email has become a standard medium for official communication therefore these results were not unexpected. However, making email the primary medium of communication can cause a problem. A product owner can become irritated of answering the same questions again and again. This can take his useful time for answering the already solved problems. Therefore, recommendation from the author is to use variety of different mediums of communication like forums, wikis and emails. Large organizations have found various ways to tackle this issue   and an organization needs to find a way which is best suited for its structure. Cost savings effort at the designers level demand an awareness about the cost related issues in the designers. This was lacking among them. They just think how they can save the development time. In actual case, a decision based on shorter development time may be misleading for the organization. Some projects require more time for the understanding part of the problem as compare to the solution part, in such cases it is difficult to find the actual development time. Therefore decisions bases solely on development time can cause problem for the management. Therefore, costs should be considered by the designers while reusing any artifact. 3.1.8 Recommendations Making the reuse process institutionalized should be the prime aim of every organization. A reuse process can yield maximum benefits in a consistent way if a standard well defined reuse process is present and followed inside the organization . This leads to a systematic reuse process as defined by the literature. This process can vary according to the needs of the organization. Therefore, a well defined process and guidelines for using that process are required. These two changes can be started by the management only. Effect of these two changes may not be evident immediately but once the reuse processes are well established positive results can be achieved. Frameworks in literature are present which can help an organization in obtaining a systematic reuse culture.  Much emphasis of reuse inside the organization is on the consumption of Chapter 3. Background Work 28 reusable artifact. A lesser focus is on the production of a reusable artifact. A reusable process can benefit a lot if well defined reusable artifacts are produced internally according to the future needs of the organization . By producing the customized artifacts ready for the reuse process, a lot of time and effort can be saved. This saving of time and effort improves the savings as well as improved the quality of the product itself. The concept of producing the reusable artifact is an old concept  which is not widely practiced in the industry. However, by following this concept an organization can save maximum amount of cost. Designers which try to reuse any software artifact complained about the lack of support present for the artifact. This is a critical problem and no reuse activity can be successful without solving this problem. No product owner is present which can help the designers in case of any issues. The designers supported the use of open-source components because they can find support for their queries. Hence, reuse can be made integral part of the development process if each reusable component has some product owner. In literature we can find recommendations about the product owner    at several places. Domain analysis is an important practice which takes place in organizations with large application product families. In this practice, components and artifacts are listed which can be shared among the different products. Further analysis is done on how to make the reuse of common artifacts easy and with less cost. This analysis should be done on the major organization products in order to list the common artifacts. In future releases and updates the listed reuse resources can be used to save the costs and time. Reuse activities inside an organization can increase if a central repository is present where only very high quality artifacts are stored. This will save time for searching the new artifact and also improve the quality of the final product. Each component should have a product owner team. This team can comprise of number of resources from different levels of project development. A product owner should lead the team who should be responsible for solving the problems related to the reuse of the artifact after consultation with the team members. This may not be a dedicated team but used on occasional bases depending on the priority of the request Wikis and emails should be used for storing documentation and relevant information about artifacts. Black box reuse should be encouraged. Even for the components where code is involved, interfaces should be designed in such a way that they can support future reuse of that artifact. Designers should be aware of cost benefit analysis of reusable component. Since an organization is aiming for cost reduction because of reusable components therefore at design level this awareness should be present. 3.1.9 Future work Future work, based on this study, should be more focused on two different aspects, cost savings, and effect of systematic reuse on organization. These two are Chapter 3. Background Work 29 described below. Cost avoidance and financial benefits are major reason behind the usage of reusable artifact. However, organizations do not know what exactly is the amount of reuse present inside there development unit and how much costs have been saved. A framework should be developed which can help the organizations to find status of reuse and savings associated with it. These saving can be direct savings like not having to buy any artifact or these can be indirect savings like reducing the number of possible defects. A major study should be launched on this aspect. Systematic reuse can improve process of reuse, making it easy for stakeholders to reuse artifacts. At the same time it is important not to forget the continuous improvement of this process. Therefore, a small study should be launched, after the implementation of systematic reuse process, which measures the effect of new guidelines over other operations inside the organization. 3.1.10 Validity This study was of limited duration and scope. Major objectives were partially achieved because of lack of feedback received from designers. However, feedback received showed some important patterns but they can only be confirmed by a major study in future. The validity of study has a question mark on it since all the feedback received was compared with literature and then interpreted and narrated here. If some problems are not reported in literature then these cannot be identified with help of this study. In future studies, these two things can be fixed by adding more time for the study and by persuading the designers to answer the questions. Interviews can be best suited for such exploratory studies since interviewee can express his feelings in a better way. He can talk about things which researcher has ignored in his interview questions. In short this study has questions marks over it and its results need further validation. 3.1.11 Conclusion In order to know the reuse activities present inside an organization a survey was conducted at designer level. This survey showed that reuse activities are ad-hoc based and these activities are present at individual level. No central procedure or guidelines are present inside the organization to support these activities. Therefore, each designer is free to use his own method and procedure for reusing any artifact. Most of designers want a product owner for any reusable artifact, who can answer their queries related to the component. Open source components were the most popular reusable components because they have enough support present if some questions arise. Designers were unable to answer cost related questions. They do not perform any cost-benefit analysis before reusing any component. Chapter 3. Background Work 30 They opt for reuse only because it can reduce development time. Recommendations are also provided by the author in order to move the reuse culture inside an organization from Opportunistic reuse to Systematic reuse. Suggestions like domain analysis, institutionalization of reuse process and many small changes were listed in order to improve reuse process. Recommendations for future work were to launch one study on cost benefits and one separate study on the effect of systematic reuse over organizations processes. Overall this study proved to be a good exploratory study on the reuse activates taking place inside an organization. It can help the organization in understanding its process and in launching future research on the reuse. 3.2 Literature Survey on Reuse Practices of 5 Large organizations This research study tried to identify various success factors which are considered important by various organizations. A review of literature pointed out industrial experience shared by 5 different organizations. Details of experiences are present in section 2. Section 3 contains analysis and discussion regarding the results. Section 4 contains recommendations fro introducing reuse based development program in an organization. 3.2.1 Industrial Review In this section a review of reuse practices followed by 5 different companies is described. Each organization and its factors are described in respective subsections. Hewelt Packard (HP): Hewelt Packard started its focusing on reuse activities during mid-80s. From mid80s to early 90s lot of investment had been done on making reuse an integral part of development process. Research on many aspects of software reuse was carried out. This research was driven by the problems and issues experienced during the reuse of various products. During the early 90s HP launched a comprehensive program on domain specific reuse. Here in this section, results gathered from two HP related studies, on reuse, are present. Various factors, related to software reuse, are presented as following. These factors are identified from articles   . Motivation Main motivation behind HPs program was to reduce time to market by reusing common features present in various products. Chapter 3. Background Work 31 Technology Transfer Method: HP developed its own method for transferring new technology of software reuse. Details about this method are missing in literature. This method enabled HP developers community to learn new technologies and practices related to software reuse. Non-Technical vs Technical Problems According to articles published on reuse, HP reuse community feels that nontechnical problems are major hindrance in reuse related problems. These problems vary from searching / locating of reusable item to managements non-commitment to reuse program. Technical problems were considered to be less important and solvable by the reuse community. Management Support: According to articles, researchers feel that managements support for reuse program is a major problem related to software reuse. If management is not willing to support reuse initiatives then reuse related success is not possible in the organization. Designers or developers at low level could reuse artifacts on their own but organizations get major benefits only when software reuse becomes a priority in the organization. Integration of Process, People and Technology: Integration and alignment of processes, people and technology is important to achieve positives results related to software reuse. All these should be integrated in such a way that they have a common goal, objectives and aims. Working methodology to support reuse activities should be introduced and stakeholders should feel comfortable with it. Similarly technology which can support reuse of artifacts should be introduced; people should be trained for that. Design for reuse: HP research community believes that reuse cannot be successful unless component / artifact are built keeping in mind its future reuse aspects. For example , modern technologies (at that time) such as OOP and high level programming languages makes it easy for architects to design applications which are more coherent and less coupled with other applications. Such applications can be easily reused. Tailored Reuse Methods: Research articles describe the importance of tailored methodology for reusing artifacts. Each organization should develop is own methods, processes and guidelines for introducing reuse culture inside organization. These methods should be based on organizations ways of working and competence level present inside the organization. Tailored method will help in reducing possible non-technical prob- Chapter 3. Background Work 32 lems related to reuse. Similarly organizations would not need any extra efforts for introducing reuse culture in the organization. Incremental Strategy: HP followed incremental approach for introducing reuse culture in organization. Changes were introduced gradually and no large scale changes were introduced immediately. Slowly but gradually organizational structure was molded to form a structure supportive of software reuse. Such strategy was acceptable for all stakeholders since they did not have to learn new things immediately. Usually, large scale changes were distributed over 5 to 7 years. Producer-Consumer Model: HPs reuse community developed its own producer-consumer model for reusing artifacts. This model was developed over several years and guidelines were developed in order to introduce reuse culture inside the organization. Customized Metrics and Cost Model: Another important factor in HPs successful reuse program was its measurements related to software reuse. Based on organizational structure HP developed its own customized metrics and cost models. These metrics and cost models kept track of progress made by the organization and savings because of reuse. This gives a good idea of success / unsuccessful reuse program. Decision making was done based on the results received from these models. International Business Machines (IBM) IBM is one of the famous organizations in the world which develops variety of software applications. Software reuse had been focus of IBM since early 90s. However, very limited amount of work is published by the organizations. Since, IBM has several similar style applications, reuse initiatives were taken in order to benefit form common reusable features. These applications vary from large scale development tools (Clear case etc) to small plug-ins (for eclipse etc). These factors are identified from articles   . Success factors reported are described below: Motivation: Motivation behind IBMs reuse program was to improve quality of the product by developing high quality reusable artifacts and then reusing these artifacts in several products. Maintenance cost could be cut down in that way. Planned Reuse: IBM realized the importance of planned reuse culture inside the organization. Researchers inside the organizations believed that reuse can only be successful when planned at organizational level. Therefore, strategy was developed in order Chapter 3. Background Work 33 to make reuse integral part. This strategy was based on the need of organization and several experts were responsible for developing this strategy. Design and Analysis Phases: Bottom-up approach was used for developing applications with software reuse. Design and analysis phase was used for identification of reusable artifacts and other trade-offs related to software reuse. Availability of items for reuse was also considered while designing application with reusable artifacts in it. Knowledge Management: An important feature of IBMs reuse program was its objective to retain knowledge about reusable artifacts inside the organizations. In very large organizations, people move out or move in. Important and competent members of the team sometimes leave organizations and with them they take important knowledge out of the organization. IBM developed its knowledge management program in order to control this out-flow of knowledge. Strategies were developed in order to spread and share knowledge among organization members as well organizational departments. This helped in sustaining the knowledge related to reuse inside the organization. Processes were well documented and people were asked to share there new learn stuff with each other. Incentives: Incentives were offered to the designers and developers who reuse an artifact or there artifact was reused by someone else. This helped in creating competitive environment related to reuse. Types of incentives were not mentioned in the literature. Idea was to push more and more people in reusing artifacts and developing applications which can be reused. Reuse Champions: A term often used in literature has its origin at IBM. Reuse champions were introduced; these were the guys who had detail knowledge about the products and how to reuse these products. They were the resource person for different departments in case of any help related to reuse of an artifact. Evaluation of Reuse Process: Evaluation of reuse processes was performed after a specified time. This evaluation was done keeping in mind the organizational goals and targets. This evaluation helped in improving and generating guidelines for reuse inside organization. Similarly, decisions were made for future reuse related policies. Product Lines: Concept of product lines was introduced in order to maximize the benefits. Usually products developed by IBM have common features among them. Therefore, Chapter 3. Background Work 34 product lines were developed in order to reuse these common features. Continuous efforts were made in order to find the commonality between different products. These common features were made generic enough so that they can be reused in several products. Motorola Motorola is an organization which produces applications for telecommunication sector. Few articles have reported cases about Motorolas success in introducing reuse culture inside the organization. Features related to success or failures of reuse program at Motorola are listed in this section. These factors are identified from articles    . Motivation: Business needs forced Motorola to look for methods which can develop software easily, quickly and of high quality. Therefore, reuse was considered as a major contributor in business needs. Phased Implementation: A critical factor in success of reusable artifacts is the phased implementation of reuse strategies. Policies related to reuse were not implemented immediately, they took years to be implemented. Changes were introduced slowly to the organization. This helped to avoid creating a panic situation inside the organization. People accepted the changes since they do not have to change their ways of working completely differently. These phases were spread over number of years. Bottom Up approach Bottom up approach meant that organization started introducing reuse culture right at developers level. Changes and guidelines were meant for developers. Training sessions were held for educating developers and designers about software reuse practices. Workshops were conducted in order to share common knowledge about software reuse. Reuse Repository: A reuse repository was developed where all the reusable artifacts were stored. Developers and other stakeholders can search this repository and look for artifact for their own need. Guidelines for developing these artifacts were also shared to all the organization staff. Managements Involvement: Articles on Motorolas reuse program reported the involvement of higher management in reuse program. It was considered inevitable and important for any reuse program that higher management takes interest in it. Same was found in Motorolas case where management was keen to develop a successful reuse struc- Chapter 3. Background Work 35 ture inside the organization. Management identified that reuse has a potential to improve organizations finances. Pilot Projects for reuse: Another idea, practiced by Motorola, was to use small scale projects as a proof of concept before introducing any changes in the organization because of reuse policies. This helped in understanding effect of possible changes and helped in developing measures in order to counter the negative effect. These small projects gave a good idea of future problems related to reuse practices introduced in the organization. Reuse of Processes: Motorolas research community believed that process could also be reused inside the organization. However, attempts to reuse processes failed because of several reasons listed in articles  . Product Innovation: Motorola used reuse as a tool for future innovations. Features of products were introduced in other products in a reusable form which leads to new innovations in these products. These innovations helped in building business value for the old products and in return earning large amount of financial benefits for the organization. Reuse of Knowledge: Another concept found in literature was reuse of knowledge inside the organization. Knowledge could be in the form of competent architect, developer, and designer or in the form of documents. Efforts were made in order to share the knowledge among the organization. Training: Designers, architects and other staff members were trained on topics related to software reuse. These training sessions helped in creating awareness among team members about possible problems and standardized solutions of problems. Reuse Based Architecture: New products were developed based on reusable architecture. Guidelines related to architecture and technology for development were provided by the organization National Aeronautics and Space Administration (NASA) NASA has a software development program as an essential to its space mission. Although literature lacks detail about the reuse program present inside NASA, but still few articles describe the general practices present inside the organiza- Chapter 3. Background Work 36 tion. Features of reuse program which were found important in these articles are described here. These factors are identified from articles   . Motivation: Emphasis of NASAs reusable effort was to find bug-free reusable artifacts which can be reused several times in different products. Fault and Change Metrics: NASA developed its own fault and change metrics in order to measure the faults found in reused artifacts and impact of these faults. This was necessary for developing error free multi-million dollar products. Metrics measure the impact of change after a fault was fixed and other quality measures. All the measures were specifically developed for reusable artifacts. Reuse Working Group: A group of experienced members was formed in order to drive reuse goals, set guidelines, monitor the progress, set targets for different units and recommend changes in case of problems. This working group was also responsible for introducing reuse culture inside the organization. Software Repository: A reuse storage place was developed in order to store reusable artifacts. Retrieving and storing of artifacts in repository has specific guidelines. Based on usage or non-usage of data this repository was updated every year. Old and non-used items were removed while new ones were added. Reuse community: A community was formed where people can voluntarily share there experiences and ideas on reuse. This prompted some important changes in reuse policy of organization. Domain Analysis: NASA research community shared an experience where domain analysis was performed in order identify potential reusable artifacts for future. Orbotech Orbotech  is another organization sharing its experience on reusable artifacts. It is an organization which develops CBs, FPDs and imaging solutions for PCB production. Although there was only one article present on its experience but still it is worth mentioning in this report. There experience is important for medium and small size organizations. Important factors from there experience is mentioned here. These factors are identified from articles  Chapter 3. Background Work 37 New Technology enabling Reuse: Orbotech molded its process and technology in order to use new technologies which can enable reuse inside organization. New languages and tools were introduced which helped in making reuse easy inside the organization. Black-Box Reuse: Producers and consumers of reusable artifacts were asked to use black-box reuse as a guideline. White-box reuse was discouraged. However, code for each blackbox reused artifact was provided in order to develop confidence of user and in order to understand the actual working of reused artifact. Focus on Teams: Instead of focusing on individuals, for training and other reuse related stuff, Orbotech decided to focus on teams. Each team was responsible for reusing and producing artifact. No single individual was appointed for that matter. This formed a sense of shared responsibility among team members. 3.2.2 Analysis and Discussion This study pointed out some important results on software reuse in large organizations. These results show trends and important points to consider while introducing reuse process. We can divide these results into three parts: Managerial settings, Industrial setting and reuse related education. This division was made because most of the factors described by organizations fall into these categorize. Managerial Settings: Most of the organizations have business driven needs which forced them to implement reuse driven processes inside them. Financial benefits were a major driving force in most of the cases. In NASA’s case, where high value and mission critical software is required; focus was on quality aspect of reuse artifacts. Only after realizing need of reuse, organizations have developed processes required for it. Therefore, management has to be convinced off the benefits of reuse in order to implement reuse related processes. If management is not willing to invest in software reuse, development process cannot have long term benefits. Reuse required customized settings inside the organization and if organization is not willing to setup resources in order to identify these factors then reuse related benefits cannot be obtained. In a study related to IBM’s reuse processes, non-technical aspects of reuse were considered to be most important. Management’s role becomes more crucial when a strategy is required for sustaining knowledge about reusable artifacts, which is present inside the organiza- Chapter 3. Background Work 38 tion. Management needs to make sure that knowledge sharing and distribution is present and it should be independent of people present inside the organization. Industrial Settings: Another result which can be derived from above is the need of proper industrial processes in order to support reuse. Organizations have to implement a mechanism where searching, locating, and obtaining of reusable artifact becomes easy and staff should know where to look for in order to perform these steps. Decision making related to reuse should be done at the start of development. Analysis and design phase can be the most common phase for identification and deciding about any reusable artifact. Documentation was the most common way to describe any reusable artifact. Domain analysis was performed in order to identify artifacts for future reuse. Industrial settings are technical aspects of reuse program. These settings are important for making reuse possibly, technically and in short span of time. These settings can vary from organization to organization, depending on working methodologies and organizational structure. Reuse Related Education: Educating the staff members on the importance of software reuse is equally important. In one of the studies, conducted by author, it was pointed out that designers often do not know about reuse processes present in the organization. Awareness level can be increased by introducing workshops, specific training sessions and other relevant ways in order to emphasis importance of software reuse. Common Features: Different organizations have various ways to implement reuse processes inside them. However, there are some common features which were identified as common among all the organizations. These features should be considered as guidelines or important steps part of reuse processes. Generically, these processes should be present in all organizations which want to adopt reuse driven development program, Feature Phased Implementation Reuse repositories Management Support Tailored Reuse Methods Training Black-box reuse Planned Reuse Organization All All All All All All All Table 3.1: Common Factors Chapter 3. Background Work 39 Organization Specific Features: Importance of tailoring a reuse processes was emphasized and discussed in previous section. Tailoring helps in molding and optimization of processes according to organization needs. Features which were identified as ’organization specific’ are listed below: Feature Product Innovation Pilot Projects on Reuse Fault and change Metrics Focus on Teams Reuse of Processes Reuse community Organization Motorola Motorola NASA Orbotech Motorola NASA Table 3.2: Organization Specific Factors 3.2.3 Recommendations Increasing demands of software systems are making it hard for the organizations to meet satisfactory level of production  . It is hard for the organizations to introduce any rapid changes in order to develop reuse as an integral part of organization. A three phased strategy should be developed for introducing reuse inside organization. First phase should be limited to steps which do not require any organizational changes. These steps can be adopted by staff members without any training and changes. Usually such steps should require less than a year to be implemented. Technical aspects of reuse can be addressed in this phase. Second phase should consist of steps which can be introduced in 1 to 3 years time. However, it is difficult to introduce these basic features at once since it might affect productivity of the organization. Prioritizing these practices should be left on the organizations choice and they can do that based on their immediate need and resources. These practices / guidelines range from technical aspect to managerial aspects. Third phase involves steps which cannot be introduced in short span of time. These are the fundamental changes which should be introduced in small steps and over a lengthy duration. These factors can affect organizations ability to deliver in time if they are introduced rapidly. However, introduction is necessary since it can lead to a systematic software reuse inside the organization. Each organization should consider its own state of affairs before deciding to introduce these factors. 3.2.4 Validity Focus of report was on industrial experience shared by large organizations. Validity of report is dubious since organizations only share there positive experience Chapter 3. Background Work 40 with outside world. Bad experiences are seldom shared. Another important point to consider was the lack of details present in the articles. Articles were not describing their positive features in detail. There focus was more on describing the results and less on how they achieved this result. Factors identified by the author are from limited number of articles. Some factors are identified by author by his own perception of things. No negative experience or factor was reported by any organizations. There might be several factors which have negative effect on reuse practices. This report therefore misses an important aspect of reuse experience 3.2.5 Conclusion This research study describes important factors related to reuse practices. These factors were identified from literature review of five organizations. These factors are mostly related to managerial issues and less focused on technical issues. Analysis phase helps in understanding the nature and types of these factors. These factors were of three main types. Common factors found in all organizations were listed. These are applicable for organizations which want to introduce reuse inside their development processes. Recommendations were made for future reuse program to be introduced. These recommendations are based on an iterative process. Validity threats are discussed in respective section. 3.3 Reuse of a black-box component An Industrial Experience This section has described experience of reusing a software component called Rule Engine in an new product. This new product was developed for an organizations innovation competition and it was based on an innovative idea of merging rule engine of one product with another internal product. This rule engine accepts input and executes rules based on values provided in the input parameters. Furthermore, after getting result from execution of rules some commands are issued to another product called CS. The reused artifact was of foremost importance because whole new product was built upon the results obtained from it. Development team was successful in reusing the rule engine and it worked exactly according to the requirements. New product became success and now the next step was to identify the reasons behind this positive experience. In this report numbers of factors, influential in successful reuse, are described. Section 2 describes all the success factors which were identified. Section 3 describes suggestions for improving the reuse process. Future work is recommended in section 4. A conclusion of whole proceedings is present at the end. Chapter 3. Background Work 3.3.1 41 Factors and Discussion Researchers have recommended number of practices related to a successful reuse project. Starting point for all these practices is the support of management. If management is not willing to support reuse of software artifact then this reuse process can be ad-hoc and is dependent on individual brilliance of designers and developers . Similarly, Black box reuse is most recommended way of reusing any artifact . A table showing summary of recommended practices from literature and their comparison with practices found in this project is shown below. Factor Presence of artifact owner Black Box reuse Maturity of Artifact Management Support Technological Support Dependency on other modules Similarity of Domains Willingness of Owner Systematic Reuse Reduced Search time Presence of reuse support team Literature Confirmation Project Confirmation Yes Yes Yes No Yes Yes Yes No Yes Yes Yes Yes No Yes Yes Yes Yes No Yes Yes Yes No Table 3.3: Comparison between Literature and Practice These factors are closely related to each other. Here are some of the factors which made it possible for the team to reuse Rule Engine (RE) for this prototype project. Each section contains the literature recommendation, experience from the project followed by the discussion. Presence and willingness of owner According to literature, any reuse component should be owned before it is being reused by anyone . An owner should be assigned to the component and this owner should respond to all the queries related to the component. Owner knows the component inside out and suggests measures in case of any problems. All queries should be directed towards the product owner. A product owner can be a one person or a whole team depending on the complexity of component. In our case, an owner was available and willing to help. He was available through email all the time and he was quick in replying to the queries. In the initial phase of understanding the component owner was really helpful. He also helped in validating the integration of reuse component with teams prototype. During the intermediate stages he suggested some key points for integrating the Chapter 3. Background Work 42 component and these valid points. This factor helped in increasing the confidence level of the team at the initial stages of the development which resulted in developing the product a week earlier than it was expected to be complete. Black box and white box reuse Literature points out that the software reuse should be in the form of black box . White box reuse is discouraged. Black box reuse not only saves time for the modification but also guarantees a quality product since the reusable component is properly tested before being published. But in our case the component was between black box and white box reuse. Team was free to customize the component according to the need. Code was provided by the owner and team started working on the prototype by understanding the code and mapping it to the requirements. However, after going through the requirements team felt that they do not need to change any part of the component and the component will be used without any modification. The availability of code made it easy for the team to understand and identify the important parts of code. Another important point worth mentioning is that the code which was provided to the team was not deployable in application server. It was not previously tested with application server (Glassfish application server ) but our requirements demanded a code deployable in glassfish server. By having the component in the form of code, team was able to deploy it and use it according to its own need. If the component was present in the binary form then it would have been very hard for the team to deploy it in glassfish server along with code of newly developed prototype. Reduced Searching time In literature it is mentioned that searching for a reusable component is often very expensive and takes a lot of effort on the part of team . Therefore, by focusing on only one possible solution team was able to save useful time and resources. Search time was almost none and team members do not have to search and compare any artifact according to the requirements of the project. Another interesting factor behind the successful reuse is the lack of available alternatives of ERE. Although, open source rule engine might be an alternative for our requirements but author was unable to locate any rule engine which fulfills the requirements of this prototype. Therefore, developers always have in the back of their minds that they have to use the provided rule engine. Team spent their energies on reusing the provided ERE instead of wasting time on searching any other alternative solution. Chapter 3. Background Work 43 Working example A demonstration of integrating ERE with another example code was provided to the team at the start of the prototype development. Although this example was not relevant to prototype but still it removed the fear from teams mind about the component. Secondly, team found the parts of code which needs to be used for integrating the ERE with our prototype. Example was well supported by discussion at the end of the demonstration. Discussion was helpful in understanding the context of the example, relevant parts of ERE and things which should not be changed at all. In literature there was no description present on the effect of working example on reusable component. This area can be investigated in the future research. Management support No reuse can be successful without support of management. Nearly all recent studies show the importance of management being aware of possible benefits of reuse. If the management is willing to offer resources and time to the development team chances of a successful reuse increases.   . In this prototype, management supported the team by assigning a resource i.e. product owner for helping the team in integrating of ERE. This made a significant difference in this success story as owner of the product has to answer our queries related to product. In another example management assigned the technical experts to help the team when it was stuck in a major problem related to the serialization of custom data types. Technical experts assigned were able to solve the problem and therefore saved a lot of time and effort on part of the team. Similarly, management was keen in knowing the progress of team. Progress was observed on weekly basis, agile approach was followed strictly and management was quick in observing the problems faced by the team. Team got the impression of full support from the management. Well supported by technology Object oriented technology was initially hinted as an approach to increase the software reuse. Researches have pointed out this factor in many of the published articles  . Java is one of the major languages supporting the object oriented programming approach. Our team used Java for the developing the prototype. The reusable component was also developed in java. The similarity in programming approach made it easy for the developers to integrate ERE with the prototype. Team does not have to bother about the tweaking and modification of original code, the only thing team needed was the understanding of code. After understanding the code, calls to classes were easy to make and objects can be passed from one method to another very easily. Chapter 3. Background Work 44 Another important technology factor was the support provided by java to deploy the reused code in application server i.e. glassfish. Any other language might have caused a lot of trouble in deploying the code. The deployment of code was not done in original ERE but it was required by our own prototype. Therefore, java made it very easy for the team to do all this obnoxious stuff. Independent module Rule Engine (ERE) works as an independent module. It doesnt require services of any other sub-system to perform its main functions. This helps the team in deploying it on a local machine and thus using it without taking care of other sub-systems. Presence of module on a local machine meant that team can experiment on it without worrying about the possible effect over other systems. After deploying the ERE on local machine it worked like a black box where developers do not have to change anything and they were able to fetch the results without any problem. Easy to implement logic for getting the result from ERE, was because of lesser dependency of ERE over other sub-systems. Face to Face Meetings Often face-to-face meetings are more helpful in identifying the problem as compare to the remote location . In these meetings people can have discussions in a better way as compare to the talking on phone or through Email. In literature related to global software engineering it is recommended to have face to face meetings more often . This helps in improving the quality of the product and it also helps in overcoming the misconceptions among the team members. ERE was developed in the same location where it was reused. Although it was in different department but sharing the same location helped in finding the owner and helpful resource required for the prototype. Developers and designers can go to the product owner, meet him face to face and discuss everything they wanted to discuss. This helped the team to understand the artifact in a better way. Therefore reuse process was boosted by the presence and availability of face to face meetings with the product owner. Things might have been different if the owner was at some remote location and was available through modern ways of communication. This could have created problems for the team members. Similar domains The developed prototype and reused component (Rule Engine) were both from the same domain. They both were part of large telecom solution, this helps in reusing ERE. Design of the prototype was made in such a way to accommodate ERE. Architects of prototype knew what is expected of ERE and what value it can provide to the prototype. All this understanding was because of similar in nature products. If ERE was from some other domain, such as embedded Chapter 3. Background Work 45 systems, then the reuse would have been difficult. Architects wouldnt have the knowledge of both domains and therefore possibility of reuse would have been reduced. However in literature we only find attributes supporting the reuse process in one product line . Reusing artifacts from various different products opens up new research questions for the researchers. 3.3.2 Recommendations Starting point for any reuse artifact is the documentation which is present for it. In this project, the documentation of the reusable artifact was an old version. The document was not relevant to the reuse process. It was providing the detail of functions that reusable artifact can perform. Having a completely relevant and updated version of documentation is a good starting point of any reusable artifact. This will help in reducing the time for understanding part. Similarly, it can address the very basic questions related to the reuse and it can reduce the number of queries directed towards the product owner or product team. Having a complete team, called as product owner team, is more beneficial and can help the consumer of artifacts in a better way. This team should consist of developer, tester, designer, system analysts and other relevant members. Variety of different members can help in understanding of queries and can answer them in a better way. This team can have a dedicated team lead that is responsible for receiving the queries and directing them to the corresponding team member. The team lead can be dedicated to the artifact on full time bases, but the other team members should only be used when required. White box reuse should be discouraged and black box reuse should be encouraged. This can reduce the time since understanding of reuse artifact takes more time than any other part of reuse process . For internal reuse of any artifact this can be anticipated in advance and while designing the new release its reuse scenarios should be considered. This can be done with the help of domain experts and experienced designers. Even in the literature we can find methods which support the forward looking reuse process . Neither the consumer of the reuse artifact nor the producer of the artifact found any guidelines for producing and utilizing the artifact for reuse process. Guidelines should be provided which can describe the actual process of reuse. How the producer should take care of the artifact, what needs to be done in order to store that artifact, how a consumer can search for the component and what is the process of obtaining the artifact from producer? These questions need to be addressed by the management and guidelines should be issued for general use. 3.3.3 Future work This report can become a starting point for achieving the systematic reuse insider the products. Next step should be to fix the problems identified during this small Chapter 3. Background Work 46 project and then analyze the factors which are influential for the success of the project. In this way a continuous improvement of the processes can also be achieved. . This project involved the reuse of in-house developed product. In a case where an outside developed reusable artifact is used the factors can vary from the above mentioned factors. In future a detail study can be launched which describes the factors identified from the reuse of third party products (3PP). A comparison report can be an interesting finding for organization and for research community. Another possible investigation for the future can be the effect of more than one reusable component on any project. A project can be analyzed by reusing more than one component in it. Effect and experience gained from the reuse of each artifact under the same team and same project setting can be very interesting. We can find the variable factor which is common in each of the reusable artifact and the factor which remains the same for each of the artifact Working examples of the reusable component not only remove the fears from the mind of developers but also helped in identifying the external interfaces of the reusable component. Further research can be carried out which can identify the time period or number of usages after which an artifact becomes mature for the reuse process. 3.3.4 Conclusion Software reuse promises to provide low cost, high quality and reduced time to market. This report described number of factors which were responsible for a successful reuse in a prototype product. These factors range from technology to management of human resources. Author has described all these factors and is of the view that there is no one single factor which can guarantee success in reuse. Successful reuse will be dependent on many varying factors. However, from the above experience we can list the most important factors which can increase the possibility of success in case of reused software artifact. At the end recommendations are provided which should be introduced inside the organizations in order to make the reuse process more beneficial. These recommendations are related to reuse process as well as reusable product. Lessons learn from this study indicate the need for a more comprehensive study. Here is the summary of the lessons learnt. Factors which have a positive influence over the project are: 1. Presence of reusable artifact owner 2. Maturity of Artifact 3. Management Support Chapter 3. Background Work 47 4. Technological Support 5. Dependency on other modules 6. Similarity of Domains 7. Willingness of Owner 8. Reduced Searching time Areas where improvement is needed are: 1. White Box reuse should be discouraged 2. Systematic Reuse process should be adopted 3. Guidelines for the reuse process Following areas can be the focus of future research: 1. Effect of more than one reusable component on any project 2. Factors identified from the reuse of third party products (3PP) and their comparison with currently identified factors. 3. Number of usages or time period after which an artifact becomes mature for reuse. A section related to future work is also present which describes different scenarios for a similar study. A comparison report of the different scenarios with comparison to this study can also be produced in future. Chapter 4 Research Methodology This Chapter describes the research design and how research was conducted during the thesis. 4.1 Research Design Developing a model, for industrial usage, and evaluating this model involves various research techniques. These research techniques should focus on literature as well as on industrial aspects. Therefore combinations of different techniques were used to answer the research questions. These techniques involve literature review and observations based on action research (since researcher has been actively participating in development projects of organization) and experience of other organizations narrated in literature, section 3.2. The research design is influenced by the technology transfer method proposed by Tony et.all  and is divided into four phase, as shown in figure. Reason behind this selecting was because of its relevance with industry and simplicity. This design considered real world industry settings and allowed the researcher to be flexible and more realistic when selecting the candidate solution for industry. Other possible alternatives were to carry out this research in more traditional way i.e. industrial case study and then suggesting the findings. However, in such studies the candidate solution is based on theoretical hypothesis and do not consider real world industry settings  . Secondly, author has been actively involved in projects inside the organization and believes that various different methods like action research, observations, and literature review will complement each other in providing a reasonable solution. First phase of the research involved problem understanding and analysis of the problems. This phase took into consideration a number of different factors and used different research techniques to understand the problem context. Second phase consists of development of candidate solution and propose a model for cost avoidance. This solution was based on the preliminary studies and organization settings. Feedback from the practitioners will help in static testing of the framework and will help in tailoring the framework for the current organization. Third phase involved dynamic testing of the framework on various small projects, 48 Chapter 4. Research Methodology 49 which had used various reusable artifacts. Results and analysis achieved from the dynamic testing of project were used to improve the model. Model was released in the fourth phase. This release was complemented by a workshop and a session with actual users of the model Figure 4.1: Research Design 4.2 Conducting the Study In this section four phases, described in research design, and their sub-phases are described. These phases and sub-phases were influenced by the study described in . Details are as following. Chapter 4. Research Methodology 4.2.1 50 Phase 1: Preliminary investigation Objective of phase 1 was to analyze the current organization settings and identify key aspects related to the problem. After identifying the problem next step was to formulate a research agenda. All these closely involved the practitioners of industry and regular feedback from the actual users of developed model. Two major steps in this phase are described below: Step 1: Identify potential improvement areas based on industry needs For problem identification two steps were performed. In the first step a survey was conducted in the organization on software reuse (section 3,1), in second step several discussion sessions were held with stakeholders inside the organization and third step was to analyze similar experience shared by large organizations in the literature. These sessions were aimed at finding the potential flaws and problem. Second step involves presence of researcher at the site and being part of the development team for different projects. This helped in identifying the affected parts of the organization and in figuring out actual problems related to cost aspects of software reuse. The reuse survey, present in Section 3.1, was conducted at the designers level. Aim of the survey was to find the awareness levels related to software reuse practices and cost related awareness present at designers level. Results from this survey showed that the some extents of software reuse practices are present in the organization. These practices are carried out at individual level. A gap concerning the guidelines for software reuse practices was found. Other aim of this survey was to find out benefits, in terms of cost, because of software reuse practices. Surprisingly it was pointed out that at the designer level no consideration was given to cost. Mostly designers focused on lesser development time or availability of the artifact as the main reuse design decision. Another gap was found which showed the absence of cost measurement method for any reusable artifact. There was no method which can be used by the managers or designers for calculating the potential costs which they can save or for calculating costs which they saved through any artifact. Above two survey results were then discussed with upper management and they were not surprised of these results. They were concerned of these two factors and their priority was to have a model which can enable them to measure reuse related costs and also provide guidelines in order to transform opportunistic reuse level to systematic reuse level. These two problems which were identified: No method present for measuring costs related to reuse, especially costs avoided through software reuse. What steps are required in order to transform an organization from opportunistic reuse to systematic reuse? Chapter 4. Research Methodology 51 Step 2: Formulate a research agenda After discussion with management, research agenda was formulated. An industrial contact was assigned for future discussions. This industrial contact was a useful in pointing out exact needs and requirements. Organizational issues such as getting the required resources were responsibility of this contact. After discussion, with this contact person and practitioners, research objectives were prioritized. Prioritized research agenda was based on organizational needs as well as on the needs of practitioners. After few meetings an informal domain specific vocabulary list was formed between the researchers and practitioners. This list was helpful in communicating the message and information between both groups. Chances of ambiguity were less reduced because of this vocabulary list. In this case, the primary need identified was to provide a model which can measure the cost avoided through every kind of software reuse artifact. Artifacts can be of four different forms ranging from code to documents, as identified by survey present in section 3.1. Organization does not have any systematic reuse present inside therefore they were mainly concerned with cost avoided through reuse. Less focus was performed on organizational level cost-benefit analysis of reuse. Secondary need was to provide guidelines which can help in establishing systematic reuse practices. However, it was required that major organizational changes should not be suggested. All the practices should be recommended keeping in mind the organization structure. 4.2.2 Phase 2: Model Creation In this phase actual model was created. This model was then tested in the lab settings as well as presented to the stakeholders. Necessary changes were accommodated in the model, based on the feedback. A simple tool was also developed which implements the model Step 3: Formulate a candidate solution Several of meetings with industry contact and observations made by researcher during on site stay led to formation of candidate solution. Some of the characteristic of this solution were as following: Solution was based on person-hours spent on each task. Reason behind this choice was simple as person-hour was the only metrics collected by the organization. Management thought it would be hard for them to find out other historical data related to each task. Solution should be generic enough to accommodate seven different sites. Each site has its own hourly rate and budget. Expert opinion should be included if no historical data is present of any task. Model developed for measuring cost avoided should not be limited to code reuse. It should measure Chapter 4. Research Methodology 52 four different types of reuse artifacts, identified by initial survey present in section 3.1. Model should be designed keeping in mind the users of the model. In this case users were managers, therefore less technical information should be required to use this model. Keeping in mind the requirements imposed by the management, a systematic literature review was conducted. Aim of this review was to find out already present models of measuring cost avoided. Chapter 2 contains details of this systematic literature review. Management asked that guidelines for enhancing software reuse should not involve any major changes. These guidelines should be developed keeping in view the current organization settings and ways of working. Researcher used his working experience inside the organization to formulate the guidelines for organization. These guidelines and their detail are present in section 3.3. Step 4: Conduct lab validation After creating the model, researcher conducted its lab validation. All the possible values and aspects were considered. Some example scenarios were tried out. It was decided that a tool should be developed in order to use this model. Tool should be simple enough to use and should not involve any complications. A tool was developed which used this model in order to analyze cost avoided because of software reuse. This tool was tested with possible values. Worst case scenarios and beset case scenarios were considered and analyzed. While developing this tool, special consideration was given to the data collection method. Data collection was made easy for globally distributed organizations by collecting data through email. Step 5: Perform static validation A presentation and demonstration of model and tool was made for the actual users. Results from lab validation were presented. Actual working of tool based model was described to the users. Users objected on the formula used for calculation cost avoidance. They thought that formula used should only be based on number of hours spent on task. Formula should not be based on figures present in literature. Values in formula should only use the data from own organization. Another feedback was to extend the tool in order to evaluate the results from several different perspectives. Various types of charts, graphs and tables were added in order to analyze the results achieved by software reuse. Based on this feedback, formula present in the model was fixed. Researcher noted that original formula and previous formula were almost the same but presented in two different ways. However, feedback was entertained accordingly and tool was updated with necessary changes. Chapter 4. Research Methodology 53 Since, industry was less interested in actual implementation of reuse guidelines, therefore no seminar or workshops were held on that topic. However some recommendations were made which are present in section 3.1. 4.2.3 Phase 3: Testing in industrial settings In this phase dynamic validation of the model was performed in industrial settings. Details of this validation are provided in a section below. This step was helpful in the analysis of the model in real world settings. Limitations and future extensions related to the model were identified and analyzed. Model performed according to the requirements defined initially by the stakeholders and researchers. However there were some recommendations for future extensions but these recommendations were out of scope for this study. Step 6: Perform dynamic validation Dynamic validation was performed in three steps. In first step historical data from an old product was used to evaluate the model. In the second step model was tested on a single site with various types of reuse artifacts. Third step involved validation of model at six different sites. This sequence is shown in figure 2. In the first step, organization stakeholder was asked to provide the data from one project. Data was collected according to the need of model. It was noted that metrics required was easily available and no questions or problems were asked when metric was collected. Metric was total person-hours spent on the product when no old products were reused and other metric was total person-hour spent on product when artifacts were reused from old product. Results from this step indicate that model and tool were mature enough to try in real world settings. In next step a single site was selected for dynamic validation. This step was performed without any assistance from the researcher. Aim was to see the performance of model and note down the problems faced during the usage of tool. Reuse driver, assigned by the organization, carried out this step. An email was sent to all the stakeholders to identify the artifacts which were reused during last 3 to 4 months. List all these reused artifacts and fill out the data fields for each of these artifacts. These data fields are present in Appendix D. There were seven different artifacts which were identified during one week. These were of 3 different types, environment reuse, framework reuse and reuse of code. No case was reported of documentation reuse. Collection of metrics was easy and results were shared with the management. Later, reuse driver of the organization performed a detailed analysis of the results. This analysis was also performed with the help of developed tool. In third step, six different sites were contacted to provide data about assets which they have reused recently. These sites were provided worksheets for collecting metrics and guidelines on what to collect and what to consider as reuse. Chapter 4. Research Methodology 54 Figure 4.2: Sequence of Steps in Dynamic Validation For the first month two sites replied with data. Fourteen reused artifacts were provided by these two sites. This data was applied on the model and results were analyzed by the practitioners. In the next month 4 different sites reported there reuse cases. There were 24 reuse artifacts reported by these organizations. Overall management was happy with the working of the model. New aspects of software reuse were discovered while using this model. Organization wanted to measure the costs avoided by the artifacts in terms of number of defects avoided and savings because of the quality of reused artifact. Since this was out of scope of current research and development project therefore it was left to organization for future decisions in this regard. Since management was closely in touch with the researcher, during lab validation and static validation, there were no surprises during dynamic validation. Chapter 4. Research Methodology 4.2.4 55 Phase 4: Release of complete solution After the successful dynamic evaluation of model, it was decided by the industry contact to release this model for the industry. Instead of researchers selling this model to the practitioner, industry contact took control of things. He became relatively expert in using and understanding this model. His experience and discussions with the researchers made life easy for the researchers because he took responsibility of introducing this model to different sites around the globe. Releasing of solution became responsibility of the industry contact. Chapter 5 Model for calculating Cost Avoidance After evaluating the pros and cons of nearly all reuse economic models, we reached to the conclusion that a model is required which can help in measuring costs through all kinds of software reuse artifacts. It should not be limited to code reuse. It should provide enough guidelines on how to measure the reuse and how to collect data. Model should only consider cost avoidance and do not take into account cost-benefit analysis or return on investment, which assume that some investment has been done before the gains are measured. Model should not be based on processes such as systematic reuse or ad-hoc reuse processes. Limitations related to collecting metrics can severely impact the applicability of a model. If a model is too complicated or it is dependent on metrics which are hard to collect then it becomes very difficult for organizations to use the model. These limitations were considered while developing this model. This section proposes a model which is applicable over all types of software reuse and it can also provide guidelines on what to measure and what to include as software reuse. 5.1 Software reuse metric plan The first step for this model was to come up with metrics which can be easily collected. Studies have indicated the importance of reuse metrics in order to drive the reuse goals . Therefore it was utmost important for any model to be dependent on simple to collect metrics .The only measure which was common, among most organizations, was person-hours. Most organizations collect personhours spent on tasks performed. Therefore new model should be based on personhours as basic metric. Motivation is that by introducing person-hours we can measure costs avoided on every kind of software artifact such as reuse of test cases, development environment frameworks etc. This metrics is easy to collect and no major guidelines are required in order to collect this metrics. A similar approach was used by Amar  in their research. Another study by Lim  has also used a similar metrics. 56 Chapter 5. Model for calculating Cost Avoidance 5.2 57 The Model After deciding about the metric next step was to come up with formula for measuring cost avoided through reuse. Basic inspiration of formula was taken up from Poulins work . However fundamental difference between the two models is that instead of dealing with lines of code, the new formula deals with personhours spent on reuse artifacts. Benefits of reusing any software artifact can be measured using the formula below: Cost Avoided = Do it yourself costCost of identification, understanding and integration Cost Avoided = (OI) x H O = Person-hours spent on artifact if build from scratch I = Person-hours spent on identification, understanding and integration of reuse artifact. H = Hourly Rate in Currency Mostly historical data is available if artifact is an internal product of the organization. This data will be used to get person hours spent on artifact when build from scratch Reuse person hours spent on each artifact includes the time spent on searching, understanding, integrating and testing the artifact . Sum of all these phases will be used as time spent on reusing the artifact. Characteristics of the model are discussed in sections below: 5.2.1 Third party Reuse products Internal reuse artifacts are those which are developed inside the organizations. They are not bought form any third party. Person-hours spent on these products are kept in record by organizations in order to pay employees their salaries. Therefore it will be very easy for the organizations come up with the number of hours spent on tasks. Organizations tend to pay their employees based on hours spent on work. Therefore it is much easier and convenient to keep track of time spent on each task. This time spent can be used to measure the costs avoided by that task. Measuring internal reuse savings do not require any new settings before using this model. Organizations usually know about the time and number of resources spent on a product developed inside, they can use this historical data to measure person-hours spent on internal reuse artifacts. 5.2.2 Hourly Rate Hourly rate can be different in terms of currency and value based on the location of organization. The value of cost avoided, calculated through the formula, will be in the same currency in which hourly rates are mentioned. Model does not Chapter 5. Model for calculating Cost Avoidance 58 impose any restriction on currency or hourly rates used in the organization. For example, if hourly rate is in Swedish Kronor, e.g. 200 SEK per hour, time spent on artifact when developed from scratch is 600 hours, time spent on reusing the artifact is 100 hours, Then savings are ( (600 -100) x 200) = 100 000 SEK. Savings are counted in SEK. Similarly if hourly rate is in US Dollars then savings will be in US Dollars. Same can be true for any other currency. 5.2.3 Guidance in data collection A major factor for introducing the cost model was to provide guidance on how to measure data. As evident from systematic literature review guidelines on what metrics to collect for measuring cost avoided are missing. Organizations are often confused what metrics to collect and what not to collect. Each organization has its own way of understanding a metrics and collecting it. It is necessary for any model to be able to guide on collection of data in order to be effective. A worksheet is developed which is generic enough to accommodate any organizations without any changes in it. This sheet can be used to collect data. Appendix D shows basic data fields to be collected. Data collecting document is divided into two parts. One part is responsible for basic information of the artifact while other part is responsible for actual metrics collection. 5.3 Discussion This section describes different aspects of proposed framework and provides arguments in support of its use and also discusses potential problems associated which may be present in the model. 5.3.1 Coverage This model is based on all types of software artifacts. A software artifact can be ’Any piece of software (i.e. models/descriptions) developed and used during software development and maintenance’ . A software project can consist of several different artifacts of various types and at various stages. As most of the artifacts can be measured in terms of person-hours spent on them therefore proposed model can be applied on project level as well as on individual products. With the help of this model we can calculate the cost avoided by one artifact as well as cost avoided by several different artifacts of various different products 5.3.2 Number of reuse instances Several models take into account number of reuse instances of an artifact . However in this proposed model, counting and using number of reuse instances of Chapter 5. Model for calculating Cost Avoidance 59 artifact are left on users choice. This change was based on the observation that organizations consider only first time reuse of any artifact as the actual reuse while some organizations consider each reuse instance as a separate reuse case . 5.3.3 Cost Time relationship Time spent on each task (related to reuse) is main factor for increasing or decreasing costs. Organizations pay their employees based on the time they spent working. Model for cost avoidance can use the values based on time spent on each tasks. This model is also based on the same assumption and only considers time spent on each task as the basis of calculating costs avoided. Other models on reuse have used the time based value as the deciding factor in software reuse  . Since aim of this model was to come up with simpler and easy solution for cost avoidance, therefore time value for money was not included. 5.3.4 Productivity Productivity of developers can influence the person-hours spent on tasks. An experienced and competent developer can integrate the component in less time as compare to the new developer. Same assumption can be applied if the artifact is developed from scratch, a young developer might require more time than the experienced developer. The difference, between building from scratch and reusing the artifact, remains the same for both as long as the developer remains the same. Therefore using person-hours as a basic unit for measuring costs is a viable option. According to Frakes  experience level of developer does not affect software reuse. Keeping in mind his claims the productivity factor becomes less significant in software reuse. However, Frakes emphasized on training of developers related to software reuse. 5.3.5 Validity of Model on Different Reuse Artifacts Bhargav et. all  have listed all the software artifacts which can be reused are described in literature. According to their study, fourteen different types of reuse artifacts are present in literature. Table 1 shows possibility of measuring these artifacts in terms of person-hours. Since the basic requirement of the proposed model is to evaluate everything in terms of person-hours, therefore table shows whether an artifact can be measured in person-hours or not. 5.3.6 Generic Model Because of limited available time model will be tested in one organization only. Since, person-hours are basic metrics collected by most of the organizations there- Chapter 5. Model for calculating Cost Avoidance Artifact Algorithms Architecture Data Designs Documentation Estimates Human Interfaces Knowledge Models Modules Plans Requirements Service Contracts Test Cases Measured? May be Yes Yes Yes Yes May be Yes May Be Yes Yes Yes Yes Yes Yes 60 How? Amount of time taken to develop the algorithm Person-hours spent on developing architecture. Person-hours spent on gathering data. Person-hours spent on design of product Person-hours spent on documentation Person-hours spent on estimates Person-hours spent by the person on an assigned task Depends on type of knowledge i.e. human interfaces Person-hours spent on the development Person-hours spent on the development of module Person-hours spent on development of plans Person-hours spent on gathering / documenting requirements Similar to Documentation. Person-hours spent on developing the test cases. Table 5.1: Applicability of model on different reuse artifacts fore model could easily be applied on other organizations. However, this study would be limited to only one organization. 5.3.7 Risks Associated Organizations have variety of different methods for paying their employees. Personhours might not be a universal method for keeping track of costs spent on development. This model might not work in that case since Person-hour is the primary metric required for this model. Another possible risk is concerned with complexity of collecting metrics. If a designer is working on more than one task at the same time it would be very hard to keep track of individual task and time and effort spent on that. Third risk is associated with standardization. No standard definition of a reusable artifact can mean different things for different developers.This may lead to confusion. 5.4 Dynamic Validation The proposed model was developed keeping in mind industry needs. Efforts were made to simplify the model as much as possible. Industry relevant studies become impractical if they are not designed or carried out keeping in mind the problems which industry faces . Therefore, after developing this model first step was to try this model in an industrial environment. In this section details about the dynamic validation are mentioned. This dynamic evaluation was carried out at large telecommunication organization. Following sites were involved in this Chapter 5. Model for calculating Cost Avoidance 61 evaluation processes, Guangzhou, Shanghai, Gothenburg, Stockholm, Karlskrona and Rijen. Karlskrona site was the main driver for reuse related programs and this research was also driven by Karlskrona site. Basic details of industrial validation are present in Chapter 4. The dynamic validation was divided into two steps. In first step model was used at a local site. A tool was developed based on the model to assist managers while using this model. During the collection of data researcher was present on site so that in case of any problem managers can contact for help. It also gave a chance to evaluate the model for possible problems and fix these problems before trying the model on several sites in parallel. In second step, tool was used by remote sites for reporting their reuse cases and then cost avoided was calculated. Analysis was carried out on results obtained from the model and recommendations were made for the future use of this mode. Steps followed during validation are described below: 5.4.1 Initiation A tool was developed which implemented the model. This tool was in the form of Microsoft Excel  document with multiple worksheets. Reason for developing an excel sheet, for implementing the model, was to make it easy for managers or reuse drivers to collect data from multiple sites. Each worksheet was named after each individual site. Two sheets calculate the cost avoidance from different point of views such as cost avoided per site, total cost avoided of all six sites, artifact which avoided the most amount of cost etc. Analysis of cost avoidance was made from various aspects based on the needs of managers. Management can send the excel sheet to different sites and they can fill in the required fields. Management can see the results of individual sites as well as combined result of all the sites. Four major types for reuse artifacts, used inside the organization, were identified by a survey, present in section 3.1. The data sheets, present in Appendix D, takes care of only four different categorize i.e. Code reuse, Document Reuse (test cases, documentation etc), Reuse of Framework, and Reuse of development environment. This was decided after discussions with stakeholders. Data Collection This model requires two basic values in order to be implemented i.e. person-hours spent when artifact is build from scratch and person-hours spent for reusing the artifact. Data collection was to be made from six different sites which were geographically spread across the world. An Email was sent to each of these sites to report their use cases; each site had its own reuse driver for managing software reuse activities. Data of reuse activities was collected for three consecutive months. Each site was asked to identify the reuse cases and report them back to Chapter 5. Model for calculating Cost Avoidance 62 main reuse driver of the organization. There were in total 24 cases reported from six different sites. These cases were reported through the developed tool. 5.4.2 Data Analysis Analysis of data was carried out using the developed tool. Tool showed different charts and percentages from different viewpoints. Analysis involved measuring the percentage savings, type of reuse artifact which was extensively reused, time taken to make the artifact reusable and total cost avoided at each individual site as well as combined cost avoided. Main aim of dynamic evaluation was to judge the performance of model and less focus was on the reuse processes inside the organizations. Therefore, lesser emphasis was given to the related to software reuse practices. 5.4.3 Results Interesting results were found during the evaluation of model. Results showed that, reuse of framework were responsible for most of the savings. Nearly 75% of total savings were because of the reuse of frameworks. However, most number of reuse instances was reported from the category, reuse of environment. Total cost avoided through reuse (till the end of May) was 1.3% of total research budget. Code reuse took most amount of time for making the artifact reusable (searching, understanding and integration). Reuse of environment took least amount of time. No case was reported for the reuse of documentation. A possible reason for it could be the limited amount of time (2 months) provided to the sites in order to identify and collect cases. Secondly, as evident from literature review, practitioners and researchers sometimes only focus on executable artifacts or artifacts which directly relate to software development. However, further investigation is required in order to analyze this lack of cases reported in documentation reuse. Few interesting facts were found during the analysis phase. Different articles   claimed that it takes around 20% effort of original artifact to reuse a black box code artifact. In our case white box artifacts, on average, took around 33% effort of original artifact in order to reuse it. However, there were artifacts which took as much effort to reuse them as it was required to build them from scratch. It was interesting to find that, size of artifact has no linear relation with the savings. It was noted that medium size artifacts require more effort to reuse them as compare to large or small artifacts. This pattern was even more evident in cases where development environment was reused. Total savings were about 1.3% of total development budget. These were close to the figure provided in the literature . Some important findings are listed here: Reuse of Code took most amount of time as compare to the reuse of other artifacts. Reuse of medium size artifacts (150 300 person-hours) took most amount Chapter 5. Model for calculating Cost Avoidance 63 of effort in order to reuse these. Reuse of frameworks saved most amount of money. White Box reuse takes around 33% of effort , however some code components takes as much time as building from scratch Development environments were the most reused artifacts. These findings were gathered from 24 different reuse cases collected in the organization. These cases were carried out be different subjects with various different backgrounds. These finding are not limited to a particular department or person, these are generalized results from various reused products. However, aim of this study was not to investigate reasons behind these findings, this study is limited to cost related aspects of software reuse. 5.4.4 Evaluation of Model Feedback from different stakeholders was collected in a meeting. Managers from remotes site emailed their feedback, about the usage and results received from the model, to the reuse driver of organization. A one hour session was conducted in which three managers gave their feedback about the working of proposed model. Overall feedback was positive and model was able to achieve what was required. Management was happy with the performance and results obtained, however important suggestions were made about measurement of maintenance costs. Simplicity and ease of data collection was one of the major aims of model. Basic aim was to provide assistance in collection of metrics so that resources were not wasted on collecting of wrong metrics or useless metrics. Managers found it easy to fill out the data collection sheet, not many questions were asked on this issue. Gathered data was easily combined for analysis and presented to higher management. Usage of email for sending data collection sheet avoided any confusion. Person responsible for filling the data sheet, with required reuse cases, were not troubled by definition any field. Definition and example of each column was provided in the data sheet, this helped in reducing the confusion regarding common understanding of terms. Second aim of the proposed model was, to measure each and every kind of reuse artifact. Four different types of artifacts were measured during this dynamic evaluation. These artifacts vary from code to documents. In previous research work no account of environment reuse was found. This model was able to measure costs avoided through reuse of such artifacts. The four artifacts measured were of different types ranging from code to documents but model performed at satisfactory level for each one of these. Results obtained showed that in first 5 months costs avoided through reuse were around 1. 5 % of total researc budget. These numbers were compared with the claims present in literature  and this 15̇% value was found to be a realistic number. According to literature in an organizations with ad-hoc reuse processes have savings of around 5% of development budget per year. A separate study was conducted on the organizations reuse process and it was found to be ad-hoc Chapter 5. Model for calculating Cost Avoidance 64 reuse process. Hence results obtained are justifiable keeping in mind the previous study. While model was used in industry for 2 months. Suggestions were made regarding the expansion of this model. Some stakeholders wanted it to measure cost avoided through maintenance. According to previous studies costs avoided through maintenance are the major costs avoided through software reuse  . These maintenance costs can only be calculated if the reused software is used for lengthy duration of time. Only then we can have number of hours which were avoided in terms of maintenance costs. However, aim of the model was to measure the costs avoided through reuse artifacts. It was not planned to accommodate the maintenance costs and model do not accommodate such costs. Future work discuses further research on this topic. Comparison with previous models on Cost Avoidance Two previous models  ,  were based on lines of code. These two models cannot measure the artifacts other than code. Therefore, our model is better in terms of coverage of various reusable artifacts. In literature, we do not find any experience of dynamic validation provided by these models, as stated in chapter 2. Hence, improvement is in the area of coverage and generic nature of this model. Third model  related to cost avoidance was very similar to this model. However, our model is simple and easy to apply in terms of metrics it requires. Old model  required various metrics which were difficult to collect. Hence, simplicity of use is major improvement in the old work. Other features remain very similar to this model. Comparison with COCOMO COCOMO Intermediate involves lines of code as its basic estimation formula. However, it does not consider documents, test cases etc. Cocomo basic was an old model which did not take into account the new development technology and provides its estimation based on three types of software artifacts only . These estimates may be valid for code reuse but various other types of artifacts cannot be measured by these mdoels. In this study we aim to measure costs which were avoided previously, however COCOMO measures effort which will be required in future. Chapter 6 Guidelines for introducing reuse culture Increasing demands of software systems are making it hard for the organizations to meet satisfactory level of production  . It is hard for the organizations to introduce any rapid changes in order to increase profits. Organizations present at the opportunistic level of software reuse usually have no planned reuse in their products. Reuse present in such organizations is because of individual efforts. Although management of organizations wants to increase reuse but often they do not have enough resources and time for that. Therefore simpler guidelines are required which can guide organizations to more systematic form of software reuse. In this section these guidelines are discussed. As evident from the basic formula used in the model for increasing the savings through software reuse, costs of reusing an artifact should be reduced. This will increase the savings of organization and could reduce the lead time as well. Four phases required for reusing software were described by Poulin ; these phases are searching, locating, understanding and integration (adaptation) of reuse artifact. Lesser the time spent on searching, locating, adapting and testing more will be the profit. Therefore necessary steps are required in order to reduce costs related to these four factors. After going through the experience shared by several studies on success and failure factors of software reuse      , a three phase strategy was developed. Author of this research shared his own experience in a study about an organizations reuse success factors in section 3.3 as well. This research also helped in understanding the problems faced by very large organizations related to reuse. The three phases are described as following: 6.1 Initial Strategy Initial strategy involves steps which should be taken immediately. These steps are not difficult and require managements commitment to the reuse efforts. An organization can introduce these steps in a year long time. No major time consuming activity is present in this phase. These steps are described as following. 65 Chapter 6. Guidelines for introducing reuse culture 6.1.1 66 Small scale domain analysis At this initial level organizations have low level of reuse. Therefore first step should be to identify the reusable components present inside the organization. Identification of reusable component can be tricky. Matching the requirements is a good way to find similarity between the artifacts. A similar approach was discussed by Martinez et .all . A resource at a designers level should be assigned for that purpose. That resource should be expert in technical aspects of products. Initially only small size artifacts (2000 SLOC- 3500 SLOC) should be identified. Small artifacts are easy to adapt, according to the result of this very study in analysis section. 6.1.2 Introduction of component library A component library should be introduced which can store artifacts as well as meta-data about the artifact. Component library should store the requirements, source code and information of the contact person in the library . Considerable amount of publicity should be done about this library. During a recent survey, present in sextion 3.1, it was noted that developers often do not know about any library while managers know about it. Since it is the developers how perform the actual work therefore awareness level of developers should be increased about the library and its usage. 6.1.3 Contact person for reusable artifact Adapting and understanding an artifact is a difficult task. Help in this regard reduces the time to adapt the artifact. In the initial stage, when no systematic processes for software reuse are present, a contact person should be assigned. This contact person should preferably be the developer of that artifact. He should be able to take some time out from weekly routine and answer questions related to that artifact. Each artifact should have its own contact person. For seeking help related to that artifact, the contact person should be contacted through email. 6.2 Short-term Strategy (1 to 3 years time) Short term strategy involves practices which can be introduced in 1 to 3 years time. These are generally agreed upon features     listed by studies. However, it is difficult to introduce these basic features at once since it might affect productivity of the organization. Prioritizing these practices should be left on the organizations choice and they can do that based on their immediate need and resources. These practices / guidelines range from technical aspect to managerial aspects. Chapter 6. Guidelines for introducing reuse culture 6.2.1 67 Encourage Object Oriented based design Object oriented design makes reuse relatively easy as compare to the procedural programming style. Objects and classes are easily reused if they have less dependency over other classes or objects. Several research studies supported the idea of objected oriented programming for software reuse  . Organizations which are using Java, C# or C++ as their development language can easily adapt to pure object oriented designs. Lesser time for adaptation of artifact means more profit for the organization. It also reduces the complexity level of reusable artifact. 6.2.2 Optimize component library Different organizations have different ways of storing and documenting an artifact. Based on the needs and practices of the organization, these library artifacts should be stored. Some organizations focus on good search tool for fetching meta-data about the artifact while other organizations may be interested in actual requirements of the artifact. Therefore, based on the work habits and needs, library should be modified. Before this modification extensive feedback should be collected from all the stakeholders. This feedback should span over a year. Analysis of feedback should be done and steps for the improvement of library should be finalized. This will help in shorted search time which is a big factor in reuse related costs . 6.2.3 Store medium size components In the initial phase, small phase artifacts were recommended. However, for more profitability medium and large size artifacts should be used. After learning from the experience of storing small size artifact, organizations should analyze this experience and try to come up with improved way of storing artifacts which are larger in size. Larger artifacts are difficult to adapt and complexity level increases with the size of artifact. Therefore medium size artifacts should be adapted for reuse before storing in the library. More focus should be paid on storing medium size component as compare to larger size components. 6.2.4 Encourage black-box reuse Adaptation of artifact for the reuse purpose is a complex job. Understanding the code written by someone else is never an easy task. Therefore black box reuse should be encouraged inside the organization. Any artifact which is stored or retrieved from the library should be used as it is. This will reduce the adaptation costs and it will also increase quality aspect of the artifact . Chapter 6. Guidelines for introducing reuse culture 6.2.5 68 Design applications keeping in mind their reuse At the early stages of development it is difficult to predict the future reuse of artifact. However, with the passage of time guidelines for developers should be introduced in order to develop reusable components. These guidelines should be purely technical and should correspond to the domain and programming language used for development. This will help in producing artifacts which are already adapted for reuse, reducing time for adaptation  . 6.2.6 Documentation, groups, forums on reuse One of the objectives of short term strategy is to become independent of human resource. Human resource often move in and out of the organization, taking with them useful knowledge of products. Documentation is considered as a useful way of storing information. Documentation related to software reuse should be started in this phase. Document should tackle the most common problems faced while reusing the artifact. Forums and groups are modern ways of sharing knowledge. They have been found as a good and quick way of seeking help. Developers community realized the importance of forums years ago. Organization can introduce reuse groups and forums where people can discuss problems and find a solution. Similar experiences are shared by other large organizations as well . 6.2.7 Incentive on Reuse In order to increase the reuse level and reuse awareness, incentives should be introduced in the organizations. Incentives should be given to the developers who have reused more artifacts or who has introduced more artifacts in the library which were reused by several developers. This can lead to a healthy competition inside the organization. 6.3 Long-term Strategy (3 to 5+ years time) Long term strategy involves steps which cannot be introduced in short span of time. These are the fundamental changes which should be introduced in small steps and over a lengthy duration. These factors can affect organizations ability to deliver in time if they are introduced rapidly. However, introduction is necessary since it can lead to a systematic software reuse inside the organization. Each organization should consider its own state of affairs before deciding to introduce these factors. Chapter 6. Guidelines for introducing reuse culture 6.3.1 69 Development language and framework Languages which supports object oriented design and component based artifacts should be encouraged. Reuse of code is easy if the language and design has less coupling and more cohesion inside an artifact. This helps in producing blackbox artifacts which are easy to reuse. Since introduction of new language in the organization requires new experience and skills of developers therefore this change cannot be rapid. Long term planning and execution is required in order to change development language of organization. Exporting components from one platform to another platform has been made easy through recent developments in frameworks. Now components developed in one programming language can be reused in another programming language without too much adaptation costs . New and improved frameworks like Java Enterprise, .Net Framework   allow developers to develop deployable objects. These objects can work independently and do not require adaptation for reuse purposes. However introduction of such frameworks require expertise at developer and designer levels. This cannot be achieved over one or two years. Organization has to invest in order to improve the competence level present in the organization 6.3.2 Refactoring Contents of Component Library Component libraries should be regularly updated. Old artifacts which are not reused in the past should be removed. New components should be regularly introduced . 6.3.3 Product Line Engineering Very large organizations with similar product can introduce product line engineering in their processes. This considerably improves profit levels and reduces time to market a product. Introduction of product line is a lengthy and hectic process. Ways of introducing product line engineering is itself a wide research area. More information on that can be found in literature.   Chapter 7 Conclusion Software reuse was claimed to be silver bullet  required by software industry. Despite of several years of research, management of organizations still need to be convinced about the importance of software reuse and its financial benefits. Organizations with ad-hoc reuse processes find it difficult to measure potential gains they had from the reuse of software artifacts. Varieties of cost models for software reuse are found in literate. These models try to provide solution of measuring reuse benefits. However these models are either based on assumptions, such as presence of systematic reuse processes and investment on reuse, or these models are too complex to apply in organizations, which collect limited amount of metrics. The model proposed here tries to overcome these difficulties by providing a model which is simpler in understanding and also provides guidelines which type of metrics to collect and how to collect the metrics. Secondly the model covers 13 different types of reuse artifacts other than code reuse The proposed model has limited applicability as its focus was on cost avoidance through software reuse. It does not cover the return on investment or costbenefits of software reuse. However, this model can measure savings from all kinds of commonly reused artifacts. Two metrics are required in order to apply this model. First metric should be the time spent on artifact when it was build from scratch and other metric was the time spent on artifact in order to reuse it. This reuse time includes time spent on identification, understanding and integration of artifact. Dynamic evaluation of model was done in industry. A tool was developed which implements this model and also used for data collection. An organization was selected to run the first evaluation of the model. Six different sites were contacted to report their reuse cases using the implemented tool and guidelines provided to them. There were in total 24 cases reported from six different sites. Savings reported were around 1.5 Dynamic evaluation pointed out that model should accommodate the costs avoided through maintenance. However this requires lengthy time period to collect further data. Scope of this study was limited to the direct savings through reused artifacts; therefore in future this model needs to accommodate maintenance savings. 70 Chapter 7. Conclusion 71 Increasing the profits is the main objective of any successful organization. Guidelines for increasing the profits through software reuse are provided in this article as well. These guidelines are generally agreed upon success factors, mentioned in the literature and based on a study conducted by the author himself. Appendix A Appendix A Results after Initial search and search strings Search Term Software Reuse Software Reuse Cost Model Reuse Cost Model Software Reuse Cost measurements Software Reuse Cost measuring framework Software Reuse Cost Estimation Software Reuse Savings Measuring software reuse benefits Software Reuse Economics Reuse Economics Software Reuse Benefits Reuse Benefits Software Reuse Cost Avoidance Reuse Cost Avoidance Reuse return on investment Software reuse return on investment Reuse Finance Reuse Cost Estimation Reuse Cost Assessment Software Reuse Cost Estimation Software Reuse Cost Assessment Software Reuse Business Reusability cost Software Reuse cost measurement method Software Reuse cost measurement technique Software reuse cost reduction Software reuse price Tracking Reuse Cost Monitoring Reuse cost Reuse Cost-benefit 72 Total Results 2755 453 18 403 0 232 227 233 281 132 243 69 227 1 1053 243 0 6 8 232 336 257 50 0 0 227 227 3 1 17 Appendix A. Appendix A Software Reuse ROI Software Reuse Financial aspect 1 AND 10 1 AND 3 1 AND 13 1 AND 12 16 AND 1 Total 73 230 436 267 13 227 14 227 9348 Appendix B Appnedix B Software Reuse Cost Models 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Software Reuse Economics: Cost Benefit Analysis on a Large Scale Ada Project, In Proceedings of Internat. Conf. on Software Engineering, Melbourne, Australia, May, pp.338348. Software Reuse Some Realities, Vitro Tech. Journal 10, 1, 4757. Economics of Reuse, Revisited, Technical Report HPL-93-31, Hewlett Packard Laboratories. Reuse Level Metrics, In Proceedings of the 3rd Internat. Conf. on Software Reuse, W.B. Frakes, Ed., Rio de Janeiro, Brazil, November, pp. 139148. Measuring the Roi of Reuse, Object Magazine 4, 3, 4854. Effects of Reuse on Quality, Productivity and Economics, IEEE Software 11, 5, 2330. Cost Models for Future Software Lifecycle Processes: COCOMO 2.0, Annals of Software Engineering 1, 5794. Return on Investment of Reusable Components: Analytical and Empirical Approaches, Technical Report, University of Ottawa, Ottawa, ON, Canada. Analytical and Empirical Evaluation of Software Reuse Metrics, In Proceedings of Internat. Conf. on Software Engineering, Berlin, Germany, IEEE Press, New York. The Economics of Software Product Lines, Internat. J. Appl. Software Technology 3, 1, 2034. Value Based Software Reuse Investment, Annals of Software Engineering 5, 552. Technical Report, Center for Software Engineering, University of Southern California, Los Angeles, CA Software Reuse Key to Enhanced Productivity: Some Productivity Models, Information and Software Technology 31, 5, 258267. Making Reuse Cost Effective, IEEE Software 8, 1, 1324. Economics of Reuse: Issues and Alternatives, Information and Software Technology 32, 10, 643652. Managing Software Reuse Economics: An Integrated ROI-based Model 74 Appendix B. Appnedix B 75 17 Cost Estimation Model For Reuse Based Software Products, Proceedings of the Internat. Multi Conference of Eng. and Comp. Scientists 2008 Vol I 2008, 19-21 18 Evaluating software reuse alternatives A model and its application to an industrial case study 19 Cost-benefit analysis for software reuse A decision procedure, Lecture Notes in Computer Science, Springer Berlin / Heidelberg, Volume 887/1994 20 Software Reuse Metric Plan Defense Information Systems Agency, Joint interoperability engineering organization, center for information management, version 4.1, 4 August, 1993. 21 ”Measuring the benefits of software reuse - Examining three different approaches to software reuse.” Dr Dobbs Journal 30(6): 73-76. 22 SOFTWARE REUSE ECONOMICS MODEL, Washington Ada Symposium, Proceedings of the eighth annual Washington Ada symposium - summer SIGAda meeting on Ada: software: foundation for competitiveness, McLean, Virginia, United States Pages: 141 - 155 Year of Publication: 1991 23 Software Methodology in the Harsh Light of Economics , Information and Software Technolog, Butterworth - Co., vol 31, no 5, June 1989 24 Using Code Reusability Analysis to Identify Reusable Components from the Software Related to an Application Domain Proceedings of the 4th Annual workshop on Software Reuse, November 1991. 25 The Economics of Reusing Library Classes, Journal of Object Oriented Programming, Vol. 6, No.4 , July August 1993, pp 43- 50 26 Aligning the economic modeling of software reuse with reuse practices, Information and Software Technology, Volume 50 , Issue 7-8 Pages: 753- 762 ,2008 ISSN:0950-5849 27 A Reuse Metrics and Return on Investment Model, In Advances in Software Reuse: Proceedings of the 2nd Internat. Workshop on Software Reusability, Lucca, Italy, March, pp. 152166. 28 Cost Estimation Models for the Reuse and Prototype Software Development Lifecycles, ACM SIGSOFT Software Engineering News 15, 3, 4250. 29 A Comparison of Approaches to Reuse Investment Analysis, In Proceedings of 4th Internat. Conf. on Software Reuse, Orlando, FL, April, pp. 136145. Appendix C Appendix C Articles without full text available No 1 2 3 4 5 6 7 8 9 10 11 Article Baldo Jr, J. (1998). A measurement framework for organizational software reuse attributes. 4th International Conference on Computer Science and Informatics, JCIS 1998, October 23, 1998 - October 28, 1998, Research Triangle Park, NC, United states, Duke University Press Ben Abdallah Ben Lamine, S., L. L. Jilani, et al. (2008). A software cost estimation meta-model for systematic reuse approaches, Las Vegas, NV, USA, CSREA Press. Bond, S. (1991). THE ECONOMICS OF REUSE Bott, F. (1998). Financial models of software component reuse. Proceedings of the European Software Measurement Conference, 6-8 May 1998, Antwerpen, Germany, Technologisch Instituut Vzw Coulange, B. (1993). The economic impact of reuse. Proceedings of Sixth International Conference on Software Engineering and Its Applications, 15-19 Nov. 1993, Nanterre Cedex, France, EC2. Cruickshank, R. D. and J. E. Gaffney (1993). An economics model of software reuse. Analytical methods in software engineering economics. Berlin, Germany, Springer-Verlag: 99-137 De Lucia, A., G. A. Di Lucca, et al. (1993). Towards the evaluation of reengineering effort to reuse existing software. Proceedings of AQUIS ’93. 2nd International Conference on Achieving Quality in Software, 18-20 Oct. 1993, Pisa, Italy, IEI-CNR. Frakes, W. B., A. Amer Inst, et al. (1991). SOFTWARE REUSE - PAYOFF AND TRANSFER. Washington, Amer Inst Aeronautics Astronautics. Gaffney, J. (1989). Economics foundation for software reuse. AIAA Computers in Aerospace VII Conference, Oct 3 - 5 1989, Monterey, CA, USA, Publ by AIAA. Hagerf, B. (1997). ”Reuse of software will cut costs.” Nordic Steel and Mining Review(3): 107-107. Henderson-Sellers, B. (1993). ”The economics of reusing library classes.” Journal of Object-Oriented Programming 6(4): 43-50. 76 Appendix C. Appendix C 12 13 14 15 77 Joiner, H. F. (1990). Economic analysis of software reuse-a model study. Proceedings of Eighth Annual National Conference on Ada Technology, 5-8 March 1990, Fort Monmouth, NJ, USA, U.S. Army Commun.- Electron. Command. Korkmaz, M. and A. Mili (2007). A product line of software reuse cost models. 2nd International Conference on Software and Data Technologies, ICSOFT 2007, July 22, 2007 - July 25, 2007, Barcelona, Spain, INSTICC Press. Lamine, S. B. A. B., L. L. Jilani, et al. (2008). A software cost estimation meta-model for systematic reuse approaches. 2008 International Conference on Software Engineering Research and Practice, SERP 2008, July 14, 2008 July 17, 2008, Las Vegas, NV, United states, CSREA Press Reifer, D. J. (1998). The business case for software reuse. Proceedings of the European Software Measurement Conference, 6-8 May 1998, Antwerpen, Germany, Technologisch Instituut Vzw. Appendix D Appendix D Description of each field is given below: Case No: Listed for keeping track of numbering and for reference in other reports Name of the reuse artifact: The name used for artifact in the organization. Category: Artifacts can be categorized based on the requirements of organization. Each organization has its own products and these products vary in different domains. For example in telecommunication systems frameworks are often used extensively but organizations dealing with low level system architecture are more concerned with reuse of algorithms. Therefore this category is customizable according to the requirements of organization. Origin: Original product from which artifact was taken. It can be name or version which is used inside the organization. Reused In: The final product in which software artifact was reused. It can be the name or version which is used inside the organization. Quarter: Depends on organizations policy for generating reports. Value of this column can be replaced by month or year. Calculations: Man-hours spent on artifact when build from scratch. In case where no historical record of man-hours is present we can use expert opinion to estimate the number of hours Man-hours spent on artifact when reused (in identification, understanding , integration and testing of artifact). Comment: For providing any useful comments. Used if some clarification needs to be addressed 78 Appendix E Definitions Reuse: To use again, especially after salvaging or special treatment or processing. Guidelines: A detailed plan or explanation to guide you in setting standards or determining a course of action. Profitability: ”The quality of affording gain or benefit or profit”. Person-Hour: A person-hour is the amount of work performed by an average worker in one hour. Profit: ”An excess of the receipts over the spending of a business during any period”. Cost Avoidance: Preventing any costs from happening or occuring. 79 References  L. Amar and J. Coffey. Measuring the benefits of software reuse - examining three different approaches to software reuse. DR DOBBS JOURNAL, 30:73– 76, 2005.  D. Balda and D. A. Gustafson. Cost estimation models for reuse and prototype sw development life-cycles. SIGSOFT Softw. Eng. Notes, 15:42–50, July 1990.  Bruce H. Barnes and Terry Bollinger. Making reuse cost-effective. IEEE Software, 8(1):13–24, 1991.  Julie Baron. The people side of software: A lesson plan for establishing a successful training program. Software Engineering Education, Conference on, 0:184, 1996.  S. Biffl and T. Grechenig. Degrees of consciousness for reuse of software in practice: Maintainability, balance, standardization. In Computer Software and Applications Conference, 1993. COMPSAC 93. Proceedings., Seventeenth Annual International, pages 107 –114, November 1993.  Barry Boehm. Managing software productivity and reuse. Computer, 32:111– 113, September 1999.  Barry W. Boehm. Software Engineering Economics. Prentice Hall, Englewood Cliffs, NJ, 1981.  Erran Carmel and Pamela Abbott. Why ’nearshore’ means that distance matters. Commun. ACM, 50:40–46, October 2007.  Eoin Conchuir, P. J. AAgerfalk, Helena H. Olsson, and Brian Fitzgerald. Global software development: where are the benefits? Commun. ACM, 52:127–131, August 2009.  Microsoft Coorporation. http://office.microsoft.com/en-us/excel/. 80 References 81  A.M. de Cima, C.M.L. Werner, and A.A.C. Cerqueira. The design of objectoriented software with domain architecture reuse. In Software Reuse: Advances in Software Reusability, 1994. Proceedings., Third International Conference on, pages 178 –187, November 1994.  DISA/JIEO/CIM. Software reuse metric plan. In Defense Information Systems Agency, Joint interoperability engineering organization, center for information managemen. Defense Information Systems Agency, 1993.  Michael F. Dunn and John C. Knight. Software reuse in an industrial setting: a case study. In Proceedings of the 13th international conference on Software engineering, ICSE ’91, pages 329–338, Los Alamitos, CA, USA, 1991. IEEE Computer Society Press.  Tore Dybå and Torgeir Dingsøyr. Empirical studies of agile software development: A systematic review. Inf. Softw. Technol., 50:833–859, August 2008.  J.V. Finnigan and J. Blanchette. A forward-looking software reuse strategy. In Aerospace Conference, 2008 IEEE, pages 1 –9, 2008.  G. Fischer. Cognitive view of reuse and redesign. IEEE Softw., 4:60–72, July 1987.  William Frakes and Carol Terry. Reuse level metrics. Technical report, Blacksburg, VA, USA, 1994.  William B. Frakes and Christopher J. Fox. Sixteen questions about software reuse. Commun. ACM, 38:75–ff., June 1995.  William B. Frakes and Giancarlo Succi. An industrial study of reuse, quality, and productivity. J. Syst. Softw., 57:99–106, June 2001.  Ryan Gerard, Robert R. Downs, James J. Marshall, and Robert E. Wolfe. The software reuse working group: A case study in fostering reuse. In IRI, pages 24–29. IEEE Systems, Man, and Cybernetics Society, 2007.  M.A. Gisi and Sacchi C. A positive experience with software reuse supported by a software bus framework. Proceedings Advances in Software Reuse, Selected Papers from the Second International Workshop on Software Reusability, pages 196–203, 1993.  Tony Gorschek, Per Garre, Stig Larsson, and Claes Wohlin. A model for technology transfer in practice. IEEE Softw., 23:88–95, November 2006.  Martin L. Griss, Marty Wosser, and Shari Lawrence Pfleeger. Making reuse work at hewlett-packard. IEEE Software, 12:105–107, 1995. References 82  R. Hewett. Learning from software reuse experience. In Empirical Software Engineering, 2005. 2005 International Symposium on, page 10 pp., 2005.  R. Hitchings and M. Martinez. Reuse of process elements-one company’s experience. In Proceedings of the 10th International Software Process Workshop, pages 74–, Washington, DC, USA, 1996. IEEE Computer Society.  J. Huddlestone and J. Pike. Learning object reuse - a four tier model. In People and Systems - Who Are We Designing For, 2005. The IEE and MOD HFI DTC Symposium on (Ref. No. 2005/11078), pages 25 – 31, 2005.  A.J. Incorvaia, A.M. Davis, and R.E. Fairley. Case studies in software reuse. In Computer Software and Applications Conference, 1990. COMPSAC 90. Proceedings., Fourteenth Annual International, 1990.  S. Isoda. An experience of software reuse activities. In Computer Software and Applications Conference, 1991. COMPSAC ’91., Proceedings of the Fifteenth Annual International, pages 8 –9, September 1991.  Sadahiro Isoda. Experiences of a software reuse project. Journal of Systems and Software, 30(3):171–186, 1995.  Deb Jacobs. Accelerating Process Improvement Using Agile Techniques. Auerbach Publications, Boston, MA, USA, 2005.  Deb Jacobs. Accelerating Process Improvement Using Agile Techniques. Auerbach Publications, Boston, MA, USA, 2005.  R. E. Johnson and B. Foote. Designing reusable classes. Journal of ObjectOriented Programming, 1(2):22–35, June/July 1988.  Rebecca Joos. Software reuse at motorola. IEEE Softw., 11:42–47, September 1994.  Panagiotis Kalagiakos. The non-technical factors of reusability. In Proceedings of the 29th Conference on EUROMICRO, pages 124–, Washington, DC, USA, 2003. IEEE Computer Society.  Barbara Kitchenham and Stuart Charters. Guidelines for performing systematic literature reviews in software engineering. Technical Report EBSE 2007-001, Keele University and Durham University Joint Report, 2007.  B. M. Konda and Mandava K. K. A systematic mapping study on software reuse. http://www.bth.se/fou/cuppsats.nsf/all/ 023e3567fa0779fac125772e003a9412/$file/Thesis_Final_Draft_ MSE_2010_07_(1).pdf/. MS thesis: Blekinge Institute of Technology. References 83  Jihyun Lee, Jinsam Kim, and Gyu-Sang Shin. Facilitating reuse of software components using repository technology. In Proceedings of the Tenth Asia-Pacific Software Engineering Conference Software Engineering Conference, APSEC ’03, pages 136–, Washington, DC, USA, 2003. IEEE Computer Society.  Dong Li and Carl K. Chang. Initiating and institutionalizing software product line engineering: From bottom-up approach to top-down practice. In Sheikh Iqbal Ahamed, Elisa Bertino, Carl K. Chang, Vladimir Getov, Lin Liu, Hua Ming, and Rajesh Subramanyan, editors, COMPSAC (1), pages 53–60. IEEE Computer Society, 2009.  Wayne C. Lim. Reuse economics: A comparison of seventeen models and directions for future research. Software Reuse, International Conference on, 0:41, 1996.  W.C. Lim. Effects of reuse on quality, productivity, and economics. Software, IEEE, 11(5):23 –30, September 1994.  Shuang Liu and Peng Chen. Developing java ee applications based on utilizing design patterns. In Proceedings of the 2009 WASE International Conference on Information Engineering - Volume 02, pages 398–401, Washington, DC, USA, 2009. IEEE Computer Society.  R. A. Malan and K. Wentzel. Economics of software reuse revisited. In Proceedings of ISS’93. UC Irvine, 1993.  E. W. Martin. Strategy for a dod software initiative. Computer, 16:52–59, March 1983.  Miguel A. Martinez and Ambrosio Toval. Cotsre: A components selection method based on requirements engineering. In Proceedings of the Seventh International Conference on Composition-Based Software Systems (ICCBSS 2008), pages 220–223, Washington, DC, USA, 2008. IEEE Computer Society.  Y. Matsumoto. Experiences from software reuse in industrial process control applications. In Software Reusability, 1993. Proceedings Advances in Software Reuse., Selected Papers from the Second International Workshop on, pages 186 –195, March 1993.  T. Menzies and J.S. Di Stefano. More success and failure factors in software reuse. Software Engineering, IEEE Transactions on, 29(5):474 – 477, May 2003.  Parastoo Mohagheghi and Reidar Conradi. An empirical investigation of software reuse benefits in a large telecom product. ACM Trans. Softw. Eng. Methodol., 17:13:1–13:31, June 2008. References 84  Shlomit Morad and Tsvi Kuflik. Conventional and open source software reuse at orbotech - an industrial experience. In Proceedings of the IEEE International Conference on Software - Science, Technology & Engineering, pages 110–117, Washington, DC, USA, 2005. IEEE Computer Society.  Derek L. Nazareth and Marcus A. Rothenberger. Assessing the costeffectiveness of software reuse: a model for planned reuse. J. Syst. Softw., 73:245–255, October 2004.  Holger Noseck. Cost-benefit analysis for software-reuse a decision procedure. In Marcel Toussaint, editor, Ada in Europe, volume 887 of Lecture Notes in Computer Science, pages 397–405. Springer Berlin Heidelberg, 1994.  Douwe Postmus and Theo Dirk Meijler. Aligning the economic modeling of software reuse with reuse practices. Inf. Softw. Technol., 50:753–762, June 2008.  Jeffrey S. Poulin. Issues in the development and application of reuse metrics in a corporate environment. In Fifth International Conference on Software Engineering and Knowledge Engineering, pages 16–18, 1993.  Jeffrey S. Poulin. Measuring software reuse: principles, practices, and economic models. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 1996.  Jeffrey S. Poulin and Joseph M. Caruso. Determining the value of a corporate reuse program. In Proceedings of the IEEE Computer Society International Software Metrics Symposium, pages 21–22, 1993.  T. Ravichandran and Marcus A. Rothenberger. Software reuse strategies and component markets. Commun. ACM, 46:109–114, August 2003.  Colin. Robson. Real world research : a resource for social scientists and practitioner-researchers / Colin Robson. Blackwell, Oxford, UK ; Cambridge, Mass., USA :, 1993.  Jasmine K. S and Dr. R. Vasantha. Cost estimation model for reuse based software products, 2008.  S. Samadi, N. Almaeh, R. Wolfe, S. Olding, and D. Isaac. Strategies for enabling software reuse within the earth science community. In Geoscience and Remote Sensing Symposium, 2004. IGARSS ’04. Proceedings. 2004 IEEE International, volume 3, pages 2196 –2199 vol.3, 2004.  M.Z.H. Sarker and S. Rahman. Exploring cross language independency in .net framework. In 9th International Multitopic Conference, IEEE INMIC 2005, pages 1 –5, 2005. References 85  R.W. Selby. Enabling reuse-based software development of large-scale systems. Software Engineering, IEEE Transactions on, 31(6):495 – 510, 2005.  Glassfish Application Server. appsrvr/index.jsp/.  SoftwareEngineering. se-defs.html/. http://sun.com/software/products/ http://www.idi.ntnu.no/grupper/su/publ/ese/  Ian Sommerville. Software engineering (5th ed.). Addison Wesley Longman Publishing Co., Inc., Redwood City, CA, USA, 1995.  Thomas A. Standish. An essay on software reuse. IEEE Trans. Software Eng., 10(5):494–497, 1984.  Amir Tomer, Leah Goldin, Tsvi Kuflik, Esther Kimchi, and Stephen R. Schach. Evaluating software reuse alternatives: A model and its application to an industrial case study. IEEE Trans. Softw. Eng., 30:601–612, September 2004.  David M. Weiss. Architecture of product lines. Software Maintenance, IEEE International Conference on, 0:6, 2009.  Kevin D. Wentzel. Software reuse - facts and myths. In Proceedings of the 16th international conference on Software engineering, ICSE ’94, pages 267–268, Los Alamitos, CA, USA, 1994. IEEE Computer Society Press.  K. P. Yglesias. Ibm’s reuse programs: Knowledge management and software reuse. In Proceedings of the 5th International Conference on Software Reuse, ICSR ’98, pages 156–, Washington, DC, USA, 1998. IEEE Computer Society.
* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project