International Journal of Scientific Research and Engineering Studies (IJSRES)
Volume 2 Issue 12, December 2015
Assessment Of Components Stability For Modernization Using
Software Maturity Index
Ekanem Bassey Asuquo
Computer Science Department,
Delta State Polytechnic, Ozoro, Nigeria
Abstract: Software modernization is a common
phenomenon in the software industry due to the constant
need to transform legacy systems into modernized versions
with enhanced quality as occasioned by at least 10% annual
increase in legacy code in the software industry.
Component-based modernization as applicable to legacy
applications relies on components extracted from the system
and selected for reuse. In selecting the components, some
reusability attributes are usually considered of which
components stability is one of such. Unfortunately, the task
of selecting stable components for reuse especially from
legacy applications is a very difficult one due to inadequate
techniques and models for assessing this attribute. This
research therefore, presents a technique for assessing the
stability of extracted components from legacy application
using software maturity index together with components
ranking scale comprising of Highly Stable, Fairly Stable,
Stable, Unstable, Fairly Unstable and Highly Unstable
which could be used to rank the components accordingly
before they are selected for reuse. The research further
emphasizes the importance of proper software maintenance
data recording as such is a major requirement for legacy
components reusability assessment.
Keywords: Legacy Software, Components Stability
Assessment, Software Maturity Index, Software
Modernization.
I. INTRODUCTION
When software applications are deployed and used for
decades, they become legacy systems. The frequent
technological changes and the dynamism of the environment
in which they operate usually demand for regular maintenance
to extend their usable life. However, modifications to such
systems are usually difficult and expensive due to their
unfriendly characteristics, namely language obsoleteness, poor
code structure, poor data abstraction, lack of qualified
www.ijsres.com
ISSN: 2349-8862
engineers with experience in the obsolete tools, and
incomplete documentation (Cipresso, 2010).
Though legacy maintenance might be highly challenging
and expensive, their critical nature to routine business
operations and their effectiveness in handling such operations
over the years make it difficult to abandon or replace them;
rather, they are usually transformed into modernized versions
with features that address the maintenance challenges and
drive down maintenance cost. (Malinova, 2010), Comella-
Dorda et al (2010); Saarelainen et al (2006) and Khadka et al
(2010) maintain that legacy modernization is more profitable
than outright replacement and system must be replaced only
when it can no longer be evolved.
Modernization is a common phenomenon in the software
industry due to the constant need to transform legacy systems
into modernized versions with enhanced quality as occasioned
by at least 10% annual increase in legacy code in the software
industry (Denoncourt, 2011). In fact Gartner (2012) CIOs
survey report reveals that modernization is presently one of
the top 10 IT technology priorities of CIOs globally.
Amongst the different modernization techniques in
existence, namely wrapping, migration, reengineering, and
component-oriented reengineering (CORE), CORE technique
is believed to have the greatest potentials in restructuring
legacy systems into modernized versions with best qualities
and maintainability attributes (Mishra, 2009).
Research findings indicate that components stability is a
key attribute that influence their choice for reuse in CORE
modernization (Younoussi and Roudies, 2015). However, the
task of selecting stable components for reuse especially from
legacy software could be very difficult, hence the need for a
systematic approach to components assessment and selection.
There is no doubt the fact that, information from such
assessment would serve as a guide to professionals in making
proper choice of components and providing some levels of
confidence in the components being selected.
Furthermore, preliminary review of existing literature
reveals that most of the existing models for components
assessment, mainly focus on measures to ensure well-planned
Page 47
 International Journal of Scientific Research and Engineering Studies (IJSRES)
