Thesis Final Draft MSE 2010 07 PDF

Master Thesis
Software Engineering
Thesis no: MSE-2010:07
April 2010
A Systematic Mapping Study on

Software Reuse
Bhargava Mithra Konda and Kranthi Kiran Mandava
School of Computing
Blekinge Institute of Technology
Box 520
SE 372 25 Ronneby
Sweden
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, Folkparksvgen 16, 372 40, Ronneby, Sweden
E-mail: bhargavmitra@gmail.com
Kranthi Kiran Mandava
Address: Rum 10, Folkparksvgen 16, 372 40, Ronneby, Sweden
E-mail: kranthikiranm67@gmail.com
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
Phone
Fax
: www.bth.se/tek
: +46 457 38 50 00
: + 46 457 271 25
ii
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.
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 wouldnt 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.
ii
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.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.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.2 RESULTS ............................................................................................................................ 39
4.2.1 Maintenance Taxonomy .......................................................................................... 39
4.2.2 Bubble Graph ............................................................................................................ 40
4.2.3 Results ........................................................................................................................ 41
iii
4.3 ANALYSIS ........................................................................................................................... 44

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
iv
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
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
vi
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
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:
1.3
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.
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?
2
- 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
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
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 Kitchenhams 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
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
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 criterias.
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.
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
RQ 2.2
Software Reuse
Areas in focus for value of

reuse
Academia

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
RQ 3.2
Software Reuse
Areas in focus
for
maintenance of reusable
software
Academia

maintenance category per year
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 criterias 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.
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
9
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
researchers 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
researchers 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.
10
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.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
2.1
Algorithms
Architecture
Data
Designs
Documentation
Estimation Templates
Human Interfaces
Knowledge
Models
Modules
Plans
Requirements
Service Contracts
Test Cases
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.
11
Search Terms:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
Assets
Algorithms
Architecture
Artifacts
Aspects
Components
Data
Designs
Document
Estimates
HCI
Human Computer Interface
Human Interface
Knowledge
Lifecycle
Models
Modules
Plans
Requirements
Reusable
Reuse
Reused
Service contracts
Software
25. Test
Search Questions:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
asset AND reuse OR reusable AND software

Lifecycle AND reuse AND software
software AND reusable AND aspects
software AND reusable AND artifacts
software AND reusable AND components
{Reusable OR reuse} AND Data
{Reusable OR reuse} AND Documentation
{Reusable OR reuse} AND Estimates(Templets)
{Reusable OR reuse} AND plans(project plans)
{Reusable OR reuse} AND {Test cases OR Test designs}
{Reusable OR reuse} AND Service contracts
{Reusable OR reuse} AND Algorithms
{Reusable OR reuse} AND Designs
{HCI} AND {software AND reus*} AND {asset OR artifact OR component}
Knowledge AND {software AND reus*} AND {asset OR artifact OR component}
Requirements AND {software AND reus*} AND {asset OR artifact OR component}
Architecture AND {software AND reus*} AND {asset OR artifact OR component}
Human Interface AND {software AND reus*} AND {asset OR artifact OR component}
Human computer Interface AND {software AND reus*} AND {asset OR artifact OR component}
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.
12
Number of hits
Basic inclusion
criteria
Detailed inclusion/
exclusion criteria
Snowball
Sampling
Google Scholar
21
ACM
17761
24
13
Inspec
36673
108
12
IEEE
244
36
19
Elsevier
12469
42
Springer
68892
363
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
[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]
[Giuseppe, 94]
[1]
[I Issenin, 04]
[2]
[Jones, C, 93]
[21]
[W Frakes, 96]
[22]
[R. Leach, 97]
[23]
Data
13
Designs
Documentation
Estimation template
Human Interface
Knowledge
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]
[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]
[ Jones, C. 93]
[21]
[W Frakes 96]
[22]
[Jones C, 1993]
[21]
[Lozano-Tello et al, 02]
[66]
[Frakes, W et al, 96]
[22]
[Robert Bogue, 06]
[67]
[Swanson, 89]
[68]
[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]
14
Models
[Larsen, 06]
[71]
Modules
[Isoda, 92]
[69]
[Frakes, W.B, et al, 94]
[70]
[Leach, 97]
[23]
[D. L. Parnas, 1972]
[187]
[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]
[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]
[Haibin Zhu, 05]
[24]
[Lucas et al, 97]
[202]
[Mark Folkerts, 08]
[13]
[David Binkley et al., 95]
[14]
[A V Mayrhauser, 93]
[15]
Plans
Requirements
Service Contracts
Test Cases/ Test Designs
19
10
15
[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

16
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].
17
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.
18
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 dont 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.
120
Percentage of Validation
100
80
60
Validated
Non-Validated
Review s
40
20
0
Architecture
Algorithms
Design
Data
Estimates
Documentation
Knowledge
HCI
Modules
Models
Plans
Requirements
Test cases
Service Contracts
Reusable Assets
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
19
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.
Assets in Focus
16
14
Test cases
Service contracts
Requirements
Plans
Num ber of Studies
12
10
Modules
Models
Know ledge
Human Interfaces
Estimates/ Templates
Documentation
Design
Data
Architecture
Algorithm
1973
1975
1977
1979
1981
1983
1985
1987
1989
1991
1993
1995
1997
1999
2001
2003
2005
2007
2009
1972
1974
1976
1978
1980
1982
1984
1986
1988
1990
1992
1994
1996
1998
2000
2002
2004
2006
2008
Years
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].
20
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
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.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
Software
Reuse
Amount
Cost
Benefit
Investment
Assessment
Maturity
Reusability
Failure
Modes
Models
Metrics
Measurement
Value
Library
Quality
Business
Level
Frequency
Ratio
Density
Economics
24. Reused
21
Search Questions
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
software AND reuse AND metrics AND measurement

