Project Objectives

The principle business objectives of the industrial partners in the RENAISSANCE project are to improve their capability to offer profitable services in the area of systems evolution and to increase their return on investment in their software assets. We believe that these business objectives can be met by developing a more methodological approach to evolution and re-engineering which is consistent with current development and maintenance practises used in industry.

The main objective of the RENAISSANCE project is therefore:

To develop a systematic method for system evolution and re-engineering which is geared to the requirements of the commercial systems domain.

The RENAISSANCE method will take into account technology changes in this domain which have led to customer pressure to migrate applications from centralised mainframes to object-based, distributed client-server systems. It will include support for the specific requirements of 3GL and 4GL system evolution. The key sub-objectives of the project are therefore:

• To provide techniques for modelling the principle structures of 3GL and 4GL business applications, and to give advice on the use of architectural modelling as a basis for system understanding, re-engineering and distribution of these systems.
  
• To provide techniques and technologies for converting centralised legacy systems and associated data to distributed client-server system architectures.
  
• To provide advice to managers responsible for planning the evolution process on evolution strategies, organisational factors which must be taken into account in the planning process (e.g process changes, training, etc.) and the risks and economics of applying these strategies in the evolution process.

The RENAISSANCE method will incorporate the results derived from these sub-objectives as well as the normal method components, i.e. process guidance, suggested documentation, rules and recommendations and report structures.

We will consider the problems of evolution of systems written in conventional programming languages such as COBOL (currently the market priority due to the number and size of the systems involved) and in 4GLs (a rapidly emerging market need) which rely on large databases. We will ensure that the RENAISSANCE method provides full coverage for the domain by evaluating the results of the project using several different types of business systems application.

Project Results

The principle result of the project will be a RENAISSANCE method handbook which describes a generic method for software evolution with variants which reflect the specific requirements of 3GL and 4GL evolution. The method handbook will be widely disseminated by ensuring that it is published by a commercial publisher. The handbook will include information about evolution processes, system models and documentation for evolution, and rules and guidance for applying the method. It will also integrate the results of the project which are embodied as consultancy reports described below.

This handbook will be supported by a set of more detailed RENAISSANCE consultancy reports and associated training materials which may be used to develop internal and external consultancy services in the areas of system maintenance and evolution.

The RENAISSANCE reports will be important documents which will give partners a market advantage when selling consultancy in the areas covered by the reports. The reports will be written at a level of detail so that they may be used by professional consultants providing services and advice to clients with evolution and re-engineering problems. The consultancy reports are exploitable project results in their own right and we expect that they will be exploited by partners outside of the RENAISSANCE method.

Titles and summaries of the reports are:

• System modelling for evolution. This report will be concerned with methods, techniques and tools for modelling the architecture of legacy systems, written in both 3GLs and 4Gls, in preparation for evolution. Architectural modelling is important as many legacy systems are relatively unstructured either because of the development approach used or because the devlopment language (e.g. a 4GL) does not include application structuring constructs. As well as general advice on modelling, the report will identify major entities and relationships in 4GLs and show how these can be modelled using existing methods and tools.
  Executive summary
  
• Migrating to distributed client-server systems. This will provide an overview of client server models and provide advice and guidelines on transforming centralised architectures to distributed architectures. It will also include a discussion of object brokers and how these may be used to integrate reusable components with existing systems and commercial software packages.
  Executive summary
  
• Evolution planning. This will discuss evolution strategies such as re-engineering where a system is analysed and restructured, refurbishment where sub-systems are selectively replaced, and recycling where sub-systems are salvaged from a system and packaged for use in a re-engineered system. It will provide advice on how to assess the risks of each of these strategies in a particular context and suggest how an economic assessment of each strategy might be carried out. It will also consider other non-functional considerations which must be taken into account in the evolution planning process such as the need for training of end-users when a system is re-engineered, the effect of re-engineering on other applications, the influence of hardware changes, etc.
  Executive summary

These reports will be supplemented by a standard training delivery kit which will include a set of instructor's notes, master versions of overheard projector transparencies and material for distribution to students. This training delivery kit will consist of high quality training material (transparencies, instructor's notes, trainee's notes) for delivery to external customers. This will support training courses to be provided by the universities and industrial partners involved in the project.

We do not propose to develop new CASE tool support for the RENAISSANCE evolution method or supporting consultancy reports. Rather, we will investigate how the method may be used with existing CASE tools which are in use by our application partners and which are currently available. To assist with this, we propose to support a tool vendors forum for selected vendors of forward and reverse engineering toolsets. Members will be given advance information about the method which they may take into account in developing new versions of their tools and will be able to see how their existing tools may be used for RENAISSANCE method support.

This approach to presenting the project results is the most effective for ensuring their dissemination both within the companies in the RENAISSANCE project and outside the consortium:

• The method handbook will be a public, widely disseminated deliverable which will be made generally available at very low cost (say 50ECUs as the normal price of a book). Any organisation will be able to adopt the advice presented here. Experience of method providers (e.g. Yourdon, Jackson, Rumbaugh) has been that making the method public is the most effective way to ensure acceptance and use of the method. It generates interest in the approach and consultancy business as companies explore the applicability of the method in their organisation and its introduction into their software process.
  