and controlled reuse-oriented software development process in
organizations. They are designed mainly to support
reusability assessment of components built for software
development projects with little or no emphasis on reusability
assessment of components extracted from legacy systems for
reuse in modernization (Younoussi and Roudies, 2015; Fazal-
e-Amin et al, 2011; Jasmine and Vasantha, 2010).
In view of the above, this research proposes a technique
for components reusability assessment specifically designed to
assess stability attribute of components extracted from legacy
application using Software Maturity Index (SMI). The
practical demonstration of this approach is based on
maintenance data collected on three legacy applications from
different organizations.
II. REVIEW OF RELATED RESEARCH WORKS
Some of the related research works in components
reusability assessment reviewed are presented below:
In Garcia, Lucredio and Alvaro (2007), RISE Maturity
Model (RISE) is presented as a model to support organizations
in improving their software development process with respect
to components reusability assessment. It serves as a roadmap
for software reuse adoption and implementation where
reusability attributes like stability, adaptability, completeness,
maintainability and understandability were considered. Also,
in Rine and Nada (2000), Reuse Reference Model (RRM) is
presented with both technical and organizational elements
needed to establish a successful practice of software reuse in
organizations. The level of reuse as defined in RRM,
determines the capability of improvements in the productivity,
quality and time-to-market of the organization.
Jasmine and Vasantha (2010) presented a model called
Reuse Capability Maturity Model (RCMM) which focuses on
measures needed to ensure a well-planned and controlled
reuse oriented software development. The model is structured
into five levels with each level representing a stage in the
evolution to a mature reuse process. A set of maturity goals
for each level and the activities, task and responsibilities are
specified.
Other relevant research works reviewed include the
following: in Fazal-e-Amin et al (2011), a review of software
components reusability assessment approaches was made,
with the research results indicating that the majority of the
approaches (i.e. 70%) are based on metrics, and applicable to
the object oriented development projects using Java as the
target language. The research further emphasizes the need for
other approaches particularly experimental based approaches
for comparison and better results.
Also, in Younoussi and Roudies (2015), a detailed
literature review of recent research works in software
reusability is presented with stability, understandability,
portability, maintainability, flexibility, independence,
documentation, adaptability and interface complexity
identified as attributes that influence software components
reusability. The research further reports that studies on
maturity models of software reuse are limited and more
www.ijsres.com
Volume 2 Issue 12, December 2015
ISSN: 2349-8862
needed to be done in this area to help organizations in proper
auditing of their maturity reuse level.
III. FINDINGS FROM THE REVIEW
The reviewed works clearly indicate that existing
techniques and models were designed mainly to support
reusability assessment of components built for software
development projects with little or no emphasis on reusability
assessment of components extracted from legacy systems for
reuse in modernization. In other words, these techniques and
models were designed primarily to support and ensure that
reuse-oriented software development are well-planned and
controlled for successful software reuse practice in
organizations where they are applied. To this end, existing
assessment techniques rely on software development data
from integration testing for the measurement (Fazal-e-Amin,
2011); whereas maintenance data of legacy application from
one version to another are needed in the case of legacy
components reusability assessment.
Considering the fact that new applications deployed for
use in organizations today are tomorrow’s legacy applications
and candidates for modernization, there is a need to fill the
gap of inadequate techniques for legacy components
reusability assessment if the present gains in component-
oriented modernization as applicable to legacy system are to
be consolidated. This could be addressed by adapting existing
models primarily designed for components assessment in
development projects to utilize legacy maintenance data in
assessing legacy components reusability. Better still new
techniques and models could be evolved specifically for
legacy reusability assessment to fill the gap.
IV. DESCRIPTION OF SOFTWARE MATURITY INDEX
(SMI) MODEL
Software Maturity Index (SMI), a metric in IEEE (1988),
specifically IEEE 982.1-1988 was introduced to measure the
maturity of software systems as a software evolves from one
version to another. The metric is represented thus:
SMI = (M – (A + C + D))/M
where
M = number of modules in current version
A = number of added modules in current version
C = number of changed modules in current version
D = number of deleted modules in current version
More precisely, SMI = 1 – N/M
Where
M is the total number of modules in the current version of
the system
N is the number of modules added, changed or deleted
between the previous version and the subsequent version.
According to the standards, SMI can be used as a measure
of product stability. Therefore, when SMI approaches 1.0 the
product is said to be stable. Also, when this is correlated with
the time it takes to complete a version of the software, an
Page 48
 International Journal of Scientific Research and Engineering Studies (IJSRES)
