A Systematic Mapping Study on Software Reuse831637/FULLTEXT01.pdfFirst and foremost, we owe a lot to...

Master Thesis Software Engineering Thesis no: MSE-2010:07 April 2010

School of Computing Blekinge Institute of Technology Box 520 SE – 372 25 Ronneby Sweden

A Systematic Mapping Study on Software Reuse

Bhargava Mithra Konda and Kranthi Kiran Mandava

ii

This thesis is submitted to the School of Engineering 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(s): Bhargava Mithra Konda Address: Rum 10, Folkparksvägen 16, 372 40, Ronneby, Sweden E-mail: [email protected] Kranthi Kiran Mandava Address: Rum 10, Folkparksvägen 16, 372 40, Ronneby, Sweden E-mail: [email protected]

University advisor(s): Dr. Mikael Svahnberg Department of System and Software Engineering, Blekinge Institute of Technology

School of Engineering Blekinge Institute of Technology Box 520 SE – 372 25 Ronneby Sweden

Internet : www.bth.se/tek Phone : +46 457 38 50 00 Fax : + 46 457 271 25

ABSTRACT

Context: Software reuse is considered as the key to a successful software development because of its potential to reduce the time to market, increase quality and reduce costs. This increase in demand made the software organizations to envision the use of software reusable assets which can also help in solving recurring problems. Till now, software reuse is confined to reuse of source code in the name of code scavenging. Now a day, software organizations are extending the concepts of software reuse to other life cycle objects as they realized that reuse of source code alone does not save money. The academia has put forward some assets as reusable and presented methods or approaches for reusing them. Also, for a successful software reuse the organizations should assess the value of reuse and keep track on their reuse programs. The other area which is vital for software reuse is the maintenance. Maintenance of reusable software has direct impact on the cost of the software. In this regard, academia has presented a number of techniques, methods, metrics and models for assessing the value of reuse and for maintaining the reusable software. Objectives: In our thesis, we investigate on the reusable assets and the methods/ approaches that are put forward by the academia for reusing those assets. Also a systematic mapping study is performed to investigate what techniques, methods, models and metrics for assessing the value of reuse and for maintaining the reused software are proposed and we also investigate their validation status as well. Methods: The databases like IEEE Xplore, ACM digital library, Inspec, Springer and Google scholar were used to search for the relevant studies for our systematic mapping study. We followed basic inclusion criteria along with detailed inclusion/exclusion criteria for selecting the appropriate article. Results: Through our systematic mapping study, we could summarize the list of 14 reusable assets along with the approaches/methods for reusing them. Taxonomy for assessing the value of reuse and taxonomy for maintaining the reusable software are presented. We also presented the methods/metrics/models/techniques for measuring reuse to assess its value and for maintaining the reusable software along with their validation status and areas in focus.

Conclusion: We conclude that, there is a need for defining a standard set of reusable assets that are commonly accepted by the researchers in the field of software reuse. Most metrics/models/methods/approaches presented for assessing the value of reuse and for maintaining the reuse software are academically validated. Efforts have to be put on industrially validating them using the real data.

Keywords: Software, Reuse, Reusable Assets, Value, Measuring, Maintenance, systematic mapping study, Metrics, Models, Methods, Approaches.

ii

ACKNOWLEDGEMENT�

First and foremost, we owe a lot to Lord Shiridi Sai Baba and Durga Devi Talli for his blessings. We are greatly indebted to Dr. Mikael Svahnberg for his advices, guidance and support. We thank him for allocating some of his valuable time for meetings, apart from his busy schedule. These meetings guided us in all walks during this thesis period and also in building confidence, without which we wouldn’t had made it this far.

We thank our parents for their effort in sending us to attain quality education and also we thank them for their affection and moral support towards us. We would like to thank Mrs. Eva Norling for her advices in designing the search terms. We are thankful to the librarians, whose support in providing the literature helped us a lot throughout our thesis. Last but not the least, we are grateful to our friends especially Vinod, for their moral support where and when needed and for sharing everlasting memories during our stay in Sweden.

iii

Table of Contents

1 INTRODUCTION ..................................................................................................................... 1

1.1 SOFTWARE REUSE .............................................................................................................. 1 1.2 AIMS AND OBJECTIVES ....................................................................................................... 2 1.3 RESEARCH QUESTIONS ....................................................................................................... 2 1.4 THESIS STRUCTURE ............................................................................................................ 3 1.5 BACKGROUND AND RELATED WORK ................................................................................. 3 1.6 RESEARCH METHODOLOGY .............................................................................................. 5 1.6.1 Search Strategy ........................................................................................................... 5 1.6.2 Search Process Execution ........................................................................................... 7

1.6.2.1 Search Term identification and Search Questions framing process ............................................................................................................................. 7 1.6.2.2 Basic Inclusion Criteria ...................................................................................... 8 1.6.2.3 Detailed Inclusion/ Exclusion Criteria .............................................................. 8 1.6.2.4 Snowball sampling ............................................................................................... 9 1.6.2.5 The Analysis ......................................................................................................... 9 1.6.3 Validity Threats .......................................................................................................... 9

2 REUSABLE ASSETS .......................................................................................................... ...11

2.1 METHODOLOGY EXECUTION ........................................................................................... 11 2.2 RESULTS ............................................................................................................................ 13 2.2.1 Reusable Assets ......................................................................................................... 13 2.2.2 Bubble Graph ............................................................................................................ 16 2.2.3 Results ........................................................................................................................ 17

2.3 ANALYSIS ........................................................................................................................... 18 2.3.1 State of Validation..................................................................................................... 19 2.3.1.1 Overall Validation Status .................................................................................. 19 2.3.1.2 Validation Status for Each Asset ...................................................................... 19 2.3.2 Assets in Focus .......................................................................................................... 20

3 VALUE OF REUSE ............................................................................................................... 21

3.1 METHODOLOGY EXECUTION ........................................................................................... 21 3.2 RESULTS ............................................................................................................................ 22 3.2.1 Taxonomy ................................................................................................................. 22 3.2.2 Bubble Graph ............................................................................................................ 25 3.2.3 Results ........................................................................................................................ 26

3.3 ANALYSIS ........................................................................................................................... 29 3.3.1 State of Validation..................................................................................................... 29 3.3.1.1 Overall Validation Status .................................................................................. 29 3.3.1.2 Validation Status for Each Category ................................................................ 31 3.3.2 AREAS IN FOCUS ....................................................................................................... 33 3.3.3 REPRESENTATION METHODS ................................................................................... 34

4 MAINTENANCE OF REUSABLE SOFTWARE .............................................................. 36

4.1 METHODOLOGY EXECUTION ........................................................................................... 37 4.2 RESULTS ............................................................................................................................ 39 4.2.1 Maintenance Taxonomy .......................................................................................... 39 4.2.2 Bubble Graph ............................................................................................................ 40 4.2.3 Results ........................................................................................................................ 41

iv

4.3 ANALYSIS ........................................................................................................................... 44 4.3.1 State of Validation..................................................................................................... 45 4.3.1.1 Overall Validation Status .................................................................................. 45 4.3.1.2 Validation Status for Each Category ................................................................ 45 4.3.2 Areas in Focus .......................................................................................................... 47 4.3.3 Validity Threats ....................................................................................................... 48

5 CONCLUSION ....................................................................................................................... 49

6 REFERENCES ........................................................................................................................ 51

7 Appendix .................................................................................................................................. 66

v

List of Tables

Table 1: Population, Intervention, Context, Outcome for each Research Question ..... 8 Table 2: Basic Inclusion Criteria ....................................................................................... 8 Table 3: Detailed Inclusion/ Exclusion Criteria ............................................................... 9 Table 4: Search Terms and Search Questions for Reusable Assets ............................. 12 Table 5: Hits after each phase for RQ1............................................................................ 13 Table 6: Reusable Assets Table ....................................................................................... 13 Table 7: Search Terms and Search Questions for Value of Reuse ................................ 21 Table 8: Hits after each phase for RQ2............................................................................ 21 Table 9: Contribution Table for Value of reuse ............................................................. 26 Table 10: Search Terms and Search Questions for Maintenance ................................ 37 Table 11: Hits after each criterion for RQ3 .................................................................... 38 Table 12. Contribution Table for Maintenance ............................................................. 41 Table 13: Abbreviations used in Tables and Figures ..................................................... 66 Table 14: Result Table for Algorithms Reuse ................................................................ 68 Table 15: Result Table for Architecture Reuse .............................................................. 68 Table 16: Result Table for Data Reuse ........................................................................... 69 Table 17: Result Table for Design Reuse ........................................................................ 69 Table 18: Result Table for Documentation Reuse ......................................................... 70 Table 19: Result Table for Estimates Reuse ................................................................... 71 Table 20: Result Table for Human Interface Reuse ...................................................... 71 Table 21: Result Table for Knowledge Reuse ................................................................ 71 Table 22: Result Table for Model Reuse ......................................................................... 72 Table 23: Result Table for Modules Reuse ..................................................................... 72 Table 24: Result Table for Plans Reuse .......................................................................... 73 Table 25: Result Table for Requirements Reuse ............................................................ 73 Table 26: Result Table for Service Contract Reuse ....................................................... 75 Table 27: Result Table for Test Case/ Test Plan Reuse ................................................. 75 Table 28: Result Table for Cost Benefit Analysis .......................................................... 76 Table 29: Result Table for Maturity Assessment Models ............................................. 77 Table 30: Reuse Table for Amount of Reuse Metrics .................................................... 77 Table 31: Reuse Table for Failure Modes Model ........................................................... 78 Table 32: Result Table for Reusability Assessment ....................................................... 79 Table 33: Result Table for Reuse Library Metrics ........................................................ 79 Table 34: Result Table for Strategies .............................................................................. 80 Table 35: Result Table for Change Impact Analysis ..................................................... 80 Table 36: Result Table for Software Configuration Management ............................... 82 Table 37: Result Table for Module Dependencies ......................................................... 83 Table 38: Result Table for Legal Issues .......................................................................... 84 Table 39: Result Table for Aging Symptoms .................................................................. 84 Table 40: Reference List for Chapter 2, 3 and 4 ............................................................ 85

vi

List of Figures

Figure 1: Search Strategy .................................................................................................... 6 Figure 2: Detailed Analysis through Bubble Graph ........................................................ 16 Figure 3: Validation Status (Reusable Assets) .................................................................. 19 Figure 4: Assets in Focus (Reusable Assets) .................................................................... 20 Figure 5: Reuse Metrics and Models Taxonomy .............................................................. 23 Figure 6: Systematic Mapping for Value of Reuse ........................................................... 25 Figure 7: Validation status (Value of Reuse) ................................................................... 31 Figure 8: Percentage of Academic, Industrial and Survey Validations .......................... 33 Figure 9: Areas in Focus (Value of Reuse) ...................................................................... 34 Figure 10: Taxonomy of Maintenance ............................................................................. 40 Figure 11: Systematic Mapping for Maintenance ............................................................ 40 Figure 12: Validation Status (Maintenance of Reuse) ..................................................... 45 Figure 13: Percentage of Academic, Industrial and Survey Validations ........................ 47 Figure 14: Areas in Focus (Maintenance of Reuse) ........................................................ 47

1

1 INTRODUCTION This section deals with the introduction to our thesis along with our aim and

objectives, research questions, thesis structure and research methodology.

1.1 Software Reuse Software reuse is the process of creating a new system from that of existing system rather than creating the new one from the scratch. In other words, it is the reusing of existing software artifacts or software assets to build a new system. The concept of software reuse has been introduced to overcome the software crisis i.e., the problem of building large and reliable software system in a cost effective and controlled way by McIlroy in 1968 [177]. Initially, software reuse was limited to source code. Due to the increase in customer needs and market demand for sophisticated software, the software companies started thinking beyond source code. This leads to the reuse of other life cycle assets. By reusing the other life cycle assets like design, algorithms, knowledge etc, new software can be brought in to the market faster. Software reuse helps in not only reducing the time but also reduces the cost [34] [177].

Though research is going on in the field of software reuse, the software industry is still in its initial stages. Many sources said that the research in the field of software reuse was started in 1968 [177] [96] [121], since then many questions arose which were left unanswered. Some of them are:

1) Are there any standard set of reusable assets defined?

2) Is there a standard taxonomy defined for assessing the value of reuse?

3) Is there a standard taxonomy defined for maintaining of reusable software?

Through our research, we would proceed further to find an answer to the above questions. Source code is most commonly reused and thus many had the misconception that software reuse is the reuse of source code alone [36]. Frakes[176] mentions that little is known about the reuse of assets other than coding. But Reuse of source code cannot alone save money. Some studies have shown that though 50% of the code was reused the cost savings on the software product was much smaller. This motivated us to find the other reusable assets apart from coding [92]. So for successful software reuse and getting more benefit through software reuse, the industries are looking forward to extend the concept of reuse to the assets other than coding, which are reusable. Researchers like R. J. Leach [23], Swanson [68], Bollinger [81] and Jones [21] presented some reusable assets along with code, but the list of reusable assets they presented do not exactly match with each other. There are some assets that were mentioned commonly by them but there is no common understanding between the researchers on a standard set of reusable assets. Assessing the value of reuse is a major concern in the software industry. For assessing its value, reuse should be measured by using the metrics and models. Measuring reuse will help the organization to know their progress in software reuse, to know how much amount of reuse is done or to assess the cost benefits of software reuse etc. For this, W. B. Frakes in 1996 has done a review on some of the existing important models or metrics or methods. However, there are no widely accepted models and the organizations are still unsure of getting success by using those models which are predicted [89]. It is observed that the researchers have just started to realize the importance of extending the concept of reuse to other life cycle objects beyond coding but very few authors have worked on assessing the value of reuse in them, most of the authors dealt with the assessing the value of reuse in a code. The metrics or models which are designed for assessing the value of reuse

2

in other life cycle objects are inspired from those designed for coding. For example: For assessing the amount of reuse metrics, W. B. Frakes [22] had derived a formula for assessing the amount of reuse in whole life cycle which is inspired by the formula for coding.

The other issue concerning to software reuse is the maintenance. Maintenance of reusable software is the most expensive part of the software life cycle. Software maintenance involves modification of a software component after it has been handed over to the client. The changes are made to the software to ensure error corrections, performance or other improvements, functionality up-gradations, or adaptations to changed environments. There have been situations where more than 50% of the budget is spent on the maintenance of the software. Maintenance is treated as reuse-oriented task. The life cycle assets like requirements, design, documentation etc, from the earlier versions of the system must be revisited for maintaining the software reuse which in turn makes it easy for the maintenance programmers to understand the problem [36].

Most of the research works proposed models or methods for assessing the value of reuse and for maintaining the reusable software. However, there are no widely accepted methods or models. The organizations are still unsure of getting success by using those models [89]. Literature that published the experiences of industry or success stories of industry in using a particular model is scarce. By seeing this, we assume that industries are not fully confident in getting success by reusing software [113].

The aim of our research is to investigate the status of the research performed since 1968 on the assets other than source code, that are mentioned in the literature as reusable. Also, to investigate on software reuse particularly in assessing the value of reuse and maintaining the reusable software through our systematic mapping study and to investigate the trends and developments in this field of research particularly in assessing the value of reuse and maintaining the reused assets. Also, we aim to study if there is any effort put by the industry in validating the proposed models till first half of 2009.

Our research report will help the industry to know exactly which assets can be reusable along with coding as we come out with a set of reusable assets that we have found through our review and to know what are the metrics and models for measuring reuse to assess its value and what are the methods for maintaining the reusable software. Our report will also help them to know which models are industrially validated up to now so that they can feel confident in using those industrially validated models. It also encourages the industry and researchers to further validate the non validated models either academically or industrially, so that they can be useful for the industry to use them.

1.2 Aims and Objectives The aim of this research is to do a systematic mapping study to find out reusable assets other than coding that are mentioned in the literature, models or metrics that are used for assessing the value of reuse, methods/models/metrics/approaches/tools for maintaining the reusable software and to report the results and analysis of our review.

This aim will be fulfilled by the following objectives:

• To identify the assets other than coding that are mentioned in the literature as reusable.

• To identify the methods or approaches for reusing these assets.

• To identify the metrics and models used for assessing the value of reuse.

• To identify the methods for maintaining reusable software.

1.3 Research Questions RQ1. What are the assets other than coding have been mentioned in the literature as reusable?

- RQ1.1. What are the methods or approaches for reusing these assets?

3

- RQ1.2. What is their validation status? - RQ1.3. What are the assets in focus?

RQ2. What are the metrics and models that have been proposed for measuring reuse to assess its value?

-RQ2.1. What is the validation status? -RQ2.2. What are the areas in focus?

RQ3. What approaches have been proposed for maintaining the reusable software?

-RQ3.1. What is their validation status? -RQ3.2. What are the areas in focus?

1.4 Thesis structure Chapter 1: In this chapter, we start with introduction to our report and present our aims objectives and research questions. In section 1.5, we discuss the background and related work. Section 1.6, deals with the research methodology in which we discuss in detail about our search strategy and give a clear picture of design and execution of our systematic mapping study. In section 1.6.3, we present the validity threats.

Chapter 2: This chapter deals with answering the research question RQ1. In section 2.1, we present the methodology execution along with the search terms and search combinations we used in finding the relevant studies and present the names of the databases used along with the studies obtained for each criteria. In Section 2.2, we present the results of our systematic review in which we present the reusable assets along with their definitions. In Section 2.3, we present the analysis of our review for RQ1 and RQ1.1.

Chapter 3: This chapter deals with research question RQ2. In section 3.1, we present the methodology execution along with search terms and search combinations we used in finding the relevant studies and present the names of the databases used along with studies obtained for each criteria. In Section 3.2, we present the results of systematic mapping study in which, we present the taxonomy of Reuse metric and models for assessing the value of reuse. In Section 3.3, we present the analysis of our review for RQ 2.

Chapter 4: This chapter deals with research question RQ3. In section 4.1, we present the methodology execution along with search terms and search combinations we used in finding the relevant studies and present the names of the databases used along with the studies obtained for each criteria. In Section 4.2, we present the results of our review in which, we present the maintenance of software reuse taxonomy. In Section 4.3, we present the analysis of our review for RQ 3.

Chapter 5: In this chapter, we present the conclusion of our report along with future work and recommendations for the future research work.

Chapter 6: In this chapter, we present the references used in our research.

Chapter 7: This chapter is an appendix which contains the definitions to the abbreviations that were used in the figures and tables of different chapters. Section A2, Section A3, Section A4 contains the results of our systematic mapping study (for answering RQ1, RQ1.1, RQ2 and RQ3) in the form of tables.

1.5 Background and Related Work In the earlier days of software development, the software used to be built from the scratch. In this rapidly changing world, user needs and expectations are never constant and changes time to time and users expect new versions as fast as possible. The organizations have focused on finding new ways to bring out the products to its customers as fast as they can, within shorter time and with reduced cost, which meets the user expectations. Product success is affected by

4

many success parameters like time to market, product cost, delivering optimal quality, level of effort, engineering overhead etc [181, 182]. The need for faster development of software and for introducing a successful product into the market led to the concept of reuse of software assets from the existing systems. Software reuse is not a new topic to discuss. The idea of Software reuse was first introduced by McIlroy in 1968 [177] and its role is predominant in software development. D. L. Parnas [187] in 1972 was the first to use the word "Modularization". He put his efforts in the field of modular programming in which the system is decomposed in to smaller modules. By this, smaller code modules can be developed. These modules can be used for reassembling or can be replaced by the other existing module. Most famous researchers like McIlroy [177], D. L. Parnas [187] etc thought that software reuse is nothing other than code reuse.

There are many definitions for software reuse by many researchers. We would like to quote Krueger's general view definition of software reuse. "Software reuse is the process of creating software systems from existing software rather than building software systems from scratch” [34, 179]. Now a day, most of the software companies are tending towards software reuse. Since, with software reuse we can minimize redundant work, produce high quality, reduce development cost, release the product in time, minimize maintenance and training cost, reduce team size, share expertise (code) and reduce documentation [179].

Reuse of software involves use of already existing assets from the previous versions of the software, finding the appropriate ones that are needed at present for reuse and integrating them with the currently new ones [60]. Many people assume that reuse of software means reuse of code (code scavenging) alone. But, there are several other assets which can be considered apart from code, such as requirements, design, test cases, test plans, architectural framework, look and feel of the applications, knowledge generated, reasoning, templates for any asset and so on [37, 58, 19, 50].

Though research is going on in the field of software reuse, the software industry is still in its initial stages of software reuse. By seeing this we assume that they are not fully confident in getting success by reusing software [113].

Regarding the assets many authors have only just dealt with code reuse. But for successful software reuse and getting more benefit through software the industries are looking forward to extend the concept of reuse to the assets other than coding, which are reusable. But some authors like Leach [23] and Jones [21] tried to present some reusable assets along with code, but the list of reusable assets they presented do not exactly match with each other. There are some assets that were mentioned commonly by both but there does no common understand between the researchers on a standard set of reusable assets.

Measuring or assessing the value of reuse is a major concern among the organizations and there are works predicting models or methods. However, there are no widely accepted models and the organizations are still unsure of getting success by using those models which are predicted [89]. W.B Frakes [22] in 1996 has done a review on some of the existing important models or metrics or methods. Clearly, it is observed that the researchers have just started to realize the importance of extending the concept of reuse to other life cycle objects beyond coding but very few authors have worked on assessing the value of reuse in them, most of the authors dealt with the assessing the value of reuse in a code. The metrics or models which are designed for assessing the value of reuse in other life cycle objects are inspired from those designed for coding. For example: For assessing the amount of reuse metrics, W.B Frakes [22] had derived a formula for assessing the amount of reuse in whole life cycle which is inspired by the formula for coding. Literatures that published the experiences of industry or success stories of industry in using a particular model are scarce [113,179].

Maintenance of reusable software is another area of concern. Maintenance of reusable software is an expensive task. There are many factors which has impact on the maintenance of reusable software. These factors include coupling and cohesion, software configuration management, change impacts, aging of a legacy system, licensing, contractual and negotiation

5

issues. Approaches/ models/ methods have been proposed by academia for each factor. But, there are no standard maintenance models which could solve the problems related to the complete set of above mentioned factors. Moreover, there are no widely accepted models.