• The consultancy reports will provide more detailed information to supplement the method handbook which will be available to the RENAISSANCE partners to develop their own consultancy businesses and which will be sold, at the appropriate market price, to other companies who wish more detailed information on the RENAISSANCE method. Note that 47% of the projects in which CGInn are involved are carried out with other parts of the CAP Gemini Group and that INTECS, Engineering and debis all plan to expand their consultancy businesses in the area of software re-engineering. The report on evolution planning will be used for management consultancy and in the negotiation phase of projects; the reports of architectural modelling and client-server migration will be used for technical consultancy.
  
• The results of the project will be directly applicable by the application partners as a means of improving their own evolution and re-engineering processes leading to better quality software which can be produced more quickly and at a lower price. CSH, debis and Engineering are important applications management companies so the impact of this process improvement is not simply within the application partners. Their external customers will benefit through improved software quality and faster response to change requests generated by new system requirements. Telesoft's customers for telecommunications management systems will benefit in a similar way.
  
• Our goal of providing method support through commercially available tools means that we do not have the risks of new tool development and marketing and that we do not tie ourselves to a specific tool provider. This ensures that the market for the method is not restricted to companies which have invested in a specific tool or development method.

Assessment of Results

This project will be driven by the real evolution problems faced by partners. Representative applications will be used to test the project results against application requirements. Application partners will apply the technical results to real problems in parallel with normal developement and will thus access their strengths, weaknesses and commercial viability.

This evaluation will be carefully planned during the first year of the project and will be based on the identification of specific problems by the application partners. During that planning, application partners will use their normal management processes to estimate the cost, resources and calendar time required to complete the planned work without the use of the RENAISSANCE results. We will also measure the actual costs, resources and time required during the evaluation and will compare these with this baseline.

An important success criteria for the RENAISSANCE method is its contribution to process improvement in the application partners. Although partners have well-defined development processes, their evolution processes are more informal. The RENAISSANCE method will contribute to the definition of a more structured process (in SEI terms, the process will increase its maturity level) and hence should lead to repeatable evolution processes.

Any method must exhibit certain attributes if it is to be commercially successful. These attributes and the ways in which we plan to assess them are as follows:

• Generality. Can the method be used for a range of different types of system with different implementation technologies? We will assess this by applying the method to example applications written in different programming languages, including 4GLs.
  
• Usability. Can the method be learned and applied without undue expense? We will provide the application partners with initial training and they will apply the method to their own problems. We will gather feedback on their experiences with the method.
  
• Scalability. Can the method be applied successfully to different sizes of system? The method will be applied to applications ranging from several thousand to over a million lines of code.
  
• Adaptability. Can the method be adapted depending on individual circumstances, processes and standards. Again, we will be able to make some assessment of this because of the range of different trial applications which are part of the project.
  
• Supportability. Can the method be supported by using a range of different CASE tools, re-engineering tools, etc. The application partners use different toolsets in their work and will assess whether adaptions to use the specific features of these toolsets are possible.

Success Criteria

The following list sets out success criteria for project results which may be judged within the lifetime of the project. However, as the benefits of the method accrue after it has been applied in increasing the quality of re-engineered systems and reducing subsequent maintenance costs, we must base our assessments on estimates of these attributes rather than measurements which may be made.

RENAISSANCE method handbook (plus associated consortium-specific information):

• Must provide specific advice on -
• Evolution and re-engineering processes.
• Documentation for re-engineering.
• Rules and guidelines for re-engineering.
• Integration with 3GL and 4GL implementation technologies and commercial tools to support re-engineering and evolution processes.
• Method adaption to local circumstances, implementation technologies and application domains.
• Must provide a basis for application developers to improve their current evolution and re-engineering processes and allow for a gradual transition from these processes.
• Must integrate the advice provided in the detailed consultancy reports and must be consistent with that advice.
• Project managers and engineers must agree that the quality of systems re-engineered with the method should result in significantly lower maintenance costs.
• Must be usable by consultants working with clients in this area.
• Based on data from previous projects and formal planning estimates for the applications, the advice provided should significantly reduce (i.e. by at least 25%) the costs of re-engineering legacy systems.

RENAISSANCE report "Migrating to distributed client-server systems":

• Must provide specific advice on -
• Client-server system models.
• Practical applicability of frameworks including CORBA and OLE.
• Conversion of systems using TP monitors to use these frameworks.
• Sub-system encapsulation for distribution.
• Implementation issues for systems written in 3GLs and 4GLs.
• Use of GUI builders for UI re-engineering.
• Data migration to server systems.
• The advice in the report must be understandable and applicable by software engineers who have a general understanding of the principles of client-server systems but no detailed knowledge of these systems
• Must be usable by consultants working with clients in this area
• Based on data from previous projects and formal planning estimates for the applications, the advice provided should significantly reduce (i.e. by at least 25%) the costs of conversion from centralised to distributed forms.

RENAISSANCE report "System modelling for evolution":

• Must provide specific advice on -
• Architectural styles and their applicability.
• Identifying the architecture of legacy systems written in 3GLs and 4GLs.
• The documentation required to define system architectures.
• Defining architectural models using CASE toolsets.
• 4GL system architectures, variations between 4GLs (e.g. UNIFACE, SQL Windows, etc.)
• Must support the modelling of client-server architectures.
• Must take into account likely future use of O-O methods and be consistent with commercial developments (e.g. Unified method) in this area.
• Must be usable by consultants working with clients in this area.
• Project managers/engineers involved in re-engineering and maintenance projects must agree that architectural modelling for re-engineering and for future system maintenance is an improvement over techniques which are currently used.
• Must be able to capture all architectural views required by application partners.