Amount AND reuse
cost AND benefit AND analysis
Quality AND investment AND reuse AND{ software AND reuse AND metrics AND measurement}
return AND investment AND{software AND reuse AND metrics AND measurement}
business AND reuse AND metrics
reusability AND assessment
Maturity AND assessment AND reuse
Failure AND modes AND models
Reuse AND library AND metrics
reuse AND value
reuse AND level
reuse AND frequency
reuse AND ratio
15. reuse AND density
Table 7: Search Terms and Search Questions for Value of Reuse

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
Detailed inclusion/
exclusion criteria
Snowball
sampling
Google scholar
ACM
10253
156
13
Inspec
2279
333
IEEE
30
30
15
Elsevier
428
86
Springer
12116
58
Total
25106
663
43
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 subcategories 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].
22
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.
23
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.
24
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)
25
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
Cost
benefit
analysis
models
Economic
cost benefit
analysis
Model
Model
Validation of
previous model
in [74]
Validation of
previous model
in [72]
Model
A study of
existing
industrial case
studies
Model
Metric
Return on
Investment
Quality of
investment
Maturity
assessment
models
Formulae
Metric
Business
Reuse
metrics
Metric
No
subcategories
Model
Metric
Model
Model
Validation of
model in [85]
Model
Model
Model
Contribution name
or
Study title name
Model for Economics of reuse
Cost of Development Model
"What price reusability? A
case study"
Author name
and
Reference number
Barnes, B et al
[74]
Gaffney, J E et al [72]
Favor, J
[73]
"Software reuse economics:

cost benefit analysis on a large
scale Ada project".
Development phase model
Quality, productivity and
economic benefits of software
reuse: a review of industrial
studies
Cost estimation model
"A reuse metrics and return on
investment model"
"Return on invest models"
An analytical approach for
making good reuse
investments
"A reuse metrics and return on
investment model"
Metrics to estimate the effort
saved by reuse (used by IBM)
Koltun and Hudson reuse
maturity model
STARS reuse maturity model
A reuse capability model
"Investments in reusable
software, A study of software
reuse investment success
factors"
"A phased reuse adoption
model"
Reuse reference model
RiSE maturity model
Margono, J et al
[75]
Malan, R et al
[76]
P Mohagheghi et al [79]
Jasmine, K S et al [80]
J S Poulin et al [115]
K El Emam
Barns, B H et al
[116]
[81]
J S Poulin et al
[115]
J S Poulin et al
[82]
Koltun, P et al
[83]
Davis, M J
Davis, T
Rine, D C et al
[84]
[85]
[106]
S Wartik et al
[86]
D C Rine et al
[87]
Almeida, E S et al [88]
26
Extension to a
model
Amount of
reuse
metrics
Reuse level
Model
Metric
Model
Model
Method
Metric
Method
Reuse level
A study of
Reuse level
Metrics
A study of
Reuse level
Metrics
Metrics
Reuse
percentage
Reuse
frequency
Reuse ratio
Metric
A study of
Reuse
percentage
Metrics
A study of
Reuse
percentage
Metrics
Metrics
A study of
Reuse
frequency
Metrics
A study of
Reuse
frequency
Metrics
Metrics
Metric
"Towards a maturity model for

reuse incremental adoption"
(Extension to RiSE Maturity
model)
Reuse level metrics
Reuse level metric
Reuse level metrics
"Modeling reuse across the
software life cycle"
"Methods of measuring
software reuse for the
prediction of maintenance
effort"
"Software reuse: metrics and
models"
"Empirical analysis of the
correlation between amountof-reuse metrics in the c
programming language"
"A comparative study on
software reuse metrics and
economic models from
traceability perspective"
"Admire: Asset development
metrics-based integrated reuse
environment"
"Reuse Ratio Metrics RL and
RF-Demo"
The business case for
software reuse
environment"
Garcia, V C et al
[89]
Frakes, W B
[109]
Frakes, W B et al [198]
Terry, C
[110]
W B Frakes et al [91]
Leach, R J
[92]
W B Frakes
[22]
Curry, W et al
[94]
J. Mascena et al
[112]
Jorge, C et al
[113]
Frakes, W B et al
[95]
Poulin, J.S et al
[82]
J. Mascena et al
[112]
Jorge, C et al
[113]
Reuse Frequency Metric

environment"
Frakes W et al
J. Mascena et al
[198]
[112]
Jorge, C et al
[113]
"Reuse Ratio Metrics RL and

RF-Demo"
How Reuse Influences
Productivity in Object
Oriented Systems
Frakes, W B et al
Basili V et al
[95]
[199]
27
A study of
Reuse ratio
Metrics
Reuse
density
Reuse size
and
frequency
Failure
modes
models
Reusability
assessment
No
subcategories
No
subcategories
A study of
Reuse ratio
Metrics
A study of
Reuse density
metrics
A study of
Reuse density
metrics
Metric
A study of
Reuse size and
frequency
metrics
A study Reuse
size and
frequency
metrics
Model
Method
Method
Analysis
Metrics
Metrics
Metrics and
Models
Framework
Approach
Model
Reuse
library
metrics
Indexing
costs
Search
effectiveness
Metrics
Metrics
Model
Model

