Legacy Systems

1. Legacy Systems • Older software systems that remain vital to an organisation

2. Legacy systems • Software systems that are developed specially for an organisation have a long lifetime • Many software systems that are still in use were developed many years ago using technologies that are now obsolete • These systems are still business critical that is, they are essential for the normal functioning of the business • They have been given the name legacy systems

3. Legacy system change • Systems must change in order to remain useful • However, changing legacy systems is often expensive • Different parts implemented by different teams so no consistent programming style • The system may use an obsolete programming language • The system documentation is often out-of-date • The system structure may be corrupted by many years of maintenance • File structures used may be incompatible

4. The legacy dilemma • It is expensive and risky to replace the legacy system • It is expensive to maintain the legacy system • Businesses must weigh up the costs and risks and may choose to extend the system lifetime using techniques such as re-engineering.

5. Legacy system structures • Legacy systems can be considered to be socio-technical systems and not simply software systems

6. Layered model

7. System change • In principle, it should be possible to replace a layer in the system leaving the other layers unchanged • In practice, this is usually impossible • Changing one layer introduces new facilities and higher level layers must then change to make use of these • Changing the software may slow it down so hardware changes are then required • It is often impossible to maintain hardware interfaces because of the wide gap between mainframes and client-server systems

8. Layered model

9. Legacy system assessment • Organisations that rely on legacy systems must choose a strategy for evolving these systems • Scrap the system completely and modify business processes so that it is no longer required • Continue maintaining the system • Transform the system by re-engineering to improve its maintainability • Replace the system with a new system • The strategy chosen should depend on the system quality and its business value

10. Legacy system categories • Low quality, low business value • These systems should be scrapped • Low-quality, high-business value • These make an important business contribution but are expensive to maintain. Should be re-engineered • High-quality, low-business value • Replace with COTS • High-quality, high business value • Continue in operation using normal system maintenance

11. Maintenance • Re-Engineering • Reverse Engineering

12. Maintenance Software System re-engineering • Reorganising and modifying existing software systems to make them more maintainable

13. System re-engineering • Re-structuring or re-writing part or all of a legacy system without changing its functionality • Applicable where some but not all sub-systems of a larger system require frequent maintenance • Re-engineering involves adding effort to make them easier to maintain. The system may be re-structured and re-documented

14. When to re-engineer • When system changes are mostly confined to part of the system then re-engineer that part • When hardware or software support becomes obsolete • When tools to support re-structuring are available

15. Re-engineering advantages • Reduced risk • There is a high risk in new software development. There may be development problems, staffing problems and specification problems • Reduced cost • The cost of re-engineering is often significantly less than the costs of developing new software

16. Forward engineering and re-engineering

17. The re-engineering process

18. Reverse engineering • Analysing software with a view to understanding its design and specification • May be part of a re-engineering process but may also be used to re-specify a system for re-implementation • Builds a program data base and generates information from this • Program understanding tools (browsers, cross-reference generators, etc.) may be used in this process

19. The reverse engineering process

20. Reverse engineering • Reverse engineering often precedes re-engineering but is sometimes worthwhile in its own right • The design and specification of a system may be reverse engineered so that they can be an input to the requirements specification process for the system’s replacement • The design and specification may be reverse engineered to support program maintenance

21. Program structure improvement • Maintenance tends to corrupt the structure of a program. It becomes harder and harder to understand • The program may be automatically restructured to remove unconditional branches • Conditions may be simplified to make them more readable

22. Condition simplification -- Complex condition if not (A > B and (C < D or not ( E > F) ) )... -- Simplified condition if (A <= B or (C>= D and E > F)...

23. Restructuring problems • Problems with re-structuring are: • Loss of comments • Loss of documentation • Heavy computational demands