Volume 2 Issue 12, December 2015
ISSN: 2349-8862

indicator of the maintenance effort needed in maintenance is
obtained.
A closer examination of this model reveals possible
adaption to fit into legacy component stability assessment. In
this case, the maintenance data on each component in the
recent versions of a legacy application could be collected and
used to compute the respective SMIs of each components; in
which case modules as used in the model are replaced by
legacy components in the application under study. The result
of such computation is further interpreted and used to
determine components stability. This research is based on this
concept and uses maintenance data on three legacy
applications from three organizations.
CPXid = the identification number of component x, for x =
1 to the nth component in the Application.
The datasheet has sections to collect data on the last four
versions of the application which are denoted as Version N-3,
Version N-2, Version N-1, and Version N,
VII. DATA PRESENTATION AND ANALYSIS
Data collected on three legacy applications labelled
Legacy Applications A, B and C from the three (3)
organizations are given below:

Component
Version N-3 Version N-2 Version N-1 Version N

Id
V. RESEARCH METHODOLOGY
M A C D M A C D M A C D M A C D

The research work was designed as a case study research A1 13 4 2 1 17 3 1 0 20 0 3 0 20 0 1 0

with the following processes: A2 10 2 2 0 12 2 4 3 14 3 3 4 17 1 5 2

 Review of relevant documentations A3 14 1 2 0 15 3 3 1 18 1 1 1 19 0 1 0

 Semi-structured interview with relevant professionals at A4 6 0 1 0 6 3 3 1 9 0 0 1 9 1 2 2
the Case study organizations for data collection A5 12 1 0 0 13 5 2 0 18 0 2 0 18 2 5 2
 Data Coding and Analysis A6 9 2 1 0 11 2 4 1 13 1 1 0 14 0 1 0
 Results Interpretation and discussions A7 9 1 3 0 10 4 1 2 14 3 1 1 17 1 0 0
A review of relevant literature was made to establish the
level of achievements in the research area and identify Table 2: Maintenance Record of Legacy Application A
research gaps. Furthermore, three organizations coded in this
Component

research as Organization A, Organization B, and Organization

Id

Version N-3 Version N-2 Version N-1 Version N

C were selected as case study organizations for the research
with legacy applications in these organizations selected for the
research coded as Legacy Application A, Legacy Application M A C D M A C D M A C D M A C D
B and Legacy Application C. The identified reusable A1 8 2 2 2 10 2 3 2 12 1 0 2 13 0 4 0
components in each application are coded as Ai where i = 1 to
the nth identified component. For instance, A1, A2, A3 … A2 11 1 2 1 12 1 2 1 13 2 2 2 15 1 2 0

A12 refer to the twelve components of a particular legacy A3 9 3 2 0 12 3 3 0 15 0 1 0 15 1 1 0

application. A4 9 1 1 1 10 2 1 1 12 1 1 1 13 0 0 3
Datasheets carefully designed with the required data
A5 10 0 0 1 10 4 2 0 14 1 0 3 15 0 1 1
columns were administered to the software professionals in
charge of the selected legacy systems in those organizations to A6 7 1 1 0 8 1 4 1 9 3 2 0 12 1 1 0

complete and return accordingly. The data were coded and A7 8 1 3 0 9 3 1 2 12 2 1 0 14 0 1 0

analyzed using statistical packages to generate results that are
A8 10 2 2 1 12 1 2 1 13 1 2 1 14 1 0 1
further interpreted and reported accordingly.
A9 6 1 2 2 7 2 2 1 9 0 2 1 9 1 0 0

A10 7 0 1 0 7 2 1 0 9 2 0 2 11 0 1 1
VI. DATA COLLECTION A11 5 2 3 0 7 1 0 0 8 1 0 0 9 1 1 0