Admire: Asset development
environment
environment"
Reuse Size and Frequency
metric
environment"
J. Mascena et al
[112]
Jorge, C et al
[113]
J. Mascena et al
[112]
Jorge, C et al
[113]
Devanbu P et al
[200]
J. Mascena et al
[112]
Jorge, C et al
[113]
Failure modes model
Frakes, W B
[108]
"Quantitative studies of
software reuse"
"Ada reusability and
measurement"
models"
" Evolution of framework
reusability"
Component reusability model
"Reusability metrics for
Software components".
"Assessing Module
Reusability"
Artificial Neural Network
based approach
Reuse Readiness Levels Model
Selby, R W

models"
models"
RASCAL model
"A new characterization
scheme of reusable software
components"
[96]
Basili, V R et al
[97]
Frakes, W B
[22]
Cardino, G et al.
[98]
Washizaki, H et al [99]
Rotaru, O et al [100]
Luer, C
[101]
Arun S
[204]
J J Marshall et al. [90]

Frakes, W B
[22]
Frakes, W B
[22]
McCarey, F
[103]
Parvinder, S S
[104]
28
Support for
understanding
Metrics
Efficiency
Metrics
"An empirical study of

Frakes, W B et al. [105]
representation methods for
reusable software components"
(7-point ordinary scale for
measuring support for
understanding)
"Software reuse: metrics and Frakes, W B
[22]
models"
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.
2.
3.
4.
5.
6.
3.3.1
Cost Benefit Models

Maturity Assessment Models
Amount of Reuse Metrics
Failure Modes Models
Reusability Assessment Models
Reuse Library Metrics
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 dont 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 nonvalidated and remaining 14% are review studies. Based on the observation nonvalidated models are a bit higher than the validated.
29
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.
30
120
Validated
Non-Validated
Review s
% o f va lid a tio n
100
80
60
40
20
0
Cost benifit analy sis
Maturity Assessment
Amount of reuse
Failure Modes
Reusability Assessment
Categories
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
31
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.
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.
32

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.
120
100
80
60
Academic
Industrial
40
Survey
20
0
Cost-Benefit Analysis
Maturity Assessment
Amount of Reuse
Failure Modes
Reusability Assessment Reuse Library Metrics
Study Category
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.
33
12
10
Num ber of s tudies

Failure Modes models
Amount of Reuse metrics
Maturity Assessment models

Cost-Benefit Analysis models
0
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
Years
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.
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. .
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.
Only two studies were found in this category and those two studies represented their models
using diagrammatic, tabular and theoretical approaches.
their metrics/models/methods through mathematical means and about 71.4% of the studies
34

their metrics/models/methods through mathematical means and about 85.7% of the studies
35
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.
36
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
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.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
Maintenance
Maintainability
Maintenance with Software Reuse
Reuse maintenance
Component Based Software Development
OSS
Open Source Software
FLOSS
FOSS
Open Software
Free Software
Aging,
Strategies
Version Control
37
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.
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
IEEE
694
97
34
Elsevier
10062
23
Springer
8919
405
Total
30198
1063
58
12
Table 11: Hits after Each Criterion for RQ3

38
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 upgradations 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.
39
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
40
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 its the title of the study.
Category
Strategies
Contribution
Approach,
Author and
Title of the article
Reference Number
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]
Model
Object-Oriented
Model
Heisler
[194]
Approach
Some Stability Measures for Software

Maintenance
Yau, S.S
[141]
Metrics
A
Framework
for
Maintenance Metrics
Software
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,
Change Impact Analysis of ObjectOriented 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

analysis
using
singular
decomposition
Sherriff
[138]
Method
Change impact analysis for AspectJ

programs
Sai Zhang
[139]
Tool
Change Impact
Analysis
Contribution Name or
Metrics
Maintenance-Oriented
impact
value
41
Software
Configuration
Management
Module
Dependencies
Approach
An Approach for Comparison of

Architecture Level Change Impact
Analysis Methods and Their Relevance
in Web Systems Evolution
Mehboob
[140]
Model
Supporting reuse and configuration: a

port based SCM model
Aquilino
[147]
Tool
System Modeller Tool

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
Software System
Hassan
[153]
Approach
Information Theory Approach
Edward B. Allen
[157]
Approach
On the Nonmaintainability of OpenSource 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
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]
Method
Iterative Reengineering
Functions
Legacy
Alessandro Bianchi [175]
Metrics
Ageing of a data-intensive legacy

system: symptoms and remedies
Giuseppe Visaggio [174]
Legal Issues
Aging
Symptoms
for
Cedar
Propagation
Coupling
in
Measurement
of
Table 12: Contribution Table for Maintenance

