Hello friends today my topic is on LEGACY SYSTEM In Software Engineering.

1. Legacy Systems

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

3. 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 out-dated
• 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

4. 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 out-dated 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

5. The legacy problem
• 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.

6. Legacy system structures
• Legacy systems can be considered to be socio-technical
systems and not simply software systems
• Sociotechnical systems (STS) in organizational
development is an approach to complex organizational
work design that recognizes the interaction between
people and technology in workplaces.

7. Layered model
Socio-technical system
Hardware
Support software
Application software
Business processes

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

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
• It is 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
Understanding and
transformation
Existing
software system
Re-engineered
system
Design and
implementation
System
specification
New
system
Software re-engineering
Forward engineering

17. Reengineering Process

18. Reengineering Process
• 1.Source code translation The program is converted
from an old programming language to a more
modern version of the same language or to a
different language.
• 2. Reverse engineering The program is analysed and
information extracted from it which helps to
document its organisation and functionality.
• 3. Program structure improvement The control
structure of the program is analysed and modified to
make it easier to read and understand.

19. Reengineering Process
• 4. Program modularisation Related parts of the program
are grouped together and, where appropriate, redundancy
is removed. In some cases, this stage may involve
architectural transformation
• 5. Data re-engineering The data processed by the program
is changed to reflect program changes.

20. 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 may be used in this process

21. The reverse engineering
process
Data stucture
diagrams
Program stucture
diagrams
Traceability
matrices
Document
generation
System
information
store
Automated
analysis
Manual
annotation
System to be
re-engineered

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

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

24. 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)...

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