A12 6 3 2 1 9 2 2 2 11 1 1 2 12 0 2 1
The datasheet presented below was administered to the
three software professionals in charge of the selected legacy Table 3: Maintenance Record of Legacy Application B
applications in the three case study organizations. The
maintenance data were entered accordingly in the datasheet
Component Id

and returned for further processing:

Compone Version N-3 Version N-2 Version N-1 Version N Version N-3 Version N-2 Version N-1 Version N
nt M A C D M A C D M A C D M A C D
Id
CPXid
Table 1: Datasheet for Legacy Maintenance Data Collection
where M = number of modules in current version
A = number of added components in current version M A C D M A C D M A C D M A C D

C = number of changed components in current version

D = number of deleted components in current version A1 8 2 1 1 10 2 0 1 12 1 0 0 13 0 1 0

www.ijsres.com Page 49
 International Journal of Scientific Research and Engineering Studies (IJSRES)
Volume 2 Issue 12, December 2015
ISSN: 2349-8862

A2 11 1 3 0 12 1 3 0 13 2 4 2 15 3 3 2
A5 0.9
0 0.40 0.71 0.87
A3 12 0 2 1 12 2 2 0 14 0 2 0 14 0 1 0
A6 0.7
1 0.25 0.44 0.83
A4 10 2 2 0 12 4 4 0 16 3 3 1 19 1 0 0 A7 0.5
0 0.33 0.75 0.93
A5 11 4 1 1 15 2 0 1 17 1 0 2 18 0 0 1 A8 0.5
0 0.67 0.69 0.86
A6 9 3 1 1 12 3 3 2 15 0 1 1 15 0 1 0 A9 0.1
7 0.29 0.67 0.89
A7 10 2 3 0 12 4 1 3 16 0 0 1 16 0 1 0 A10 0.8
6 0.57 0.56 0.82
A8 6 2 4 0 8 4 0 3 12 3 0 3 15 0 1 0 A11 0.0
0 0.86 0.88 0.78
A9 8 3 2 0 11 2 3 2 13 1 3 2 14 2 1 2 A12 0.0
0 0.33 0.64 0.75
Table 4: Maintenance Record of Legacy Application C Table 6: Software Maturity Index of Legacy Application B

Component
Software Maturity Index (SMI)

Id
VIII. RESULTS AND DISCUSSIONS Version Version Version Version
N-3 N-2 N-1 N
The maintenance data were entered into statistical
package with appropriate formulae entered based on the SMI
model to generate the SMIs for each component per legacy A1 0.50 0.70 0.92 0.92
application. A2 0.64 0.67 0.38 0.47
A3 0.75 0.67 0.86 0.93
A. SOFTWARE MATURITY INDEX OF APPLICATION A4 0.60 0.33 0.56 0.95
COMPONENTS A5 0.45 0.80 0.82 0.94
A6 0.44 0.33 0.87 0.93
The table below presents the SMIs of legacy components A7 0.50 0.33 0.94 0.94
for each application: A8 0.00 0.13 0.50 0.93
A9 0.38 0.36 0.54 0.64
Component

Software Maturity Index (SMI)

Id

Table 7: Software Maturity Index of Legacy Application C

Versio Versio Version Version N
n N-3 n N-2 N-1 B. COMPONENTS STABILITY ASSESSMENT

A1 0.46 0.76 0.85 0.95 For better understanding of the results, graphical
A2 0.60 0.25 0.29 0.53 representation of the components SMIs were obtained. Figure
A3 0.79 0.53 0.83 0.95 1 is the graphical representation of the SMIs of the seven
A4 0.83 -0.17 0.89 0.44 components in Legacy Application A. Also, graphical
A5 0.92 0.46 0.89 0.50 representation of the SMIs of components in Legacy
A6 0.67 0.36 0.85 0.93 Application B and C are given in figures 2 and 3.
A7 0.56 0.30 0.64 0.94
Table 5: Software Maturity Index of Legacy Application A
Compo

Software Maturity Index (SMI)

Id
nent

Ve Vers Vers Version

