System Re-engineering

Module code: CO7206

Software engineers are often hired to maintain and evolve existing systems, rather than develop new ones. If a new system is to be developed, it usually has to be integrated with other existing 'legacy' software: valuable software systems that are still in use but are difficult to maintain, change or migrate because they were developed with technologies of the past and/or because they were not engineered properly. Very often, these systems were developed without proper documentation, version control, or proper design. They may have undergone numerous changes by different people that violate the original system design, if any ever existed. As a result, it is challenging to understand, modify or migrate these systems.

Fresh software developers are usually neither equipped with the necessary skills nor have the desire to work with legacy software. Fresh software development is usually considered superior to software maintenance and re-engineering. The year 2000 problem ('Millennium Bug') and the deployment of the Euro to replace national currencies gave rise to research and practice of software system reverse engineering and re-engineering. Re-engineering is "the examination of a subject system to reconstitute it in a new form and the subsequent implementation of the new form." [Chikofsky, and Cross II, 1990]. Part of any re-engineering effort is a reverse engineering process, which is "the process of analysing a subject system with two goals in mind: (1) to identify the system's components and their interrelationships; and, (2) to create representations of the system in another form or at a higher level of abstraction." [Chikofsky, and Cross II, 1990].

In this module you will study the main issues related to software systems ageing and evolution. We will examine some of the available methods and technologies for software reverse engineering and re-engineering as well as some of the managerial and planning issues specific to software re-engineering projects.