Related Work Authors like Jones [21], Frakes [22], Leach [23] and Bollinger [81] have presented their own list of reusable assets. They have some reusable assets in common. But, it can be clearly understood that no author have actually tried to present a set of reusable assets that can be accepted by most of the researchers in the software reuse community. The above mentioned authors have actually tried to mention the assets but it seems that there is no common agreement between them regarding reusable assets. Each author presented his own list of reusable assets. The list proposed by one author differs with the list proposed by the other. Regarding metrics and models for measuring reuse to assess its value Frakes [22] in 1996 has done a major work in bringing different reuse metrics and models together and categorizing them based on their application to different areas of software reuse. His taxonomy of reuse metrics and models was an inspiration to later works in this field. Mohagheghi [79] in 2007 reviewed the journals between 1994 and 2005 to gather the evidences of successful software reuse programs in industry. This work helped us to know the validation status (industrial validation) of the studies in the past before 2007. In our report, we also tried to trace out the industrially validated studies along with academically validated till the first half of mid 2009. Curry et al. [94] had done a review study on amount of reuse metrics and Frakes [95], Mascena [112, 113] have done study regarding amount of reuse metrics. In these studies, we found few additional subcategories in the amount of reuse metrics along with those mentioned by Frakes [22]. These subcategories are added to the taxonomy of reuse metrics and models in our review report. In 2005, Frakes [107] presented a paper on present status and future of software reuse. This paper gives us an idea on present status of research in the field of reuse metrics and models. Victor Basili [120] in 1990 was the first person to discuss reuse in terms of maintenance and development. Few researchers like Kwon [121] proposed integrated approaches which are a combination of software reuse, maintenance and SCM for the maintenance of reusable software. Michael Jiang et al. [125] proposed integrated approaches which are combination of data mining, defect tracking system and SCM for the maintenance of reusable software. Reddy [197] in 1996 started his research in the field of maintenance of software reuse and introduced another type of maintenance called Reconstructive maintenance. None of the research works found so far has defined taxonomy for the maintenance of software reuse. Moreover, the research works discussed maintenance of reusable software in terms of their individual topic areas like software configuration management, change impact analysis, module dependencies, legal issues and aging symptoms. Every topic area plays a vital role in maintaining reusable software. So, we would be presenting these topic areas under taxonomy. We categorized each topic area and also introduced a category named strategies which deals with the integrated approaches [121] [125] and approaches for reuse as whole like full reuse maintenance model [124] and simple reuse model [120].

1.6 Research Methodology In this report, we followed Kitchenham’s guidelines for performing a systematic mapping study [180, 183]. A systematic mapping study is a precursor to a systematic literature review. It is another type of review which complements systematic literature review. It is also known as scoping study. A systematic mapping study is used to identify the extent and form of the literature on a particular topic. A systematic mapping study is suitable when we notice that there is very little evidence available or when the topic area is too broad during the initial examination of the domain before a systematic review is executed [183]. A systematic mapping study helps in identifying the evidence that is available for a particular topic and can be represented at high level of granularity. The results obtained through mapping study would help in identifying the evidence clusters and evidence deserts which would

6

suggest which areas are to be more focused by the future systematic reviews and the areas where there is a need to conduct more primary studies [183].

The systematic mapping study consists of finding an answer to the research questions. This involves analyzing, identifying, evaluating and interpreting all research works that are relevant to a particular research question, or topic area, or phenomenon of interest. Most important of all and which is applicable for our work is to identify and summarize the extent of current technology or treatment till date and identifying the gaps in current research work in order to throw light on what has to be done as future work. The search strategy followed in finding the relevant studies is discussed in section 1.6.1, Search Strategy. The methodology discussed in this section is being followed in the chapter 2, chapter 3 and chapter 4.

1.6.1 Search Strategy The search strategy which is being followed in our systematic mapping study is presented in figure 1. The search strategy consists of four phases:

Phase 1: First phase consists of executing the search both electronically and by citation search. This phase involves identification of search terms and search questions. This search results are documented and are maintained including the selected and rejected documents which makes the search process easy. The search terms and search questions are framed based on the research questions, the topic area and the phenomenon as a whole.

Phase 2: This phase involves the execution of inclusion and exclusion criteria which are explained in sections.

Phase 3: Apart from the first two phases, the third phase is slightly different. In the third phase, we slightly deviated from the Kitchenham's guidelines and conducted snowball sampling. This is discussed in more detail in section 1.6.2.5.

Phase 4: This phase consists of the analysis of the studies obtained from the three phases.

A central database is used for the storing and retrieval of the studies for each phase.

Figure 1: Search Strategy

7

Initially, we found 191343 studies after the citation and electronic search. In order to refine these hits, we applied basic inclusion criteria and detailed inclusion/ exclusion criteria. On applying basic inclusion criteria, we found 2299 studies. We eliminated the duplicates in the basic inclusion criteria itself. We further executed the detailed inclusion and exclusion criteria which resulted in 165 full text studies. We performed snowball sampling based on the obtained full texts which in turn resulted in 42 studies. Finally, a total of 207 studies where found for our research work. (Note: The total number of studies mentioned here is the final figure after removing the 6 duplicates (duplicates means some references/studies falls into more than one category or chapter)). A list of references for each chapter is given in table 40 in appendix.

We presented a table in each chapter in order show the number of studies found initially, number of studies found after the basic inclusion criteria, number of studies found after the detailed inclusion/ exclusion criteria and studies found through snowball sampling respectively for each database. Databases used: The databases used during the systematic mapping study are:

1. IEEE Xplore

2. Inspec + Compendex

3. ACM Digital

4. Elsevier

5. Springer

These are the five major databases we used. We used Google scholar for performing the citation search which is discussed in section 1.6.1. Through this, we could find

• The articles which cites an article,

• The article having particular keywords since a particular year

• The articles which are similar to the current article.

We also used Google scholar for our snowball sampling which is discussed in section 1.6.2.4. Some of the research works found during snowball sampling are from the Citeseer database.

1.6.2 Search Process Execution Search process execution consists of identifying the search terms and search questions and defining the inclusion/ exclusion criteria’s. 1.6.2.1 Search Term identification and Search Questions framing process The search terms are derived by considering the population, intervention, outcome, context and comparison. The population in this study represents the domain of software reuse. The intervention represents the application of search techniques used for the analysis of the different types of assets, value of software reuse and the maintenance of software reuse. Comparison in our case is not applicable for the reason being that the three research questions are of three different topic areas in the same domain. However, comparison is performed within each research question.

8

Table 1: Population, Intervention, Context, Outcome for each Research Question

Other terms are obtained by identifying the alternative terms and synonyms to the major search terms. Some terms are obtained from the keywords which are mentioned in the research paper relevant to our topic. Search questions are framed by using the Boolean OR and AND. Some databases like Inspec, Compendex etc facilitate the use of truncation “*” and wildcards “?” in the keywords which can also be used to perform efficient search. For example: reus* instead of reuse, reusable, reusability and wom?n instead of woman or women.

1.6.2.2 Basic Inclusion Criteria

The inclusion and exclusion criteria’s are used for data extraction in obtaining the most appropriate studies which are necessary in answering the research questions. The basic inclusion criteria will help in initial refinement of the articles. In order to perform the basic inclusion criteria, we are considering three criteria. These three criteria will help us in deciding which articles are to be included. They are discussed in table 2.

Basic inclusion criteria

1. Include article if the title matches with the topic area. 2. Include article if the abstract matches with the topic area. 3. Include only non-redundant articles.

Table 2: Basic Inclusion Criteria

By applying the basic inclusion criteria, 191341 studies as shown in figure 1, were reduced to 2299 studies. The reason for this huge variation is due to the removal of duplicates in the basic inclusion itself. 1.6.2.3 Detailed inclusion/ exclusion criteria After the basic inclusion criteria, a detailed inclusion/ exclusion criteria is applied on the results obtained by the basic inclusion criteria. The detailed inclusion/ exclusion criteria are discussed in the table 3.

Population Intervention Context Outcome

RQ 1 Software Reuse Review of reusable assets Academia Reusable Assets

RQ 1.1 Software Reuse Methods for reusing assets Academia Methods

RQ 1.2 Software Reuse Validation status for assets Academia Graph representing the percentage of validation.

RQ 1.3 Software Reuse Assets in focus Academia Graph showing the research contribution for each asset per year

RQ 2 Software Reuse Assessing the value of reuse Academia Reuse metrics and models

RQ 2.1 Software Reuse Validation status for value of reuse

Academia Graph representing the percentage of validation.

RQ 2.2 Software Reuse Areas in focus for value of reuse

Academia Graph showing the research contribution for each value (Reuse metrics and models) category per year

RQ 3 Software Reuse Maintenance of software reuse

Academia Methods/Models/ Metrics/ Approach

RQ 3.1 Software Reuse Validation status for maintenance of reusable software

Academia Graph representing the percentage of validation.

RQ 3.2 Software Reuse Areas in focus for maintenance of reusable software

Academia Graph showing the research contribution for each maintenance category per year

9

Detailed inclusion/ exclusion criteria

Inclusion criteria

1. The article must be peer reviewed 2. The article must be available as full text 3. The article should relate to the software reuse 4. The article should be in the topic area of assets, value or maintenance in software reuse. 5. The article should be literature review, systematic review, systematic mapping study, case study, experiment or experience report, survey or a comparitative study. 6. The article should be included if it proposes a model, metrics, approach or method. 7. The article should be included if it deals with the extension to existing model. 8. The article should be included if it deals with the validation to existing model or the currently proposed model.

Exclusion criteria

1. Articles which do not follow inclusion criteria can be excluded. 2. Some articles mentions management as maintenance should also be excluded. Management of software reuse refers to naming, storage and retrieval of reusable assets which is not related to our report and hence, it has to be excluded. 3. Non-English articles should be excluded.

Table 3: Detailed Inclusion/ Exclusion Criteria

1.6.2.4 Snowball Sampling

Snowball sampling is an approach to study the hidden population. Hidden population refers to the research works which are not found when search process is executed. Snowball sampling is performed on the works of the researchers which fits our study requirements. In this approach, if we find a reference in an article, we will make use of that reference to find two more and so on. Kitchenham [183] suggests manual scanning of reference lists from relevant primary studies and appropriate article to find suitable articles. The other reason for choosing snowball sampling is that, this approach can also be applied to find the articles which use different terminologies. Though, many researchers presented the same idea, they made use of different terminology. We followed the same basic inclusion and detailed inclusion/exclusion criteria (mentioned in table 2 and table 3) for snowball search results.

1.6.2.5 The Analysis

The results obtained from the systematic mapping study are analyzed in order to answer the research questions. The analysis mainly focuses on the state of validation, areas in focus of the research work and shift in trends in the research.

1.6.3 Validity threats It is essential to know the validity of study results and how these threats impact the results of the research work. In this section, we will be discussing the threats noticed during the systematic mapping study. There are four types of validity threats:

1. Conclusion Validity

This type of validity relates to the statistical significance between the treatment and the outcome [205] [188]. These types of threats are commonly noticed during the search process execution. Wrong framing of search question formed by choosing inappropriate search terms leads to irrelevant study results. Usage of many appropriate search terms will help in filtering the irrelevant studies, but usage of one inappropriate search term may also result in many irrelevant studies. In order to avoid this, we framed the search terms and search questions under the supervision of the librarian. The conversation with the librarian helped us in framing

10

the basic search terms. By executing the basic search terms, we could derive few other search terms. Usage of inappropriate Boolean operators (like AND in place of OR and vice versa) would also result in many irrelevant studies. The execution of search strategy may result in some irrelevant studies due to bad framing of inclusion/ exclusion criteria. In order to avoid these irrelevant studies, we consulted experts like the librarian and a senior researcher during the framing of inclusion/ exclusion criteria. Some standard terms, when given as input for the search process leads to too many hits. In order to avoid this kind of threat, usage of quotes will help in finding the relevant studies. For example: When we use software AND configuration AND management instead of "software configuration management", the number of hits found in IEEEXplore would be around 2000. Number of hits with the quotes would be 140. Such type of threats can be avoided by making use of quotes.

2. Internal Validity

This type of validity relates to a casual relationship between treatment and the outcome [205] [188]. Creswell [206] states a general view definition as "Internal validity threats are experimental procedures, treatments or experiences of the participants that threaten the researcher’s ability to draw correct inferences from the data in an experiment". The inclusion of certain unpublished research works can introduce unwanted outcomes. Some of the literature works owned by organizations and research institutes are not available as full texts. This introduces a gap in the research work. Other reason is that, the native language of both the authors involved in this research work is not English. Therefore, the chances of interpreting the things in different perspectives may persist. In order to avoid this, cross checking the works of each other is necessary to ensure a common perspective. We noticed two types of review studies. Some studies deals with only reviews which provides suggestions or summary. The other type of review studies deals with reviewing the other researcher’s work followed by validating or non-validating that work. Usually, percentage of validated and non-validated studies should sum up to 100%. But, in this report, we included reviews also. So, percentage of validated and non-validated studies along with review will sum up to 100%. When we encounter a study which consists of a review and proposes a model which is either validated or non-validated, we would be marking them in the subsequent column in the result table. The threat noticed here is that when both the columns are marked, the overall percentage exceeds 100%. In order to avoid such threats, we introduced two columns namely “Extension to (E.T)” and “Validation Of”. Whenever there is a review followed of a model and its validation, the “Validation Of” column is marked instead of review. Whenever there is a review followed by an introduction to new model which is not validated, then “Extension To” column is marked instead of marking it in review column. Such threats occurred for two studies [122, 124]. Apart from that a study by Oh-Cheon Kwon [122] has a non-validated tool and a review which made the total percentage go beyond 100%. The threat still remained for such discussions.

3. External Validity

This type of validity relates to the generalization of results outside the scope or time span of the study [205] [188]. Creswell [206] provides a general view definition as "External validity arise when experimenter draw incorrect inferences from the sample data to other persons, other settings and past or future situations". For example, Cyril [207] proposed an approach for requirements in August 2009. Since, we have limited our time span till first half of 2009, we are not considering this study for our research work.

4. Construct Validity

This type of validity refers to the relationship between the theory and the application [205] [188]. This type of validity threat is noticed when relevant studies are excluded. In order to avoid these threats, we introduced an exhaustive search strategy in section 1.6. In this search strategy, we made use of four phases. These four phases will help in overcoming the construct validity threats.

11

2 REUSABLE ASSETS Reusable assets are considered as the building blocks for software reuse. The

reusable assets can be of a technical or managerial in nature, large grained or fine grained, simple or composite. The reusable assets can have varying degree of leverage. A leverage of a reusable asset happens when a reuse of one asset leads to the reuse of chain of assets in a downstream process. The reusable assets may consist of single asset or several assets in one asset (nested) [44] [63].

Ezran [44] [63] defines reusable asset as “Software assets are composed of a collection of related software work products that may be reused from one application to another”. The terms like components and work products are also used in place of reusable assets. Jacobson et al. [35] states that the assets and work products are also used in place of components.

We present the definitions of components and work products to distinguish between the three terms. A component is defined as “an executable asset that may be integrated as-is into an application” [44]. An asset is made from a set of related work products. And these work products represents a same piece of software at different abstraction levels. These work products can be used at every step of software life cycle [44].

When considering the reusable assets most works mentions about coding. But there are other assets that can be reusable. So, we aimed at searching for other reusable assets apart from coding that are mentioned in the literature. Through our Systematic mapping study, we found 14 assets that can be reusable. Here, we excluded the code intentionally as we are searching for the reusable assets that are other than coding. The other reusable assets are:

1. Algorithms 2. Architecture 3. Data 4. Designs 5. Documentation 6. Estimation Templates 7. Human Interfaces 8. Knowledge 9. Models 10. Modules 11. Plans 12. Requirements 13. Service Contracts 14. Test Cases

2.1 Methodology Execution The search terms and search combinations are formed in order to answer the research questions RQ1 and sub-researches question RQ1.1, RQ1.2 and RQ1.3.Very few authors contributed in the field of software reusable assets. Initially, the search process was carried out by using eight terms like 1, 4, 5, 6, 20, 21, 22, and 24 in table 4. Through these eight search terms, we could find the research works and books of few renowned researchers. Among them are Jones [21], Leach [23], Frakes [22] and Swanson [68] who presented lists of reusable assets. In order to gain more knowledge about each asset in their list, we used the asset names as search terms.

12

Search Terms:

1. Assets 2. Algorithms 3. Architecture 4. Artifacts 5. Aspects 6. Components 7. Data 8. Designs 9. Document 10. Estimates 11. HCI 12. Human Computer Interface 13. Human Interface 14. Knowledge 15. Lifecycle 16. Models 17. Modules 18. Plans 19. Requirements 20. Reusable 21. Reuse 22. Reused 23. Service contracts 24. Software 25. Test

Search Questions:

1. asset AND reuse OR reusable AND software 2. Lifecycle AND reuse AND software 3. software AND reusable AND aspects 4. software AND reusable AND artifacts 5. software AND reusable AND components 6. {Reusable OR reuse} AND Data 7. {Reusable OR reuse} AND Documentation 8. {Reusable OR reuse} AND Estimates(Templets) 9. {Reusable OR reuse} AND plans(project plans) 10. {Reusable OR reuse} AND {Test cases OR Test designs} 11. {Reusable OR reuse} AND Service contracts 12. {Reusable OR reuse} AND Algorithms 13. {Reusable OR reuse} AND Designs 14. {HCI} AND {software AND reus*} AND {asset OR artifact OR component} 15. Knowledge AND {software AND reus*} AND {asset OR artifact OR component} 16. Requirements AND {software AND reus*} AND {asset OR artifact OR component} 17. Architecture AND {software AND reus*} AND {asset OR artifact OR component} 18. Human Interface AND {software AND reus*} AND {asset OR artifact OR component} 19. Human computer Interface AND {software AND reus*} AND {asset OR artifact OR component} 20. Models AND {software AND reus*} AND {asset OR artifact OR component} 21. Modules AND {software AND reus*} AND {asset OR artifact OR component}

Table 4: Search Terms and Search Questions for Reusable Assets

The articles are obtained by executing the basic inclusion criteria along with the detailed inclusion/ exclusion criteria. These criteria are discussed in section 1.6. The results or the number of hits obtained are tabulated in table 5.

13

Number of hits Basic inclusion criteria


Snowball Sampling

Google Scholar - - - 21

ACM 17761 24 13 -

Inspec 36673 108 12 -

IEEE 244 36 19 -

Elsevier 12469 42 5 -

Springer 68892 363 9 -

Total 136039 573 58 21

Table 5: Hits after Each Phase for RQ1

NOTE: A list of references for this Chapter 2 are shown in Table 40 in Appendix

2.2 Results In this section, the results found through our review are presented. We have plotted the results in a bubble graph. 2.2.1 Reusable Assets In Table 6, we present the list of assets that are found through the review. The table also includes the number of articles found for each asset along with the author name, year of publication and the reference number of the article. Reusable Asset Number of Articles Authors Reference

Number

Algorithms 1 [Karsten, 97] [25]

Architecture 11 [Krueger, 92] [34]

[Leach, 97] [23]

[Jacobson et al, 97] [35]

[Sametinger, 97] [36]

[Peter Eeles, 08] [37]

[Li. H et al, 92] [38]

[White et al, 98] [39]

[Baum et al, 98] [40]

[Gomaa, 95] [41]

[Griss et al, 99] [42]

[Clements et al, 01] [65]

Data 5 [Giuseppe, 94] [1]

[I Issenin, 04] [2]

[Jones, C, 93] [21]

[W Frakes, 96] [22]

[R. Leach, 97] [23]

14

Designs 10 [Kevin W. Jameson, 89] [26]

[V Upadhyay, 92] [29]

[G Arango, 93] [33]

[ Jones, 93] [21]

[S Komiya, 94] [30]

[Paul Kogut, 95] [28]

[W Frakes, 96] [22]

[S Channarukul, 05] [32]

[P Gomes, 06] [31]

[J E Ettlie, 08] [27]

Documentation

9

[J.Sametinger, 96] [3]

[Childs and Sametinger, 96] [4]

[David M. Levy, 93] [5]

[Aida Boukottaya et al, 06] [6]

[David Barta et al, 96] [7]

[E. Guerrieri, 98] [8]

[Jones C, 93] [21]

[W Frakes, 96] [22]

[R. Leach, 97] [23]

Estimation template 2 [ Jones, C. 93] [21]

[W Frakes 96] [22]

Human Interface

5 [Jones C, 1993] [21]

[Lozano-Tello et al, 02] [66]

[Frakes, W et al, 96] [22]

[Robert Bogue, 06] [67]

[Swanson, 89] [68]

Knowledge 7 [P. Gomes et al, 06] [58]

[Parsons et al, 04] [59]

[Kucza et al, 01] [60]

[Von Krogh et al, 05] [61]

[Liu Xue-Mei et al, 09] [62]

[Wai Fong Boh, 08] [31]

[Althoff et al, 99] [64]

[Hall, 87] [117]

[Yglesias, 93] [118]

[Soundarajan, 98] [119]

15

Models 1 [Larsen, 06] [71]

Modules 4 [Isoda, 92] [69]

[Frakes, W.B, et al, 94] [70]

[Leach, 97] [23]

[D. L. Parnas, 1972] [187]

Plans 7 [Bernhard Nebel, 94] [9]

[Subbarao Kambhampati,94] [10]

[Subbarao Kambhampati,90] [11]

[L Spalazzi, 01] [12]

[Jones, C. 93] [21]

[W Frakes, 96] [22]

[R.Leach, 97] [23]

Requirements 19 [Krueger, 92] [34]

[Leach, 97] [23]

[Jacobson et al, 97] [35]

[Sametinger, 97] [36]

[Monzon, A. 08] [43]

[Cyril Montaberta et al, 09] [207]

[Thais Ebling et al, 09] [45]

[Lam, W. 97] [46]

[Spanoudakis et al, 96] [47]

[C. Montabert et al, 05] [48]

[Erdvinas Perednikas 08] [49]

[B. Keepence et al, 95] [50]

[Lam, W et al, 97] [51]

[Antonellis et al, 93] [52]

[Johnson et al, 91] [53]

[Gotzhein et al, 98] [54]

[Lopez et al, 02] [55]

[Philippe Massonet et al, 97] [56]

[Moon et al, 05] [57]

Service Contracts 2 [Haibin Zhu, 05] [24]

[Lucas et al, 97] [202]

Test Cases/ Test Designs

10

[Mark Folkerts, 08] [13]

[David Binkley et al., 95] [14]

[A V Mayrhauser, 93] [15]

16

[Mikko Karinsalo et al., 04] [16]

[D D Lonngren, 98] [17]

[J D. McGregor, 02] [18]

[Yunwei Dong, 08] [19]

[J A Dallal, 08] [20]

[Jones, C. 93] [21]

[W Frakes, 96] [22]

Table 6: Reusable Assets Table

2.2.2 Bubble Graph In figure 2, we present a systematic mapping using a bubble graph. Bubble graph briefing is given below.

Figure 2: Detailed Analysis through Bubble Graph

17

The size of the bubble depends upon the number of studies in that bubble. The bubbles at the intersection of the axes contain reference numbers of the studies. The X-Axis is divided in to two halves i.e., the left and right halves. On the right half of the X-Axis in figure 2, we show the validation status of the studies and also indicate which type of validation; the study falls in to (like industrial case study, academic case study, academic experiment, industrial experiment, survey). On the left half of the X-Axis we present the studies which proposed a method, model or an approach for reusing a particular asset. The Y-Axis deals with the asset categories like Algorithms, Architecture, Data, Design, Documentation, Estimates, Human Interfaces, Knowledge, Models, Modules, Plans, Requirements, Service Contracts and Test Cases.