rsion ion N-2 ion N-1 N
N-3
A1 0.2
5 0.30 0.75 0.69
A2 0.6
4 0.67 0.54 0.80
A3 0.4
4 0.50 0.93 0.87
A4 0.6
7 0.60 0.75 0.77 Figure 1: Software Maturity Index for Legacy Application A

www.ijsres.com Page 50
 International Journal of Scientific Research and Engineering Studies (IJSRES)
Volume 2 Issue 12, December 2015
ISSN: 2349-8862

FAIRLY UNSTABLE: A component is said to be Fairly

Unstable if it is characterized by regular/irregular SMI
decreases in the last three software Versions with the last two
SMIs receding from 1
HIGHLY UNSTABLE: A component is said to be Highly
Unstable if it is characterized by regular/irregular SMI
decreases in the last three software Versions with the SMIs
receding from 1
For the purpose of clarity, 0.9 is fixed as a benchmark for
SMI tending to 1. Applying the above principle to Legacy
Application A, the following components rankings are
obtained: A1, A3 and A6 are Fairly Stable Components; A7 is
a Stable Component; A4 and A5 are Fairly Unstable
components while A2 is and unstable Components. For this
legacy application, components A1, A3 and A6 are best
Figure 2: Software Maturity Index for Legacy Application B candidates for reuse due to their position in components
ranking in the application. This is summarized in table 8;
while tables 9 and 10 summarize those of Legacy Applications
B and C.
Component Rank
Component
Software Maturity Status
Index (SMI)
Id
Ver Ver Ver Ver
sion sion sion sion
N-3 N-2 N-1 N
A1 Regular SMI Fairly
increases Stable
with last
two tending
0.46 0.76 0.85 0.95 to 1
A2 Regular SMI Unstabl
Figure 3 increases e
with the
C. COMPONENTS RANKINGS SMIs not
0.60 0.25 0.29 0.53 tending to 1
For better results from stability assessment, there is need A3 Regular SMI Fairly
to rank the components based on their SMI values since for increases Stable
instance, the stability level of any two components based on with last
their SMIs may not be the same. This sort of ranking will two tending
further boast the confidence of the software professionals in 0.79 0.53 0.83 0.95 to 1
the components being selected for reuse. To this end, this A4 Irregular Fairly
research presents a components ranking scale with the SMI Unstabl
following: Highly Stable, Fairly Stable, Stable, Unstable, decreases e
Fairly Unstable and Highly Unstable. The criteria for this with the last
ranking is given thus: two
HIGHLY STABLE: A component is said to be Highly - receding
Stable if it is characterized by regular SMI increases in the last 0.83 0.17 0.89 0.44 from 1
three application versions with all three SMIs tending to 1
A5 Irregular Fairly
FAIRLY STABLE: A component is said to be Fairly Stable
SMI Unstabl
if it is characterized by regular SMI increases in the last three
decreases e
application versions with the last two SMIs tending to 1
with the last
STABLE: A component is said to be Stable if it is
two
characterized by regular SMI increases in the last three
receding
application versions with the SMI of the recent version
0.92 0.46 0.89 0.50 from 1
tending to 1
A6 Regular SMI Fairly
UNSTABLE: A component is said to be Unstable if it is
increases Stable
characterized by regular/irregular SMI increases between the
with last
last three application versions with the SMIs not tending to 1
0.67 0.36 0.85 0.93 two tending

www.ijsres.com Page 51
 International Journal of Scientific Research and Engineering Studies (IJSRES)
Volume 2 Issue 12, December 2015
ISSN: 2349-8862

to 1 tending to 1
A7 Regular SMI A9 Regular SMI unstab
increases Stable increases le
with the with the
SMI of the SMIs not
recent 0.17 0.29 0.67 0.89 tending to 1
version A10 Regular SMI unstab
0.56 0.30 0.64 0.94 tending to 1 increases le
Table 8: Ranking of Legacy Application A Components with the
Component Rank SMIs not
Component

Software Maturity Status 0.86 0.57 0.56 0.82 tending to 1

Index (SMI) A11 Irregular Fairly
Id

