RENAISSANCE Objectives & Results

Objectives

Results

Assessment of Results

Success Criteria

Introduction

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.

The RENAISSANCE Method Handbook

  • 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.

Go to this document in the RENAISSANCE Method document section

The "Migrating to distributed client-server systems" report

  • 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.

Go to this document in the Method Foundations document section

The "Architectural modelling for evolution" report

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

Go to this document in the Method Foundations document section

Objectives

Results

Assessment of Results

Success Criteria