2.2.3 Results

Detailed tables of reusable assets obtained through our review are shown in appendix section A2. We briefly introduce each asset type: 1. Algorithms: Algorithmic reuse is the reuse of algorithms as a solution every time for the same type of problems that occur. Reusable algorithms are used in software designs [25].

2. Architecture: The architecture is an organizational structure of a system or component [154].

3. Data: Data reuse in a particular project makes it easier to achieve the continuous processes improvement or in improving the development process. Data in the sense, an experience that is recorded during the previous projects [1].

4. Design: The key to reusing design is to use the models to capture design knowledge and facilitate the early analysis of system properties [28].

5. Documentation: A document may contain important information of a project and can be reused for the similar projects or next version of the project. Generally new documents are designed which often share features of the old ones. This is all to reduce time and cost [4] [5] [7].

6. Estimation Template: For estimating the new project in order to forecaster what it takes to successfully complete it, reusing the estimation templates of the older projects is a better choice. It makes our estimation work easy. Regarding estimation templates, we could find only 2 studies that too they have only mentioned about it.

7. Human Interface: An interface enables information to be passed between a human user and hardware or software components of a computer system [154].

8. Knowledge: Knowledge generated during the software development process can be a valuable asset for a software company. But in order to take advantage of this knowledge, the company must store it for reuse. Knowledge can be obtained from all the phases of Software Development Life Cycle [86]. The knowledge may represent the experience, idea or reasoning [33] [117] [118] [119].

9. Models: A model can depict critical solutions and insights to a problem and hence it can be considered as an asset for an organization. A pattern which explains a recurring problem and solutions to those recurring problems can be expressed as a model. A model is a type of asset which may or may not implement a pattern specification [71].

10. Modules: Module is a file that contains instructions. "Module" implies a single executable file that is only a part of the application, such as a DLL [164].

11. Plans: Plans mean project plans. The parts of the old plans can be reused by the planner for the new versions.

12. Requirements: A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents [154].

18

13. Service Contracts: Service contract is an agreement between developers/designers and the user of the reusable asset. This is also called reuse contracts. The service contracts acts as an interface for the reusers of an asset. The service contract helps us in guiding how a software asset can be reused, how and why the asset is being reused. This information can be helpful in predicting where and how the system can be tested, what problems might occur and how to rectify the problem, after the system is evolved [202]. The service contracts should have the below properties [24]: (1) It should be concise and understandable (2) It should be clear and unambiguous (3) It should be concrete and easily evaluated to easily evaluate the quality of a service.

14. Test Case/ Test Design: Test cases that are developed for the previous versions can be reused for the next version and so on. They can be reused many times for different versions belonging to same family [13, 15, and 17].

Other Assets: Swanson in [68] mentioned few other assets apart from the above mentioned assets which includes user application components, system software, data resources, distributed processing components, network gateways, communication facilities, network management, application design/ development tools and end user computing facilities. Leech [23] mentioned few other assets like reconfiguration of flexible and reusable systems, negotiation with software vendors, classes and instances, transformation systems, filters, “glue ware”, negotiations with customers, interface specifications, inputs to application generators and inputs to very high level languages.

2.3 Analysis Source code is most commonly reused and thus many had the misconception that software reuse is the reuse of source code alone [36]. But the true cost of the system depends upon all the activities and assets during the software development lifecycle. Reuse of source code cannot alone save money. Some studies have shown that though 50% of the code was reused the cost savings on the software product was much smaller. This motivated us to find the other reusable assets apart from coding [92]. Through our review, we could find 14 reusable assets. These 14 reusable assets are shown in section 2.2.1.

1. Algorithms 2. Architecture 3. Data 4. Designs 5. Documentation 6. Estimates 7. Human Interfaces 8. Knowledge 9. Models 10. Modules 11. Plans 12. Requirements 13. Service Contracts 14. Test Cases

Through our analysis, we could find that the authors who mentioned or discussed about the reusable assets have only some reusable assets in common. That is each author presented his own set of reusable assets, but they don't exactly match with the set proposed by other authors. It can be clearly understood that, no author have actually tried to present a set of reusable assets that can be accepted by most of the researchers in the software reuse community. By doing a review, we tried to present a set of reusable assets in our report, which are mentioned by different authors.

19

2.3.1 State of Validation

We present a graph (in figure 3) to show the validation status of each reusable asset. In the graph, X-Axis represents the reusable assets and Y-Axis represents the percentage of validation (i.e., number of validated and non-validated studies and reviews as well). As the gathered studies also contain reviews which don’t come under validated or non-validated studies, they are presented in the graph along with the validated and non-validated studies. The validated and non-validated studies along with reviews will sum up to 100 percent.

AlgorithmsArchitecture

DataDesign

DocumentationEstimates

HCIKnowledge

ModelsModules

PlansRequirements

Service ContractsTest cases

0

20

40

60

80

100

120

Validated Non-ValidatedReview s

Reusable Assets

Percentag

e of Validation

Figure 3: Validation Status (Reusable Assets)

Overall validation status

• There are 3 types of studies found regarding this RQ1 and RQ1.1. Among these three types of studies, some studies just mentioned that a particular asset can be reusable, some studies have proposed a model or method or approach for reusing a particular asset and some studies are reviews of the previous studies.

• Excluding the review studies, when we observe the other two types of studies, the percentage of validated ones is very less and is about 27%.

• The percentage of non-validated studies reaches its height with about 68% of the total number of found studies and the remaining share is occupied by the reviews with about 5%

• Among the found validated studies about 55% are academically validated, 25% are industrially validated and 20% are validated through surveys.

• Figure 3 show that the industries are not keeping much effort on validation as we can observe that most of validated studies are only validated academically.

Validation status of studies for each reusable asset

From figure 3, more than half of the reusable assets are non-validated. A good contribution of the validated studies can be observed for knowledge (54%) with 3 industrial validations, 1 academic validation and 2 studies validated through surveys from the total of the 11 studies. The validation studies can also be noticed for plans (43%), documentation (33%), design (30%), requirements (21%) and test cases (20%) respectively. Some assets like algorithms, architecture, data, estimates, human interfaces, models, modules and service contracts are

20

discussed but not validated. And hence, the non-validated bar shows 100% for these reusable assets in figure 3. This shows that there is less contribution in terms of these reusable assets.

2.3.2 Assets in Focus In this section, we present a surface graph (in figure 4) which shows the assets in focus. Figure 4 shows the number of studies found per year.

19721973

19741975

19761977

19781979

19801981

19821983

19841985

19861987

19881989

19901991

19921993

19941995

19961997

19981999

20002001

20022003

20042005

20062007

20082009

0

2

4

6

8

10

12

14

16

Assets in Focus

Test casesService contractsRequirementsPlans

ModulesModelsKnow ledgeHuman InterfacesEstimates/ TemplatesDocumentationDesign

DataArchitectureAlgorithm

Years

Num

ber o

f Studies

Figure 4: Assets in Focus

From figure 4, we can notice that research contribution is more during the periods between 1991 and 1999. Research contribution focused on reusable assets like algorithms, architecture, data, designs, documentation, estimation templates, human interfaces, knowledge, modules, plans, requirements and test cases during this period. Much focus is put on requirements, documentation, and architecture when compared with other assets. From 2000 to 2009, the research contribution extended to other reusable assets like models and service contracts. Above all, a very less focus is put on algorithms, service contracts, models and estimation templates. From the figure, we can notice a fall in the research contributions during 2009. The reason for this is that, we have limited our search till the first half of 2009. And so, only few articles are found during the first half of 2009.

Problems:

1. The lack of tool support for indexing, searching, retrieval and browsing of reusable assets makes it difficult for reusing the software assets [203].

2. The basic problem faced by the software reuse community is that, though it can be extended to many related research areas, it is remaining as a closed group. This can be treated as a reason for not introducing a standard set of reusable assets till date [168].

3. Reusing the assets involve lot of capital to be invested on the domain engineering, building libraries of assets, organizing these assets and for training the engineers for systematically reusing these assets [63].

4. From the organizations perspective, most organizations deal with one project at a time. Reuse of assets comes in to picture when the organizations are dealing with series of projects [63].

21

3 VALUE OF REUSE In this section, we introduce reuse metrics and models for measuring reuse to assess

its value. Now a day, organizations are interested in implementing reuse program. As the “reuse” is growing in software industry, there is a growing need to assess the value of reuse by measuring it, which helps to know their success. According to Frakes [107], software reuse is based on science and engineering and so it must be treated as an empirical discipline. As the concepts like reuse and reusability emerged, a question arose on how to measure them in order to get success through reuse. For measuring reuse, reuse metrics and models have been defined for many areas of software reuse and categorized into 6 categories [22]. (A Metric is a quantifiable measurement of an attribute of a software product [107] [22]. A Model is a stated relationship among metric variables [107] [22]). The six categories are discussed in section 3.2.

3.1 Methodology Execution The search terms and search combinations are formed in order to answer the research questions RQ2, RQ2.1 and RQ2.2. In the table 7, search terms and search combinations are presented. Some search terms 1, 2, 3, 4, 5, 6, 14, 15 and 23 in table 7 were considered as initial search terms. After applying these search terms, we could find few studies and among them is a study by Frakes W B [22] in which he categorized the reuse metrics and models in to 6 categories. For discussing in details regarding these 6 categories mentioned by [22], we have again formed the search terms for each and every category as shown in table 7. For example: A category named Maturity Assessment is present in Frakes Taxonomy. In order to get detailed information regarding maturity assessment, we have used "Maturity" and "Assessment" as our search terms.

Search Terms

1. Software 2. Reuse 3. Amount 4. Cost 5. Benefit 6. Investment 7. Assessment 8. Maturity 9. Reusability 10. Failure 11. Modes 12. Models 13. Metrics 14. Measurement 15. Value 16. Library 17. Quality 18. Business 19. Level 20. Frequency 21. Ratio 22. Density 23. Economics 24. Reused

22

Search Questions 1. software AND reuse AND metrics AND measurement 2. Amount AND reuse 3. cost AND benefit AND analysis 4. Quality AND investment AND reuse AND{ software AND reuse AND metrics AND measurement} 5. return AND investment AND{software AND reuse AND metrics AND measurement} 6. business AND reuse AND metrics 7. reusability AND assessment 8. Maturity AND assessment AND reuse 9. Failure AND modes AND models 10. Reuse AND library AND metrics 11. reuse AND value 12. reuse AND level 13. reuse AND frequency 14. reuse AND ratio 15. reuse AND density

Table 7: Search Terms and Search Questions for Value of Reuse

The articles are obtained by executing the basic inclusion criteria along with the detailed inclusion/ exclusion criteria. These criteria are discussed in section 1.6. The number of hits obtained after each phase are tabulated in table 8.

Number of Hits Basic inclusion criteria


Snowball sampling

Google scholar - - - 9

ACM 10253 156 13 -

Inspec 2279 333 8 -

IEEE 30 30 15 -

Elsevier 428 86 5 -

Springer 12116 58 2 -

Total 25106 663 43 9

Table 8: Hits after Each Phase for RQ2


3.2 Results In this section, the results which were found through our review are presented.

3.2.1 Taxonomy We present taxonomy of reuse metrics and models in which different categories and sub-categories of reuse metrics/models/methods are presented. This taxonomy is based on the taxonomy defined by Frakes in [22]. Frakes [22] in his taxonomy does not show subcategories. But going deep into the report, we could find that some categories do have the subcategories. And to his taxonomy, we have added some other subcategories in cost benefit analysis models and amount of reuse metrics. These are not mentioned by Frakes [22]. But, we have gone through other studies of Jorge Mascena [113], Frakes [95] and Suri [111] in which they have mentioned the subcategories to amount of reuse metrics category along with those mentioned by Frakes [22].

23

Figure 5: Reuse Metrics and Models Taxonomy

The reuse metrics and models are divided into 6 categories as shown figure 5 [22, 107].

1. Cost Benefit Analysis Models

2. Maturity Assessment Models

3. Amount of Reuse Metrics

4. Failure Modes Model

5. Reusability Assessment

6. Reuse Library Metrics

The resultant tables for value of reuse obtained through our review are shown in Appendix section A3. Here we also consider the articles which deal with reuse metrics and models for reusable code.

1. Cost Benefits Analysis Models

Cost benefit analysis helps to know the cost benefits of implementing reuse. These models include economic cost benefit analysis, return on investment, quality of investment and productivity pay-offs. These models are for assisting the organization in estimating their cost, effort, and time which is involved in systematic reuse.

“The value of software reuse refers to whether it is more cost effective, in terms of time, money, or personnel, to reuse software as opposed to developing it from scratch each time it is needed ” Frakes [102].

This cost benefit analysis models category is subdivided into 4 types [22, 107]

1. Economic Cost Benefit Analysis: Economic Cost Benefit Analysis helps in assessing the costs of reusing a reusable component.

2. Return on Investment Analysis: It is one of several approaches to evaluating and comparing investments. It helps us to know the benefits. A good Return on Investment means that the investment returns compare favorably to investment costs. This analysis is crucial for reuse investments.

24

3. Quality of Investment: Quality of investment helps in making a good reuse investment.

4. Business Reuse Metrics: These metrics help in assessing or estimating the effort saved by reuse.


Maturity assessment is needed by an organization in assessing the degree of maturity of its reuse implementation process. Reuse maturity assessment models will help the organizations in estimating how advanced the reuse programs are in implementing systematic reuse [22]. This helps the organizations to know their progress in implementing reuse programs.


Amount of reuse metrics is used to estimate how much of reuse is done in a give life cycle object. According to [22], amount of reuse metrics are used to assessing and also monitoring the reuse improvement effort by tracking of the percentages of reuse for life cycle objects. The amount of reuse metrics is subdivided into six types:

1. Reuse level: Reuse level is the ratio of number of reused items to the total number of items [198,112] [186].

2. Reuse percent: Reuse percent is the ratio of number of reused lines of code to the total number of lines of code [115, 112] [186].

3. Reuse frequency: Reuse frequency is the ratio of number of references to the reused items to the total number of references [198,112]

4. Reuse ratio: Reuse ratio considers partially changed items as reused and is same as reuse percent [200,112].

5. Reuse density: Reuse density is the ratio of number of reused parts to the total number of lines of code [112, 201].

6. Reuse size and frequency: Reuse size and frequency is similar to reuse frequency and considers the size of items in number of lines of code (LOC) [200, 112].

4. Failure Modes Models

Failure modes analysis is used to identify and order the obstacles to reuse in an organization. Failure modes analysis gives us an approach for measuring the reuse process and improving it which is based on a model of the ways a reuse process fails [108, 22].


Reusability metrics indicate the possibility that an artifact is reusable or the readiness of an artifact or asset to be reusable. In this the attributes of a component which indicate its reusability are measured [22].


Reuse library metrics are used for managing and tracking the reuse repository usage. The Indexing schemes in the reuse library are evaluated by using these metrics. For evaluating the indexing schemes the reuse library metrics and their definitions are are [22]:

1. Indexing costs: Measuring the cost of creating, maintaining, updating a classification scheme.

2. Searching effectiveness: Assess how well the classification schemes help users to search effectively for reusable components.

25

3. Support for understanding: Measures how well a classification scheme helps the users to understand the components.

4. Efficiency: Measure the efficiency of reusable library in terms of memory, fastness etc.

In addition to this, Quality of the assets is also a measure for reuse library metrics which was derived by Frakes in 1987.

3.2.2 Bubble graph The size of the bubble depends upon the number of studies in that bubble. The bubbles at the intersection of the axes contain reference numbers of the studies. The X-Axis is divided in to two halves i.e., the left and right halves. On the right half of the X-Axis in figure 6, we show the validation status of the studies and also indicate which type of validation; the study falls in to (like industrial case study, academic case study, academic experiment, industrial experiment, survey). On the left half of the X-Axis we present the studies which proposed a method, model, metrics or an approach for measuring reuse to assess its value. The Y-axis has six reuse metrics and models categories (Cost benefit analysis models, Maturity assessment models, Amount of reuse metrics, Failure modes models, Reusability assessment, and Reuse library metrics).

Figure 6: Systematic Mapping for Value of Reuse (X-Axis: Study category; Y-Axis: Reuse metric categories)

26

3.2.3 Results Table 37 shows the categories and their subcategories along with studies and their contributions. In the "Contribution name (or) study name” column, we presented the contribution name only if the contribution is named by the author and if not we have presented the study name itself. In this column, the text in between the inverted comas is the study name and the text without inverted comas is the contribution name. The category and subcategories presented in the table 37 are based on the Frakes [22] taxonomy.

Note: Not all the studies, those belonging to this category are included because some of the studies like the review papers are not presented in this table. Only the studies with a contribution to particular category are presented. For further details regarding the review papers in each category see Appendix section A3 (result tables).

Category

Sub-category

Contribution Contribution name

or “Study title name”

Author name and

Reference number Cost benefit analysis models

Economic cost benefit analysis

Model Model for Economics of reuse Barnes, B et al [74] Model Cost of Development Model Gaffney, J E et al [72]

Validation of previous model

in [74]

"What price reusability? A case study"

Favor, J [73]

Validation of previous model

in [72]

"Software reuse economics: cost benefit analysis on a large

scale Ada project".

Margono, J et al [75]

Model Development phase model Malan, R et al [76] A study of existing

industrial case studies

”Quality, productivity and economic benefits of software reuse: a review of industrial

studies”

P Mohagheghi et al [79]

Model Cost estimation model Jasmine, K S et al [80] Return on Investment

Metric "A reuse metrics and return on investment model"

J S Poulin et al [115]

Formulae "Return on invest models" K El Emam [116] Quality of investment

Metric An analytical approach for making good reuse

investments

Barns, B H et al [81]

Business Reuse metrics

Metric "A reuse metrics and return on investment model"


Metric Metrics to estimate the effort saved by reuse (used by IBM)


Maturity assessment models

No subcategories

Model Koltun and Hudson reuse maturity model

Koltun, P et al [83]

Model STARS reuse maturity model Davis, M J [84] Model A reuse capability model Davis, T [85]

Validation of model in [85]

"Investments in reusable software, A study of software reuse investment success

factors"

Rine, D C et al [106]

Model "A phased reuse adoption model"

S Wartik et al [86]

Model Reuse reference model D C Rine et al [87] Model RiSE maturity model Almeida, E S et al [88]

27

Extension to a model

"Towards a maturity model for reuse incremental adoption" (Extension to RiSE Maturity

model)

Garcia, V C et al [89]

Amount of reuse metrics

Reuse level

Model Reuse level metrics Frakes, W B [109] Metric Reuse level metric Frakes, W B et al [198] Model Reuse level metrics Terry, C [110] Model "Modeling reuse across the

software life cycle" W B Frakes et al [91]

Method "Methods of measuring software reuse for the

prediction of maintenance effort"

Leach, R J [92]

Reuse level

Metric "Software reuse: metrics and models"

W B Frakes [22]

Method "Empirical analysis of the correlation between amount-of-reuse metrics in the c programming language"

Curry, W et al [94]

A study of Reuse level Metrics

"A comparative study on software reuse metrics and economic models from traceability perspective"

J. Mascena et al [112]

A study of Reuse level Metrics

"Admire: Asset development metrics-based integrated reuse

environment"

Jorge, C et al [113]

Metrics "Reuse Ratio Metrics RL and RF-Demo"

Frakes, W B et al [95]

Reuse percentage

Metric ”The business case for software reuse”

Poulin, J.S et al [82]

A study of Reuse

percentage Metrics



A study of Reuse

percentage Metrics


environment"


Reuse frequency

Metrics Reuse Frequency Metric Frakes W et al [198] A study of Reuse

frequency Metrics



A study of Reuse

frequency Metrics


environment"


Metrics "Reuse Ratio Metrics RL and RF-Demo"

Frakes, W B et al [95]

Reuse ratio Metric ”How Reuse Influences Productivity in Object Oriented Systems”

Basili V et al [199]

28

A study of Reuse ratio Metrics



A study of Reuse ratio Metrics

Admire: Asset development metrics-based integrated reuse

environment


Reuse density

A study of Reuse density

metrics



A study of Reuse density

metrics


environment"


Reuse size and

Metric Reuse Size and Frequency metric

Devanbu P et al [200]

frequency A study of Reuse size and frequency



metrics A study Reuse

size and frequency metrics


environment"


Failure modes models

No subcategories

Model Failure modes model Frakes, W B [108]

Reusability assessment

No subcategories

Method "Quantitative studies of software reuse"

Selby, R W [96]

Method "Ada reusability and measurement"

Basili, V R et al [97]

Analysis "Software reuse: metrics and models"

Frakes, W B [22]

Metrics " Evolution of framework reusability"

Cardino, G et al. [98]

Metrics Component reusability model Washizaki, H et al [99] Metrics and Models

"Reusability metrics for Software components".

Rotaru, O et al [100]

Framework "Assessing Module Reusability"

Luer, C [101]

Approach Artificial Neural Network based approach

Arun S [204]

Model Reuse Readiness Levels Model J J Marshall et al. [90]

Reuse library metrics

Indexing costs

Metrics "Software reuse: metrics and models"

Frakes, W B [22]

Search effectiveness

Metrics "Software reuse: metrics and models"

Frakes, W B [22]

Model RASCAL model McCarey, F [103]

Model "A new characterization scheme of reusable software

components"

Parvinder, S S [104]

29

Support for under-standing

Metrics "An empirical study of representation methods for

reusable software components" (7-point ordinary scale for measuring support for

understanding)

Frakes, W B et al. [105]

Efficiency Metrics "Software reuse: metrics and models"

Frakes, W B [22]

Table 9: Contribution Table for Value of Reuse

3.3 Analysis Regarding this question, the search terms are applied in the five electronic databases shown in section 1.6. with an year limitation of 1968 to mid 2009. This research question is answered using the populated taxonomy of W B Frakes [22]. The remaining research regarding this research question is based on this taxonomy. Most of the research regarding measuring the reuse to assess its value is done from 1987. As initially the reuse is considered only for coding the earlier authors discussed on methods/models/metrics for assessing the value of reuse keeping in mind, only the coding part. But later as per the observation of the recent research studies, the researchers seemed to have understood the importance of introducing the reuse to other life cycle objects (reusable assets like requirements, design etc) and they have extended this concept from coding to other life cycle objects.

From 1987 there are many methods/models/metrics discussed or presented regarding measuring the reuse to assess its value. The methods/models/metrics are presented in result section 3.2.3 (directed to Appendix section A3) in the form of tables. All these are divided into different categories based on their application to different areas of software reuse and applied to the Frakes [22] taxonomy. There are six categories as presented in section 3.2.

1. Cost Benefit Models 2. Maturity Assessment Models 3. Amount of Reuse Metrics 4. Failure Modes Models 5. Reusability Assessment Models 6. Reuse Library Metrics