Ver Ver Ver Ver SMI Unsta

sion sion sion sion decreases ble
N-3 N-2 N-1 N with the last
A1 Regular SMI unstab two
increases le receding
with the 0.00 0.86 0.88 0.78 from 1
SMIs not A12 Regular SMI Unsta
0.25 0.30 0.75 0.69 tending to 1 increases ble
A2 Regular SMI unstab with the
increases le SMIs not
with the 0.00 0.33 0.64 0.75 tending to 1
SMIs not Table 9: Ranking of Legacy Application B Components
0.64 0.67 0.54 0.80 tending to 1 From the above, A7 is the only component suitable for
A3 Irregular Fairly reuse due to its position in components ranking in the
SMI Unsta application since others are in unstable category.
decreases ble Components Rank
Component

with the last Software Maturity Status

two Index (SMI)
Id

receding Ver Ver Ver Ver

0.44 0.50 0.93 0.87 from 1 sion sion sion sion
A4 Regular SMI Unsta N-3 N-2 N-1 N
increases ble A1 Regular SMI Fairly
with the increases Stable
SMIs not with last two
0.67 0.60 0.75 0.77 tending to 1 0.50 0.70 0.92 0.92 tending to 1
A5 Regular SMI Unsta A2 Regular SMI Unstab
increases ble increases le
with the with the
SMIs not SMIs not
0.90 0.40 0.71 0.87 tending to 1 0.64 0.67 0.38 0.47 tending to 1
A6 Regular SMI Unsta A3 Regular SMI Stable
increases ble increases
with the with the SMI
SMIs not of the recent
0.71 0.25 0.44 0.83 tending to 1 version
A7 Regular SMI Stable 0.75 0.67 0.86 0.93 tending to 1
increases A4 Regular SMI Stable
with the increases
SMI of the with the SMI
recent of the recent
version version
0.50 0.33 0.75 0.93 tending to 1 0.60 0.33 0.56 0.95 tending to 1
A8 Regular SMI Unsta A5 Regular SMI Stable
increases ble increases
with the with the SMI
0.50 0.67 0.69 0.86 SMIs not 0.45 0.80 0.82 0.94 of the recent

www.ijsres.com Page 52
 International Journal of Scientific Research and Engineering Studies (IJSRES)
Volume 2 Issue 12, December 2015
ISSN: 2349-8862

version  Software professionals in charge of modernization should

