Short note: software reengineering

Software reengineering is the process of restructuring or rewriting part or all of a legacy (old) system to make it easier to understand and maintain, without changing its functionality. It is cheaper and less risky than developing a completely new system, because the existing system's tested business logic is kept.

When it is used: a system is still valuable to the business, but its code is poorly structured, badly documented, or uses outdated languages and databases, so maintenance has become costly.

Software reengineering process model (Pressman) is a cycle of six activities:

1. Inventory analysis: list all applications with size, age, business importance and maintainability, and choose candidates for reengineering.
2. Document restructuring: create or update missing and outdated documentation.
3. Reverse engineering: analyse the code to recover design and specification information at a higher level of abstraction.
4. Code restructuring: rewrite poorly structured code (for example "spaghetti" code) using structured constructs, while keeping the same behaviour.
5. Data restructuring: analyse and redesign data structures and databases, for example moving from flat files to a relational database.
6. Forward engineering: use the recovered design to rebuild the system with modern methods and improved quality.

     Inventory analysis --> Document restructuring
            ^                         |
            |                         v
  Forward engineering          Reverse engineering
            ^                         |
            |                         v
  Data restructuring  <--   Code restructuring

Sommerville lists similar activities: source code translation, reverse engineering, program structure improvement, program modularization and data reengineering.

Advantages: reduced risk, lower cost than redevelopment, and better maintainability. Limitations: there are limits to how much a system can be improved, and changing the architecture (for example to object-oriented design) is very costly.

Example: a bank's old COBOL system using flat files is translated, restructured and moved to a relational database, while the business rules stay the same.