3.3.1 State of Validation We present a graph (in figure 7) to show the validation status of each reusable asset. In the graph, X-Axis represents the reusable assets and Y-Axis represents the percentage of validation (i.e., number of validated and non-validated studies and reviews as well). As the gathered studies also contain reviews which don’t come under validated or non-validated studies, they are presented in the graph along with the validated and non-validated studies. The validated and non-validated studies along with reviews will sum up to 100 percent.

Overall Validation Status and Analysis

• Though the research in this area started from 1968, we have mainly focused the research studies in between 1987 to 2009. According to the observation there is less initiation to validate the existing models or maybe they have been validated by the organizations but were not reported.

• Among the found studies only 36% of them are validated and 50% of them are non-validated and remaining 14% are review studies. Based on the observation non-validated models are a bit higher than the validated.

30

• Among the validated metrics/models/methods, 38.8% are industrially validated and 55.5% are academically validated and 5.5% are validated through surveys.

• Observation shows that, not many industries actually put effort to report their experiences in using a particular metric/method/model. If they had reported the experiences, it would be easier for other organizations to decide whether to use a particular metric or not based on the experience that is reported.

• Some efforts are kept to validate academically, but that too not many.

• Based on the observations not many studies have actually presented the limitations as many had just proposed a model/method/metric without any actual validation and many authors tried to present the advantages of their model. But some authors tried to find the limitations in the previous models like for example Rine in their study work [106] reuse capability model of study [85] proved to be unstable.

• 3 studies have tried to validate the metrics/methods/models that are just proposed in the previous studies.

• Many studies have validated their models without using the industrial data but the validated by setting up random values.

• Review studies also played a key role in this field of research. Around 17% of the studies that are found were reviews. Some tried to review the previous studies and kept efforts to validate the models/metrics/methods and some reviewed the previous studies to find out the trends and recent happenings in this field of research like the study of Parastoo Mohagheghi [79] and Frakes [22]. Parastoo Mohagheghi [79] which reviewed the studies from 1994-2005 to gather the evidences for successful software reuse programs and successful industrial validation of models/metrics etc; in the industry and has reported that there are less number of reports that reported the successful industrial validations because most of the authors validate their models using random values rather than using the industrial values in an industrial environment. As a part of our thesis study we have searched for the reports from 1989-2009 which presented the evidences of successful industrial validations or successful software reuse programs. There is no improvement even from 2005 to 2009 and still we can find (as shown in graphs) very less number of evidences showing the successful industrial validations.

• Frakes [22] in 1996 reviewed the studies which dealt with different reuse metrics and models for assessing the value of reuse. These reuse metrics and models are categorized into 6 categories and a taxonomy is created. Here Frakes [22] reviewed the studies up-to the year 1996. We, in our thesis used this taxonomy and also added a few subcategories (which are not mentioned in Frakes [22]) which come under a particular category, along with those presented by Fakes[22] and reviewed the studies till the year 2009 to find out any new metrics/models and improvements in this area We also took the validation status of metrics/models into consideration. Frakes[22] in his study, mostly reviewed the metrics/models which are for reusable source code. Here we tried to find out the metrics/models for other reusable assets but we could find very less number of articles, but there is some improvement after 1996 as some authors worked on reuse metrics/models for the reusable assets other than coding. In Frakes [22,] it is mentioned that the reuse metrics/models for code can also be applied or used for other reusable assets with small changes.

31

Cost benifit analy sis Maturity Assessment Amount of reuse Failure Modes Reusability Assessment Reuse Library Metrics

0

20

40

60

80

100

120ValidatedNon-ValidatedReview s

Categories

% of v

alidation

Figure 7: Validation Status- Value of Reuse

Validation status for each Category

Here in this section, we present validation status of each Reuse metrics and models category in detail, along with the percentage of review studies and the gap we have found and our suggestions to fill the gap. See appendix for result tables.

1. Cost Benefit Models

From the total number of hits for this category, we have selected 15 studies using inclusion and exclusion criteria. Among those, 10 are validated and 2 are non validated model or metric or method, 3 are review studies of the total 15 studies and among those 2 studies are related to the validation of other 2. Study [73] is related to the validation of study [74] and study [75] is related to the validation of study [72]. Only two studies were applied in large scale projects [72] and [82]. That too study [82] presented the metrics used by IBM to estimate the effort saved by reuse. Around 66.6% are validated, 13.3% are non-validated, 20.1% are reviews and the remaining are validations of or extensions to others.

The cost benefit analysis models are used to assess the cost benefits, efforts, quality of investment (for good reuse investment). By the observation regarding validation, among the validated only few models/methods/metrics 5 are validated through industrial case study and the remaining is validated through academic case study and academic experiment. May be some of the models/methods/metrics validated through academic case study and academic experiment have been validated in industry but they are not reported. Among the models that have been gone through, there is no mention in their respective studies, that they are used by industry. On observation, it can be said that an organization which wants to do cost benefit analysis finds that it is difficult to choose a model that best suits for it. There are reports with industrial validation but it is not sufficient and still it needs more reports with reports of industrial validation.


We have selected 9 studies regarding this study using inclusion and exclusion criteria. In those, 1 study is validated and 7 are non validated models/metrics/methods and 1 is a review paper. among those 3 studies are extensions to the previous ones, 1 study is related to the validation of one of the 9 studies and Study [84] is the extension to [83], study [85] is

32

extension to study [84] and study [86] is the extension to study [85]. And study [106] is related to the validation of study [85]. 1 study [84] is related to STARS project and 1 study [88] is related to RiSE project.

These models help the organization to assess the advancement of the reuse programs in implementing the systematic reuse. Though very interesting models were reported around 77.7% of the models in the studies that we have found are non-validated, only 11.1% of the models are validated and 11.2% are reviews. The only one validated study is only validated through survey and there are no reports with industrial validation. So, much more validation process is needed for the non-validated models and if this validation is done in industrial scenario or industrial environment, then it will be useful for the organizations to choose the model (using the validation results) that best suits for it. All the validated and non-validated models had the common aim of measuring the maturity of the reuse program in implementing the systematic reuse. From 2004 onwards, not much research is done in this field.


We have chosen 15 studies regarding this study. In those 3 studies are validated and 6 are non validated models/metrics/methods, 6 are review studies and study [110] is an extension to study [109] and there is not much validation is done in the past studies regarding this amount of reuse metrics study.

The amount of reuse metrics is subdivided into six categories as discussed in section 3.2.3. Almost all the studies discussed about the general or basic amount of reuse metrics, reuse level and reuse frequency and a very few articles like Poulin [82], Frakes [198], Basili [199], Devanbu [200], Frakes [95], Suri [111], Mascena [112, 113] were found which discussed on other reuse metrics like reuse percentage, reuse size and frequency, reuse ratio, reuse rate. Among the found studies around 20% are validated, 40% of the studies reported are non validated models/metrics/methods and another 40% of studies are reviews. From the percentage figures, we can observe that there are more non-validated and review studies regarding amount of reuse metrics and so, much more effort should be kept in validating the models mainly in the industrial scenario.

4. Failure Modes Models

We could find 2 studies that could best suit for our cause and study [108] is a not validated model and study [22] is a review study.

. W Frakes in [22] [108] was the only author who presented and mentioned about the failure modes model in his studies, according to our observation. The concept is very useful for the organization to make them know the obstacles for reuse. So it is good to have much more research in this field is required.

5. Reusability Assessment Models

We could find 9 studies important regarding this study. In those 3 are validated and 5 are non validated models or metrics or methods or frameworks. 1 study is a review study.

The 8 studies that are found regarding reusability assessment had a common aim of assessing the readiness of an artifact to be reusable or to indicate the possibility that an artifact is reusable. Only 33.3% of the models are validated and 55.5% of models are non-validated and 11.1% is review study. The research in this field from 1997 to 2003 seems to be not much. We strongly recommend much research to be done in this area focusing on the other reusable assets (which are other than coding) by not sticking to code itself.

33


For each type of reuse library metrics we have searched and we could find 5 studies regarding this study. Only 1 study is validated and there are 4 non validated models or metrics. We could find more non-validated studies than that of validated.

There is very less research in this category. The studies that were found have the common aim helping in managing and tracking the reuse repository usage. We could find 7 models of which only 20% are validated and other 80% are non-validated studies.

In figure 8, we have shown the percentage of academic, industrial and survey validations under each category. We can notice that industrial validations are very less with 39% when compared to academic validation with 56%. When considering the cost benefit analysis we could notice that academic and industrial validations are equal in ration. Only one study used survey for the validation purpose. Since, the survey is conducted in an industrial environment; it can be treated as an industrial validation. The figure 8 shows that the academic validations are more than the industrial validations.

Cost-Benefit Analysis Maturity Assessment Amount of Reuse Failure Modes Reusability Assessment Reuse Library Metrics0

20

40

60

80

100

120

AcademicIndustrial

Survey

Study Category

Percentag

e of Validation

Figure 8: Percentage of Academic, Industrial and Survey Validations

3.3.2 Areas in focus In this section, we present a surface graph (in figure 9) which shows the assets in focus. Figure 9 shows the number of studies found per year.

Cost benefit analysis, Maturity assessment model, Amount of reuse metrics were focused more than the Failure modes models, Reuse library metrics and Reusability assessment. As per the observation of studies from 1987 to 2009 Cost benefit analysis, Maturity assessment model, Amount of reuse metrics and Reusability assessment were equally focused by the researchers. There are studies regarding these which were published in close intervals of time. But on observing the Failure modes models, it was mainly mentioned by W.B Frakes [22] [108] both in year 1996 and there is no recent publication regarding this category. Regarding reuse library metrics, some research was done and upon observing the studies from 1987 to 2009, the gap between each published study is much greater for example one study published in 1987 and next important study published in 1994. On coming to reusability assessment there is a large gap in between the year 1997 and 2003.

34

1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 20090

2

4

6

8

10

12

Reuse Library MetricsReusability AssessmentFailure Modes modelsAmount of Reuse metrics

Maturity Assessment modelsCost-Benefit Analysis models

Years

Numbe

r of s

tudies

Figure 9: Areas in Focus

Through this graph, we can identify which areas are in focus for a particular year. For example there was no contribution in the year 2001 for all six categories. We can also notice that, the research contribution is more during the year 2006. There is no contribution on cost benefit models during the period between 1997 and 2001. The contribution on the failure mode models is only present between 1995 and 1997.

3.3.3 Representations methods for methods/models/metrics each category Here we present the percentage of representation methods used by the authors to represent their methods/models/metrics etc;

1. Cost Benefit Analysis Models review results shows that approximately 77.7% of the studies represented their metrics/models/methods through the mathematical means and about 22.3% of the studies represented through diagram or tables or theories. Other studies used the diagrams or table or theory to represent or describe their metrics/models/methods.

2. Maturity Assessment Models Systematic mapping study results shows that approximately 16.6% of the studies represented their metrics/models/methods through the mathematical means and about 83.4% of the studies represented their metrics/models/methods through diagrams or tables or theories. .

3. Amount of Reuse Metrics Systematic mapping study results shows that approximately 40% of the studies represented their metrics/models/methods through the mathematical means and about 60% of the studies represented through diagram or tables or theories.

4. Failure Modes Models Only two studies were found in this category and those two studies represented their models using diagrammatic, tabular and theoretical approaches.


Systematic mapping study results shows that approximately 28.6% of the studies represented their metrics/models/methods through mathematical means and about 71.4% of the studies represented through diagram or tables or theories.

35


Systematic mapping study results shows that approximately 14.3% of the studies represented their metrics/models/methods through mathematical means and about 85.7% of the studies represented through diagram or tables or theories.

36

4 MAINTENANCE OF REUSABLE SOFTWARE Maintenance of reusable software is the most expensive part of the software life

cycle. Software maintenance is the process of modification of a software component after it has been handed over to the client. The changes in the software include error corrections, performance or other improvements, functionality up-gradations, or adaptations to changed environments. There have been situations where more than 50% of the budget is spent on the maintenance of the software [36].According to IEEE, software maintenance is defined as

"The process of modifying a software system or component after delivery to correct faults, improve performance or other attributes, or adapt to a changed environment” [154][178].

Also mentioned the five types of maintenance such as:

1. Corrective maintenance: Maintenance performed in response to software failures is called Corrective maintenance [154][178].

2. Adaptive maintenance: Maintenance due to changes in data and processing environments is categorized as adaptive maintenance [154][178].

3. Perfective maintenance: Maintenance performed to eliminate processing inefficiencies, enhance performance, or improve maintainability is termed as perfective maintenance [154][178].

4. Preventive maintenance: Maintenance which is performed in order to prevent problems before they occur is called Preventive maintenance [154][178].

Apart from the above four types of maintenance, Y. B. Reddy [197] proposed another type of maintenance called the Reconstructive maintenance.

5. Reconstructive maintenance: Reconstructive maintenance is usually performed in order to accommodate the dramatic changes that occur in both the software requirements and the hardware environment in the existing systems.

The difference between the adaptive and the reconstructive maintenance is that adaptive maintenance is mainly concerned with preserving the same functional requirements. Whereas, reconstructive maintenance focuses on the changes which includes operational and environmental apart from functional. The reconstructive maintenance focuses on reusing other software components for constructing the new system to meet operational environment, hardware and software facilities which is not done in the adaptive maintenance [197].

The three points that the reconstructive maintenance engineer should keep in mind is that:

1. Clear understanding of the application domain.

2. Disassembling the existing software system.

3. Constructing a new software system.

From the Systematic mapping study, we divided maintenance of software reuse in to six categories. These six categories have been defined based on their impact towards the maintenance of the software reuse. Here, we have also considered the articles that deal with the maintenance of reusable software in the code perspective. These six categories are discussed briefly:

1. Strategies (STR): Strategies deals with discussions, approaches, tools and models which are proposed for the maintenance of software in terms of reuse as a whole and the integrated approaches for maintenance.

37

2. Change Impact Analysis (CIA): The process of understanding how a change induced in a software system will have impact on the overall system is called the Change Impact Analysis [192].

3. Software Configuration Management (SCM): Software configuration management consists of monitoring and controlling changes to the software. This report, we would be discussing the configuration management of reusable software assets. Configuration management involves version control, change control, revision control and build control [145].

4. Module Dependencies (MDP): The module dependencies play a vital role in the maintenance of the software reuse. The module dependencies involve two aspects. They are coupling and cohesion. Coupling defines the degree of interaction between two modules of a software product where as cohesion is the degree to which the components in the module interacts [155].

5. Legal Issues (LEG): Legal issues involve licensing, ownership and contractual issues. These issues come in to picture in the case of Integrated Development of software systems where the software is developed by integrating different reusable components. However, these licensing, contractual issues help in preventing the illegal use of the software and in a way help in sharing the resources for the sake of reusability and maintainability [168].

6. Aging Symptoms (AGE): Software, over a period of time, becomes difficult to maintain which is called the aging of the software system. The reengineering of the legacy system is important because it comprises of number of applications developed using programming languages and methodologies and everything will go obsolete without maintenance [175].

4.1 Methodology Execution

The methodology execution involves identification of the search terms and framing of search questions. The search terms and search combinations are formed in order to answer the research questions RQ3. In the table 10, we present the search terms and search combinations. The first 11 search terms in table 10 were considered as initial search set of search terms. By applying these search terms, we could find studies related to various areas like software configuration management, module dependencies, change impact analysis, legal issues and aging symptoms which have impact on the maintenance of software reuse. Based on these, we defined taxonomy for maintenance in which we categorized the individual topic areas. For getting relevant studies regarding these categories, we used the terms like “software configuration management”, “module dependencies” etc which are obtained from the initial set of search terms on to the electronic database.

Search Terms 1. Maintenance 2. Maintainability 3. Maintenance with Software Reuse 4. Reuse maintenance 5. Component Based Software Development 6. OSS 7. Open Source Software 8. FLOSS 9. FOSS 10. Open Software 11. Free Software 12. Aging, 13. Strategies 14. Version Control

38

15. Change Control 16. Revision Control 17. Coupling 18. Cohesion 19. RSN 20. Release Sequence Number 21. Integrated Approaches 22. Legal Issues 23. Licensing Issues 24. Contractual Issues 25. Negotiations 26. Legal Issues 27. Module Dependencies 28. SCM 29. software Configuration Management 30. Change Impact Analysis 31. CIA 32. Common Coupling 33. Clandestine Common Coupling 34. Trust Issues.

Search Questions

1. {licens*} + { software AND Reus* } + {software maint*}

2. {{contract OR legal OR Trust} AND issues} + { software AND Reus* } + {software AND maint*}

3. software AND configuration AND management

4. SCM AND {integrated AND approaches} AND {software AND reus* AND maintenance}

5. SCM AND {integrated AND approaches} AND {software AND reus* OR maintenance}

6. {Change AND Impact AND Analysis} AND {software AND maintenance} AND {software AND reus*}

7. {{Version OR Revision OR Change} AND control} AND {software AND maintenance} AND {Software reus*}

8. {Module AND dependenc*} AND {Software AND maintenance} AND reus*

9. {Cohesion AND coupling} AND {Software AND maintenance} AND reus*

10. {Cohesion OR coupling} AND {Software AND maintenance} AND reus*

11. {{Clandestine OR common} AND coupling} AND {Software AND maintenance} AND reus*

Table 10: Search Terms and Search Questions for Maintenance

In this sub-section, the methodology execution which is discussed in section 1.6 is as follows. The articles are obtained by executing the basic inclusion criteria along with the detailed inclusion/ exclusion criteria. These criteria are discussed in section 1. 6.

Number of Hits Basic inclusion criteria

Detailed inclusion/ exclusion Criteria

Snowball sampling

Google Scholar - - - 12

ACM 7187 302 13 -

Inspec 3336 236 4 -

IEEE 694 97 34 -

Elsevier 10062 23 2 -

Springer 8919 405 5 -

Total 30198 1063 58 12

Table 11: Hits after Each Criterion for RQ3


39

4.2 Results The results obtained after the review process would be the taxonomy for the maintenance of reusable software, a systematic mapping bubble graph and the table containing the details of studies involved in each category.

4.2.1 Maintenance Taxonomy Software systems evolve consistently over a period of time. During its evolution, the software undergoes changes due to error corrections, performance improvements, functionality up- gradations etc., which means that the software system is undergoing maintenance. The reasoning for defining the maintenance taxonomy is as follows: 1. Researchers have proposed many methods to deal with maintenance issues in a reusable

software. But, none of them can solve them in entirety as the methods were from a general perspective. From these methods, maintenance can be done from a general perspective but not in specific to a particular topic.

2. Maintenance issues can also arise from the topic areas like software configuration management, change impact analysis, module dependencies, legal issues and aging symptoms. The maintenance models have been proposed from the perspective of individual topic areas. But, for maintaining a software system, it is essential to address issues concerning to each and every topic area.

The maintenance taxonomy defined, would help at least to know what these topic areas are and the methods which have been dealt under those topic areas. So far, we have identified six categories.

In this section, we present taxonomy for maintenance of reusable software. Inspired by the taxonomy for value of reuse defined by W. B. Frakes [22], we depicted taxonomy for the maintenance of software reuse. This taxonomy is derived from the review process and each category mentioned under maintenance is the categories which can impact the maintenance of software reuse. The main idea behind defining a taxonomy is that, they helps in taxonomizing existing studies consisting of reviews, discussions, methods, models and approaches and validations of the studies under a relevant category. The studies placed under a particular category are based on the similarity of the studies.

The taxonomy defined will help to perform three kinds of tasks:

1. Identification: Identifying whether there is solution which can be useful for solving the issues concerning to the problem domain. Here, we also check whether the information is available for that problem domain.

2. Discovery: Finding which categories are related to the problem domain as well as the researchers working in that domain.

3. Delivery: Obtaining the studies which are available for the each category.

This taxonomy will help in answering the RQ3, and also helps identifying the research work done from the perspective of other reusable software assets apart from source code.

40

Figure 10: Taxonomy of Maintenance

4.2.2 Bubble graph

In the figure 11, we present a systematic mapping using a bubble graph. The size of the bubble represents the number of studies which comes under that particular category. The bubbles at the intersection of the axis contain reference number of the studies. The X-Axis is divided in to two halves i.e., the left and right. In the right half on the X-Axis of figure 11, we show the validation status of the studies and also indicate which type of validation; the study comes under (like industrial case study, academic case study, academic experiment, industrial experiment, survey). The left half on the X-Axis deals with the method, models, metrics and approaches that are dealt for each category. The Y-Axis deals with the maintenance categories like Strategies, Change Impact Analysis, Software Configuration Management, Module Dependencies, Legal Issues and Aging Symptoms. For example, there is only one article [175] which comes as a method and comes under the aging maintenance categories. This article is presented in the bubble graph exactly at the intersection of the method (Which is represented as Mt in the bubble graph) on X-Axis and the Aging of Y-Axis as shown in figure 11.

Figure 11: Systematic Mapping Bubble Graph for Maintenance

41

4.2.3 Results The table contains the details of the study. It shows whether the study is discussing the model/ method/ Metrics/ approach/ tool, followed by the name of the model/ method/ Metrics/ approach/ tool if available or the title of the study, author and the reference number of the study. The content in the quotes represents that it’s the title of the study.

Category Contribution Contribution Name or

Title of the article

Author and

Reference Number

Strategies Approach,

Tool

“Software Configuration Management for a Reusable Software Library within a Software Maintenance Environment”

Kwon, O. C [121]

Approach “Enhancing Software Product Line Maintenance with Source Code Mining”

Michael Jiang [125]

Model Staged model for software maintenance Bennett, K. H. [123]

Tool RAPID Tool Baldassarre [124]

Change Impact Analysis

Model Object-Oriented Maintenance-Oriented Model

Heisler [194]

Approach “Some Stability Measures for Software Maintenance”

Yau, S.S [141]

Metrics “A Framework for Software Maintenance Metrics”

Pfleeger [193]

Approach “Change impact identification in object oriented software maintenance”

D. Kung [127]

Approach “Algorithmic analysis of the impact of changes to object-oriented software”

L. Li [128]

Method,

Metrics

“Change Impact Analysis of Object-Oriented Software”

M. Lee [192]

Method “Techniques of Maintaining Evolving Component-Based Software”

Ye Wu [142]

Approach Chaining Technique J.A. Stafford [190]

Approach “UML model-based approach to impact analysis”

Briand et al [189]

Approach Light weight proactive CIA approach using Use-case maps.

Hewitt, J [134]

Method “Impact Analysis by Mining Software and Change Request Repositories”

Canfora [135]

Approach Component interaction based approach for the CIA

Tie, F [184]

Approach “Computing ripple effect for object oriented software”

H.Z. Bilal [136]

Method “Empirical software change impact analysis using singular value decomposition”

Sherriff [138]

Method “Change impact analysis for AspectJ programs”

Sai Zhang [139]

42

