A background in Software Engineering is recommended, even if not mandatory.

Keywords: application management, software maintenance, software evolution, legacy systems and legacy dilemma, business process reengineering, software reengineering,

These numbers emphasise the need for improved maintenance efficiency and reliability, since software systems, and their maintenance, have several inherent problems, which can be summarized as follows:

This leads to legacy systems that lack the ability to evolve to meet ever changing demands in a cost-effective manner.

Moreover, many legacy systems are performing a crucial work for their organization, and usually they represent years of accumulated experience and knowledge. Hence the decision on how to manage them is crucial. Sometimes it could be more convenient to replace the legacy software with a new developed one; sometimes it could be more convenient to restructure it, and sometimes it could be even better to do nothing at all. The decision depends on a mixture of factors, both technical and economic.

The term reengineering is quite broad, and covers a wide variety of techniques. While more details on reengineering and specific techniques can be found in the RENAISSANCE Technical Reports, in the following we cite the [STSC 95] taxonomy of reengineering strategies (with the obviously meaning), just to give an idea of the spectrum of technologies involved in a reengineering project:

Some of these specific techniques will be fully supported by the RENAISSANCE method, while for others references to main knowledge sources will be provided.

Main benefits from reengineering can be summarized as follows:

Even if the above discussion provides only an overview on reengineering, it is quite evident that reengineering seems to be a valuable, promising approach for revamping (in the broader sense) existing legacy systems. But this is not enough. Once we have recovered the current situation, we need to look ahead, and we must avoid that both newly developed systems and forward-engineering of reengineered systems become tomorrow’s legacy systems.

Owing to the fact that legacy software is basically the result of management inaction rather than a technical deficiency [LEHM 80], we must learn to regard software evolution as an integral part of the development process, not an adjunt. And reengineering must become a continuing part of the process of software development and evolution.

The RENAISSANCE approach we are going to present in the next chapter provides a solution to this more general problem of both migrating existing legacy systems toward evolvable systems, and to build new evolutionary systems.

The future of the candidate system depends on the answers to these critical what to do question. A formal assessment of an existing application to determine whether to maintain, reengineer (with which strategy), or retire that system is necessary. The RENAISSANCE What To Do phase will address these questions, while the How To Do phase will provide guidelines for implementing the planned transformation.

The need for software evolution is most evident in systems built and maintained in the context of continuously evolving requirements, rapid changes in technology, and an incremental process of understanding real needs.

[TILL 95] recognizes four critical needs for evolutionary systems:

While we can suppose that new projects will be started with these needs in mind, for legacy systems there is still a need for evolutionary principles to be applied. There needs to be evolutionary technology applied to existing systems so that they will be nearly as easy to maintain as newly developed systems. But this will not be accomplished without some reengineering.: there will be need to refresh, rewrite, redesign, rearchitect, and redocument existing legacy systems. And quite often, in order to achieve real benefits, it is not sufficient to perform the technical reengineering of a legacy application, but the complete business systems, whose logic is often embedded in the legacy application itself, must be rethought and reengineered. This Business Process Reengineering perspective is detailed in the next section.

Software reengineering, and, more generally, business process reengineering, is a drastic and dangerous step, but it could be the only way to cut down the amount of money and resources that some companies blatantly waist for no apparent reason other than by way of their inefficient structure or used technology.

Apart technology, looking at case studies, and both success and failure stories, [STSC 93] recognizes as mandatory to consider the so-called human factor, that is:

The first step for evolving processes is to assess the existing process. Metrics, like SEI-CMM (Capability Maturity Model by Software Engineering Institute) should be used for this assessment, whose result can be used to drive the following improvement.

RENAISSANCE borrows from BPR the need to rethink (or reengineer) the entire business process, when it is a legacy one, but it concentrates only on reengineering information systems. This means that providing support to BPR is clearly out of scope of RENAISSANCE. Nevertheless the method could be used within a more general BPR framework, in order to achieve the above described results: capturing design information and embedded business rules, which are the basis for a success BPR-story. This is the rational for having presented here a quick overview on business process reengineering.

The principal business objectives of the industrial partners in the RENAISSANCE project are to improve their capability to offer profitable services in the area of system evolution and to increase their return on investment in their software assets. These business objectives will be met by developing a more methodical approach to evolution and re-engineering which is consistent with current development and maintenance practices used in industry.

A list of expected benefits is reported in the following:

It must be noted that the motivations that drive RENAISSANCE method adoption fall in two category:

A volatile user environment generates new user requirements. These requirements are translated into maintenance requests which call for modifications or enhancements to the existing system. Hence, the higher the volatility of the user environment, the higher is the maintenance effort and cost; and, as the software system is being modified and enhanced over a long period of time, its maintainability degrades: with frequent interventions, the number of inputs and outputs, the number of functions, and inter-module interactions within the software increase, leading to higher complexity. In addition, these changes are often neither well-integrated into the existing software design, nor well documented. The obvious result is a drastic deterioration of system structure and quality, which leads to increased effort for each maintenance request as the software system ages. The increase in the effort per request exacerbates the total cost of maintenance, and forces companies to shift their focus from software development to software maintenance tasks. Evolving a system to meet changing user needs is reflected by a need to change software during long lifetimes.

The lesson learnt from decades of maintenance is that systems evolve both during and after development, but the requirement for the evolution is hardly ever addressed at the start. This has led to a new perspective, which is becoming broadly accepted: the evolutionary perspective on software development. That is: it makes sense to design software for change in the first place, in order to reverse the current trend in large, complex systems.

The evolutionary perspective recognizes that:

The concept of evolutionary systems represents a break with the old "develop and maintain" model of software production in favour of a new lifecycle model that features continuos evolution. This changed lifecycle approach is quickly becoming an imperative for software organizations, especially when the targets are systems to be built and maintained in contexts of continuously evolving requirements and rapid changes in technologies.

Evolutionary systems are defined as systems that are capable of accommodating changes over an extended operational life. The technology that supports evolutionary systems must enable

There are at least four main differences between maintained and evolutionary systems. The objectives of evolutionary systems can be summarized as follows:

Summarising, the new paradigm for evolution demands for:

The need of evolvability over the long term must be addressed from the very start of new systems development. With evolution as primary objective, the greatest emphasis must be put on engineering for change, which addresses

The main obstacle in adopting this paradigm is represented by the large base of existing legacy systems, most of them currently performing crucial tasks. These systems have been developed and evolved over the past quarter century with a variety of languages, operating systems, hardware, development methods, tools, and idiosyncrasies; and documentation is often poor or even unexistant. However, because of the existing investment in these applications, the critical roles they perform, and the expense of (re)developing them from scratch, it is necessary to protect the existing asset. This means that it is unfeasible to replace these legacy systems with redeveloped ones, built on top of the evolutionary paradigm; it is necessary to turn legacy, maintained systems into evolutionary ones. There needs to be evolutionary technologies applied to existing legacy systems so that they will be nearly as easy to maintain as newly developed systems. This will not be accomplished without some reengineering. There will be need to refresh, rewrite, redesign, and redocument. However, over the long term, these costs can be more than justified by the savings achieved in maintaining otherwise-unmaintainable systems. Which refreshing strategy the system needs is the main problem we have to face out. The RENAISSANCE method focuses on this problem, and it gives guidelines to ensure evolvability.

Building and evolving large software systems involves very large upfront investments in time and effort for learning and relearning requirements from scratch and for validating results. Concerning the software engineering domain, much of this investment is precluded by the use of architectural and product models as well as tested and compatible components. The three enabling keys to implement the evolutionary concept within the software domain are:

Changing the paradigm from maintenance to evolution is not an easy task, and it is necessary both understanding and transforming the legacy asset.

The remaining sections detail the RENAISSANCE framework, and provide

The simple solution adopted by RENAISSANCE consists in balancing the BPR and Kaizen approaches, in the same way software engineering principles suggest to balance top-down and bottom-up approaches during software systems development.

RENAISSANCE proposes the following definition as a paradigm for the evolution of software systems:

Reengineering, by itself, is not the total solution to the problem of evolving legacy software systems, but it is a bridge to such a solution, if it prepares the system to evolve in the long term (i.e. by building or transforming the architecture). The RENAISSANCE method provides support to this paradigm.

RENAISSANCE defines three intuitive views and three intuitive role categories, as depicted in figure c.

The three views are:

The three general categories proposed by RENAISSANCE to group roles are described in the following, while (specific) roles belonging to the identified categories will be detailed in the method definition, because they are not relevant for the framework:

Role categories, whose objectives and main activities can be summarized as in table b, are used to provide a structured view on a system; details can be found in [AMES 94].

Based on the previous structure, the RENAISSANCE reengineering process framework is shown in figure d and detailed in the reminder of this section.

The framework encompasses the following phases, which are detailed in the remaining sections:

A trade-off analysis is the starting point for each reengineering effort. Current system, open technical issues, technical market trend and business goals must be deeply investigated in order to realize what is called "pre-planned product improvement" by [TILL 95], that is to design the software for future changes.

The aim of this activity is to analyse possible changes, especially technologies trade-offs, which could be even largely independent from the quality of the system itself; i.e., the demand for client/server paradigm could be mandatory even if the current system is a reliable, well-documented and structured huge centralised executable.

