1 / 23

Legacy Systems

Legacy Systems. Older software systems that remain vital to an organisation. 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

shannaw
Download Presentation

Legacy Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related