Approach “An Approach for Comparison of Architecture Level Change Impact Analysis Methods and Their Relevance in Web Systems Evolution”

Mehboob [140]

Software Configuration Management

Model “Supporting reuse and configuration: a port based SCM model”

Aquilino [147]

Tool System Modeller Tool for Cedar Programming Languages

Lampson [143]

Tool RCS- a revision control tool Walter F. Tichy [144]

Tool SCCS and make Tools V. Ambriola [146]

Tool Project Revision control System(PRCS) Josh MacDonald [149]

Tool ROSE Tool Zimmermann [151]

Model, Tool “A fine-grained and flexible version control for software artifacts”

Junqueira [195]

Approach “Detection of Logical Coupling Based on Product Release History”

Hall [152]

Approach “Predicting Source Code Changes by Mining Change History,”

A.T. Ying [150]

Approach “Predicting Change Propagation in Software System”

Hassan [153]

Module Dependencies

Legal Issues

Approach Information Theory Approach Edward B. Allen [157]

Approach “On the Nonmaintainability of Open-Source Software,”

S. R.Schach [158]

Approach "Categorization of Common Coupling and Its Application to the Maintainability of the Linux Kernel,"

Liguo Yu [160]

Approach “Refactoring — Improving Coupling and Cohesion of Existing Code”

Bart Du Bois [161]

Approach “Object-Oriented and Classical Software Engineering”

S.R.Schach [162]

Approach Dynamic Coupling Measurement Technique

A. B. Deraman [196]

Approach “Impact of release intervals on empirical research into software evolution, with application to the maintainability of Linux”

Thomas, L.G [165]

Metrics “Multiple-parameter coupling metrics for layered component-based software”

Yu [166]

Approach “Analyzing software licenses in open architecture software systems”

Alspaugh [173]

Aging Symptoms

Method “Iterative Reengineering of Legacy Functions”

Alessandro Bianchi [175]

Metrics “Ageing of a data-intensive legacy system: symptoms and remedies”

Giuseppe Visaggio [174]

Table 12: Contribution Table for Maintenance

43

1. Strategies (STR)

In this section, we deal with discussions, approaches, tools and models which are proposed for the maintenance of software in terms of reuse as a whole and the integrated approaches for maintenance. Apart from this section, other sections deals with their individual impact towards maintenance of software reuse. The study on strategies ended up in finding 8 studies on strategies for maintenance. Among this, 3 studies are validated and 3 studies dealt with discussions. 2 studies dealt with methods and 1 study dealt with model.

2. Change Impact Analysis (CIA)

User needs changes very rapidly. Changes are expected to take place in software as the software is augmented to meet the needs of the user. When a change is made to a software system during its evolution, the change may cause disastrous effects on the other modules which are connected with the changed module. A change impact analysis technique can help in analyzing the potential effects beforehand which are caused by a change or to measure the impact of the change caused after the change is made. If CIA is applied beforehand, it helps the maintainer to predict the cost of the proposed changes. If CIA is applied after modification, it warns the engineer regarding the affected modules. CIA information can be useful in planning changes, making changes and tracing through the effects of changes [132].

Briand et al. defined Impact analysis as "The process of identifying the potential consequences (side-effects) of a change, and estimating what needs to be modified to accomplish a change.” [189]. Out of the 23 articles, we found 11 studies which are validated. 5 studies deals with discussions, 8 studies deals with methods and 10 deals with approaches.

3. Software Configuration Management (SCM) A software product may encounter specification changes, bug fixations, upgradations are performed which in turn creates different versions which suits different needs. Because of this families of systems having similar functions evolve which are different from one another. Dealing with those changes is not an easy task. When a bug is encountered in a version of software, the old versions helps as references in corrections, error fixations and enhancements. [145, 148].

Software Configuration Management consists of 3 major activities such as version control, change control and build control which will help in monitoring and controlling the changes that are done to software and thus ensuring the maintainability of the reusable software [145]. In this report, we use SCM as the collective name for those activities that are connected with version control, change control and build control. The study on SCM ended with finding 12 studies, out of which 6 studies are validated. One study dealt with discussions, 4 studies with approaches, 2 studies with model and 5 studies dealt with methods.

4. Module Dependencies (MDP) When a new software product is developed by reusing an existing component, it is essential to ensure that the reusability of the reused component is preserved in the new product. Software reusability is related to software dependency. Software dependency has its impact on the modifiability, maintainability and reusability of software [163]. From the perspective of dependency, a software module can be easily comprehended, maintained and reused if it holds fewer dependencies of its module on other modules [166]. When strong dependencies exist between a set of software modules, then it would be impossible to reuse even one module in a new product without completely redesigning and reimplementing that module, which in turn conflicts the purpose of reuse [163]. Moreover, when a change is induced in a module, the probability that the change in one module may affect the other modules is high and introduces regression faults, which leads to detrimental effects on software maintenance. Too much coupling will induce fault-proneness in to the software

44

system which makes it difficult to reuse and difficult to maintain. Thus, strong coupling also hinders software reuse [160, 166]. If software modules doesn’t have coupling at all in a software system, then that software system would comprise of a single large module, so some amount of coupling clearly is needed [160].

Measuring coupling in early design process can give insight into design attributes and help in predicting software quality. If the design attributes or predicted quality seems unsatisfactory, then the designs can be revised before changes become too expensive [157]. The overall aim is to predict and improve the maintainability of software reuse by measuring the coupling and cohesion [157, 161].

Coupling and cohesion: Coupling defines the degree of interaction between two modules of a software product where as cohesion is the degree to which the components in the module interacts. Out of 15 articles, 8 articles are academic case study and 1 article is academic experiment validations, one article represents metrics and 7 articles represent approaches. One article makes use of the call graph to measure software dependency and 3 articles use Definition-Use Analysis to measure software dependency. 2 articles provide guidelines to measuring the reusability, one for code in particular and the other for source code folder in particular.

5. Legal Issues (LEG)

Licensing, ownership, contractual issues play an important part in reusing and maintaining software. These issues come in to picture in the case of integrated development of software systems where the software is developed by integrating different reusable components. However, these licensing, contractual issues help in preventing the illegal use of the software and in a way help in sharing the resources for the sake of reusability and maintainability [168]. For example, if a COTS component is reused which is bought from a third party vendor, it may initially satisfy our requirements. But, over a period of time, it may show disastrous effects which leads to the failure of the software system. It is hard to fix as sometimes documentation is not available. Though, it is available, it may not contain the limitations of using the COTS component which leads to high maintenance. Legal issues also help the contractor by forcing him to reuse the common set of reusable components in an integrated development environment thereby ensuring maintainability and reusability [168]. A total of 7 papers were identified in this area. One paper presented an approach and validation. The other 6 papers discussed regarding the licensing, legal, contractual and negotiation issues.

6. Aging Symptoms (AGE)

Large organizations like banks, builds their own software which has some special features pertaining to their domain. This software over a period of time becomes difficult to maintain which is called the aging of the software system. The reengineering of the legacy system is important because it comprises of number of applications developed using programming languages and methodologies and everything will go obsolete without maintenance. The papers found, will through light on how to maintain these legacy systems [174, 175]. We found 2 articles from the same author, one proposing the metrics for the issues related to aging symptoms and the other proposes a method for the gradual reengineering of whole legacy system.

4.3 Analysis The research studies which are needed for the analysis part are obtained by executing the search process without any year limitation as discussed in section 1.6. The basis for our analysis is the taxonomy defined for the maintenance of software reuse. In this section, we would be discussing about the validation status, shift in the trends and the areas in focus.

45

4.3.1 State of validation In this section, we present the overall validation status and validation status for each category as well. 4.3.1.1 Overall Validation Status

• From the total of 67 studies, 47% are validated and 28% are non-validated. 28% of the studies deal with discussions, 23% deals with methods, 36% deals with approaches, 7% deals with models and 6% deals with metrics.

• Among the 32 validated studies, 72% are academically validated, 25% are industrially validated methods/approaches/models/metrics and 3% is validated through survey.

4.3.1.2 Validation Status for Each Category Though the concept of software reuse started in 1968 by McIlroy, it is still an emerging field as there is less research work going on in the field of maintenance of software reuse. Lack of standard models for maintenance of reusable software proves this. In this section, we follow a similar validation graph which is discussed in section 2.3.1.

From the validation graph, we could notice that all those studies related to aging symptoms category are validated. Less validated studies are found in legal issues category (14%). Other categories which are validated are module dependencies (60%), software configuration management (50%), change impacts analysis (48%) and strategies (38%). The studies are classified in to validated studies, non-validated studies and others are reviews. The sum of the percentages of the three should constitute 100%. But, in the strategies category, a study by Oh-Cheon Kwon [122] has a non-validated tool and a review which made the total percentage go beyond 100%.

STR CIA SCM MDP LEG AGE0

20

40

60

80

100

120

ValidatedNon-validatedReview s

Study Categories

Percentage of Validation

Figure 12: Validation Study

1. Strategies (STR): The study on strategies includes methods/ approaches/ models which deal with maintenance of software reuse and the integrated approaches for the maintenance of software reuse as well. Among the studies found, only 38% are validated and 62% are non-validated. Among the validated studies, 33% are industrially validated and 67% are academically validated. Most of the methods/ models/ approaches proposed found in the studies under the maintenance of software reuse topic area are a small part of maintenance process or the integrated approaches of these small parts which has its impact on the maintenance of software reuse. Two models are proposed to solve the problem of maintenance of software reuse as a whole and these models are also non-validated [120 and 123]. These small parts are Change Impact analysis, Module dependencies, Software Configuration Management, Legal Issues and Aging symptoms which are being discussed in the coming sections.

46

2. Change Impact Analysis (CIA): The Change Impact Analysis and the Ripple Effect contributes to the large extent in the maintenance of software reuse. Lot of research is going on in this field. Among the 23 studies, we found, 48% are validated and 30% are non-validated. Among the validated studies, 18% are industrially validated and 82% are academically validated.

From the above study, we identified that most change impact analysis techniques found, deals with source code in particular utilizing call graphs, dynamic executions of the system, or static code analysis that do not include non-source code files, such as media files, help files, and configuration files [132, 133, 135]. One study done by William et al [139], proposed an impact analysis methodology that uses historical change records for both executable as well as non-executable files in a software system to find and prioritize potentially affected areas of a system modification based on risk.

Many researchers like Boehm, Martin McClure, Parikh and Sharpley proposed maintenance models which are similar [192]. Their main objective is to ensure the following:

1. Understanding the software 2. Modifying the system 3. Revalidation

The shift in trend has been observed from Yau and Patrik in 1978. They worked on change impact analysis and ripple effect. The introduction to object oriented models started in 1989 by Heisler et al. Heisler et al made use of ripple effect and program slicing to anticipate the potential effects of an object oriented system when a change is made [194]. Over the years, there is a continuous effort put in the field of CIA. The contribution in CIA is not just to source code but also for other reusable assets like architecture [184, 140, 190 and 193] analysis/ design documents [189 and 193].

3. Software Configuration Management (SCM): Much information is not available on the change control and build control. Most researchers discussed on the version control and revision control. Out of the studies found, 50% are validated and 26% are non-validated. From the validated studies, 33% are industrially validated, and 50% are academically validated. Different authors used different terminology to represent the same ideas [147]. Lack of standard terminology could be treated as one cause for this problem.

It’s been three decades since the concept of software configuration management has started. One interesting thing is that the way the versions of the source code are handled hasn't been changed since then. Version control systems and configuration management process remained the same [195]. Many tools have been developed for SCM during these three decades.

4. Module Dependencies (MDP): Coupling and Cohesion defines the degree of bonding between the modules and the components in the modules. Out of studies found under this category, 60% are validated and 11% are non-validated. The validated studies found are academically validated. There are no industrial validations in this category. This is a peculiar category where most of the studies are validated using Open Source Software (OSS) like Linux. And most of the works are an extension to the other works. Apart from the traditional ways of measuring coupling, some researchers mentioned that coupling should be calculated based on the Release date instead of Release Sequence Number (RSN) and by calculating coupling distance. This category is getting importance since 2000. There were very less contribution till 2000.

5. Legal Issues (LEG): Legal issues contribute a lot to the development and maintenance of the reusable software. Out of the studies found, 86% are discussions and only 14% are validated. Only one approach is discussed and it is validated through industrial case study. Though, all the software companies give utmost importance to the legal, contractual, negotiational and licensing issues, there has been very less research going on in this field.

47

6. Aging Symptoms (AGE): Aging of the software system is directly proportional to the increase in the maintenance of the software system. There is very less contribution in this area. We could find only two research works. These two research works are industrially validated.

In figure 13, we have shown the validation percentage of academic, industrial and survey validations under each category. We can also notice that industrial validations are more for the categories like aging symptoms and legal issues. But, from figure 12, we could identify that the research contributions for these categories are low. The categories which have more research contribution have less industrial validations. Tichy [144] has done survey by comparing RCS files on two machines in software configuration management category. This could be treated as an academic survey.

STR CIA SCM MDP LEG AGE0

20

40

60

80

100

120

AcademicIndustrial

Survey

Study Category

Perce

ntag

e of Validatio

n

Figure 13: Academic and Industrial Validation Status for each Category.

4.3.2 Areas in Focus

Large part of the research is done in the areas like Software Configuration Management, Change Impact Analysis and Module Dependencies. Very less contribution is encountered in the fields of Legal Issues, Aging symptoms and also in introducing models and methods for the maintenance of software reuse and their validations as well. The reason could be that the organizations might have been using the traditional models and not concentrating on the new models.

19721973

19741975

19761977

19781979

19801981

19821983

19841985

19861987

19881989

19901991

19921993

19941995

19961997

19981999

20002001

20022003

20042005

20062007

20082009

0

1

2

3

4

5

6

7

8

Areas in focus

AGELEG

MDPSCMCIASTR

Years

Num

ber of studies

Figure 14: Areas in Focus.

From figure 14, we can notice that the research contribution is more during the period between 2001-2006 and 2007- 2009. We can notice that research contributions for module dependencies and software configuration management are more. Very less contribution in the field of maintenance of software reuse is notices between 1972 and 1988. Less contribution is done on aging. Consistent research contribution is noticed for change impact analysis,

48

strategies and software configuration management since 1988. The graph shows a fall at 2009, since there are very less numbers of research works available as we have limited our search till the first half of 2009.

4.3.3 Validity Threats

In addition to the validity threats discussed in section 1.6.3, the following threats were uncovered during the study in this chapter

• Some authors used different terminology to represent the same ideas. This could be due to the fact that, there is no standard terminology defined.

• Most methods, approaches and models focus on source code in particular. Very few deals with the other reusable assets.

• Some of the articles found for maintenance of software reuse discuss management of software reuse. This is due to the lack of standard terminology.

49

5 CONCLUSION An increasing demand for software reuse to save time and cost lead to a research for

identifying the best ways to increase the efficiency of software reuse.

Source code is most commonly reused and so there is misconception that software reuse is code reuse [36]. The organizations will benefit, only by extending the concept of reuse to other assets which can be reusable and not sticking to only reuse of code. The organizations will benefit, only by extending the concept of reuse to other assets which can be reusable. This will save the project costs and time and gives them the benefits. These assets are termed as reusable assets/artifacts/components. So our first research question RQ1 is focused on identifying the other reusable assets and also identifying the methods/models/approaches for reusing those assets. As shown in analysis section 2.3, we found a total of 14 reusable assets. As per the observation there are more non validated studies, may be because the most authors have just mentioned that a particular asset is reusable and never tried to prove it. The studies which were found proposing a list of reusable assets have no common point of view regarding reusable assets. Each study has its own set of reusable assets and only a few assets are in common with others list. Our observation regarding reusable assets shows that no author had actually tried to define a standard set of reusable assets that are commonly accepted by the researchers in the field of software reuse. Out of the total number of studies, the 27% are validated, 68% are non-validated and 5% are reviews. Out of the validated studies about 55% are academically validated, 25% are industrially validated and 20% are validated through surveys.

Assessing the value of reuse is a major concern in the software industry. For assessing its value, reuse should be measured by using the metrics and models. Our second research question RQ2 focused on identifying the existing reuse metrics and models. Measuring reuse will help the organization to know their progress in software reuse, to know how much amount of reuse is done or to assess the cost benefits of software reuse etc; Our observations shows that, the reuse metrics and models are divided in to six categories, based on their application to different areas of software reuse. The organizations can use these metrics and models for measuring reuse and reusability. As shown in the analysis section 3.3, the percentage of validated studies is less than the percentage of non validated studies. Out of 50 studies, 18 studies (36%) are validated and 25 studies (50%) are non-validated. Out of these validated studies, 39% are industrially validated, 56% are academically validated and 5% are validated through surveys. Among the found six categories, cost benefit analysis, maturity assessment, amount of reuse metric areas are more focused or concentrated more than the other categories. A good research is going on in this field, but it is a not sufficient.

Another major concern in the software industry is maintenance of reusable software. Maintenance of software reuse is an expensive task in the software life cycle. More than 50% of the budget is invested on the maintenance of the reusable software. For an organization to save money, it is essential to reduce the maintenance cost. Our third research question RQ3 focused on identifying the approaches for the maintenance of reusable software. In order to answer RQ3, we found six areas which impact the maintenance of reusable software. We have categorized them under maintenance taxonomy. The approaches which have been proposed under each category are dealt accordingly. For the maintenance of software reuse, a total of 67 studies were found. Out of these 67 studies, 32 studies (47%) are validated and 19 studies (28%) are non-validated. Out the 32 validated studies, 25% are industrially validated, 72% are academically validated and 3% validation is noticed through survey. Research contribution is more towards Software Configuration Management, Change Impact Analysis and Module Dependencies categories. Though there is less contribution in the areas like aging symptoms and legal issues, they are industrially validated.

Unfortunately, among the validated models/ methods/ metrics/ approaches which were identified while answering the three research questions, the percentage of industrially

50

validated is less than the percentage of academically validated model/method/metric. Most of these works are validated in academic perspective. The reason for lack of industrial validations could be that some software organizations may not be willing to disclose their information. Other possible reason might be the proposed models developed from academic perspective might not meet the exact requirement of the software organizations. The authors who have validated academically used some random values for the validation purpose. They are not the real data from the industry. The industries would feel confident to use a model or metric, if it is validated in the industry and is proved to be a success. From section 3 and 4 we observe that, though researchers have realized the importance of extending the reuse to the assets other than coding, they still present their model/metric/method/approach in a code perspective. By this, we conclude that the software industry is in its initial phases of software reuse.

Future work: • Most of the model/metric/method/approach proposed for assessing the value of reuse

and maintenance of software reuse are not industrially validated or may be; most of the industrial validations might be validated but not reported. The reason could be that the software organizations may not be willing to disclose their information. The organizations are not confident in using most of the models/metrics/methods because the present models/metrics/methods may not meet the requirements or needs of the software organizations as most of them are developed in the academic perspective. In our future work, we would like to conduct an industrial survey to obtain the results of the industrial validations of model/metric/method/approach.

Recommendations: • The researchers should go beyond code perspective and continue their research on

other assets like requirement, design etc; • Much more research should be done in designing reliable

models/metrics/methods/approaches in the areas like assessing the value of reuse and for maintenance of reusable software which can widely be accepted by the industry.

• The model/metric/method/approach should be developed in accordance with the industrial needs.

• Much more effort should be spent on validating the present model/metric/method/approaches industrially using the real data instead of using random values (through examples) so that the industry feel confident in using them.

51

6 REFERENCES

[1] Visaggio, G. (1994). "Process improvement through data reuse." Software, IEEE 11(4): 76-85.

[2] Issenin, I., Brockmeyer, E., Miranda, M., and Dutt, N (2004). Data Reuse Analysis

Technique for Software-Controlled Memory Hierarchies. In Proceedings of the Conference on Design, Automation and Test in Europe. Washington, DC, 10202, IEEE Computer Society. Volume 1.

[3] Sametinger, Johannes. (1996). Reuse documentation and documentation reuse. In

Richard Mitchell, Jean-Marc Nerson, and Bertrand Meyer, editors, TOOLS 19: Technology of Object-Oriented Languages and Systems, pp: 17-28. Prentice Hall, Paris, France.

[4] Childs, B. and J. Sametinger (1996). Literate programming and documentation reuse.

In Proceedings of the Fourth International Conference on Software Reuse: pp: 205–214.

[5] Levy, D. M. (December 1993). Document reuse and Document systems, Electronic

Publishing. Volume 6(Number 4), pp: 339-348.

[6] Boukottaya, A. ( 2006). A Document Reuse Tool for Communities of Practice. First European Conference on Technology Enhanced Learning, Crete.

[7] Barta, D. and J. Gil (Jun 1996). A system for document reuse. In Proceedings of the

7th Israeli Conference on Computer systems and Software Engineering. Washington, DC, USA, IEEE Computer Society Press: pp: 83–94.

[8] Guerrieri, E. (1999). Software document reuse with XML. In Proceedings of the 5th

International Conference on Software Reuse: pp: 246-254.

[9] Nebel, B. and J. Koehler (1995). Plan reuse versus plan generation: A theoretical and empirical analysis. Artificial Intelligence, Elsevier. Volume 76: pp: 427–454.

[10] Kambhampati, S. (1994). Exploiting causal structure to control retrieval and refiting

during plan reuse. Computational intelligence. Volume 10: pp: 213-224. [11] Kambhampati, S. (August 1990). A theory of plan modification. In Proceedings of 8th

National Conference on Artificial Intelligence. Boston, M. A. [12] Spalazzi, L. (2001). "A survey on case-based planning." Artificial Intelligence Review

Volume 16(Number 1): Pp: 3-36. [13] Mark Folkerts, Tim Lamey, et al. (June 2008). Common Test Patterns and Reuse Test

Designs, Microsoft. [14] Binkley, D. (1995). Reducing the cost of regression testing by semantics guided test