The scope and direction of the reengineering effort are established in this phase, through analysis of the legacy software, which is assessed with long-term target in mind.

This phase primarily aims at assessing the current status of the application (i.e. in terms of technical and environmental issues, as well as business issues) in order to decide if it needs to be reengineered. The current status is combined with the result of the trade-off analysis to choose the right long-term strategy. The final result is a scenario of possible directions for conducting the reengineering activity.

This is a crucial phase, and it represents the concentration point for the flow of information coming from the other activities. The best reengineering strategy and the plan must be decided on the basis of the variety of information produced by previous phases.

On the basis of the accepted reengineering plan, a solution must be designed with the evolution concept in mind. Possibly, the solution should solve the family of problems pointed out by the analysis, and the use of state-of-the-art solution patterns should be strongly encouraged. The new solution in then implemented.

The new implemented system is validated and, if accepted, deployed.

Everything must be continuously refined. This means that:

It has to be noted that the integration among activities needs a repository (we call it System Repository), which contains all the information concerning the system under reengineering, ranging from assessment results to candidate strategies report, software manufacts, and so on. The System Repository supports the cooperation among activities for a subject legacy system; it allows incremental building, and exchange of information among roles involved in the activities.

The arrow from Solution Deployment to Trade Off Analysis models both the incremental approach adopted by RENAISSANCE in reengineering systems (subsystems identification, reengineering and integration, as it will be detailed in the method) and the new process in case of change of the renewed system. In both the cases, the process takes advantage of the existing System Repository for that system, in order to reduce the effort.

The above introduced phases, which constitute a process framework for reengineering, are described below in terms of the generic activities that are necessary to fulfil their intended function and of the roles of agents which have to perform the activities. The RENAISSANCE method, as defined in the corresponding report, is an instance of this framework both in terms of activities and roles per task.

There is an emphasis put by the six-phases framework on the initial evolution decision assessment, and on the concept of continuos improvement derived by the Kaizen approach. Half of the process is on the decision of "what to do" with the current system; the second half of the process implements the adopted strategy and answers the "how to do" question; the Kaizen phase models the continuos thinking of the process (and the target system) with the aim of refining it (figure f).

RENAISSANCE puts a strong emphasis on the evolution decision process (the what to do process) . This emphasis will also be reflected by the structure of the RENAISSANCE method. There will be two distinct phases: the first one will define the method for assessing an application and taking the most appropriate evolution approach, and the second one will define the method for implementing such an approach.

Next section defines which evolution approaches are supported by RENAISSANCE, and the reminder details the activities of the framework.

The Issue Assessment phase, detailed in figure h, involves internal understanding of the software system, that is white box analysis.

The initial activity of this phase is to establish both scope and direction of the reengineering effort. Inputs to this phases are:

The output is the result of the assessment of the legacy asset with indications on candidate (or possible applicable) reengineering strategies to adopt. The different indications on the nature of the intervention to be performed are passed to the following phases. As shown in the figure above, Issue Assessment includes the following main activities:

Role categories involved are: Operational, Service.

The Decision Analysis phase follows the Issue Assessment, and it is detailed in figure i. A robust decision-making process is needed to account for all the issues that can influence and affect reengineering. As integral part of the decision process, a cost/benefit/risk analysis must be performed, and a decision on the nature of the intervention must be taken. The output of this phase is a decision on the reengineering approach to be used, and a plan for the intervention. The best approach is selected among the Alternative Strategies in input.

In other words, the combined effect of Trade-Off Analysis and Issue Assessment (which could be grouped within a common activity, like Investigate) and Decision Analysis is to provide a systematic means for

Role categories involved are: Strategic, Operational.

The Solution Implementation phase (figure j) constitutes the core element of the reengineering effort, and models the system transition phase.

This phase of the framework is expanded as follows:

Role categories involved are: Operational, Service.

The Solution Deployment phase of the reengineering process framework models the deployment of the reengineered system to the new operational environment at the user site. It is detailed in figure k.

Once a solution has been validated and accepted, it must be deployed to its operational environment. This means that:

Role categories involved are: Service.

The final phase of the reengineering process framework is the continuous, or Kaizen, improvement of the process itself (figure l). This puts a link from the end of the current project and the next project’s beginning, and models the way in which reengineering is seen as an enabling technology for building evolutionary applications.

This means two things:

From this point of view, this phase must not be just the last phase of the overall process: improvement must be seen as a pervasive activity, which continuously rethink of the current activity with the aim of improving it and the overall process. This is the reason it appears in the middle of the global framework picture, with links to every phases of the process.

As shown in the figure, the Kaizen Improvement can be modelled with the following sequence of intuitive activities:

Role categories involved are: Strategic, Operational, Service.