D4.2a Method

Executive summary

The RENAISSANCE method aims at supporting the reengineering of legacy software systems, that is the transformation of valuable software assets which are difficult to maintain toward new systems which are able to evolve both in the short and long term. This report defines such a method.

The report first defines the objectives of RENAISSANCE, and the constraints and benefits of applying this technology. Then it introduces a simple notation for representing the method itself, gives an overview of the method and hints for introducing the technology within an organization and adopting it; and then details both the activities and the control flow among activities in order to provide the user with operative procedures for reengineering systems.

There are two basic ideas behind the RENAISSANCE method:

• reengineering must be company and project specific;
• both the reengineering process and the reengineered system must be continuously refined.

These are implemented as follows. RENAISSANCE identifies generic activities, which can be specialised and decomposed to address specific needs of the user of the method, coming both from company and project constraints and practices. Activities are identified through their interface, which is defined in terms of Pre, Enabling and Post Conditions. Concerning the implementation of an activity, RENAISSANCE simply describes the actions to be performed, without forcing any implementation approach. Concerning the execution, both the overall control flow and the activation of a single activity can be customized. The cooperation of the activities and the incremental approach to refine the system under reengineering are achieved through a repository containing all the artefacts needed by the process, that is both produced and consumed by activities.

The method is structured on two main phases. The first one, or what to do, assesses the organization and the legacy system and identifies both the need and urgency of reengineering and the best candidate strategy to adopt for renewing the system: continue with the current maintenance approach; re-engineer the system from user-interface, structure, architecture, and design point of views; replace the existing system with a new developed one. The second phase, or how to do, supports the implementation of the planned transformation.

Since the RENAISSANCE method is an instance of the RENAISSANCE framework, as defined in the corresponding report, the last chapter of this report defines the traceability from that framework to this method. Reading this chapter is optional, and readers who are not interested in pointing out such a traceability can skip it, with no impact at all on the understanding and mastering of the RENAISSANCE method.