42
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
43
system which makes it difficult to reuse and difficult to maintain. Thus, strong coupling also
hinders software reuse [160, 166]. If software modules doesnt 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.
44
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 OhCheon Kwon [122] has a non-validated tool and a review which made the total percentage go
beyond 100%.
120
P
e
rc
e
n
ta
g
eo
fV
a
lid
a
tio
n
100
80
V alidated
Non-v alidated
Review s
60
40
20
0
STR
CIA
SCM
MDP
LEG
A GE
Study Categories
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 nonvalidated. 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.
45
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 nonvalidated. 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.
Its 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.
46
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.
120
100
80
60
Academic
Industrial
40
Survey
20
0
STR
CIA
SCM
MDP
LEG
AGE
Study Category
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.
Areas in focus
8
7
Number of studies
6
AGE
LEG
5
4
MDP
SCM
CIA
STR
3
2
1
0
1973
1975
1977
1979
1981
1983
1985
1987
1989
1991
1993
1995
1997
1999
2001
2003
2005
2007
2009
1972
1974
1976
1978
1980
1982
1984
1986
1988
1990
1992
1994
1996
1998
2000
2002
2004
2006
2008
Years
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,
47
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.
48
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
49
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.
50
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: 8394.
[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: 427454.
[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.
51
[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 Objectoriented 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.
52
[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), 131183.
[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, ASMEETCE98.
[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. SpringerVerlag, London.
53
[45] Thais Ebling, Jorge Luis Nicolas Audy, et al. (2009). Towards a requirements reuse
method using Product Line in distributed environments. http://wer.inf.pucrio.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: 613.
[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
(FTRTFT98), Lecture Notes in Computer Science 1486, Springer pp: 6574.
[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. Leito (2006). A Tool for Management and Reuse of Software
Design Knowledge. Managing Knowledge in a World of Networks. AILab, Centro de
54
Informtica 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., Nttinen, 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: 141152.
[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 SEKE99.
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. Gmez-Prez (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.
55
[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: 245255.
[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 organizations
reuse capability. In Proceedings of 2nd ACM/IEEE International Workshop on
Software Reusability, IEEE Computer Society Press / ACM Press: pp: 126133.
[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.
56
[88] Almeida, E. S., Alvaro, A., Lucredio, 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:4853.
[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, Sao 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: 309320.
[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: 35140.
[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.
57
[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.. Cinnide, 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, Vincius 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. intl 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.
58
[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 AsiaPacific 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: 171184.
[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.
59
[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: 268277.
[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 ComponentBased 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). RCSa system for version control. SoftwarePractice &
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.
60
[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: 268276.
[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: 574586.
[151] Thomas Zimmermann, Peter Weigerber, 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. Intl 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
[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.
61
[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
[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.
62
[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
searchbased
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.
63
[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: 2142
[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 objectoriented 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.
64
[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.
65
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)
66
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
RLM
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
67
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
Validation
N.V E.T Me Mo Mt/Tl
IC AC AE IE Sy
[25]
1997
Discussion Rw
Ap
AL
Description
Mn
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
Year
Validation
IC
AC
AE
N.V
E.T
Me
Mo
Mt/Tl
IE Sy
Discussion
Ap
Rw
Description
Mn
[34]
1992
AR
[38]
1992
AR
[41]
1995
AR
[36]
1996
AR
Discussed on architecture
[23]
1997
AR
[35]
1997
AR
[39]
1998
AR
Proposed a method for the reuse
of design and architecture.
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.
Discussed how the architectural

elements as reusable assets of
an Architectural Description
Language (ADL) can be
characterized.
The
main
68
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
[42]
1999
AR
[37]
2008
AR
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.
Proposes a method which makes

use of high level UML
constructs for the reuse of
architecture.
1
Discussed on Architecture and

different asset types in it.
Table 15: Result Table for Architecture Reuse
2.3. Data
R.
Year
Validation
N.V
E.T
Me
Mo
Mt/Tl
Discuss
Rw
Description
no.
IC
AC
AE
IE
Sy
Ap
1
Mn
[21]
1993
DA
Discussed on data reuse (approach)
[1]
1994
DA
Discussed on data reuse
[22]
1996
DA
[23]
1997
DA
[2]
2004
DA
Table 16: Result Table for Data Reuse
2.4. Design
R.
Year C
Validation
N.V E.T Me Mo Mt/Tl Discuss
Rw
Description
no.
IC AC AE Ex
[26] 1989
DE
[29] 1992
DE
[33] 1993
DE 1
Sy
Ap Mn
1
Presented a model for representing and manipulating

the module level software design information leading
to the effective reuse of it.
1
This study is a thesis work and is a discussion on

design reuse as a strategy for incremental new product
development.
The study tells us that when designers operate in a
workplace with low-cost access to reusable analysis
69
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
[30] 1994
DE
[28] 1995
DE
[22] 1996
DE
[32] 2005
DE
[58] 2006
DE
Discussed on software design knowledge reuse
[27] 2008
DE
A general discussion on design reuse.
Mentioned design can be reused
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.
1
1
1
Discussion on design reuse. Focused on how the

methods for design reuse in chemical engineering can
be adopted for software engineering.
Mentioned design can be reused
This study discusses an approach. The approach has

been implemented in an experimental system call
Ease Design.
Table 17: Result Table for Design Reuse
2.5. Documentation
R.
Year
Validation
N.V
E.T
Me
Mo
Mt/Tl
Discuss
Rw
Description
This study tested the 4 approaches to

reuse through a comparision
experiment.
no.
IC
AC
AE
IE
S
y
Ap
Mn
[5]
1993
DO
[21]
1993
DO
[3]
1996
DO
Presented a natural means of reusing

a document
[4]
1996
DO
This study presented a natural means

of reusing any kind of document.
[22]
1996
DO
[7]
1996
DO
[23]
1997
DO
Mentioned on documentation reuse
[8]
1998
DO
This study discussed on

documentation reuse
[6]
2006
DO
1
1
[5]
Discussed on Documentation reuse
Discussed on documentation reuse

Proposed a model and tested it on his
own document
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.
70
2.6. Estimation templates
R.
Year
Validation
N.V
E.T
Me
Mo
Mt/Tl
Discuss
Rw
Description
no.
IC
AC
AE
IE
Ap
Sy
Mn
[21]
1993 ET
Mentioned Estimates reuse
[22]
1996 ET
Mentioned that Estimates can be

reused
Table 19: Result Table for Estimates Reuse.
2.7. Human interfaces

R.
Year
Validation
N.V
E.T
Me
Mo
Mt/Tl
Discussion
Rw
Description
no.
IC
AC
AE
IE
S
y
Ap
Mn
[68]
1989
HI
Mentioned as user interface as an

asset.
[21]
1993
HI
Mentioned as asset.
[22]
1996
HI
Mentioned as asset.
[66]
2002
HI
Mentioned as asset.
[67]
2006
HI
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.
Year
Validation
N.V E.T Me Mo Mt/Tl Discussion Rw
Description
no.
IC AC AE IE Sy
Ap
Mn
[117]
1987
KN
Discussed knowledge (ideas) as reusable asset
[118]
1993
KN
Discussed knowledge (information) as reusable asset.
[119]
1998
KN
[64]
1999
KN
[65]
2001
KN
[60]
2001
KN
1
1
Discussed knowledge (reasoning) as reusable asset.
Proposes a tool which emphasizes on the continuous

learning and the reuse of all forms of experiences
from the domain.
1
Discussed Knowledge as reusable asset

Proposed a KM process model and discusses the
71
integration of continuous process improvement to it.

Validated this in an industrial case study.
[59]
2004
KN
[61]
2005
KN
[58]
2006
KN
[31]
2008
KN
[62]
2009
KN
Proposes a cognitive heuristics such as anchoring and

adjustment, helps to predict issues that occurs when a
code or design is reused.
Discusses on the types of knowledge reuse and the

factors influencing them
Presents a CASE tool for the Design knowledge reuse
by the use of Case Based Reasoning Approach
Proposed a model to analyze the factors like when

and how the individuals reusing knowledge assets
benefit.
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.
Year
Validation
N.V
E.T
Me
Mo
Mt/Tl
Discussion
Rw
Description
no.
IC
[71]
2006
AC
AE
IE
Sy
MD
Ap
1
Mn
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.
Year
Validation
N.V
E.T
Me
Mo
Mt/Tl
Discussion
Rw
Description
no.
IC
AC
AE
IE
Sy
Ap
Mn
[187]
1972
ML
Was the first to introduce the concept

of modularization.
[69]
1992
ML
Discussed about the reusable

Modules
[70]
1994
ML
Discussed about the reusable

Modules
[23]
1997
ML
Discussed about the reusable Module
Table 23: Result Table for Modules Reuse.
72
2.11. Plans
R.
Year C
Validation
N.V E.T Me Mo Mt/Tl
Discuss
Rw Description
no.
IC
AC
AE
IE
Sy
Ap Mn
[11]
1990
PL
[21]
1993
PL
[9]
1994
PL
[10]
1994
PL
[22]
1996
PL
Mentioned about plan reuse
[23]
1997
PL
[12]
2001
PL
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.
1
Tested the hypothesis of plan reuse empirically
Focused on developing the solutions to some

underlying problems and evaluating them
Table 24: Result Table for Plans Reuse.
2.12. Requirements
R.
Year
Validation
N.V
E.T
Me
Mo
Mt/Tl
Discussion
Rw
Description
No
IC
AC
AE
IE
Sy
Ap
1
Mn
[53]
1991
RQ
Proposed
a
knowledge
base
structuring mechanism called ARIES
to reduce the issues due to
communication
problems
and
misunderstanding.
[34]
1992
RQ
[52]
1993
RQ
[50]
1995
RQ
[23]
1997
RQ
[47]
1996
RQ
[35]
1997
RQ
Discussed about requirements
[36]
1997
RQ
[46]
1997
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
Presented a technique for writing

Reusable requirement specification
(SMARTe Requirement). This is
validated by a case study on earth
remote sensing (ERS-1).
1

Proposes
a
model
for
the
identification of the analogies in the
requirement
specification
for
promoting analogical reuse.
Proposed an approach which is based

on the current domain analysis
techniques
and
applied
these
73
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
[56]
1997
RQ
[54]
1998
RQ
[55]
2002
RQ
[48]
2005
RQ
[57]
2005
RQ
[43]
2008
RQ
[49]
2008
RQ
[20
7]
2009
RQ
[45]
2009
RQ
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.
1
Proposed a meta-model which is an

integration of various types of
semiformal
diagrams
into
a
requirements reuse approach
Proposed a model for the reuse of

requirements specification through
task modeling in a Notification
System Design. Validated by a
usability study.
[16]
Proposed a reuse based approach

which is used to specify system
requirements
based
on
the
requirement patterns.
Discusses 10 practical steps which are

followed
at
Rolls-Royce
for
systematic requirements reuse.
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.
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.
Proposed
an
approach
for
requirements reuse based on the
forecasting of user needs. But failed
to discuss regarding the knowledge
acquisition.
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 SCOPEPublished in August, 2009)
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.
74
2.13. Service Contracts
R.
Year C
Validation
N.V E.T Me Mo Mt/Tl Discuss
Rw
Description
No
IC AC AE IE Sy
Ap Mn
[202] 1997
SC
Discussed that Service contract reusability.
[24]
SC
Discussed that Service contract reusability.
2005
Table 26: Result Table for Service Contract Reuse.
2.14. Test case/ Test design
R.
Year
Validation
N.
V
No
IC
A
C
AE IE
E.
T
Me
M
o
Mt/Tl
Sy
Discuss
Ap
Description
R
w
Mn
[21]
1993
TC
[15]
1993
TC
[14]
1995
TC
[22]
1996
TC
Discussed on test case/test design reuse
[17]
1998
TC
Discussed on test case reuse
[18]
2002
TC
[16]
2004
TC
[19]
2008
TC
[20]
2008
TC
This study discussed on test case reuse
[13]
2008
TC
This study discussed on test case reuse
Mentioned that Test cases can be reused
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.
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
1
1
In this paper gave an overview of building

reusable test assets.
Discussed on test case reuse
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.
Table 27: Result Table for Test Case/ Test Plan Reuse.
75
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.
Year
Validated
N.V
E.T
Rw
Me
Mo
Mt
Fr
Ap
Validation
no.
IC
[74]
Description
of
1988
COS
AC
A
E
IE
Sy
This model was used by [73] in his work in an

industrial setting
(as mentioned in [22])
[72]
1989
COS
[73]
1991
COS
[81]
1991
COS
Cost of development model (applied to a large

scale Ada project for assessing the economic
benefits of a reuse effort on it) [22].
[74]
1
This study used the model of [74] in its work

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
[72]
[76]
1993
COS
[82]
1993
COS
Presented metrics used by IBM to estimate the

effort saved by reuse.
[115]
1993
COS
Described the reuse metrics and return on

investment process in place of IBM
[22]
1996
COS
[77]
2002
COS
[78]
2003
COS
[116]
2003
COS
[114]
2004
COS
[79]
2007
COS
[80]
2008
COS
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.
This study is a review of existing cost benefit

analysis models.
1
This study developed A Domain Specific Cost

Benefit model.
This study developed A Domain Specific

Software Reuse model
1
1
1
1
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
Discussed on return on investment.

Proposed a COPLIMO ( constructive product line
investment model)
Reviewed the journals between 1994 2005 to
gather the evidences of successful software reuse
programs in industry.
Proposed economic model for cost analysis
Table 28: Result Table for Cost Benefit Analysis.
76
3.2. Maturity Assessment Models

R.
Year
Validated
N.V
E.T
Rw
Me
Mo
Mt
Fr
Ap
no.
Description
of
IC
[83]
Validation
1991
AC
AE
IE
Sy
MAT
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
[83]
This study presented reuse maturity model of

STARS project
[85]
1993
MAT
[84]
This study presented reuse capability model

which is an advancement of STARS reuse
maturity model
[22]
1996
MAT
[106]
1998
MAT
[86]
1999
MAT
[87]
2000
MAT
[88]
2004
[89]
2007
A review on maturity assessment models
[85]
[85]
In this study work RCM of [85] proved to be

unstable
This study presented a Phased model which

will reduce the initial risk in the reuse
adoption.
This study presented RRM (reuse reference

model) (as mentioned in [89])
MAT
RiSE Maturity Model was developed during

rise project.
MAT
[88]
This study Reviewed the RiSE maturity model
Table 29: Result Table for Maturity Assessment Models.
3.3. Amount of Reuse Metrics
R.
Year
Validated
N.V
E.T
Rw
Me
Mo
no.
Fr
Ap
Validation
Description
of
IC
[109]
Mt
1990
AC
AE
ARM
IE
Sy
1
Proposed a model for reuse level

(as is also mentioned in [22])
[110]
1993
ARM
[109
]
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
[198]
1994
ARM
[91]
1995
ARM
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.
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).
1
This study reported on strong correlation
77
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
[199]
1996
ARM
[22]
1996
ARM
[200]
1996
ARM
[93]
1998
ARM
[94]
1999
ARM
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
A part of study discuss on amount of reuse

metrics
[113]
2006
ARM
A part of study discuss on amount of reuse

metrics
[95]
2009
ARM
A review on the reuse level and reuse

frequency
[111]
2009
ARM
A discussion on amount of reuse metrics
This study presented a number of

techniques and methods for the
measurement of amount of reuse
Presented reuse rate metric (means the

percentage of reused code within the
system due to either slightly modified
reuse or verbatim (direct) reuse).
This study is a review of amount of reuse

metrics and also presented a general
metric for measuring the amount of reuse
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.
This study presented a method that will

support measuring the amount of reuse
with different software models.
Table 30: Reuse Table for Amount of Reuse Metrics.
3.4. Failure Modes Model

R.
Year
Validated
N.V
E.T
Rw
Me
Mo
no.
Mt
Fr
Ap
Validation
Description
of
IC
[108]
1996
FM
M
[22]
1996
FM
M
A
C
AE
IE
Sy
In their study presented the failure modes model
A review of Failure modes model
Table 31: Reuse Table for Failure Modes Model.
78
3.5. Reusability Assessment

R.
Year
Validated
N.V
E.T
Rw
Me
Mo
Mt
Fr
Ap
Validati
on
no.
Description
of
IC
[96]
1989
AC
AE
IE
Sy
RAS
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
[22]
1996
RAS
[98]
1997
RAS
[99]
2003
RAS
[100]
2005
RAS
[101]
2007
RAS
[90]
2008
RAS
[204]
2009
RAS
This study proposed methods for two reuse studies of systems written
in Ada.
1
1
1
A Review of reusability assessment metrics

1
Proposed a reusability metrics for frameworks reusability
Proposed a metrics suit that composed of six metrics which are proved
to be used to measure the component's reusability through experimental
validation.
Proposed Metrics and mathematical models

1
Proposed a framework for assessment of reusability of modules
Discussed on the Reuse Readiness Levels model (helps reusers of

software in measuring the software reusability).
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.
Year
Validated
N.V
E.T
Rw
Me
Mo
no.
Mt
Fr
Ap
Validation
Description
of
IC
AC
AE
IE
Sy
[102]
1986
RLM
Proposed Metrics (indicators of quality of

assets) (as mentioned in [22])
[105]
1994
RLM
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
Metrics
for
indexing
effectiveness, Efficiency
[103]
2006
RLM
[104]
2007
RLM
costs,
search
Demonstrated their model RASCAL regarding

search effectiveness
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.
79
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
Validation
IC
AC
AE
N.V
IE
E.T
Rw
Ap
Mo
Me
Mt
Tl
Validation
of
Description
Sy
[120]
1990
STR
[196]
1993
STR
[197]
1996
STR
[121]
1998
STR
[122]
1999
STR
[123]
2000
STR
[124]
2003
STR
[125]
2008
STR
First person to discuss reuse in terms of

maintenance and development. Also
proposed a simple reuse model.
1
Did an analysis to suggest the general

requirements which are essential for an
Integrated toolset for Computer Aided
Software Maintenance.
Proposed a new type of maintenance called
Reconstructive maintenance.
[121]
Proposed an Integrated approach of software

reuse, maintenance and SCM. Proposed a
TERRA Tool support.
[121]
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.
[120]
Discussed the drawbacks by implementing

the TERRA Tool.
Did a comparitative study between the FullReuse and Iterative-Enhancement Model and
concluded that Full-Reuse Model degrades
software quality. Also developed RAPID
Tool
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
Validation
IC
[141]
1980
CIA
[194]
1989
CIA
AC
AE
N.V
IE
E.T
Rw
Ap
Mo
Me
Mt
Tl
Validation
of
Description
Sy
Proposed an approximated algorithm for

Ripple Effect.
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.
80
[193]
1990
CIA
[126]
1993
CIA
[127]
1994
CIA
[128]
1996
CIA
[129]
1998
CIA
[192]
1998
CIA
[142]
2000
CIA
[130]
2002
CIA
[131]
2003
CIA
[190]
2003
CIA
[189]
2003
CIA
[132]
2004
CIA
[133]
2004
CIA
[134]
2005
CIA
Focused on change impact analysis and

proposed a metrics based on the traceability
graph to measure the stability of the whole
system including documentation.
Discusses change impact analysis in terms

of source code
1
Proposed an algorithmic Approach to

identify the changes parts of the system for
OO systems.
Proposed an algorithmic approach to

analyze the proposed changes in OO
systems and to quantitatively calculate
change impacts.

of source code
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
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.

of source code
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
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
Compares the Dynamic Impact Analysis

Algorithms
[126]
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
Proposed Chanti Tool for change impact

analysis for java programs
Proposed a light weight proactive CIA
approach which deals with analyzing the
requirement changes using Use Case Maps
[129]
[131]
[135]
2005
CIA
[184]
2005
CIA
[136]
2006
CIA
[137]
2008
CIA
Proposed a method to find out source files

impacted by a proposed change request by
using information retrieval algorithms.
1
[128]
[141]
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
Proposed
reformulated
approximated
algorithm to calculate the ripple effect for
OO programs
Proposed REST tool which uses

approximated algorithm to calculate the
81
ripple effect for C programs which is

reformulation to Yau and Collofello's ripple
effect.
[138]
2008
CIA
[139]
2008
CIA
[140]
2009
CIA
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.
Proposed a method for CIA for AspectJ

Programs
using
atomic
changes
representation
to
identify semantic
difference between two versions.
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.
Year
Validation
N.V
E.T
Rw
Ap
Mo
Me
Mt
Tl
no.
Validation
Description
of
IC
AC
AE
IE
Sy
[143]
1983
SCM
[144]
1985
SCM
[146]
1990
SCM
[147]
1991
SCM
[148]
1993
SCM
[149]
1998
SCM
[152]
1998
SCM
[145]
2002
SCM
[150]
2004
SCM
Proposed an approach that uses association

rule mining to predict the change patterns in
the modification task
[153]
2004
SCM
Presented Heuristics to predict change

propagation.
[151]
2005
SCM
[195]
2008
SCM
Proposed System Modeller Tool for Cedar

Programming Languages.
Proposed a RCS- a revision control tool.

Presented a survey on version control tools.
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.
Proposed a Port Based SCM for supporting

software reuse and configuration of the
system.
Proposed an algebraic version language of

histories, subversion and joins.
[144]
Was the first to present an approach that

detects logical coupling based on the release
data.
Discussed about the concepts of SCM.
Proposed a Project Revision control

System(PRCS) which has a clean user
interface compared to RCS
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.
Proposed a model for fine grained version

control. Also proposed a tool
Table 36: Result Table for Software Configuration Management
82
4.4. Module Dependencies
R.
Year
Validation
N.V
E.T
Rw
Ap
Mo
Me
Mt
Tl
Validation
no.
Description
of
IC
AC
AE
IE
Sy
[187]
1972
MDP
Was the first to introduce the concept of

modularization.
[155]
1980
MDP
Discussed on the coupling and cohesion

issues. Also proposed scales for measuring the
severity of the scales.
[156]
1993
MDP
Suggested the scales for finding the severity of

the coupling.
[157]
2001
MDP
Proposed an Information Theory Approach for

measuring the coupling and cohesion of the
modules.
[158]
2002
MDP
Validated 365 versions of Linux and proved

that the common coupling increases as the
modules, version numbers and their
interactions increases.
[159]
2003
MDP
[160]
2004
MDP
[161]
2004
MDP
[162]
2005
MDP
[163]
2005
MDP
[167]
2005
MDP
[164]
2007
MDP
[191]
2008
MDP
[165]
2009
MDP
[158]
Validated using 391 versions of Linux and

proved that best way to avoid clandestine
common coupling is by avoiding common
coupling.
Classified the global variable in to 5 categories

to predict safe and unsafe maintenance.
Validated on 400 versions of Linux.
Proposed a set of refactoring guidelines which

are needed to improve the characteristics of
the coupling and cohesion in terms of code in
particular.
Suggested the scales for finding the severity of

the coupling.
[160]
[167]
[160]
Proposed a categorization of common

coupling which makes it easy to measure the
maintainability. Implemented it on the Darwin
Operating System.
1
Proposed a categorization of common

coupling which is easy to measure the
maintainability of the kernel based system.
1
Proposed a set of guidelines to improve

reusability in terms of source code folders.
Proposed a dynamic coupling measurement

technique.
[158]
Proved that the common coupling should be

calculated on temporal variables like release
dates rather than release sequence number.
Validated on Linux.
[159]
[166]
2009
MDP
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
83
4.5. Legal Issues
R.
Year
Validation
N.V
E.T
Rw
Ap
Mo
Me
Mt
Tl
Validation
no.
Description
of
AC
IC
AE
IE
Sy
[168]
1989
LEG
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
Discusses on Legal issues.
[169]
2001
LEG
Discussed regarding the licensing issues.
[170]
2004
LEG
Discussed regarding the legal issues

concerning the negotiation of service level
agreement.
[171]
2005
LEG
Discusses the licensing issues between

COTS and FOSS.
[172]
2008
LEG
Discussed regarding the legal issues

concerning the negotiation of service level
agreement.
[173]
2009
LEG
[170]
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.
Year
Validation
N.V
E.T
Rw
Ap
Mo
Me
Mt
Tl
no.
Validation
Description
of
IC
[174]
2001
AGE
[175]
2001
AGE
AC
AE
IE
Sy
[174]
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.
1
Proposes a method for the gradual

reengineering of the procedural components
of a legacy system.
Table 39: Result Table for Aging Symptoms.
84
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
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
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
213 (studies) 6 (duplicates) 1(out of scope study [207])
79
3 / Value of reuse
4/ Maintenance
Total
Table 40: Reference List for Chapter 2, 3 and 4 ( marked ones are duplicates = total 6
duplicates (4 appears twice and 1 appears trice))
85
52
70
206

Thesis Final Draft MSE 2010 07 PDF

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Thesis Final Draft MSE 2010 07 PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

Master Thesis

A Systematic Mapping Study on

Bhargava Mithra Konda and Kranthi Kiran Mandava

This thesis is submitted to the School of Engineering at Blekinge Institute of Technology in

Keywords: Software, Reuse, Reusable Assets, Value,

4.3 ANALYSIS ........................................................................................................................... 44

Aims and Objectives

To identify the methods or approaches for reusing these assets.

To identify the methods for maintaining reusable software.

- RQ1.2. What is their validation status?

Background and Related Work

In this report, we followed Kitchenhams guidelines for performing a systematic mapping

Figure 1: Search Strategy

The article having particular keywords since a particular year

The articles which are similar to the current article.

Search Process Execution

Review of reusable assets

Methods for reusing assets

Validation status for assets

Graph representing the percentage of validation.

Graph showing the research contribution for each

Assessing the value of reuse

Reuse metrics and models

Validation status for value

Graph representing the percentage of validation.

Areas in focus for value of

Graph showing the research contribution for each

Methods/Models/ Metrics/ Approach

Graph representing the percentage of validation.

Graph showing the research contribution for each

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

Basic Inclusion Criteria

Table 2: Basic Inclusion Criteria

Detailed inclusion/ exclusion criteria

Table 3: Detailed Inclusion/ Exclusion Criteria

asset AND reuse OR reusable AND software

Table 4: Search Terms and Search Questions for Reusable Assets

Table 5: Hits after Each Phase for RQ1

[Jacobson et al, 97]

[Peter Eeles, 08]

[Li. H et al, 92]

[White et al, 98]

[Baum et al, 98]

[Griss et al, 99]

[Clements et al, 01]

[R. Leach, 97]

[Kevin W. Jameson, 89]

[Paul Kogut, 95]

[Childs and Sametinger, 96]

[David M. Levy, 93]

[Aida Boukottaya et al, 06]

[David Barta et al, 96]

[E. Guerrieri, 98]

[R. Leach, 97]

[Lozano-Tello et al, 02]

[Frakes, W et al, 96]

[Robert Bogue, 06]

[P. Gomes et al, 06]

[Parsons et al, 04]

[Kucza et al, 01]

[Von Krogh et al, 05]

[Liu Xue-Mei et al, 09]

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

{Module AND dependenc} AND {Software AND maintenance} AND reus