Professional Documents
Culture Documents
Software Engineering
Thesis no: MSE-2010:07
April 2010
School of Computing
Blekinge Institute of Technology
Box 520
SE 372 25 Ronneby
Sweden
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.
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.1 METHODOLOGY EXECUTION ........................................................................................... 21
3.2 RESULTS ............................................................................................................................ 22
3.2.1 Taxonomy ................................................................................................................. 22
3.2.2 Bubble Graph ............................................................................................................ 25
3.2.3 Results ........................................................................................................................ 26
3.3 ANALYSIS ........................................................................................................................... 29
3.3.1 State of Validation..................................................................................................... 29
3.3.1.1 Overall Validation Status .................................................................................. 29
3.3.1.2 Validation Status for Each Category ................................................................ 31
3.3.2 AREAS IN FOCUS ....................................................................................................... 33
3.3.3 REPRESENTATION METHODS ................................................................................... 34
4 MAINTENANCE OF REUSABLE SOFTWARE .............................................................. 36
4.1 METHODOLOGY EXECUTION ........................................................................................... 37
4.2 RESULTS ............................................................................................................................ 39
4.2.1 Maintenance Taxonomy .......................................................................................... 39
4.2.2 Bubble Graph ............................................................................................................ 40
4.2.3 Results ........................................................................................................................ 41
iii
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
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 metrics and models used for assessing the value of reuse.
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
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
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
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.
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,
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 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
Academia
Reusable Assets
RQ 1.1
Software Reuse
Academia
Methods
RQ 1.2
Software Reuse
Academia
RQ 1.3
Software Reuse
Assets in focus
Academia
RQ 2
Software Reuse
Academia
RQ 2.1
Software Reuse
Academia
RQ 2.2
Software Reuse
Academia
RQ 3
Software Reuse
Maintenance of software
reuse
Academia
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
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
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.
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.
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
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]
[35]
[Sametinger, 97]
[36]
[37]
[38]
[39]
[40]
[Gomaa, 95]
[41]
[42]
[65]
[Giuseppe, 94]
[1]
[I Issenin, 04]
[2]
[Jones, C, 93]
[21]
[W Frakes, 96]
[22]
[23]
Data
13
Designs
Documentation
Estimation template
Human Interface
Knowledge
10
[26]
[V Upadhyay, 92]
[29]
[G Arango, 93]
[33]
[ Jones, 93]
[21]
[S Komiya, 94]
[30]
[28]
[W Frakes, 96]
[22]
[S Channarukul, 05]
[32]
[P Gomes, 06]
[31]
[J E Ettlie, 08]
[27]
[J.Sametinger, 96]
[3]
[4]
[5]
[6]
[7]
[8]
[Jones C, 93]
[21]
[W Frakes, 96]
[22]
[23]
[ Jones, C. 93]
[21]
[W Frakes 96]
[22]
[Jones C, 1993]
[21]
[66]
[22]
[67]
[Swanson, 89]
[68]
[58]
[59]
[60]
[61]
[62]
[31]
[64]
[Hall, 87]
[117]
[Yglesias, 93]
[118]
[Soundarajan, 98]
[119]
14
Models
[Larsen, 06]
[71]
Modules
[Isoda, 92]
[69]
[70]
[Leach, 97]
[23]
[187]
[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]
[35]
[Sametinger, 97]
[36]
[Monzon, A. 08]
[43]
[207]
[45]
[Lam, W. 97]
[46]
[47]
[48]
[49]
[50]
[51]
[52]
[53]
[54]
[55]
[56]
[57]
[24]
[202]
[13]
[14]
[A V Mayrhauser, 93]
[15]
Plans
Requirements
Service Contracts
19
10
15
[16]
[D D Lonngren, 98]
[17]
[J D. McGregor, 02]
[18]
[19]
[J A Dallal, 08]
[20]
[Jones, C. 93]
[21]
[W Frakes, 96]
[22]
2.2.2
Bubble Graph
In figure 2, we present a systematic mapping using a bubble graph. Bubble graph briefing is
given below.
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
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.
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
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
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
Methodology Execution
The search terms and search combinations are formed in order to answer the research
questions RQ2, RQ2.1 and RQ2.2. In the table 7, search terms and search combinations are
presented. Some search terms 1, 2, 3, 4, 5, 6, 14, 15 and 23 in table 7 were considered as initial
search terms. After applying these search terms, we could find few studies and among them is
a study by Frakes W B [22] in which he categorized the reuse metrics and models in to 6
categories. For discussing in details regarding these 6 categories mentioned by [22], we have
again formed the search terms for each and every category as shown in table 7. For example:
A category named Maturity Assessment is present in Frakes Taxonomy. In order to get
detailed information regarding maturity assessment, we have used "Maturity" and
"Assessment" as our search terms.
Search Terms
1.
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.
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
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
23
24
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]
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
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]
Frakes W et al
J. Mascena et al
[198]
[112]
Jorge, C et al
[113]
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
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]
Frakes, W B
[108]
"Quantitative studies of
software reuse"
"Ada reusability and
measurement"
"Software reuse: metrics and
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
[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]
[22]
Frakes, W B
[22]
McCarey, F
[103]
Parvinder, S S
[104]
28
Support for
understanding
Metrics
Efficiency
Metrics
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
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
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
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.
3. Amount of Reuse Metrics
We have chosen 15 studies regarding this study. In those 3 studies are validated and 6 are non
validated models/metrics/methods, 6 are review studies and study [110] is an extension to
study [109] and there is not much validation is done in the past studies regarding this amount
of reuse metrics study.
The amount of reuse metrics is subdivided into six categories as discussed in section 3.2.3.
Almost all the studies discussed about the general or basic amount of reuse metrics, reuse level
and reuse frequency and a very few articles like Poulin [82], Frakes [198], Basili [199],
Devanbu [200], Frakes [95], Suri [111], Mascena [112, 113] were found which discussed on
other reuse metrics like reuse percentage, reuse size and frequency, reuse ratio, reuse rate.
Among the found studies around 20% are validated, 40% of the studies reported are non
validated models/metrics/methods and another 40% of studies are reviews. From the
percentage figures, we can observe that there are more non-validated and review studies
regarding amount of reuse metrics and so, much more effort should be kept in validating the
models mainly in the industrial scenario.
4. Failure Modes Models
We could find 2 studies that could best suit for our cause and study [108] is a not validated
model and study [22] is a review study.
. W Frakes in [22] [108] was the only author who presented and mentioned about the failure
modes model in his studies, according to our observation. The concept is very useful for the
organization to make them know the obstacles for reuse. So it is good to have much more
research in this field is required.
5. Reusability Assessment Models
We could find 9 studies important regarding this study. In those 3 are validated and 5 are non
validated models or metrics or methods or frameworks. 1 study is a review study.
The 8 studies that are found regarding reusability assessment had a common aim of assessing
the readiness of an artifact to be reusable or to indicate the possibility that an artifact is
reusable. Only 33.3% of the models are validated and 55.5% of models are non-validated and
11.1% is review study. The research in this field from 1997 to 2003 seems to be not much. We
strongly recommend much research to be done in this area focusing on the other reusable
assets (which are other than coding) by not sticking to code itself.
32
120
Percentage of Validation
100
80
60
Academic
Industrial
40
Survey
20
0
Cost-Benefit Analysis
Maturity Assessment
Amount of Reuse
Failure Modes
Study Category
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
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
3.3.3
Here we present the percentage of representation methods used by the authors to represent
their methods/models/metrics etc;
1. Cost Benefit Analysis Models
review results shows that approximately 77.7% of the studies represented their
metrics/models/methods through the mathematical means and about 22.3% of the studies
represented through diagram or tables or theories. Other studies used the diagrams or table or
theory to represent or describe their metrics/models/methods.
2. Maturity Assessment Models
Systematic mapping study results shows that approximately 16.6% of the studies represented
their metrics/models/methods through the mathematical means and about 83.4% of the studies
represented their metrics/models/methods through diagrams or tables or theories. .
3. Amount of Reuse Metrics
Systematic mapping study results shows that approximately 40% of the studies represented
their metrics/models/methods through the mathematical means and about 60% of the studies
represented through diagram or tables or theories.
4. Failure Modes Models
Only two studies were found in this category and those two studies represented their models
using diagrammatic, tabular and theoretical approaches.
5. Reusability Assessment
Systematic mapping study results shows that approximately 28.6% of the studies represented
their metrics/models/methods through mathematical means and about 71.4% of the studies
represented through diagram or tables or theories.
34
35
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
Methodology Execution
The methodology execution involves identification of the search terms and framing of search
questions. The search terms and search combinations are formed in order to answer the
research questions RQ3. In the table 10, we present the search terms and search combinations.
The first 11 search terms in table 10 were considered as initial search set of search terms. By
applying these search terms, we could find studies related to various areas like software
configuration management, module dependencies, change impact analysis, legal issues and
aging symptoms which have impact on the maintenance of software reuse. Based on these, we
defined taxonomy for maintenance in which we categorized the individual topic areas. For
getting relevant studies regarding these categories, we used the terms like software
configuration management, module dependencies etc which are obtained from the initial
set of search terms on to the electronic database.
Search Terms
1.
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
2.
{{contract OR legal OR Trust} AND issues} + { software AND Reus* } + {software AND maint*}
3.
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.
9.
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
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
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.
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
Reference Number
Kwon, O. C
[121]
Approach
Michael Jiang
[125]
Model
Bennett, K. H.
[123]
Tool
RAPID Tool
Baldassarre
[124]
Model
Object-Oriented
Model
Heisler
[194]
Approach
Yau, S.S
[141]
Metrics
A
Framework
for
Maintenance Metrics
Software
Pfleeger
[193]
Approach
D. Kung
[127]
Approach
L. Li
[128]
Method,
M. Lee
[192]
Method
Ye Wu
[142]
Approach
Chaining Technique
J.A. Stafford
[190]
Approach
Briand et al
[189]
Approach
Hewitt, J
[134]
Method
Canfora
[135]
Approach
Tie, F
[184]
Approach
H.Z. Bilal
[136]
Method
Sherriff
[138]
Method
Sai Zhang
[139]
Tool
Change Impact
Analysis
Contribution Name or
Metrics
Maintenance-Oriented
impact
value
41
Software
Configuration
Management
Module
Dependencies
Approach
Mehboob
[140]
Model
Aquilino
[147]
Tool
Lampson
[143]
Tool
Walter F. Tichy
[144]
Tool
V. Ambriola
[146]
Tool
Josh MacDonald
[149]
Tool
ROSE Tool
Zimmermann
[151]
Model, Tool
Junqueira
[195]
Approach
Hall
[152]
Approach
A.T. Ying
[150]
Approach
Predicting Change
Software System
Hassan
[153]
Approach
Edward B. Allen
[157]
Approach
S. R.Schach
[158]
Approach
Liguo Yu
[160]
Approach
Bart Du Bois
[161]
Approach
S.R.Schach
[162]
Approach
Dynamic
Technique
A. B. Deraman
[196]
Approach
Thomas, L.G
[165]
Metrics
Yu
[166]
Approach
Alspaugh
[173]
Method
Iterative Reengineering
Functions
Legacy
Metrics
Legal Issues
Aging
Symptoms
for
Cedar
Propagation
Coupling
in
Measurement
of
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
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
Percentage of Validation
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
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
Future work:
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.
50
REFERENCES
[1]
[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]
[4]
[5]
[6]
[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]
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
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
60
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
Volume 6(Issue 3): pp: 38-42.
[172] Sneed, H. M. (2008). "Offering software maintenance as an offshore service."
Software Maintenance, 2008. ICSM 2008. IEEE International Conference on: pp: 1-5.
[173] Alspaugh, T. A., Asuncion, H. U., and Scacchi, W. (2009). Analyzing software
licenses in open architecture software systems. In Proceedings of the 2009 ICSE
Workshop on Emerging Trends in Free/Libre/Open Source Software Research and
Development (May 18 - 18, 2009). International Conference on Software Engineering.
Washington, DC, IEEE Computer Society: pp: 54-57.
[174] Giuseppe, V. (2001). "Ageing of a data-intensive legacy system: symptoms and
remedies." Journal of Software Maintenance and Evolution: Research and Practice
13(5): 281-308.
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.
63
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)
AGE
Aging
AL
Algorithms
Ap (Approach)
AR
Architecture
ARM
C (Category)
CIA
COS
DA
Data
DE
Designs
DO
Document
E.T
Extension To
ET
Estimation Templets
Ex
Example
FMM
Fr (Framework)
HI
Human Interfaces
KN
Knowledge
66
Legal Issues
MAT
Maturity Assessment
MD
Models
MDP
Module Dependencies
Me (Metric)
ML
Modules
Mn (Mention)
Mo (Model)
Mt (Method)
NV (Non-validated)
PL
Plans
RAS
Reusability Assessment
RLM
RQ
Requirements
Rw (Reviews)
SC
Service Contracts
SCM
STR
Strategies
Sy (Survey)
TC
Test Cases
Tl (Tool)
67
2.1. Algorithms
R.
No
Year
Validation
IC AC AE IE Sy
[25]
1997
Discussion Rw
Ap
AL
Description
Mn
1
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
Discussed on architecture
[35]
1997
AR
Discussed on architecture
[39]
1998
AR
Discussed on architecture
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.
68
1998
AR
[42]
1999
AR
[37]
2008
AR
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
[1]
1994
DA
[22]
1996
DA
[23]
1997
DA
[2]
2004
DA
2.4. Design
R.
Year C
Validation
Rw
Description
no.
IC AC AE Ex
[26] 1989
DE
[29] 1992
DE
[33] 1993
DE 1
Sy
Ap Mn
1
69
DE
[30] 1994
DE
[28] 1995
DE
[22] 1996
DE
[32] 2005
DE
[58] 2006
DE
[27] 2008
DE
1
1
2.5. Documentation
R.
Year
Validation
N.V
E.T
Me
Mo
Mt/Tl
Discuss
Rw
Description
no.
IC
AC
AE
IE
S
y
Ap
Mn
[5]
1993
DO
[21]
1993
DO
[3]
1996
DO
[4]
1996
DO
[22]
1996
DO
[7]
1996
DO
[23]
1997
DO
[8]
1998
DO
[6]
2006
DO
1
1
[5]
70
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
[22]
1996 ET
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
[21]
1993
HI
Mentioned as asset.
[22]
1996
HI
Mentioned as asset.
[66]
2002
HI
Mentioned as asset.
[67]
2006
HI
2.8. Knowledge
R.
Year
Validation
Description
no.
IC AC AE IE Sy
Ap
Mn
[117]
1987
KN
[118]
1993
KN
[119]
1998
KN
[64]
1999
KN
[65]
2001
KN
[60]
2001
KN
1
1
71
2004
KN
[61]
2005
KN
[58]
2006
KN
[31]
2008
KN
[62]
2009
KN
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
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
[69]
1992
ML
[70]
1994
ML
[23]
1997
ML
72
2.11. Plans
R.
Year C
Validation
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
[23]
1997
PL
[12]
2001
PL
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
[36]
1997
RQ
[46]
1997
RQ
1
1
73
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
[16]
Proposed
an
approach
for
requirements reuse based on the
forecasting of user needs. But failed
to discuss regarding the knowledge
acquisition.
74
R.
Year C
Validation
Rw
Description
No
IC AC AE IE Sy
Ap Mn
[202] 1997
SC
[24]
SC
2005
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
[17]
1998
TC
[18]
2002
TC
[16]
2004
TC
[19]
2008
TC
[20]
2008
TC
[13]
2008
TC
1
1
Table 27: Result Table for Test Case/ Test Plan Reuse.
75
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
[72]
1989
COS
[73]
1991
COS
[81]
1991
COS
[74]
1
[75]
1992
COS
[72]
[76]
1993
COS
[82]
1993
COS
[115]
1993
COS
[22]
1996
COS
[77]
2002
COS
[78]
2003
COS
[116]
2003
COS
[114]
2004
COS
[79]
2007
COS
[80]
2008
COS
1
1
1
1
76
Year
Validated
N.V
E.T
Rw
Me
Mo
Mt
Fr
Ap
no.
Description
of
IC
[83]
Validation
1991
AC
AE
IE
Sy
MAT
[84]
1992
MAT
[83]
[85]
1993
MAT
[84]
[22]
1996
MAT
[106]
1998
MAT
[86]
1999
MAT
[87]
2000
MAT
[88]
2004
[89]
2007
[85]
[85]
MAT
MAT
[88]
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
[110]
1993
ARM
[109
]
[82]
1993
ARM
[198]
1994
ARM
[91]
1995
ARM
77
1996
ARM
[199]
1996
ARM
[22]
1996
ARM
[200]
1996
ARM
[93]
1998
ARM
[94]
1999
ARM
[112]
2005
ARM
[113]
2006
ARM
[95]
2009
ARM
[111]
2009
ARM
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
78
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
[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
Proposed a metrics suit that composed of six metrics which are proved
to be used to measure the component's reusability through experimental
validation.
Year
Validated
N.V
E.T
Rw
Me
Mo
no.
Mt
Fr
Ap
Validation
Description
of
IC
AC
AE
IE
Sy
[102]
1986
RLM
[105]
1994
RLM
[22]
1996
RLM
Metrics
for
indexing
effectiveness, Efficiency
[103]
2006
RLM
[104]
2007
RLM
costs,
search
79
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
[121]
[120]
Did a comparitative study between the FullReuse and Iterative-Enhancement Model and
concluded that Full-Reuse Model degrades
software quality. Also developed RAPID
Tool
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
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
[126]
[129]
[131]
[135]
2005
CIA
[184]
2005
CIA
[136]
2006
CIA
[137]
2008
CIA
[128]
[141]
81
2008
CIA
[139]
2008
CIA
[140]
2009
CIA
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
[153]
2004
SCM
[151]
2005
SCM
[195]
2008
SCM
[144]
82
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
[155]
1980
MDP
[156]
1993
MDP
[157]
2001
MDP
[158]
2002
MDP
[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]
[160]
[167]
[160]
[158]
[159]
[166]
2009
MDP
83
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
[70]
1994
LEG
[169]
2001
LEG
[170]
2004
LEG
[171]
2005
LEG
[172]
2008
LEG
[173]
2009
LEG
[170]
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]
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