Conference PaperPDF Available

Renaissance: A method to support software system evolution

Authors:

Abstract and Figures

Legacy systems are often business critical and are associated with high maintenance costs. In this paper, we present an overview of a method, Renaissance, which aims to manage the process of regaining control over such systems. Renaissance supports system evolution by first recovering a stable basis using reengineering, and subsequently continuously improving the system by a stream of incremental changes. In both cases, the extent of evolution is determined by a phase which takes into account of technical, business, and organisational factors. Renaissance defines a process framework, a predefined number of evolution strategies, an information repository, and a generic set of personnel responsibilities. The method can be tailored to the needs of particular projects and organisations, and it is not prescriptive of particular tools and techniques.
Content may be subject to copyright.
Renaissance: A Method to Support Software System Evolution
Ian Warren and Jane Ransom
Computing Department
Lancaster University
Lancaster, LA1 4YR, UK
Email iw | bjr@comp.lancs.ac.uk
Abstract
Legacy systems are often business critical and are
associated with high maintenance costs. In this paper,
we present an overview of a method, Renaissance, which
aims to manage the process of regaining control over
such systems. Renaissance supports system evolution by
first recovering a stable basis using reengineering, and
subsequently continuously improving the system by a
stream of incremental changes. In both cases, the extent
of evolution is determined by a phase which takes
account of technical, business, and organisational
factors. Renaissance defines a process framework, a
predefined number of evolution strategies, an
information repository, and a generic set of personnel
responsibilities. The method can be tailored to the needs
of particular projects and organisations, and it is not
prescriptive of particular tools and techniques.
Key words: evolution, reengineering, method, legacy
system, incremental, maintenance.
1. Introduction
The need for change in software systems is now well
understood. Factors which initiate change include
changes in user requirements, the emergence of new
technology, changes in business goals, and the need for
organisations to exploit new opportunities. Unless
systems can be changed to respond to their changing
environments, they will progressively become less useful
[1].
The developed world has invested heavily in software
systems. However, many of these systems are what we
define as legacy systems [2]. A legacy system is an old
system that remains in operation within an organisation.
Many legacy systems are business-critical and are
expensive to maintain. The reasons for high maintenance
costs include short anticipated system lifetimes, the
immaturity of software engineering practice at the time
of their construction, and the sacrifice in maintainability
needed to satisfy other design constraints.
Organisations which depend on legacy systems face a
dilemma [3]. Continuing to maintain the system is
expensive and may prove ineffective in accommodating
necessary changes. Alternatively, organisations may
consider replacing the system, but the costs of
developing and deploying a new system may be
prohibitively high. Furthermore, replacing a legacy
system incurs the risk of losing business critical
information; this in itself can prove fatal.
Reengineering offers a compromise between
continued maintenance and replacement of a legacy
system. Like maintenance, the starting point for
reengineering is an existing system and not a new
development project. Unlike maintenance, however,
reengineering usually involves improving the system in
some way, with the aim of reducing the costs and risks
associated with subsequent evolution [4]. Studies have
shown that reengineering, where appropriate, is generally
more cost effective and less risky than developing a new
system [5].
While developments in reengineering contribute
towards transforming legacy systems to evolveable
systems, managing the process of system change has
largely been ignored [6]. In this paper, we provide an
overview of the Renaissance method [2, 7] whose aim is
to support a controlled approach to system evolution.
2. Objectives
Providing a controlled approach to system change
essentially means reducing the costs and risks associated
with change. With these aims in mind, we have identified
four key requirements of a method to support system
evolution (Table 1).
The first requirement aims to reduce the risks and
spread the costs associated with system evolution. A
stream of incremental changes to a system involves less
risk than a single large reengineering effort or a new
development project since developers can exploit the
feedback which is available after each increment. In
addition, incremental evolution enables costs to be
distributed over time [5].
In many cases, reengineering would reduce evolution
costs and risks. However, reengineering is not always
appropriate. Requirement R2 addresses this issue; the
method should provide guidance on when to reengineer a
system and when to replace it.
Proceedings of the 26 th Annual International Computer Software and Applications Conference (COMPSAC’02)
0730-3157/02 $17.00 © 2002 IEEE
R1. The method should support incremental evolution.
R2. Where appropriate, the method should emphasise
reengineering, rather than system replacement.
R3. The method should prevent the legacy
phenomena from reoccurring.
R4. It should be possible to customise the method to
particular organisations and projects.
Table 1 Method requirements
To reduce the costs and risks of evolution in the long
term, a method which supports evolution should do more
than support a single evolution project. The method
would offer significantly greater value if it regained
control over a legacy system for the remainder of its
useful lifetime. Requirement R3 addresses this need.
Requirement R4 recognises that evolution projects are
diverse and that organisations have their own established
processes and tools. To be successful, the method should
be sufficiently flexible so that it can support this variety,
while at the same time effectively manage evolution.
Furthermore, the method should not impose an overhead
which where the cost of following the method is too high
for the return on that investment.
3. The Renaissance method
With Renaissance, we propose a two-stage process for
transforming legacy systems to evolveable systems
(Figure 1). First, a stable basis should be established
from where the legacy system can be evolved cost
effectively. This stage involves strategic planning, which
may result in reengineering the legacy system, or in
extreme cases, replacing it. Once the system has been
transformed, the costs and risks associated with its
evolution can be predicted with greater certainty than
that of the legacy system. Stage 2 applies a programme
of continuous improvement to the system for the
remainder of its useful life.
Figure 1 The Renaissance approach
The Renaissance method comprises a classification of
evolution strategies, a process framework, an
information repository, and a set of responsibilities to be
met in a typical evolution project. Each of these elements
can be tailored to fit particular project and organisational
factors.
3.1 Evolution strategies
An evolution strategy describes a particular form
which system evolution might take. We define six
strategies which span continued maintenance,
reengineering, and system replacement. Since
reengineering is a general term, we define four particular
classes of reengineering. Table 2 presents these strategies
in terms of increasing cost, benefit and risk.
Continued Maintenance is often the most cost-
effective strategy, particularly when the system is well-
documented, when there is no shortage of experienced
maintenance personnel, when the system is in good
technical condition and when it is able to accommodate
forecasted changes in requirements. For many legacy
systems, however, Continued Maintenance is
inappropriate.
Where estimates show reduced maintenance costs
following reengineering, reengineering may be a better
strategy. In addition, where a system is in poor technical
condition, or where it is dependent on obsolete
technology, reengineering may also be appropriate.
System replacement should only be considered when
reengineering solutions are not feasible or where they do
not significantly reduce cost and risk.
The Revamp strategy is appropriate where the
motivation for change is to improve the presentation of
the system in terms of its user interface. Middleware
tools exist to interpret the character stream of a text-
based user interface and generate GUI events [8]. Where
application logic and the user interface are loosely
coupled, use of such middleware products often requires
no change to the source code of the legacy system. While
the Revamp strategy gives the illusion of a new system,
it does not increase the system's evolveability since any
problems with its data or logic structures remain.
Continued
Maintenance
The accommodation of change in a
system, without radical change to its
structure, after it has been delivered
and deployed.
Revamp The transformation of a system by
modifying or replacing its user
interfaces. The internal workings of the
system remain intact, but the system
appears to have changed to the user.
Restructure The transformation of a system's
internal structure without changing any
external interfaces.
Rearchitecture The transformation of a system by
migrating it to a different technological
architecture.
Redesign with
Reuse
The transformation of a system by
redeveloping it utilising some legacy
system components.
Replace Total replacement of a system.
Table 2 Evolution strategies
(1) Reengineering
Legacy
system
Evolveable
system
(2) continuous
evolution
Proceedings of the 26 th Annual International Computer Software and Applications Conference (COMPSAC’02)
0730-3157/02 $17.00 © 2002 IEEE
Restructure is the inverse of Revamp. A restructured
system should be more evolveable since the objective of
restructuring is to simplify the system's logic and data
structures. This makes the system easier to understand
and evolve. Restructuring a system typically involves
improving the flow of procedural components, removing
redundant code, conforming to coding standards, and
reducing component dependencies. Like Revamp, there
are several tools which can be used to automate system
restructuring. There is no immediate return on the
investment in restructuring, but medium-term evolution
costs should fall because of the system's improved
evolveability.
Rearchitecture is a more radical strategy than
Restructure. Rearchitecturing involves transforming a
centralised architecture to a distributed model. Hardware
and software rearchitecturing are generally
interdependent. Rearchitecturing is more expensive and
carries greater risk than restructuring, but its benefits are
greater. A rearchitectured system is likely to be
evolveable in the long-term because it runs on modern
well-supported hardware. In addition, modern
client/server, object-oriented, and component-based
technologies typically conform to interoperability
standards and are generally more responsive to change.
Redesign with Reuse is a variation on
Rearchitecturing which aims to preserve the knowledge
and business rules that are embedded in legacy system
components by integrating them within a new
architecture. In [9] we describe how both data and
procedural components can be encapsulated for use in a
new architecture.
3.2 Process framework
Figure 2 Abstract process model
Figure 2 shows how the process model is split into
four high-level phases and Table 3 identifies key
activities for each phase. The entry phase for any
evolution project is Plan Evolution, which addresses the
system's long-term future. Plan Evolution involves
assessing the current system from technical, business,
and organisational perspectives with a view to develop
an evolution strategy.
Phase Activities
Plan Evolution Calibrate method
Assess system
Develop evolution strategy
Implement Plan evolution project
Design, transform and test system
Prepare environment
Deliver Migrate data
Install system
Train operators
Deploy and Use Changeover system
Evaluate system
Document environment changes
Table 3 Key activities
The decision reached in the Plan Evolution phase
determines whether the remaining three phases should be
followed. Where a system is found to have no useful
future, there is no need to continue with the method. In
other cases, phases Implement, Deliver, and Deploy and
Use support the tasks of managing the evolution project
and making the transition between the current and
transformed systems according to the evolution strategy.
Plan Evolution starts with a calibration activity where
the method is customised to take account of particular
project and organisational factors. In general, we
recommend techniques and tools to support method
activities. In [9] for example, we outlined an attribute-
rating scheme for assessing legacy systems for fitness for
evolution. In [10] we describe how the UML can be used
to develop system models. However, we expect that
practitioners will override some of our suggestions in
favour of their established procedures.
Once calibrated, the rationale for using Renaissance
and any project constraints should be recorded in the
information repository. These pieces of information
contribute towards the development of a system's
evolution record. Renaissance can be used to manage
many evolution scenarios, such as: systems whose
maintenance costs are too high; organisations which
intend to pursue new markets and need to determine how
their systems will need to change; and situations where
systems cannot be effectively maintained to integrate
new requirements.
Project constraints include time, budget, deployment,
and technology constraints. To illustrate a technology
constraint, in one case study, we saw that an evolution
project was initiated because of senior management's
wish to migrate their mainframe system to a distributed
client/server system. In this case, the motivation for
Evolution Planning
'what to do'
Evolution Project Management
'how to do'
Evolveable
system
Accepted
system
Plan
Evolution
Implement
Deliver
Deploy
and Use
Transformed
system
Evolution
strategy
Proceedings of the 26 th Annual International Computer Software and Applications Conference (COMPSAC’02)
0730-3157/02 $17.00 © 2002 IEEE
prescribing particular technology was to achieve a
standard technology across a large enterprise.
The key to effective evolution planning is a thorough
assessment of the legacy system [9]. Assessing a system
means calculating measures for the system's technical
quality and business value, and taking account of any
organisational factors which might affect an evolution
project.
The technical quality of a system can be measured by
assessing its software and hardware. In the absence of
reliable documentation and individuals who understand
how a system has been implemented, it will be necessary
to build context models to support the assessment
exercise. In [10] we describe how to build both context
and technical models of legacy systems using the UML.
A context model describes a system at an abstract level
and from four views: business, functional, structural, and
environmental. The business view captures a system's
support for its business process. The functional view
describes the services that implement the business
process. The structural view gives an overview of the
main configuration elements of the system and the
environmental view shows the main physical devices.
To determine the business value of a system, its
organisation's business goals should be captured.
Business goals generate tomorrow's system requirements
and they heavily influence the choice of evolution
strategy. For example, an organisation may have a
strategic plan which makes a system redundant. In this
case, continued maintenance of that system is likely to be
the only cost effective evolution strategy. In other cases,
business goals may show that the system's data and
services are critical to the organisation's continued
operation. Here, the system must survive, in some form.
Organisational factors span the organisations which
are involved in operating the system, and those that are
responsible for evolving the system. For the former, the
organisation's attitude to change could affect the success
of an evolution project. Where an organisation appears to
resist change, for example, an incremental evolution
strategy may reduce the probability of users rejecting the
evolved system. For the latter, the availability of
maintenance personnel who are experienced with a
particular legacy system is likely to affect the degree of
modelling needed to understand the system.
Based on the results of assessment, an evolution
strategy can be developed. For each evolution strategy
introduced in Table 2, we provide guidance on its
applicability. For example, each strategy is associated
with particular costs and risks; in Table 4 we point out
possible risk factors. In [11], we elaborate on risk
management and cost estimation in the context of
evolution projects. In many cases, a number of evolution
strategies will be identified as candidates. To pick the
most appropriate strategy, an exercise which considers
the relative costs, benefits, and risks of each strategy
should be performed.
Continued Maintenance
Revamp
Restructure
Rearchitecture
Redesign with Reuse
Replace
Lack of system
knowledge
bbbbb
b
Lack of experienced
maintenance personnel
bb
Poor documentation
bbbbb
b
New technology skills
shortage
bb
b
Legacy technology skills
shortage
bbb
Errors introduced during
evolution
bbb
b
Technology immaturity
bb
b
Loss of embedded
business rules
b
System will not meet
evolution requirements
bb
Obsolete operational
environment
bbb
Table 4 Evolution strategy risk factors
Phase Implement begins with planning the evolution
project which will implement the chosen evolution
strategy. Project planning has more in common with
traditional development project planning than the
strategic planning of the first phase. As such, project
planning involves allocating resources, managing risk,
estimating costs, and scheduling.
However, since evolution projects involve
transforming an existing system, they raise a number of
additional issues not found in new-development projects.
Evolution project planning should also tackle data
migration, system deployment, managing an incremental
system transformation, and integrating legacy system
components with new technology. In [2, 11], we describe
all these issues in greater depth.
Focusing on deployment very briefly, the deployment
period should generally be as short as possible to
minimise disruption to system users. The evolution
strategy dictates, to a large extent, how a system can be
deployed. For strategies which do not involve radical
reengineering or replacing the system, the system can
often be deployed incrementally. In many cases,
deploying the system incrementally can be performed
without affecting system users.
Proceedings of the 26 th Annual International Computer Software and Applications Conference (COMPSAC’02)
0730-3157/02 $17.00 © 2002 IEEE
For more challenging reengineering projects or where
the legacy system is to be replaced, the legacy system
typically has to be decommissioned before the new
system can be deployed. However, the drawback of this
approach is the inevitable disruption and loss of service
experienced by the organisation which operates the
system.
Where a break in system service cannot be avoided,
the deployment period can be minimised by effective
project planning. Renaissance defines activities in the
Deliver phase, such as acceptance testing and end user
training, which should be completed prior to deployment.
Renaissance does not finish when the transformed
system has been deployed. Phase Deploy and Use aims
to preserve the evolveability that an evolution project has
granted a system. The final phase includes activities to
evaluate the system, with the view of capturing new
requirements to be considered for subsequent evolution
iterations. Any new requirements in addition to changes
in the system's environment should be recorded to help
maintain the system's usefulness within its operational
organisation.
3.3 Information Management
Renaissance defines a structured document repository
for managing information which can be used throughout
a system's evolution. Documents are classified as
Business, System, Evolution Strategy, Project
Management and Test. These documents should not be
discarded after an evolution project, but instead, they
should persist so that developers can use them to make
informed decisions when evolving the system in the
future.
Business documents describe the organisation's
business goals and the business process supported by a
system. System documents include an assessment report
which contains measures of the system's business value
and technical quality. In addition, System documents
include the results of any modelling activities.
Based on the work carried out in the Plan Evolution
phase, the Evolution Strategy documents describe the
possible evolution strategies for a system. Where there is
more than one strategy to consider, these documents
should also describes the relative costs, risks, and
benefits of each strategy and the rationale for choosing a
particular strategy. In this way, these documents record
evolution rationale, which adds value to subsequent
evolution projects involving the system.
Project Management documents record the details of
project planning and deployment planning. Where an
incremental evolution strategy has been developed, these
documents describe the schedule and activities needed to
produce a stream of system increments. Test documents
include the testing strategy used for the project, test data
and the results of testing.
3.4 Responsibilities
Renaissance defines a set of responsibilities which
need to be met in a typical evolution project. Identifying
responsibilities and assigning them to individuals is part
of project planning. Given a particular project, an
individual might meet several responsibilities, and
conversely, several individuals might meet a single
responsibility.
We classify the responsibilities in two groups: those
related to the organisation which operates the system,
and those which are technical. The former group includes
individuals who understand the system's role within their
organisation. Such individuals are often senior personnel
and should be able to answer questions concerning the
system's purpose and functionality. In addition, a range
of system users, including those who physically operate
the system and those who benefit indirectly from its
services, should be identified. Collectively, such
individuals help technical personnel to understand the
behaviour of the system.
Technical responsibilities represent the computing
professionals who will be involved in the evolution
project. One valued technical responsibility, but one
which is not always possible to meet, is legacy system
developer. This responsibility requires engineers who
have developed a good working knowledge of the system
from a technical perspective. Unfortunately, in many
evolution projects, individuals who could meet this
responsibility are no longer available. In this case,
system models have to be built to gain the necessary
understanding of how the system has been implemented
and changed.
4. Evaluation and Discussion
During the Renaissance project, industrial partners
were involved in evaluating the method. Each partner
used applications with different technical, business, and
organisational properties. Based on their findings, the
method was refined.
The process framework was found to be well-defined
and easy to follow with a logical flow of activities which
mapped well onto the concrete steps taken in evolution
projects. The lack of detailed project management
support was viewed positively, since partners used
established procedures of their own. For example,
Renaissance has been integrated with ISO9000-certified
project management processes without difficulty.
Evaluation confirmed that risks can be reduced and
costs distributed when a project is managed
incrementally (requirement R1). Furthermore, in one
case, incremental reengineering was exploited to manage
staff training so that engineers were prepared for using
new technology needed to implement particular
increments. In this way, existing staff can be retained and
Proceedings of the 26 th Annual International Computer Software and Applications Conference (COMPSAC’02)
0730-3157/02 $17.00 © 2002 IEEE
allowed to develop new skills which are needed for a
system's evolution.
The evolution strategy selection process (R2), based
on the predefined evolution strategies, their costs,
benefits, and risks, also proved useful. In practice, hybrid
evolution strategies were used, with different evolution
strategies being applied to different components within a
system.
Throughout evaluation, the ability to customise the
method to account for particular organisational and
project factors (R4) was seen as essential. For example,
some evaluation work used the method to conduct a
feasibility study. In this case, only the Plan Evolution
phase, a subset of documents, and a subset of
responsibilities were necessary to carry out the study.
Used in this way, the method can support an exercise
which aims to prioritise an organisation's applications as
candidates for evolution. Where an organisation has
several applications, it can quickly determine which
systems need to be addressed first [12].
Renaissance allows the inversely proportional
relationship between cost and risk to be exploited. For
example, to gain an approximate measure of a system's
technical quality, the assessment process can be
performed at a high level with little effort. For a measure
which is associated with more confidence, the process
can be performed at a more detailed level. In other cases,
a ball-park figure for evolution costs might be sufficient.
Here, a technique based on expert judgement could be
used rather a more accurate, but more time consuming
technique. Choosing the level at which to perform an
activity helps to reduce the overhead of using
Renaissance.
However, the evaluation revealed that the overhead of
adopting Renaissance for the first few projects is high.
Initially, evolution costs were estimated to be higher
when using Renaissance than if it were not used. Having
gained experience and familiarity with using
Renaissance, evaluators found the overhead of using the
method to drop significantly. It is to be expected that
adopting a new non-trivial method involves a learning
curve. Furthermore, the costs of using Renaissance
should be put in context with its benefits and the
reduction in risk through using it.
In addition to the overhead of learning how to use
Renaissance, another weakness reported was the
overhead imposed for managing small projects. Once
over the learning curve, evaluators found that the method
was better suited to managing medium-to-large projects
than small projects.
Method requirement R3, concerns the need for the
method to preserve the evolveability of a transformed
system for the remainder of its useful life. Whilst it is
difficult to evaluate whether this requirement has been
satisfied in the short term, the Renaissance approach has
been designed to account for it. With Renaissance, a
system's evolution is managed by a stream of evolution
increments. This is analogous to the Kaizen approach to
business process change [13]. Kaizen reduces the risks of
change by managing change as a series of conservative
improvements to the process. However, this approach
requires that the process is in a state where it can be
effectively improved. For software systems, this means
recovering a stable basis using reengineering.
5. References
[1] Lehman, M. M. and Belady, L. Program Evolution:
Processes of Software Change. London: Academic Press.
1985.
[2] Warren, I. (ed.) The Renaissance of Legacy Systems.
Practitioner series, Springer. 2000.
[3] Bennet, K. Legacy Systems: Coping with Success. IEEE
Software, 12(1). 1995.
[4] Tilley, S. Perspectives on Legacy Systems
Reengineering. Reengineering Centre, Software
Engineering Institute (SEI), Carnegie Mellon University,
USA. 1995.
[5] Ulrich, W. M. The Evolutionary Growth of Software
Reengineering and the Decade Ahead. American
Programmer, 3(10). 1990.
[6] Reengineering Technology Report. Software Technology
Support Centre (STSC). 1993.
[7] The Renaissance Method. RENAISSANCE project
deliverable, D4.2. 1998.
[8] Client/Server Migration. RENAISSANCE project
deliverable, D3.1. 1998.
[9] Ransom, J., Sommerville, I., and Warren, I. A Method for
Assessing Legacy Systems for Evolution. Proc. 2
nd
Euromicro Conference on Software Maintenance and
Reengineering (CSMR). 1998.
[10] Architectural Modelling. RENAISSANCE project
deliverable, D3.2. 1998.
[11] Evolution Planning. RENAISSANCE project
deliverable, D3.3. 1998.
[12] Sneed, H. M. Planning the Reengineering of Legacy
systems. IEEE Software 12(1). 1995.
[13] Imai, M. Kaizen: The Key to Japan's Competitive
Success. McGraw-Hill Publishing. 1986.
6. Acknowledgements
This work has been partially funded by the European
commission's ESPRIT initiative (project 22010,
RENAISSANCE). Copies of project deliverables, which
describe this work in more detail and other aspects of the
RENAISSANCE project, may be downloaded from
http://www.comp.lancs.ac.uk/projects/renaissance.
Proceedings of the 26 th Annual International Computer Software and Applications Conference (COMPSAC’02)
0730-3157/02 $17.00 © 2002 IEEE
... Therefore, to achieve the longlasting usefulness of the software, their maintenance should be done by the organization. According to INPRES No. 3 Tahun 2003, the software should be used or developed by the government and their periodical maintenance as well [2]. ...
... Software maintenance is the process of changing a system after it has been delivered to the user [1,3]. Maintenance aims to extend the life of assets, ensure the availability of equipment installed for production or services and get the return value of the investment, ensure the operational readiness of all equipments needed in an emergency, and ensure the safety of people who use the facility [4]. ...
... This assessment was based on two essential aspects i.e., business value and technical value. Assessment of each aspect validated by using metrics mapping that refers to ISO/IEC 9126-4 standard [10] and other relevant literature supports [3,5,6,11,12]. Moreover, Likert's questionnaire, which is intended for stakeholders (managers) and operator officers in the institution, was used to asses the business value of e-Government software assets. ...
... Jika tidak, program tersebut akan menjadi tidak berguna. Pemeliharaan adalah penyesuaian (akomodasi) perubahan suatu perangkat lunak setelah disampaikan atau disebarkan kepada pengguna [5]. Perubahan perangkat lunak dapat berupa perubahan sederhana; seperti perbaikan kesalahan pengkodean dan perubahan yang lebih luas (kompleks); seperti perbaikan kesalahan desain, spesifikasi atau akomodasi kebutuhan baru [4]. ...
... Sistem warisan (legacy system) adalah sistem perangkat lunak lama yang sampai saat ini terus digunakan karena sistem tersebut kritikal bagi organisasi [5]. Menurut De Lucia, dkk., sistem warisan adalah sistem perangkat lunak kritikal yang dibangun pada masa lalu yang telah ada dan telah berubah pada waktu yang lama tanpa tindakan perbaikan yang sistematis [19]. ...
... Nilai Bisnis adalah nilai yang merepresentasikan pentingnya sebuah perangkat lunak bagi organisasi. Sumber informasi yang diperlukan untuk melakukan penilaian nilai bisnis sebuah perangkat lunak dapat diperoleh secara high level (penilaian menurut pendapat ahli) atau pun secara detailed level (penilaian yang dilakukan oleh analis bisnis) [6] atau dengan mempelajari dokumen bisnis organisasi [5]. ...
Article
Agar perangkat lunak e-Government dapat digunakan dalam menunjang kinerja organisasi dalam waktu yang relatif lama maka perlu dilakukan pemeliharaan perangkat lunak. Namun, berdasarkan hasil observasi pada organisasi perangkat daerah di Kabupaten Ketapang diketahui bahwa belum ada sebuah model atau standar yang dapat memberikan rekomendasi pemeliharaan secara objektif dan akurat. Penelitian ini mengusulkan sebuah model penilaian perangkat lunak untuk rekomendasi pemeliharaan dengan mengintegrasikan nilai bisnis dan nilai teknis. Identifikasi aset perangkat lunak, penilaian perangkat lunak, dan rekomendasi pemeliharaan adalah tiga tahap yang diusulkan dalam model ini. Kuesioner dengan skala Likert dan task analysis digunakan untuk menilai perangkat lunak berdasarkan nilai bisnis dan nilai teknis. Hasil validasi model melalui implementasi studi kasus di BKPSDM Ketapang diketahui bahwa model berhasil memberikan rekomendasi pemeliharaan untuk aplikasi SIMPAD adalah ordinary maintenance dan BAPERJAKAT adalah freeze.
... Porém, o sistema é muito valioso e substituí-lo traz novos custos de desenvolvimento e implantação, além do risco da perda de informações críticas dos negócios. Tal perda não é aceitável para as organizações [5,41]. ...
... This study has considered four established methods and models in order to meet the overall quality characteristics, namely the Systems and Software Quality Model (ISO/IEC 25010:2011) [55], Data Quality Model (ISO/IEC 25012:2008) [56], Renaissance Method [57] and the SERVQUAL Model [58]. The characteristics were combined with the specific features of citizen-centric digital that have been discussed in relevant previous studies [44,59,60] The combination of these models and methods has resulted in comprehensive features encompassing product, data, and service elements. ...
Article
Full-text available
Legacy systems are valuable assets in most public sector agencies that have been in use for a long time. These systems support government service delivery to the citizens and maintain vital public administration functions and data. However, legacy systems are often related to technical difficulties that impede innovation efforts. The maintenance of the systems has become challenging and incompatible with the demands of digital transformation in the public sector. Due to their importance, the systems cannot be easily discarded. Rebuilding the old systems from scratch entails a long development timeline, high cost, and the loss of critical service functionalities. These circumstances encourage the public sector agencies to implement the modernisation of legacy systems. However, the modernisation effort for legacy systems in the public sector is not straightforward. Besides technical aspects, it should also consider non-technical aspects, including the requirements of the new era of citizen-centric digital government. In order to achieve this aspiration, a complete strategy must be developed to serve as a guide for government agencies. Hence, the purpose of this study is to develop a comprehensive guideline for the public sector. The research has been developed using a qualitative methodology that incorporates the theoretical and empirical phases. The theoretical phase was conducted through a literature review of previous studies related to the research topic. The empirical phase in the public sector was implemented and analysed using phenomenology and grounded theory methods. A total of 19 informants were involved in the individual and focus group interviews conducted. The study results revealed that human, process, product, and organisation aspects as well as the related characteristics of the citizen-centric influence the legacy systems modernisation in the era of digital government. The findings contribute as a complete guideline for the public sector agencies in modernising the legacy systems in line with the citizen-centric digital government vision.
... The objectives of this review are (i) to reach a broad understanding of existing process models for legacy evolution to SOA (ii) identify available techniques to perform migration activities, and (iii) identify the existing issues and possible directions for future research. Through evaluating 121 primary studies using an evaluation framework, inspired from three traditional reengineering methodologies namely Butterfly (Bisbal et al., 1997), Renaissance (Warren and Ransom, 2002), and Architecture-Driven Modernization (ADM) (Khusidman and Ulrich, 2007), the authors conclude that there is still a lack of adequate automation level and techniques for determining the decomposability of legacy applications, investigating organisational perspective of migration, and postmortem reports on after-migration experience. In another attempt, Lane et. ...
Preprint
Full-text available
Moving mission-oriented enterprise applications to cloud environments is a major IT strategic task and requires a systematic approach. The foci of this paper are to review and examine existing cloud migration approaches from the process models perspective. To this aim, an evaluation framework is proposed and used to analyse and compare existing approaches for highlighting their features, similarities, and key differences. The survey distills the state of the art in cloud migration research and makes a rich inventory of important activities, recommendations, techniques, and concerns that are commonly involved in the migration process in one place. This enables academia and practitioners in the cloud computing community to get an overarching view of the cloud migration process. Furthermore, the survey identifies a number challenges that have not been yet addressed by existing approaches, developing opportunities for further research endeavors.
... This tendency is based on technological analysis and technological forecasting for many engineering systems. In some monographs, system evolution for information and software systems is examined ( [30], [31], etc.). Issues of system evolution for some traditional engineering domains (e.g, transport) have been analyzed in ( [23], [24], etc). ...
Conference Paper
Full-text available
The paper describes five-stage system evolution on the basis of six generations of devices / systems in signal processing. The following is discussed: (a) hierarchical morphological system models that are based on "hierar-chical morphological design "approach to system design; (b) system evolution operations including local operations for system elements / components (e.g., change / improvement of elements, aggregation of elements, standartization of elements) and global operations for the system or its parts (e.g., change of system structure , change / improvement of a system part). The list of some basic problems is the described. An example for signal processing devices is presented. Basic system evolution operations are proposed.
... In such situations, it is necessary to adjust the software so that it will work on a new system. This process is called software migration or, alternatively, software modernization, and the software that needs such a migration is called legacy software; see, e.g., [5], [6], [9], [10], [11]. ...
... The objectives of this review are (i) to reach a broad understanding of existing process models for legacy evolution to SOA (ii) identify available techniques to perform migration activities, and (iii) identify the existing issues and possible directions for future research. Through evaluating 121 primary studies using an evaluation framework, inspired from three traditional reengineering methodologies namely Butterfly ( Bisbal et al., 1997 ), Renaissance ( Warren and Ransom, 2002 ), and Architecture-Driven Modernization (ADM) ( Khusidman and Ulrich, 2007 ), the authors conclude that there is still a lack of adequate automation level and techniques for determining the decomposability of legacy applications, investigating organisational perspective of migration, and postmortem reports on after-migration experience. In another attempt, Lane and Richardson (2011) present a survey of process models to develop service-based applications with a focus on dynamic adaptation. ...
Article
Full-text available
Moving mission-oriented enterprise applications to cloud environments is a major IT strategic task and requires a systematic approach. The foci of this paper are to review and examine existing cloud migration approaches from the process models perspective. To this aim, an evaluation framework is proposed and used to analyse and compare existing approaches for highlighting their features, similarities, and key differences. The survey distills the state of the art in cloud migration research and makes a rich inventory of important activities, recommendations, techniques, and concerns that are commonly involved in the migration process in one place. This enables academia and practitioners in the cloud computing community to get an overarching view of the cloud migration process. Furthermore, the survey identifies a number challenges that have not been yet addressed by existing approaches, developing opportunities for further research endeavours.
Chapter
How can we use the acquired knowledge? In many practical situations, we have a well-defined problem, with a clear well-formulated objective. Such problems are typical in engineering: we want a bridge which can withstand a given load, we want a car with a given fuel efficiency, etc. There exist many techniques for solving such well-defined optimization problems. However, in many practical situations, we only have partial and/or subjective information about the situation and about our objectives. In such situations, we need to make decisions under uncertainty. This aspect of knowledge use is what we analyze in this chapter. The ultimate goal of knowledge use is to help the users. To do this, we need to get a good understanding of the corresponding processes. Gaining such an understanding is the main objective of science, when we use the observed data to find the dependencies between different quantities. Once these dependencies have been discovered, we can apply this knowledge to help the users: we can find out how to better controlthe existing systems, we can find out how to better design the new systems, and we can find out how to better maintain the systems. In all these engineering tasks, we are interested in decision making under uncertainty, in particular, in taking imprecise expert knowledge into account. In this chapter, we provide examples of applications to science and to all three aspects of engineering. Specifically, in Sect. 5.1, we consider an example of an application to science, in Sect. 5.2, we consider an example of an application to control, in Sect. 5.3, we deal with an application to design, and in Sect. 5.4, we consider an application to maintenance.
Article
Full-text available
How can you know if reengineering is cost-effective? If it is preferable to new development? Or to maintaining the status quo? The author proposes a way to quantify the costs and prove the benefits of reengineering over other alternatives and offers some advice on contracting a reengineering project
Article
Full-text available
Legacy systems are usually critical to the business in which they operate, but the costs of running them are often not justifiable. Determining whether such systems are worth keeping requires an overall assessment of the system.
Article
Today, software professionals recognize that change in software systems is inevitable. There are many systems currently in operation, however, which were developed before the need for change was understood. Such systems are commonly referred to as "legacy systems", and were developed with relatively short lifetimes in mind. Software engineering is a relatively young discipline which is continually improving to provide better support for the development of software systems. What were once state-of-the-art techniques, tools, and processes are now dated, and have resulted in systems which are not responsive to change. For historical reasons, dated development practice traded maintainability for other system attributes, such as cost and performance. A significant number of legacy systems remain in operation because they are critical to the business processes which they support. The combination of extended lifetimes and poor maintainability means that legacy systems are expensive to change, and in many cases they cannot accommodate emerging requirements. This is clearly an undesirable situation, which, until recently, has been tackled by replacing the system or attempting to maintain it. Replacing a legacy system is dangerous, since you face the risk of losing vital business knowledge which is embedded in many old systems. In many cases, system replacement is not cost-effective. Conversely, if you attempt to maintain a legacy system, there is often little return on the investment in maintenance effort and the system remains difficult and expensive to change.
Conference Paper
Legacy systems are usually critical to the business in which they operate, but the costs of running them are often not justifiable. Determining whether such systems are worth keeping requires an overall assessment of the system. We present an assessment method that examines a legacy system from its technical, business and organisational perspectives. The method guides users through assessment of these perspectives by selecting assessment characteristics and assigning values to them. The method provides further guidance on interpreting the results obtained from assessment. Our assessment method can be tailored to the needs of particular evolution projects and organisations. It is not prescriptive of particular tools and techniques, and can be instantiated to offer a cost/risk trade-off. Quick estimates can be derived from performing the method at a high level. The risk of producing an inaccurate assessment can be reduced by further iterations of the method performed at more detailed levels
Article
Legacy systems may be defined informally as “large software systems that we don't know how to cope with but that are vital to our organization”. Legacy software was written years ago using outdated techniques, yet it continues to do useful work. Migrating and updating this baggage from our past has technical and nontechnical challenges, ranging from justifying the expense in dealing with outside contractors to using program understanding and visualization techniques
The Renaissance of Legacy Systems. Practitioner series
  • I Warren
Warren, I. (ed.) The Renaissance of Legacy Systems. Practitioner series, Springer. 2000.
  • S Tilley
Tilley, S. Perspectives on Legacy Systems Reengineering. Reengineering Centre, Software Engineering Institute (SEI), Carnegie Mellon University, USA. 1995.