tending to 1 always perform components reusability assessment on
A6 Regular SMI Stable legacy components and rank them accordingly before
increases they are selected for reuse. For legacy components
with the SMI stability assessment, the technique presented in this article
of the recent is highly recommended.
version  Organizations should maintain proper records of their
0.44 0.33 0.87 0.93 tending to 1 software maintenance data from one version to another
A7 Regular SMI Fairly since this is a major requirement for legacy components
increases Stable reusability assessment.
with last two There should be deliberate efforts by researchers to
0.50 0.33 0.94 0.94 tending to 1 conduct researches aimed at evolving components reusability
A8 Regular SMI Stable assessment techniques and models suitable for legacy
increases components assessment for modernization.
with the SMI
of the recent
version REFERENCES
0.00 0.13 0.50 0.93 tending to 1
A9 Regular SMI Unstab [1] Cipresso, T. (2010): Software Reverse Engineering
increases le Education. Master’s Theses and Graduate Research, San
with the Jose State University. USA [online]
SMIs not http://scholarworks.sjsu.edu/etd_theses/3734 Retrieved
0.38 0.36 0.54 0.64 tending to 1 on: March 5, 2012
Table 10: Ranking of Legacy Application C Components [2] Comella-Dorda, S., Wallnau, K., Seacord, R. and Robert,
From the above, components A1 and A7 are best J. (2010): A Survey of Black-Box Modernization
candidates for reuse due to their position in components Approaches for Information Systems, Proceedings of
ranking in the application. However, A3, A4, A5, A6 and A8 International Conference on Software Maintenance pp.
can as well be selected for reuse since they are equally stable 173
though not as stable as A1 and A7. In taking such decisions, [3] Denoncourt, D. (2011): Approaches to Application
the professional will be guided by other factors that are crucial Modernization. Scandinavian Developer Conference 2011
to the modernization project. (SDC2011), Goteborg. Available at:
www.scandevconf.se/2011 accessed on: April 6, 2014.
[4] Fazal-e-Amin, Mahmood, A. K. and Oxley, A. (2011): A
IX. CONCLUSION Review of Software Component Reusability Assessment
Approaches; Research Journal of Information Technology
The research was undertaken as a concise step to filling 3(1) pp. 1-11
the gap of inadequate techniques and models for components [5] Garcia, V,. Lucredio, D. and Alvaro, A. (2007): Towards
reusability assessment to guide professionals’ decisions on a Maturity Model for a Reuse Incremental Adoption,
choice of components for reuse in maintenance. The study Proceedings of Simposio Brasileiro de Componentes,
presents a technique for assessing one of the key components Arguitetura e Reutilizacao de Software (SBCARS) pp.
reusability attribute that is components stability using SMIs 61-74
computed from legacy maintenance data drawn from recent [6] IEEE (1988): Description of Software Maturity Index.
versions of legacy applications. The research also presents a IEEE Standards.
simple approach to ranking extracted legacy components as www.standards,ieee.org/reading/ieee/std_public/descripti
highly stable, fairly stable, stable, unstable, fairly unstable and on/982.1-1988_desc.html Retrieved on: September 10,
highly unstable. 2015
With this technique for assessing legacy components [7] Jasmine, K. S. and Vasantha, R. (2010): A New
reusability, software professionals will be able to determine Capability Maturity Model for Reuse Based Software
the stability status of components extracted from legacy Development Process; IACSIT International Journal of
applications and use that as a guide for decision on whether Engineering and Technology 2(1)
such components should be reused in the application [8] Khadka, R., Batlajery, B. V., Saeidi, A. M., Jansen, S.,
modernization or not. The computed results on legacy and Hage, J. (2010): How Do Professionals Perceived
stability also has the net effect of establishing some levels of Legacy Systems and Software Modernization? Utrecht
confidence in each legacy component extracted for reuse. University, Utrecht, The Netherlands.
www.servicifi.files.wordpress.com/2010/06/icse.pdf
Retrieved on: August 1, 2014.
X. RECOMMENDATIONS [9] Rine, D. C. and Nada, N. (2000): An Empirical Study of
a Software Reuse Reference Model, Information and
The following recommendations are necessary: Software Technology Journal 42(1)

www.ijsres.com Page 53
 International Journal of Scientific Research and Engineering Studies (IJSRES)
[10] Saarelainen, M., Ahonen, J. J., Lintinen, H., Koskinen, J.,
Kankaanpaa, I., Sivula, H., Juutilainen, P. and Tilus, T.
(2006): Software Modernization and Replacement
Decision Making in Industry: A Qualitative Study
www.bcs.org/upload/pdf/ewic-ea06-paper.pdf Retrieved
on: August 26, 2014
[11] Malinova, A. (2010): Approaches and Techniques for
Legacy Software Modernization, Bulgaria Scientific
Works, 37 (2), University of Plovdiv, Plovdiv, Bulgaria.
www.fmi.uni-plovdiv.bg/GetResource?id=402 Retrieved
on: February 15, 2013
www.ijsres.com
Volume 2 Issue 12, December 2015
ISSN: 2349-8862
[12] Mishra, S. K., Kushwaha, D. S., Misra, A. K. (2009):
Creating Reusable Software Components from Object-
oriented Legacy System through Reverse Engineering.
Journal of Object Technology, ETH Zurich.
www.jot.fm/issues/issue_2009_07/article3.pdf Retrieved
on: April 17, 2011
[13] Younoussi, S. and Roudies, O. (2015): All About
Software Reusability: A systematic Literature Review;
Journal of Theoretical and Applied Information
Technology. www.jatit.org Retrieved on: September 10.
Page 54