case selection. In the proceedings of the 11th International Conference on Software Maintenance (ICSM'95). Washington, DC, 251, IEEE Computer Society: pp: 251.

52

[15] Anneliese Von Mayrhauser, Richard T. Mraz, et al. (October, 1994). Domain Based Testing: Increasing Test Case Reuse. Proceedings of the IEEE International Conference on Computer Design. Cambridge, MA: pp: 484-491.

[16] Karinsalo, M. and P. Abrahamsson (June 14, 2004). Software Reuse and the Test

Development Process: A Combined Approach. Software Reuse: Methods, Techniques and Tools. Oulu, Finland, Springer Berlin / Heidelberg. Volume 3107/2004.

[17] Lonngren, D. D. (Aug 1998). Reducing the cost of test through reuse.

AUTOTESTCON '98. IEEE Systems Readiness Technology Conference, IEEE: pp: 48-53.

[18] McGregor, J. D. (2002). Building Reusable Test Assets for a Product Line. Software

Reuse: Methods, Techniques, and Tools. Clemson, SC, 29634, Springer Berlin / Heidelberg. Volume 2319/2002: pp: 49-63.

[19] Dong, Y., M. F. Lau, et al. (August, 2008). On Partitioning the Domain for Test Case

Reusability. In Proceedings of the 2008 the Eighth international Conference on Quality Software. Washington, DC, QSIC. IEEE Computer Society: pp: 264-269.

[20] Al Dallal, J. S., P. (2008). "Testing Software Assets of Framework-Based Product

Families during Application Engineering Stage." Journal of Software Volume 3(Issue 5): pp: 11- 25.

[21] Jones, C. (1993). Software return on investment preliminary analysis, Software

Productivity Research, Inc. [22] Frakes, W. and C. Terry (1996). Software Reuse: Metrics and Models. ACM

Computing Surveys, ACM. Volume 28: Pp: 415 - 435. [23] R. J Leach. (1997). Software Reuse; Methods, Models and costs, Computing,

McGrawHill, New York. [24] Zhu, H. (July, 2005). Challenges to Reusable Services. In Proceedings of the 2005

IEEE international Conference on Services Computing. Washington, DC, IEEE Computer Society. Volume 02: pp: 243-244.

[25] Karsten, W. (1997). Reuse of algorithms: still a challenge to object-oriented

programming. Proceedings of the 12th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications. Atlanta, Georgia, United States, ACM.

[26] Jameson, K. W. (1989). A model for the reuse of software design information.

International Conference on Software Engineering, Proceedings of the 11th international conference on Software engineering. Pittsburgh, Pennsylvania, United States, ACM: pp: 205 - 216.

[27] J. Etlie and M. Kuberak (2008). Design Reuse in Manufacturing and services. Rochester institute of technology, 107 Lomb Memorial Drive, Rochester, NY. https://ritdml.rit.edu/dspace/bitstream/1850/7703/1/JEttlieArticle2008.pdf

[28] Kogut, P. (1995). Design reuse: chemical engineering vs. software engineering.

SIGSOFT Softw. Eng. Notes, 20, 5, pp: 73-77.

https://ritdml.rit.edu/dspace/bitstream/1850/7703/1/JEttlieArticle2008.pdf

53

[29] Upadhyay, V. (1992). Design Reuse as a Strategy for Incremental New Product Development a Study of Software Industy, Massachusetts Institute of Technology.

[30] Komiya, S. (1994). A model for the recording and reuse of software design decisions

and decision rationale. Software Reuse: Advances in Software Reusability, 1994. Proceedings., Third International Conference on, IEEE: pp: 200-201.

[31] Wai Fong, B. (2008). "Reuse of knowledge assets from repositories: A mixed methods

study." Inf. Manage. 45(6): 365-375.

[32] Channarukul. S, Charoenvikrom. S, et al. (March 2005). Case-based reasoning for software design reuse. Aerospace Conference, IEEE: pp: 4296-4305.

[33] Arango. G, Schoen. E, et al. (Mar 1993). Design as evolution and reuse. Software Reusability, 1993. Proceedings Advances in Software Reuse., Selected Papers from the Second International Workshop on.

[34] Krueger, C. W. (1992). Software reuse. ACM Comput. Surv. 24, 2 (Jun. 1992), 131-

183. [35] I. Jacobson, M. Griss, P. Jonsson. (1997). Software Reuse: Architecture, Process and

Organization for Business Success, Addison-Wesley. [36] J. Sametinger. (1997). Software Engineering with Reusable Components. Springer,

Berlin. [37] Eeles, P. (2008). Understanding Architectural Assets. Seventh Working IEEE/IFIP

Conference on Software Architecture (WICSA 2008): pp:267-270. [38] Li. H, Van Katwijk. J, et al. (1992). The reuse of software design and software

architecture. Software Engineering and Knowledge Engineering, 1992. Proceedings., Fourth International Conference on.

[39] White, S. A., Lemus-Olalde, C. (1998). Architectural Reuse in Software

Development. Energy Sources Technology Conference & Exhibition, ASME-ETCE98.

[40] Baum. L, Becker. M, et al. (1998). Using Software Architecture as a Catalyst for

Reuse. Proc. Of European Reuse Workshop 1998. Spain.

[41] Gomaa, H. (1995). Reusable software requirements and architectures for families of systems,. Journal of Systems and Software. Volume 28: pp: 189-202.

[42] Griss, M. L. (May 1999). Architecting for large-scale systematic component reuse. In Proceedings of the 21st international Conference on Software Engineering. New York, NY, ACM: pp: 615-616.

[43] Monzon, A. (2008). A Practical Approach to Requirements Reuse in Product Families

of On-Board Systems. In Proceedings of the 2008 16th IEEE international Requirements Engineering Conference. Washington, DC, IEEE Computer Society: pp: 223-228.

[44] Michel Ezran, Maurizio Morisio, et al. (2002). Practical Software Reuse. Springer-

Verlag, London.

54

[45] Thais Ebling, Jorge Luis Nicolas Audy, et al. (2009). Towards a requirements reuse method using Product Line in distributed environments. http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER09/ebling.pdf

[46] Lam, W. (1997). "Achieving requirements reuse: a domain-specific approach from

avionics." Journal of Systems and Software Volume 38(Issue 3): Pp: 197-209. [47] Spanoudakis. G and Constantopoulos. P (1996). "Analogical Reuse of Requirements

Specifications: A Computational Model." Applied Artificial Intelligence: An International Journal Volume 10(Issue 4): pp: 281-306.

[48] C. Montabert, D. Bussert, et al. (2005). Supporting Requirements Reuse in

Notification Systems Design through Task Modeling. Proc. 11th International Conference on Human-Computer Interaction (HCII ‘05), Citeseer.

[49] Perednikas, E. (2008). Requirements Reuse Based on Forecast of User Needs. International Conference 20th EURO Mini Conference “Continuous Optimization and Knowledge-Based Technologies” (EurOPT-2008). Neringa, LITHUANIA: pp: 450–455.

[50] B. Keepence, M. Mannion, et al. (1995). SMARTRe requirements: writing reusable requirements. Systems Engineering of Computer Based Systems, 1995., Proceedings of the 1995 International Symposium and Workshop on: pp: 27-34.

[51] Lam, W., McDermid, J. A., and Vickers, A. J. (1997). Ten Steps Towards Systematic Requirements Reuse. In Proceedings of the 3rd IEEE international Symposium on Requirements Engineering. Washington, DC, IEEE Computer Society: pp: 6–13.

[52] Antonellis, V. D. and L. Vandoni (1993). Temporal Apsects in Reuse of Requirement

Specifications. Advanced information Systems Engineering. F. B. C. Rolland, and C. Cauvet. London, Springer-Verlag. Volume 685: pp: 504-520.

[53] Johnson. W.L and D. R. Harris (1991). Sharing And Reuse Of Requirements Knowledge. Knowledge-Based Software Engineering Conference, 1991. Proceedings., 6th Annual, pp: 57-66.

[54] R. Gotzhein, M. Kronenburg, et al. (1998). Reuse in requirements engineering:

Discovery and application of a real-time requirement pattern. 5th International Symposium on Formal Techniques in Real-Time and Fault-Tolerant Systems (FTRTFT’98), Lecture Notes in Computer Science 1486, Springer pp: 65–74.

[55] Lopez, O., Laguna, M.A., Garcia, F.J. (2002). Metamodeling for Requirements Reuse.

Anais do WER02 - Workshop em Engenharia de Requisitos. Valencia, Spain [56] Philippe Massonet, A. V. L. (1997). Analogical Reuse of Requirements Frameworks.

Third IEEE International Symposium on Requirements Engineering (RE'97), IEEE Computer Society: pp: 26.

[57] Moon, M., Yeom, K., and Seok Chae, H. (2005). An Approach to Developing Domain

Requirements as a Core Asset Based on Commonality and Variability Analysis in a Product Line. Software Engineering, IEEE Transactions on, IEEE Computer Society. Volume 31: pp: 551- 569.

[58] Paulo Gomes and A. Leitão (2006). A Tool for Management and Reuse of Software Design Knowledge. Managing Knowledge in a World of Networks. AILab, Centro de

http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER09/ebling.pdf

http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER09/ebling.pdf

55

Informática e Sistemas da Universidade de Coimbra, Springer Berlin / Heidelberg. Volume 4248/2006: pp: 381-388.

[59] Parsons, J., Saunders, C (2004). Cognitive heuristics in software engineering applying and extending anchoring and adjustment to artifact reuse. IEEE Transactions on Software Engineering. Volume 30: pp: 873-888.

[60] Kucza, T., Nättinen, M. and Parviainen, P. (2001). Improving knowledge management

in software reuse process. 3rd International Conference on Product Focused Software Process Improvement. Kaiserslautern, Germany, Springer: pp: 141–152.

[61] Von Krogh, G. S., Sebastian; Haefliger, Stefan, (2005). Knowledge reuse in open source software: An exploratory study of 15 open source projects. Proceedings of the Annual Hawaii International Conference on System Sciences: pp 198.

[62] Liu Xue-Mei, Gu Guochang, et al. (2009). Research and Implementation of

Knowledge Management Methods in Software Testing Process. Computer Science and Information Engineering, 2009 WRI World Congress on. Volume 7: pp: 739-743.

[63] Karem Hussein. (2008). Measuring Reuse Characteristics of Software Components in an Extensible IDE. pp: 16-17, VDM Verlag, Germany.

[64] Althoff, K.-D., Andreas Birk, Susanne Hartkopf, Wolfgang Muller, Markus Nick,

Dagmar Surmann, and Carsten Tautz. (1999). Systematic population, utilization, and maintenance of a repository for comprehensive reuse. Proc. of the Workshop on Learning Software Organizations: Methodology and Applications at SEKE’99. Kaiserslautern, Germany, Springer: pp: 25-50.

[65] P. Clements and L. Northrop. (2001). Software Product Lines: Practices and Patterns,

Addison-Wesley. [66] Lozano-Tello, A. and A. Gómez-Pérez (2002). BAREMO: how to choose the

appropriate software component using the analytic hierarchy process. In Proceedings of the 14th international Conference on Software Engineering and Knowledge Engineering (Ischia, Italy, July 15 - 19, 2002). SEKE '02. New York, NY, ACM. Volume 27: pp: 781-788.

[67] Bogue, R. (2006). "User Interface Reusability, Part 2: Tools and Techniques." Internet

Journal. [68] Swanson, M. E., Curry, S.K. (1989). Results of an asset engineering program.

Information and Management. Volume 16: pp: 207-16.

[69] Isoda, S. (1992). Experience report on software reuse project: its structure, activities, and statistical results. In Proceedings of the 14th international Conference on Software Engineering (Melbourne, Australia, May 11 - 15, 1992). ICSE '92. New York, NY, ACM: pp: 320-326.

[70] William B. Frakes and S. Isoda (September 1994). "Success Factors of Systematic Reuse." IEEE Software Volume 11(Issue 5): pp: 14-19.

[71] Larsen, G. (2006). "Model-driven development: assets and reuse." IBM Systems Journal Volume 45(Issue 3): pp: 541-53.

56

[72] Gaffney, Johan, et al. (1989). Software reuse-key to enhanced productivity: some quantitative models. Information and Software Technology. Volume 31: pp: 258-267.

[73] Favaro, J. (1991). What price reusability? A case study. In Proceedings of the First

international Symposium on Environments and Tools For Ada (Redondo Beach, California, United States, April 30 - May 02, 1990). New York, NY, ACM.

[74] Barnes. B, Durek. T, et al. (1988). A framework and economic foundation for

software reuse. In Software Reuse: Emerging Technology. Los Alamitos, CA, IEEE Computer Society Press: pp: 77-88.

[75] Margono, Johan, et al. (1992). Software reuse economics: cost-benefit analysis on a

large-scale Ada project. ICSE '92: Proceedings of the 14th international conference on Software engineering. Melbourne, Australia, ACM.

[76] Malan, R., K. Wentzel. (1993). Economics of Reuse, Revisited. Technical Report

HPL-93-31, Hewlett Packard Laboratories. [77] Rothenberger. M. A and N. D (2002). A cost-benefit model for systematic software

reuse. In Proceedings of ECIS 2002.

[78] D.L. Nazareth and M.A. Rothenberger (2004). "Assessing the cost-effectiveness of software reuse: a model for planned reuse." The Journal of Systems and Software 73 pp: 245–255.

[79] Parastoo Mohagheghi , R. C. (2007). "Quality, productivity and economic benefits of software reuse: a review of industrial studies." Empirical Software Engineering Volume 12(Issue 5): pp: 471-516.

[80] Jasmine K.S and D. R. Vasantha (2008). Cost Estimation Model For Reuse Based Software Products. proceedings of the International MultiConference of Engineers and Computer Scientists. Hong Kong. Volume 1: pp: 19-21.

[81] Barns, B. H. B., T.B. (1991). Making reuse cost-effective. Software, IEEE, IEEE

Computer Society. Volume 8: pp: 13-24. [82] Poulin, J. S., Caruso, J. M., and Hancock, D. R. (1993). "The business case for

software reuse." IBM Systems Journal Volume 32(Issue 4): pp: 567-594.

[83] Koltun, P., Hudson, A (1991). A reuse maturity model. In Fourth Annual Workshop on Software Reuse Herndon, VA.

[84] Davis, M. J. (1992). Stars reuse maturity model: Guidelines for reuse strategy formulation. In Proceedings of the Fifth Workshop on Institutionalizing Software Reuse, Palo Alto, California, USA.

[85] Davis, T. (1993). The reuse capability model: A basis for improving an organization’s

reuse capability. In Proceedings of 2nd ACM/IEEE International Workshop on Software Reusability, IEEE Computer Society Press / ACM Press: pp: 126–133.

[86] Wartik, S. a. D., T. (1999). "A phased reuse adoption model." The Journal of Systems

and Software Volume 46(Issue 1): Pp: 13-23.

[87] Rine, D. C. and N. Nada (2000). "An empirical study of a software reuse reference model." Information and Software Technology Volume 42(Issue 1): pp: 47-65.

57

[88] Almeida, E. S., Alvaro, A., Lucr´edio, D., Garcia, V. C., and Meira, S. R. L. (2004).

Rise project: Towards a robust framework for software reuse. In IEEE International Conference on Information Reuse and Integration (IRI). Las Vegas, USA, IEEE/CMS: pp:48–53.

[89] V. C. Garcia, D. L. e., A. Alvaro, E. S. Almeida, R. P. M. Fortes, and S. R. L. Meira (2007). Towards a maturity model for a reuse incremental adoption. In Brazilian Symposium on Software Components, Architectures and Reuse (SBCARS 2007). Campinas, S˜ao Paulo, Brazil, Brazilian Computer Society. .

[90] J. J. Marshall and R. R. Downs (2008). Reuse Readiness Levels as a Measure of Software Reusability. International Geoscience and Remote Sensing Symposium, IEEE. Volume 3: pp: III-1414-III-1417.

[91] William B. Frakes and C. J. Fox (1995). "Modeling reuse across the software life

cycle." Journal of Systems and Software, Volume 30(Issue 3): pp: 295-301.

[92] Leach, R. J. (1996). "Methods of Measuring Software Reuse for the Prediction of Maintainance Effort." Journal of Software Maintainance – Research and Practice, Volume 8(Issue 5): pp: 309–320.

[93] Doroshenko, E. E. (1998). "Toward a method for deriving measures of reuse."

Software Engineering Conference, 1998. Proceedings. 1998 Australian: pp: 170-183.

[94] Curry W., Succi, G., Smith, M., Liu, E., Wong, R., 1999. Empirical analysis of the correlation between amount-of-reuse metrics in the C programming language. In: Proceedings of the 1999 Symposium on Software Reusability. ACM Press, New York, pp: 35–140.

[95] Frakes, W. B., R. Anguswamy, et al. (2009). Reuse Ratio Metrics RL and RF. Demo.

11th International Conference on Software Reuse. Falls Church, VA, VA Springer. [96] Selby, R. W. (1989). Quantitative studies of software reuse. Software reusability: vol.

2, applications and experience, ACM: 213-233.

[97] V. R. Basili, H. D. Rombach, et al. (1990). Ada reusability and measurement, University of Maryland at College Park: 25.

[98] Guido, C., B. Francesco, et al. (1997). "The evaluation of framework reusability." SIGAPP Appl. Comput. Rev. 5(2): 21-27.

[99] Hironori, W., Y. Hirokazu, et al. (2003). A Metrics Suite for Measuring Reusability of

Software Components. Proceedings of the 9th International Symposium on Software Metrics, IEEE Computer Society.

[100] Rotaru, O. P. and M. Dobre (2005). Reusability metrics for software components.

Proceedings of the ACS/IEEE 2005 International Conference on Computer Systems and Applications, IEEE Computer Society.

[101] Chris, L. (2007). Assessing Module Reusability. Proceedings of the First International

Workshop on Assessment of Contemporary Modularization Techniques, IEEE Computer Society.

58

[102] Frakes, W. B. and B. A. Nejmeh (1986). "Software reuse through information retrieval." SIGIR Forum 21(1-2): 30-36.

[103] McCarey, F., M.Ó. Cinnéide, and N. Kushmerick (2006). "Recommending Library

Methods: An Evaluation of the Vector Space Model (VSM) and Latent Semantic Indexing (LSI)." in Proceedings of 2006 International Conference on Software Reuse: pp: 217-230.

[104] Parvinder Singh Sandhu, Hardeep Singh, et al. (2007). "A New Characterization Scheme of Reusable Software Components." IJCSNS International Journal of Computer Science and Network Security Volume 8(Issue 8).

[105] Frakes, W. B. and T. P. Pole (1994). "An Empirical Study of Representation Methods

for Reusable Software Components." IEEE Trans. Softw. Eng. 20(8): 617-630. [106] Rine, D. C. and N. Nada (1998). "An empirical study of a software reuse reference

model." Information and Software Technology Volume 42(Issue 1): pp:47-65. [107] William, B. F. and K. Kyo (2005). "Software Reuse Research: Status and Future."

IEEE Trans. Softw. Eng. 31(7): 529-536. [108] William, B. F. and J. F. Christopher. (1996). "Quality Improvement Using A Software

Reuse Failure Modes Model." IEEE Trans. Softw. Eng. 22(4): 274-279. [109] Frakes, B. (1990). "An Empirical Framework for Software Reuse Research."

Proceedings of the Third Workshop on Methods and Tools for Reuse , Syracuse University CASE Center Technical Report, no. 9014: Pp:. 5.

[110] Terry, C. (1993). Analysis and implementation of software reuse measurement,

Virginia Polytechnic Institute and State University, Master's Project and Report.

[111] Dr. P. K. Suri and N. Garg (May 2009). "Software Reuse Metrics: Measuring Component Independence and its applicability in Software Reuse." IJCSNS International Journal of Computer Science and Network Security Volume 9(Issue 5).

[112] J. Mascena, E. Almeida, et al. (2005). A Comparative Study on Software Reuse Metrics and Economic Models from a Traceability Perspective. IEEE Information Reuse and Integration. Las Vegas, USA.

[113] Jorge C. C. P. Mascena, Vinícius Cardoso Garcia, et al. (2006). "Admire: Asset

development metrics-based integrated reuse environment." In XX Brazilian Symposium on Software Engineering.

[114] Barry Boehm , A. Winsor Brown, et al. (2004 ). "A Software Product Line Life Cycle

Cost Estimation Model." Proceedings of the 2004 International Symposium on Empirical Software Engineering (ISESE'04): pp:156-164.

[115] J.S. Poulin and J. M. Caruso (1993). A reuse metrics and return on investment model.

selected papers from the 2nd. int’l workshop on software reusability advances in software. ReuseLucca, Italy, IEEE Computer Society Press: pp: 52-166.

[116] Emam, K. E. (2003). "Return on investment models". Klocwork Inc, Citeseer.

59

[117] Hall, P. A. V. (1987). "Software components and reuse." Computer Bulletin, Volume 3(Issue 4): pp: 14-15.

[118] Yglesias, K. P. (1993). "Information reuse parallels software reuse." IBM Systems

Journal, Volume 32(Issue 4): pp: 615-620. [119] N. Soundarajan, S. F. (1998). "Inheritance: From Code Reuse to Reasoning Reuse."

Fifth International Conference on Software Reuse ICSR'98: pp: 206. [120] Basili, V. R. (1990). "Viewing maintenance as reuse-oriented software development."

Software, IEEE Volume 7(Issue 1): pp: 19-25. [121] Kwon, O. C., Boldyreff, C. and Munro, M. (1998). "Software Configuration

Management for a Reusable Software Library within a Software Maintenance Environment." The International Journal of Software Engineering and Knowledge Engineering (IJSEKE).

[122] Oh-Cheon Kwon, Gyu-Sang Shin, et al. (1999). "Maintenance with Reuse: An

Integrated Approach Based on Software Configuration Management." Sixth Asia-Pacific Software Engineering Conference (APSEC'99): pp: 507.

[123] Bennett, K. H. and V. T. Rajlich (2000). Software maintenance and evolution: a

roadmap. In Proceedings of the Conference on the Future of Software Engineering. New York, NY, ACM: pp: 73-87.

[124] Baldassarre, M. T., Bianchi, et al. (2003). "Full reuse maintenance process for

reducing software degradation." Software Maintenance and Reengineering, 2003. Proceedings. Seventh European Conference on: pp: 289-298.

[125] Michael Jiang, J. Z., Hong Zhao and Yuanyuan Zhou (2008). "Enhancing Software

Product Line Maintenance with Source Code Mining." Lecture Notes in Computer Science, Wireless Algorithms, Systems, and Applications Volume 5258/2008: pp: 538-547.

[126] Tarak, G. (1993). "Dynamic impact analysis: a cost-effective technique to enforce

error-propagation." SIGSOFT Softw. Eng. Notes 18(3): 171-181. [127] D. Kung, J. Gao, et al. (1994). Change impact identication in object oriented software

maintenance. In Conference on Software Maintenance, Piscataway, NJ, IEEE. [128] L. Li and A. J. Offutt (1996). Algorithmic analysis of the impact of changes to

object-oriented software. ICSM. Monterey, CA, USA, IEEE: pp: 171–184. [129] Mikael Lindvall and K. Sandahl (1998). "How well do experienced software

developers predict software change?" Journal of Systems and Software Volume 43(Issue 1): pp: 19-27.

[130] Bohner, S. A. (2002). "Software change impacts-an evolving perspective." Software

Maintenance, 2002. Proceedings. International Conference on: pp: 263-272. [131] James Law and G. Rothernel. (2003). "Whole Program Path-Based Dynamic

Impact Analysis." Proceedings of the 25th Intl. Conference on SE, pp: 308-318.

60

[132] Alessandro, O., A. Taweesup, et al. (2004). An Empirical Comparison of Dynamic Impact Analysis Algorithms, Proceedings of the 26th International Conference on Software Engineering, IEEE Computer Society.

[133] Xiaoxia, R., S. Fenil, et al. (2004). "Chianti: a tool for change impact analysis of java

programs." SIGPLAN Not. 39(10): 432-448. [134] Hewitt, J. and J. Rilling (2005). "A light-weight proactive software change impact

analysis using use case maps." Software Evolvability, 2005. IEEE International Workshop on: pp: 41-46.

[135] Canfora, G. and L. Cerulo (2005). Impact Analysis by Mining Software and Change

Request Repositories. Proceedings of the International Symposium on Software Metrics. Coma, Italy: pp: 9-18.

[136] H.Z. Bilal, S. E. B. (2006). "Computing ripple effect for object oriented software." Quantitative Approaches in Object-Oriented Software Engineering (QAOOSE) workshop.

[137] Sue, B. (2001). "Computing ripple effect for software maintenance." Journal of Software Maintenance and Evolution: Research and Practice 13(4): 263-279.

[138] Sherriff, M. and L. Williams (2008). Empirical software change impact analysis using

singular value decomposition, In 1st IEEE International Conference on Software Testing. Lillehamer, Norway, IEEE Computer Society: pp: 268–277.

[139] Sai Zhang, Zhongxian Gu, et al. (2008). "Change impact analysis for AspectJ

programs." Software Maintenance, 2008. ICSM 2008. IEEE International Conference on.

[140] Mehboob, Z., Zowghi, D., and Lowe, D. (2009). An Approach for Comparison of

Architecture Level Change Impact Analysis Methods and Their Relevance in Web Systems Evolution. In Proceedings of the 2009 Australian Software Engineering Conference - Volume 00 (April 14 - 17, 2009). ASWEC. Washington, DC, IEEE Computer Society: pp: 162-172.

[141] Yau, S. S. and J. S. Collofello (1980). "Some Stability Measures for Software

Maintenance." Software Engineering, IEEE Transactions on Volume 6(Issue 6): pp: 545-552.

[142] Ye Wu, Dai Pan, et al. (2000). "Techniques of Maintaining Evolving Component-

Based Software." Software Maintenance, IEEE International Conference on, p. 236, 16th IEEE International Conference on Software Maintenance (ICSM'00): pp: 236.

[143] Lampson, B. W. and E. E. Schmidt (1983). "Organizing software in a distributed

environment." SIGPLAN Not. Volume 18(Issue 6): pp: 1-13.

[144] Tichy, W. F. (1985). RCS—a system for version control. Software—Practice & Experience Volume 15(Issue 7): pp: 637-654.

[145] Frakes, W. (2002). Configuration Management for Reusable Software. Technical

Report TR-02-29. Computer Science, Virginia Tech, Citeseer.

61

[146] V. Ambriola, L. Bendix, et al. (November 1990). "The evolution of configuration management and version control." Software Engineering Journal Volume 5: pp: 303–310.

[147] Aquilino, D., P. Asirelli, et al. (1991). Supporting reuse and configuration: a port

based SCM model. Proceedings of the 3rd international workshop on Software configuration management. Trondheim, Norway, ACM.

[148] J. Plaice and W. W. Wadge (1993). "A New Approach to Version Control." IEEE

Transactions on Software Engineering, Volume 19(Issue 3): pp: 268–276. [149] Josh MacDonald, Paul N. Hilfinger, et al. (1998). "PRCS: The Project Revision

Control System." Proceedings of the SCM-8 Symposium on System Configuration Management: pp:33-45.

[150] A.T. Ying, G.C. Murphy, et al. (2004). " Predicting Source Code Changes by

Mining Change History." IEEE Trans. Software Eng Volume 30(Issue 9): pp: 574-586.

[151] Thomas Zimmermann, Peter Weißgerber, et al. (2005). "Mining Version Histories to

Guide Software Changes." IEEE Transactions on Software Engineering, Volume 31(Issue 6): pp: 429-445.

[152] H. Gall, K. Hajek, et al. (1998). "Detection of Logical Coupling Based on Product

Release History." Proc. Int’l Conf. Software Maintenance (ICSM ’98): pp: 190-198. [153] Hassan, A. E. and R. C. Holt (2004). "Predicting Change Propagation in Software

Systems." Proceedings of the 20th IEEE International Conference on Software Maintenance: pp: 284-293.

[154] (1990). "IEEE Standard Glossary of Software Engineering Terminology." IEEE Std

610.12-1990: 1. [155] M. Page-Jones, The Practical Guide to Structured Systems Design. New York:

Yourdon Press, 1980. [156] J. Offutt, M.J. Harrold, et al. (1993). "A Software Metric System for Module

Coupling." Journal for Systems and Software Volume 20(Issue 3): pp: 295-308. [157] Edward B. Allen, Taghi M. Khoshgoftaar, et al. (2001). "Measuring Coupling and

Cohesion of Software Modules: An Information-Theory Approach." Seventh International Software Metrics Symposium (METRICS'01): pp: 124.

[158] Schach, S. R. and J. Offutt (2002). "On the Nonmaintainability of Open-Source

Software." Proc. Second Workshop Open Source Software Engineering: pp: 47-49. [159] Stephen R. Schach, B. J., David R. Wright, Gillian Z. Heller and Jeff Offutt (2003).

"Quality Impacts of Clandestine Common Coupling." Software Quality Journal Volume 11(Issue 3): pp: 211-218.

[160] Liguo Yu, Stephen R. Schach, Kai Chen, Jeff Offutt (2004). "Categorization of

Common Coupling and Its Application to the Maintainability of the Linux Kernel." IEEE Transactions on Software Engineering Volume 30(Issue 10): pp: 694-706.

62

[161] Bart Du Bois, Serge Demeyer, Jan Verelst. (2004). Refactoring — Improving Coupling and Cohesion of Existing Code, wcre, 11th Working Conference on Reverse Engineering (WCRE 2004), , pp:144-151.

[162] Schach, S. R. (2005). Object-Oriented and Classical Software Engineering, 6th

edition, McGraw-Hill. [163] Yu, L., S. R. Schach, et al. (2005). Reusability before and after reuse: a Darwin case

study. Empirical Software Engineering, 2005. 2005 International Symposium on. [164] Capiluppi, A. and C. Boldyreff (2007). Coupling Patterns in the Effective Reuse of

Open Source Software. In Proceedings of the First international Workshop on Emerging Trends in FLOSS Research and Development (May 20 - 26, 2007). FLOSS. Washington, DC, IEEE Computer Society.

[165] Thomas, L. G., S. R. Schach, et al. (2009). "Impact of release intervals on empirical

research into software evolution, with application to the maintainability of Linux." Software, IET 3(1): 58-66.

[166] Liguo, Y., C. Kai, et al. (2009). "Multiple-parameter coupling metrics for layered

component-based software." Software Quality Control ,17(1): 5-24. [167] Liguo, Y. and R. Srini (2005). Categorization of common coupling in kernel based

software. Proceedings of the 43rd annual Southeast regional conference - Volume 2. Kennesaw, Georgia, ACM.

[168] Kim, Y., Stohr, E. A. (1998). "Software reuse: survey and research directions." J.

Manage. Inf. Syst. Volume 14: pp: 113-147.

[169] Wang, H., Wang, C. (2001). "Open Source Software Adoption: A Status Report." IEEE Softw Volume 18: pp: 90-95.

[170] Sneed, H. M. (2004). A Cost Model for Software Maintenance & Evolution. In

Proceedings of the 20th IEEE international Conference on Software Maintenance (September 11 - 14, 2004). ICSM. Washington, DC, IEEE Computer Society: pp: 264-273.

[171] Christian, N., Christoph Breidert (2005). "The Challenges of Using Open Source

Software as A Reuse Strategy." European Journal for the Informatics Professional Volume 6(Issue 3): pp: 38-42.

[172] Sneed, H. M. (2008). "Offering software maintenance as an offshore service." Software Maintenance, 2008. ICSM 2008. IEEE International Conference on: pp: 1-5.

[173] Alspaugh, T. A., Asuncion, H. U., and Scacchi, W. (2009). Analyzing software

licenses in open architecture software systems. In Proceedings of the 2009 ICSE Workshop on Emerging Trends in Free/Libre/Open Source Software Research and Development (May 18 - 18, 2009). International Conference on Software Engineering. Washington, DC, IEEE Computer Society: pp: 54-57.

[174] Giuseppe, V. (2001). "Ageing of a data-intensive legacy system: symptoms and

remedies." Journal of Software Maintenance and Evolution: Research and Practice 13(5): 281-308.

63

[175] Alessandro Bianchi, D. C., Vittorio Marengo, Giuseppe Visaggio (2001). "Iterative Reengineering of Legacy Functions." 17th IEEE International Conference on Software Maintenance (ICSM'01),: pp:632.

[176] Frakes, W. B. and Gandel, P. B. (1990). Representing reusable software. Inf. Softw. Technol. 32, 10 (Dec. 1990), pp: 653-664.

[177] McIlroy, M. D. (1968). "Mass Produced Software Components." Software Engineering, NATO Science Committee.

[178] A. Abran, P. Bourque, R. Dupuis, and J. W. Moore, Eds. (2001). Guide to the

Software Engineering Body of Knowledge - SWEBOK, IEEE Press. [179] E. Almeida, A. Alvaro, S. Meira, (2005). RiSE Project: Key Developments in the

Field of Software Reuse. 15th PhDOOS Workshop Glasgow. Scotland. [180] Kitchenham, B. A. (2004). Procedures for performing systematic reviews. Keele

University Technical Report TR/SE-0401 and NICTA Technical Report 0400011T.1. [181] Charles W. Krueger, (2001). Easing the Transition to Software Mass Customization,

Revised papers from the 4th International Workshop on Software Product-Family Engineering, p.282-293, October 03-05, 2001.

[182] Beck, R. P.; Desai, S.R.; Radigan, R.P.; Vroom, D.Q. (1991). "Software reuse: a competitive advantage." Communications, 1991. ICC'91, Conference Record. IEEE International Conference on, Volume 3: pp: 1505-1509.

[183] B.A. Kitchenham, (2007). Guidelines for performing systematic literature reviews in software engineering, Tech. Rep., EBSE-2007-001, UK (July 2007). URL: <http//www.dur.ac.uk/ebse/>.

[184] Tie, F. and I. M. Jonathan (2006). Applying Dynamic Change Impact Analysis in Component-based Architecture Design. Proceedings of the Seventh ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing, IEEE Computer Society.

[185] Jaktman, C. B. McGuire, E.G. (1997). "An assessment process for reusable software assets." Innovation in Technology Management - The Key to Global Leadership. PICMET '97:Portland International Conference on Management and Technology, pp:602-605.

[186] Jeffrey, S. P. (1996). Measuring software reuse: principles, practices, and economic

models, Addison-Wesley Longman Publishing Co., Inc. [187] Parnas, D. L. (1972). "On the criteria to be used in decomposing systems into

modules." Commun. ACM 15(12): 1053-1058. [188] Afzal, W. Torkar, R.; Feldt, R (2009). "A systematic review of search-

based testing for non-functional system properties." Information and Software Technology Volume 51(Issue 6): pp: 957-976.

[189] Briand, L. C., Y. Labiche, et al. (2003). Impact Analysis and Change Management of

UML Models. Proceedings of the International Conference on Software Maintenance, IEEE Computer Society.

64

[190] J.A. Stafford, A. L. Wolf, M. Caporuscio. (2003). "The Application of Dependence

Analysis to Software Architecture Descriptions." Lecture Notes in Computer Science Vol. 2804 (Bernardo, Marco; Inverardi, Paola (Eds.)): pp: 52-62. .

[191] Kavitha, A. and A. Shanmugam (2008). Dynamic coupling measurement of object

oriented software using trace events. Applied Machine Intelligence and Informatics, 2008. SAMI 2008. 6th International Symposium on.

[192] M. Lee. (1998) Change Impact Analysis of Object-Oriented Software. Ph.D.

dissertation, George Mason University [193] Pfleeger, S. L. and S. A. Bohner (1990). A framework for software maintenance

metrics. Software Maintenance, 1990., Proceedings., Conference on. [194] Heisler, K. G., W. T. Tsai, et al. (1989). An object-oriented maintenance-oriented

model for software. COMPCON Spring '89. Thirty-Fourth IEEE Computer Society International Conference: Intellectual Leverage, Digest of Papers.

[195] Junqueira, D. C., Bittar, T. J., and Fortes, R. P. (2008). A fine-grained and flexible

version control for software artifacts. In Proceedings of the 26th Annual ACM international Conference on Design of Communication (Lisbon, Portugal, September 22 - 24, 2008). SIGDOC '08. ACM, New York, NY, 185-192.

[196] A. B. Deraman, and P. J. Layzell, (1993). Computer-Aided Software Maintenance: A

Classification and Analysis, Malaysian Journal of Computer Science, Vol. 6, pp: 21-42

[197] Reddy, Y. B., Weems, D., (1996). Software Maintenance and Software Reuse, 70th

Annual Meeting of the Louisiana Academy of Sciences, Nicholls State University, Thibodeaux, LA

[198] Frakes, W. and Terry, C. (1994). Reuse Level Metrics. Proceedings 3rd International

Conference on Software Reuse. [199] Victor, R. B., C. B. Lionel, et al. (1996). "How reuse influences productivity in object-

oriented systems." Commun. ACM 39(10): 104-116. [200] Prem, D., K. Sakke, et al. (1996). Analytical and empirical evaluation of software

reuse metrics. Proceedings of the 18th international conference on Software engineering. Berlin, Germany, IEEE Computer Society

[201] Benedicenti, L. Succi, G. and Vemazza, T. (1997). Guidelines to Determine the

Impact of Code Reuse on Productivity. University of Genova, DIST-LIPS-TR-97002. [202] Lucas, C., P. Steyaert, et al. (1997). Managing software evolution through reuse

contracts. Software Maintenance and Reengineering, 1997. EUROMICRO 97., First Euromicro Conference on.

[203] Kim, Y. and Stohr, E. A. (1991). Software Reuse: Issues and Research Directions,

working paper,Center for Research on Information Systems, Stern School of Business, New York University, New York

[204] Sharma, A., Grover, P. S., and Kumar, R. (2009). Reusability assessment for software

components. SIGSOFT Softw. Eng. Notes 34, 2, 1-6.

65

[205] C. Wohlin, P. Runeson, et al. (2000). Experimentation in Software Engineering: An

Introduction. Norwell, MA, USA, Kluwer Academic Publishers. [206] Creswell, J. W. (1994). Research Design: Qualitative and Quantitative Approaches.

Thousand Oaks, London, SAGE Publications. Excluded Study: [207] Cyril Montaberta and D. S. McCrickarda (August 2009). An integrative approach to requirements analysis: How task models support requirements reuse in a user-centric design framework, Elsevier. Volume 21: pp: 304-315.

66

APPENDIX Table 13 gives the full forms and definitions to the abbreviations

Abbreviations (full forms) Details

AC (Academic case study) Validated by considering an academic case study( use of assumed values)

AE (Academic experiment)

Validated by considering an academic experiment (use of assumed values)

AGE Aging

AL Algorithms

Ap (Approach) The studies which mentioned the way to solve a problem

AR Architecture

ARM Amount of reuse metrics

C (Category) The categories in different section

CIA Change Impact Analysis

COS Cost benefit analysis models

DA Data

DE Designs

DO Document

E.T Extension To

ET Estimation Templets

Ex Example

FMM Failure modes models

Fr (Framework) Framework is the underlying structure defined for accomplishing a task

HI Human Interfaces

KN Knowledge

IC (Industrial case study) Validated by considering the case study in the industrial scenario(use of industrial values)

67

IE (Industrial Experiment) Validated by considering an experiment in an industrial environment (use of industrial values)

LEG Legal Issues

MAT Maturity Assessment

MD Models

MDP Module Dependencies

Me (Metric) Metric is a quantifiable measurement of an attribute of a software product.

ML Modules

Mn (Mention) For example: Requirements are just mentioned they can be reuse but there is no discussion on how to reuse

Mo (Model) A Model is a stated relationship among metric variables

Mt (Method) A Method is an orderly procedure

NV (Non-validated) The models/metrics/methods which are not validated

PL Plans

RAS Reusability Assessment

RLM Reuse Library Metrics

R.no (Reference number) Study reference number

RQ Requirements

Rw (Reviews) The literature review of previous studies

SC Service Contracts

SCM Software Configuration Management

STR Strategies

Sy (Survey) The results of survey of a group of people or employees in some companies

TC Test Cases

Tl (Tool) If the authors proposed a tool

Table 13: Abbreviations used in Tables and Figures

68

A2. Result table of Section 2, Reusable assets For all result tables in sections A2, A3 and A4 in appendix, the below are the common points: 1. Each and Every table is presented with detailed results.

2. If any article belongs to a particular study then that article is given a “1” near that study type.

3. “1” is considered as Tick mark.

4. For example: take reference [1] we have marked “1” near IC(industrial case study ) and Mo (model) so it means that the study is on a model and it was industrially validated.

2.1. Algorithms

R. No

Year C Validation N.V E.T Me Mo Mt/Tl Discussion Rw Description

IC AC AE IE Sy Ap Mn [25] 1997 AL 1 Mentioned that algorithms can be reused and also

suggested key goals for an algorithm to be reusable.

Table 14: Result Table for Algorithms Reuse

2.2. Architecture

R. No


IC AC AE IE Sy Ap Mn [34] 1992 AR 1 Discussed on architecture

[38] 1992 AR 1 1 Proposed a method for the reuse of design and architecture.

[41] 1995 AR 1 Presented a domain model which identifies the commonalities and variabilities of the systems that are in the application domain. The degree of variability is analyzed and the application domain having the stable, well-understood application domain will be the most appropriate one for domain modeling. Architecture is evolved making use of such domain.

[36] 1996 AR 1 Discussed on architecture



[39] 1998 AR 1 1 Discussed how the architectural elements as reusable assets of an Architectural Description Language (ADL) can be characterized. The main

69

intension of this approach is to identify the basic idea of the domain architecture that determines the family of architectures and to use this idea to develop the constructs and semantics of an ADL.

[40] 1998 AR 1 1 Suggested an architecture based approach. Its main motive is to develop a core system which combines the reuse of architecture with the reuse of other reusable artifacts which are related to the architecture.

[42] 1999 AR 1 1 Proposes a method which makes use of high level UML constructs for the reuse of architecture.

[37] 2008 AR 1 Discussed on Architecture and different asset types in it.

Table 15: Result Table for Architecture Reuse

2.3. Data

R. no.

Year C Validation N.V E.T Me Mo Mt/Tl Discuss Rw Description

IC AC AE IE Sy Ap Mn [21] 1993 DA 1 1 Discussed on data reuse (approach)

[1] 1994 DA 1 Discussed on data reuse




Table 16: Result Table for Data Reuse

2.4. Design

R. no.


IC AC AE Ex Sy Ap Mn [26] 1989 DE 1 1 Presented a model for representing and manipulating

the module level software design information leading to the effective reuse of it.

[29] 1992 DE 1 This study is a thesis work and is a discussion on design reuse as a strategy for incremental new product development.

[33] 1993 DE 1 1 The study tells us that when designers operate in a workplace with low-cost access to reusable analysis

70

and design knowledge. Software reusability is a natural consequence of the reuse of analyses and designs and developed and validated a process for constructing such workspaces.

[21] 1993 DE 1 Mentioned design can be reused

[30] 1994 DE 1 1 This study discussed on design reuse and proposed a framework for the reuse of software design knowledge recorded by means of IBIS tool. The demonstration of framework is done with an example.

[28] 1995 DE 1 Discussion on design reuse. Focused on how the methods for design reuse in chemical engineering can be adopted for software engineering.

[22] 1996 DE 1 Mentioned design can be reused

[32] 2005 DE 1 1 This study discusses an approach. The approach has been implemented in an experimental system call “Ease Design”.

[58] 2006 DE 1 Discussed on software design knowledge reuse

[27] 2008 DE 1 A general discussion on design reuse.

Table 17: Result Table for Design Reuse

2.5. Documentation

R. no.


IC AC AE IE Sy Ap Mn

[5] 1993 DO 1 1 1 This study tested the 4 approaches to reuse through a comparision experiment.

[21] 1993 DO 1 Discussed on Documentation reuse

[3] 1996 DO 1 1 Presented a natural means of reusing a document

[4] 1996 DO 1 1 This study presented a natural means of reusing any kind of document.

[22] 1996 DO 1 Discussed on documentation reuse

[7] 1996 DO 1 1 Proposed a model and tested it on his own document

[23] 1997 DO 1 Mentioned on documentation reuse

[8] 1998 DO 1 This study discussed on documentation reuse

[6] 2006 DO 1 [5] 1 This study proposed a conceptual framework that describe the services (that are able to determine the similarities between the original document) and reuse fragments and their interactions.

Table 18: Result Table for Documentation Reuse.

71

2.6. Estimation templates

R. no.



[21] 1993 ET 1 Mentioned Estimates reuse

[22] 1996 ET 1 Mentioned that Estimates can be reused

Table 19: Result Table for Estimates Reuse.

2.7. Human interfaces

R. no.



[68] 1989 HI 1 Mentioned as user interface as an asset.

[21] 1993 HI 1 Mentioned as asset.



[67] 2006 HI 1 1 1 Discussed about the tools and techniques that can be used to construct reusable User Interfaces.

Table 20: Result Table for Human Interface Reuse

2.8. Knowledge

R. no.


IC AC AE IE Sy Ap Mn [117] 1987 KN 1 Discussed knowledge (ideas) as reusable asset

[118] 1993 KN 1 Discussed knowledge (information) as reusable asset.

[119] 1998 KN 1 Discussed knowledge (reasoning) as reusable asset.

[64] 1999 KN 1 1 Proposes a tool which emphasizes on the continuous learning and the reuse of all forms of experiences from the domain.

[65] 2001 KN 1 Discussed Knowledge as reusable asset

[60] 2001 KN 1 1 Proposed a KM process model and discusses the

72

integration of continuous process improvement to it. Validated this in an industrial case study.

[59] 2004 KN 1 1 Proposes a cognitive heuristics such as anchoring and adjustment, helps to predict issues that occurs when a code or design is reused.

[61] 2005 KN 1 1 Discusses on the types of knowledge reuse and the factors influencing them

[58] 2006 KN 1 1 Presents a CASE tool for the Design knowledge reuse by the use of Case Based Reasoning Approach

[31] 2008 KN 1 1 Proposed a model to analyze the factors like when and how the individuals reusing knowledge assets benefit.

[62] 2009 KN 1 1 1 Discusses the effective integration of the Knowledge management process in to software testing. Also discussed few key technologies. Validated in QESuite2.0.

Table 21: Result Table for Knowledge Reuse.

2.9. Models

R. no.


IC AC AE IE Sy Ap Mn [71] 2006 MD 1 1 Discussed about Model as an asset

and present some steps for the Identification, organizing, packaging, publishing and reusing the Models

Table 22: Result Table for Model reuse.

2.10. Modules

R. no.


IC AC AE IE Sy Ap Mn [187] 1972 ML 1 Was the first to introduce the concept

of modularization.

[69] 1992 ML 1 Discussed about the reusable Modules

[70] 1994 ML 1 Discussed about the reusable Modules

[23] 1997 ML 1 Discussed about the reusable Module

Table 23: Result Table for Modules Reuse.

73

2.11. Plans

R. no.



[11] 1990 PL 1 1 Presented a theory of plan modification which is used removing inconsistencies in the validation structure of a plan, while it is being reused in the new changed planning situation.

[21] 1993 PL 1 Mentioned about plan reuse

[9] 1994 PL 1 1 Tested the hypothesis of plan reuse empirically

[10] 1994 PL 1 1 Focused on developing the solutions to some underlying problems and evaluating them




Table 24: Result Table for Plans Reuse.

2.12. Requirements

R.

No



[53] 1991 RQ 1 1 Proposed a knowledge base structuring mechanism called ARIES to reduce the issues due to communication problems and misunderstanding.

[34] 1992 RQ 1 Discussed about requirements

[52] 1993 RQ 1 1 Proposed a methodological approach for the requirements specification reuse which is based on using a model which is used to maintain reuse and project histories

[50] 1995 RQ 1 1 Presented a technique for writing Reusable requirement specification (SMARTe Requirement). This is validated by a case study on earth remote sensing (ERS-1).


[47] 1996 RQ 1 1 Proposes a model for the identification of the analogies in the requirement specification for promoting analogical reuse.



[46] 1997 RQ 1 1 1 Proposed an approach which is based on the current domain analysis techniques and applied these

74

techniques to generate a core-set of generic requirements. A form based tool is also developed for the reuse of requirements specifications in the newer versions.

[51] 1997 RQ 1 Discusses 10 practical steps which are followed at Rolls-Royce for systematic requirements reuse.

[56] 1997 RQ 1 1 Proposed an analogical reasoning technique which is used for the completion of the partial requirement specifications. A rich requirements meta-model combined with the formal assertion language will increase the analogical reuse effectiveness.

[54] 1998 RQ 1 1 Proposed a reuse based approach which is used to specify system requirements based on the requirement patterns.

[55] 2002 RQ 1 1 Proposed a meta-model which is an integration of various types of semiformal diagrams into a requirements reuse approach

[48] 2005 RQ 1 1 Proposed a model for the reuse of requirements specification through task modeling in a Notification System Design. Validated by a usability study.

[57] 2005 RQ 1 1 Proposed a method for producing requirements as a core asset for product families by analyzing the commonality and variability factors. Validated on e-travel system.

[43] 2008 RQ 1 1 1 A systematic approach, MIA for requirements reuse was proposed It helps in identifying the common requirements of a product family. A tool is also developed for the reuse of requirements in real projects.

[49] 2008 RQ 1 1 Proposed an approach for requirements reuse based on the forecasting of user needs. But failed to discuss regarding the knowledge acquisition.

[207]

2009 RQ 1 [16] 1 Proposed an integrated approach for requirements analysis. It integrates task modeling and critical parameters with scenario-based design in a user centric design framework which leads to project success. This approach aims at encouraging the user involvement and leveraging the requirements process for accuracy with less cost. (OUT OF SCOPE- Published in August, 2009)

[45] 2009 RQ 1 1 Proposed a method for requirements reuse which integrates software reuse in the context of Product Line, to improve the Requirement Engineering in a Distributed Software Development Environment

Table 25: Result Table for Requirements Reuse.

75

2.13. Service Contracts

R.

No



[202] 1997 SC 1 Discussed that Service contract reusability.

[24] 2005 SC 1 Discussed that Service contract reusability.

Table 26: Result Table for Service Contract Reuse.

2.14. Test case/ Test design

R.

No

Year C Validation N.V

E.T

Me Mo

Mt/Tl Discuss Rw

Description

IC AC

AE IE Sy Ap Mn

[21] 1993 TC 1 Mentioned that Test cases can be reused

[15] 1993 TC 1 1 This paper explained their Domain Based Testing tool which provides structure for the generation of test cases and for reusing of test cases. It is used to increase test case reuse.

[14] 1995 TC 1 1 In this study discusses on the test cases reuse and presents an algorithm which uses a semantic language help to reduce the cost of regression testing

[22] 1996 TC 1 Discussed on test case/test design reuse

[17] 1998 TC 1 Discussed on test case reuse

[18] 2002 TC 1 In this paper gave an overview of building reusable test assets.

[16] 2004 TC 1 Discussed on test case reuse

[19] 2008 TC 1 1 The authors propose a regression testing methodology which is called as partitioning of domain testing for analyzing the input domains of the older or previous versions and the modified or new versions so the test cases can be maximally reuse.

[20] 2008 TC 1 This study discussed on test case reuse

[13] 2008 TC 1 This study discussed on test case reuse

Table 27: Result Table for Test Case/ Test Plan Reuse.

76

A3. Result tables for section 3, Reuse metrics and models

In this section we present the result tables for research question RQ2

3.1 Cost benefit analysis models

R.

no.

Year C Validated N.V E.T Rw Me Mo Mt Fr Ap Validation

of

Description

IC AC AE

IE Sy

[74] 1988 COS 1 1 This model was used by [73] in his work in an industrial setting

(as mentioned in [22])

[72] 1989 COS 1 1 Cost of development model (applied to a large scale Ada project for assessing the economic benefits of a reuse effort on it) [22].

[73] 1991 COS 1 [74] This study used the model of [74] in its work

[81] 1991 COS 1 1 This study proposed and approach for good reuse investment or quality of investment Q where

Q=B/R (B=reuse benefits R=reuse investments)

[75] 1992 COS 1 [72] Applied the model of [72] in an large scale Ada project and also tried to compare it to other models like GTE-Contel model and JIAWG model

[76] 1993 COS 1 1 This study proposed a model to overcome the deficiencies that are in the earlier models. This paper presented this model in a series of stages, where each stage expands the factors considered to be expanded.

[82] 1993 COS 1 1 Presented metrics used by IBM to estimate the effort saved by reuse.

[115] 1993 COS 1 1 Described the reuse metrics and return on investment process in place of IBM

[22] 1996 COS 1 This study is a review of existing cost benefit analysis models.

[77] 2002 COS 1 1 This study developed A Domain Specific Cost Benefit model.

[78] 2003 COS 1 1 This study developed A Domain Specific Software Reuse model

[116] 2003 COS 1 1 Discussed on return on investment.

[114] 2004 COS 1 1 Proposed a COPLIMO ( constructive product line investment model)

[79] 2007 COS 1 Reviewed the journals between 1994 – 2005 to gather the evidences of successful software reuse programs in industry.

[80] 2008 COS 1 1 Proposed economic model for cost analysis

Table 28: Result Table for Cost Benefit Analysis.

77

3.2. Maturity Assessment Models

R.

no.


of

Description

IC AC AE IE Sy

[83] 1991 MAT 1 1 In this study a reuse maturity model is developed but it is not applied in any real case study.

( As is also mentioned in [22])

[84] 1992 MAT 1 [83] 1 This study presented reuse maturity model of STARS project

[85] 1993 MAT 1 [84] 1 This study presented reuse capability model which is an advancement of STARS reuse maturity model

[22] 1996 MAT 1 A review on maturity assessment models

[106] 1998 MAT 1 [85] In this study work RCM of [85] proved to be unstable

[86] 1999 MAT 1 [85] 1 This study presented a Phased model which will reduce the initial risk in the reuse adoption.

[87] 2000 MAT 1 1 This study presented RRM (reuse reference model) (as mentioned in [89])

[88] 2004 MAT 1 1 RiSE Maturity Model was developed during rise project.

[89] 2007 MAT 1 1 [88] This study Reviewed the RiSE maturity model

Table 29: Result Table for Maturity Assessment Models.

3.3. Amount of Reuse Metrics

R.

no.


of

Description

IC AC AE IE Sy

[109] 1990 ARM 1 1 Proposed a model for reuse level

(as is also mentioned in [22])

[110] 1993 ARM 1 [109]

1 Extended this formal [109] model by adding a variable reuse “threshold level” that had been arbitrarily set to one in the original model.

(as is also shown in [22])

[82] 1993 ARM 1 1 Presented reuse percentage (means the ratio of reused lines of code to the total number of lines of code). May be the same type of formulae can be considered to other assets.

[198] 1994 ARM 1 1 Presented reuse level metric (means the percentage of different items that are reused directly vs. total items used) and reuse frequency metric (means the percentage of references to directly reused items vs. total references).

[91] 1995 ARM 1 1 This study reported on strong correlation

78

between reuse levels of various life cycle objects and also reported on two kinds of models for predicting the amount of reuse of life cycle objects (developed based on these correlations

[92] 1996 ARM 1 1 This study presented a number of techniques and methods for the measurement of amount of reuse

[199] 1996 ARM 1 1 Presented reuse rate metric (means the percentage of reused code within the system due to either slightly modified reuse or verbatim (direct) reuse).

[22] 1996 ARM 1 1 1 This study is a review of amount of reuse metrics and also presented a general metric for measuring the amount of reuse

[200] 1996 ARM 1 1 Presented reuse size and frequency metric which is same as reuse frequency and in addition to that it also take into consideration the items size that is in the number of lines of code.

[93] 1998 ARM 1 1 This study presented a method that will support measuring the amount of reuse with different software models.

[94] 1999 ARM 1 Presented an analysis of existing amount of reuse metrics and applied to a collection of public domain software products for understanding the level of correlation that exists between them.

[112] 2005 ARM 1 A part of study discuss on amount of reuse metrics

[113] 2006 ARM 1 A part of study discuss on amount of reuse metrics

[95] 2009 ARM 1 A review on the reuse level and reuse frequency

[111] 2009 ARM 1 A discussion on amount of reuse metrics

Table 30: Reuse Table for Amount of Reuse Metrics.

3.4. Failure Modes Model

R.

no.


of

Description

IC AC

AE IE Sy

[108] 1996 FMM

1 1 In their study presented the failure modes model

[22] 1996 FMM

1 A review of Failure modes model

Table 31: Reuse Table for Failure Modes Model.

79

3.5. Reusability Assessment

R.

no.


of

Description

IC AC AE IE Sy

[96] 1989 RAS 1 1 In his study of NASA software identified module attributes which distinguishes the black box reuse modules and others.

(as mentioned in [22])

[97] 1990 RAS 1 1 This study proposed methods for two reuse studies of systems written in Ada.

[22] 1996 RAS 1 A Review of reusability assessment metrics

[98] 1997 RAS 1 1 Proposed a reusability metrics for frameworks reusability

[99] 2003 RAS 1 1 Proposed a metrics suit that composed of six metrics which are proved to be used to measure the component's reusability through experimental validation.

[100] 2005 RAS 1 1 1 Proposed Metrics and mathematical models

[101] 2007 RAS 1 1 Proposed a framework for assessment of reusability of modules

[90] 2008 RAS 1 1 Discussed on the Reuse Readiness Levels model (helps reusers of software in measuring the software reusability).

[204] 2009 RAS 1 1 This paper proposed an artificial neural network based approach for assessing the reusability of software component

Table 32: Result Table for Reusability Assessment.

3.6. Reuse Library Metrics

R.

no.


of

Description

IC AC AE IE Sy

[102] 1986 RLM 1 1 Proposed Metrics (indicators of quality of assets) (as mentioned in [22])

[105] 1994 RLM 1 1 Regarding understanding metrics. This study did a survey to measure the support for understanding, that is provided by the classification methods (Ex: enumerated, faceted etc ;) using a 7 point ordinal scale (7=best). The subjects were asked to rate on this scale.

[22] 1996 RLM 1 1 Metrics for indexing costs, search effectiveness, Efficiency

[103] 2006 RLM 1 1 Demonstrated their model RASCAL regarding search effectiveness

[104] 2007 RLM 1 1 Demonstrated their model which works on the semantic relation and doublet and triplet organization of words regarding search effectiveness

Table 33: Result Table for Reuse library metrics.

80

A4. Result tables for section 4, Maintenance of Reusable Software. In this section we present the result tables for research question RQ3

4.1. Strategies

R. no.

Year C Validation N.V E.T Rw Ap Mo Me Mt Tl Validation of

Description

IC AC AE IE Sy

[120] 1990 STR 1 1 1 First person to discuss reuse in terms of maintenance and development. Also proposed a simple reuse model.

[196] 1993 STR 1 1 1 Did an analysis to suggest the general requirements which are essential for an Integrated toolset for Computer Aided Software Maintenance.

[197] 1996 STR 1 1 Proposed a new type of maintenance called Reconstructive maintenance.

[121] 1998 STR 1 1 1 1 Proposed an Integrated approach of software reuse, maintenance and SCM. Proposed a TERRA Tool support.

[122] 1999 STR 1 [121] 1 [121] Discussed the drawbacks by implementing the TERRA Tool.

[123] 2000 STR 1 1 Suggested a staged model for software maintenance which consists of the five distinct stages in software development life cycle. Also suggested an amplified version for the staged model called Versioned Staged Model.

[124] 2003 STR 1 [120] 1 1 Did a comparitative study between the Full-Reuse and Iterative-Enhancement Model and concluded that Full-Reuse Model degrades software quality. Also developed RAPID Tool

[125] 2008 STR 1 1 Proposed an approach which is a combination of data mining, defect tracking system and SCM for simplifying the maintainability of software and improving the traceability of the reusable module finally leading to the improvement of software quality.

Table 34. Result Table for Strategies.

4.2. Change Impact Analysis

R. no. Year C Validation N.V E.T Rw Ap Mo Me Mt Tl Validation

of Description

IC AC AE IE Sy

[141] 1980 CIA 1 1 Proposed an approximated algorithm for Ripple Effect.

[194] 1989 CIA 1 1 Proposed an object-oriented model for maintaining software. Also, made use of ripple effect analysis as well as program slicing to anticipate the potential effects when a change is made.

81

[193] 1990 CIA 1 1 Focused on change impact analysis and proposed a metrics based on the traceability graph to measure the stability of the whole system including documentation.

[126] 1993 CIA 1 Discusses change impact analysis in terms of source code

[127] 1994 CIA 1 1 1 Proposed an algorithmic Approach to identify the changes parts of the system for OO systems.

[128] 1996 CIA 1 1 Proposed an algorithmic approach to analyze the proposed changes in OO systems and to quantitatively calculate change impacts.


[192] 1998 CIA 1 1 1 1 1 Proposed an analysis technique for object oriented systems. Proposed a set of metrics to quantitatively measure the object oriented change impact. Validated using Chat tool

[142] 2000 CIA 1 1 Proposed a new technique which uses the static analysis which helps to analyze the interfaces, events and dependency relationships which were impacted by the modification in the maintenance activity

[130] 2002 CIA 1 1 Did a preliminary research for extending current software change impact analysis in order to include interoperability dependency relationships to address distributed applications and to explore three dimensional visualization techniques for more effective navigation of software changes.


[190] 2003 CIA 1 1 1 Proposed a dependence analysis technique for software architecture called chaining which can support software architecture development such as debugging and testing. Also, validated using Aladdin Tool

[189] 2003 CIA 1 1 Proposed a UML model-based approach to impact analysis in analysis/design documents that can be applied before a change is made, thereby allowing an early decision-making and change planning process

[132] 2004 CIA 1 Compares the Dynamic Impact Analysis Algorithms

[133] 2004 CIA 1 1 1 Proposed Chanti Tool for change impact analysis for java programs

[134] 2005 CIA [126]

[129]

[131]

1 Proposed a light weight proactive CIA approach which deals with analyzing the requirement changes using Use Case Maps

[135] 2005 CIA 1 1 Proposed a method to find out source files impacted by a proposed change request by using information retrieval algorithms.

[184] 2005 CIA 1 1 1 Proposed a component interaction based approach for the Change Impact analysis at architectural level for component based systems. Also an architecture design for a tool SOCIAT is also introduced

[136] 2006 CIA 1 [128] 1 Proposed reformulated approximated algorithm to calculate the ripple effect for OO programs

[137] 2008 CIA 1 [141] 1 1 Proposed REST tool which uses approximated algorithm to calculate the

82

ripple effect for C programs which is reformulation to Yau and Collofello's ripple effect.

[138] 2008 CIA 1 1 Suggests an impact analysis methodology that uses historical change records for both executable and non-executable files in a software system to identify and prioritize potentially affected areas of a system modification based on risk.

[139] 2008 CIA 1 1 Proposed a method for CIA for AspectJ Programs using atomic changes representation to identify semantic difference between two versions.

[140] 2009 CIA 1 1 Discussed an approach for the comparision of the change impact analysis methods based on the architectural level.

Table 35: Result Table for Change Impact Analysis.

4.3. Software Configuration Management

R.

no.

Year C Validation N.V E.T Rw Ap Mo Me Mt

Tl Validation

of

Description

IC AC AE IE Sy

[143] 1983 SCM 1 1 1 Proposed System Modeller Tool for Cedar Programming Languages.

[144] 1985 SCM 1 1 1 Proposed a RCS- a revision control tool. Presented a survey on version control tools.

[146] 1990 SCM 1 1 1 Discussed about SCCS and make tools. Also discussed 3 technological generations of tools which are integration of SCM and VC. Focused on their strengths and drawbacks.

[147] 1991 SCM 1 1 Proposed a Port Based SCM for supporting software reuse and configuration of the system.

[148] 1993 SCM 1 1 Proposed an algebraic version language of histories, subversion and joins.

[149] 1998 SCM 1 [144] 1 1 Proposed a Project Revision control System(PRCS) which has a clean user interface compared to RCS

[152] 1998 SCM 1 1 Was the first to present an approach that detects logical coupling based on the release data.

[145] 2002 SCM 1 Discussed about the concepts of SCM.

[150] 2004 SCM 1 1 Proposed an approach that uses association rule mining to predict the change patterns in the modification task

[153] 2004 SCM 1 1 Presented Heuristics to predict change propagation.

[151] 2005 SCM 1 1 1 Proposed a ROSE Tool which makes use of evolutionary coupling to predict changes which helps to notify the developer, errors due to incomplete changes and undetected coupling by the program analysis.

[195] 2008 SCM 1 1 1 Proposed a model for fine grained version control. Also proposed a tool

Table 36: Result Table for Software Configuration Management

83

4.4. Module Dependencies

R.

no.

Year C Validation N.V E.T Rw Ap Mo Me Mt Tl Validation

of

Description

IC AC AE IE Sy

[187] 1972 MDP 1 Was the first to introduce the concept of modularization.

[155] 1980 MDP 1 Discussed on the coupling and cohesion issues. Also proposed scales for measuring the severity of the scales.

[156] 1993 MDP 1 Suggested the scales for finding the severity of the coupling.

[157] 2001 MDP 1 1 Proposed an Information Theory Approach for measuring the coupling and cohesion of the modules.

[158] 2002 MDP 1 1 Validated 365 versions of Linux and proved that the common coupling increases as the modules, version numbers and their interactions increases.

[159] 2003 MDP 1 [158] Validated using 391 versions of Linux and proved that best way to avoid clandestine common coupling is by avoiding common coupling.

[160] 2004 MDP 1 1 Classified the global variable in to 5 categories to predict safe and unsafe maintenance. Validated on 400 versions of Linux.

[161] 2004 MDP 1 1 Proposed a set of refactoring guidelines which are needed to improve the characteristics of the coupling and cohesion in terms of code in particular.

[162] 2005 MDP 1 Suggested the scales for finding the severity of the coupling.

[163] 2005 MDP 1 [160] [167] Proposed a categorization of common

coupling which makes it easy to measure the maintainability. Implemented it on the Darwin Operating System.

[167] 2005 MDP 1 [160] 1 Proposed a categorization of common coupling which is easy to measure the maintainability of the kernel based system.

[164] 2007 MDP 1 1 Proposed a set of guidelines to improve reusability in terms of source code folders.

[191] 2008 MDP 1 1 Proposed a dynamic coupling measurement technique.

[165] 2009 MDP 1 [158]

[159]

Proved that the common coupling should be calculated on temporal variables like release dates rather than release sequence number. Validated on Linux.

[166] 2009 MDP 1 1 Proposed coupling metrics which is used to measure the coupling components by making use of a parameter called coupling distance.

Table 37: Result Table for Module Dependencies

84

4.5. Legal Issues

R.

no.


of

Description

IC AC AE IE Sy

[168] 1989 LEG 1 Discussed 2 issues: Protecting Software from illegal use and framing contractual and legal issues for sharing the resources for maintainability and reusability.

[70] 1994 LEG 1 Discusses on Legal issues.

[169] 2001 LEG 1 Discussed regarding the licensing issues.

[170] 2004 LEG 1 Discussed regarding the legal issues concerning the negotiation of service level agreement.

[171] 2005 LEG 1 Discusses the licensing issues between COTS and FOSS.

[172] 2008 LEG [170] 1 Discussed regarding the legal issues concerning the negotiation of service level agreement.

[173] 2009 LEG 1 1 Proposes an approach for automatically analyzing license interactions and validated it by applying on ArchStudio4.

Table 38: Result Table for Legal Issues.

4.6. Aging Symptoms

R.

no.


of

Description

IC AC AE IE Sy

[174] 2001 AGE 1 1 1 Provides individual metrics for a list of aging symptoms and finds the relative improvement operations to overcome the symptoms. Also, shows the efficacy of the improvements. This knowledge is important as it can be reusable.

[175] 2001 AGE 1 [174] 1 Proposes a method for the gradual reengineering of the procedural components of a legacy system.

Table 39: Result Table for Aging Symptoms.

85

Chapter number/Chapter

name

Reference numbers Total no. of studies

1 / Introduction 176,177,179,180,181,182,183,188,203,205,206,185 12

2 / Reusable Assets

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, 29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51, 52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,117,118,119, 187,202,207,154,168

79

3 / Value of reuse 22,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94, 95,96,97,98,99,100,101,102,103,104,105,106,107,108,109,110,111,112,113,114,115,116,186,198,199,200,201,204

52

4/ Maintenance 22,70,120,121,122,123,124,125,126,127,128,129,130,131,132,133,134,135, 136,137,138,139,140,141,142,143,144,145,146,147,148,149,150,151,152, 153,154,155,156,157,158,159,160,161,162,163,164,165,166,167,168,169, 170,171,172,173,174,175,178,184,187,189,190,191,192,193,194,195,196, 197

70

Total 213 (studies) – 6 (duplicates) – 1(out of scope study [207]) 206

Table 40: Reference List for Chapter 2, 3 and 4 ( marked ones are duplicates = total 6 duplicates (4 appears twice and 1 appears trice))

A Systematic Mapping Study on Software Reuse831637/FULLTEXT01.pdfFirst and foremost, we owe a lot to...

Documents

Transcript of A Systematic Mapping Study on Software Reuse831637/FULLTEXT01.pdfFirst and foremost, we owe a lot to...