Software Reengineering

Dr. Isma Ul Hassan

Textbooks and Reading Material
Re-engineering legacy software, David Lorge Parnas, Chris
Birchall, Safari Books, Shelter Island, NY, 2016

Working Effectively with Legacy Code

Michael Feathers, Prentice Hall, 1 edition, 2004
Legacy Systems: Their issues and challenges

Week-2
 Legacy Systems

•Older software systems that remain vital to an organisation.

•Any existing project that’s difficult to maintain or extend.

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

Characteristics of Legacy Projects
A few features that many legacy projects have in common

•Old
•Large
•Inherited
•Poorly Documented

Exception: Linux Kernel

Reading Assignment
Characteristics of Legacy Code
A few common characteristics usually seen in legacy code

•Untested, untestable code

•Inflexible code
•Code burdened by technical debt
Legacy system replacement
There is a significant business risk in simply scrapping a legacy system and
replacing it with a system that has been developed using modern
technology

• Legacy systems rarely have a complete specification. During their

lifetime they have undergone major changes which may not have
been documented
• Business processes are reliant on the legacy system
• The system may embed business rules that are not formally
documented elsewhere
• New software development is risky and may not be successful
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
• Techniques to save space or increase speed at the expense of understandability
may have been used
• File structures used may be incompatible
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.
Legacy system structures
•Legacy systems can be considered to be socio-technical systems and not
simply software systems

• System hardware - may be mainframe hardware

• Support software - operating systems and utilities
• Application software - several different programs
• Application data - data used by these programs that is often critical
business information
• Business processes - the processes that support a business objective and
which rely on the legacy software and hardware
• Business policies and rules - constraints on business operations
Legacy system components
Layered model
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
Legacy data
•The system may be file-based with incompatible files. The change
required may be to move to a database-management system

•In legacy systems that use a DBMS the database management system
may be obsolete and incompatible with other DBMSs used by the
business
Legacy system design
•Most legacy systems were designed before object-oriented development
was used.

•Rather than being organised as a set of interacting objects, these systems

have been designed using a function-oriented design strategy.

•Several methods and tools are available to support function-oriented

design and the approach is still used for many business applications
Why Businesses Continue to Use Legacy
Systems
•The lack of financial resources to support the transition

•The fear of major disruption to the business during the modernization

•A lack of ability to retrain staff and prevent service delays

•The overwhelming prospect of upgrading a system

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
System quality and business value
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 or replaced if a suitable
system is available
•High-quality, low-business value
scrap completely or maintain
•High-quality, high business value
Continue in operation using normal system maintenance
Legacy systems
Business value assessment
•Assessment should take different viewpoints into account

• System end-users
• Business customers
• Line managers
• IT managers
• Senior managers

•Interview different stakeholders and gather results

System quality assessment
•Business process assessment

How well does the business process support the current goals of the
business?

•Environment assessment

How effective is the system’s environment and how expensive is it to

maintain

•Application assessment

What is the quality of the application software system

Business process assessment
•Use a viewpoint-oriented approach and seek answers from system
stakeholders

• Is there a defined process model and is it followed?

• Do different parts of the organisation use different processes for the
same function?
• How has the process been adapted?
• What are the relationships with other business processes and are these
necessary?
• Is the process effectively supported by the legacy application software?
Environment assessment
Application assessment
System measurement
You may collect quantitative data to make an assessment of the quality of
the application system

• The number of system change requests

• The number of different user interfaces used by the system
• The volume of data used by the system
 Techniques to Analyze Legacy Systems
st
1 Project Task (Assignment #1: Deliverable 1)
Have to understand the architecture, functionality, and potential areas
for improvement.
Some techniques that can be used to effectively analyze legacy systems:

1. Stakeholder Interviews:

• Interview stakeholders who have worked with the legacy system to

gather insights into its strengths, weaknesses, and challenges.
• Understand user pain points and areas that need improvement.
Techniques to Analyze Legacy Systems
2. Business Impact Analysis:

•Determine how the legacy system contributes to business processes and operations.
•Assess the risks associated with any potential disruptions or failures of the system

3. Risk Assessment and Mitigation:

• Identify risks associated with maintaining the legacy system and potential risks
during migration or modernization.
• Develop strategies to mitigate these risks based on the analysis findings.
Techniques to Analyze Legacy Systems
4. Legacy Data Assessment:

•Analyze the data stored within the system's databases to understand data models,
relationships, and data quality.
•Identify data that is no longer relevant or required.

5. User Experience (UX) Assessment:

•Evaluate the user interface (UI) and user experience of the legacy system.
•Identify usability issues and opportunities for modernizing the UI to meet current
design standards.
Techniques to Analyze Legacy Systems
6. Functional Analysis:

•Document and understand the system's current functionality and how it aligns with
business requirements.
•Identify areas where the functionality might be obsolete, redundant, or no longer
relevant.

7. Security Assessment:
•Perform a security audit to identify vulnerabilities, such as known security issues, such as
weak authentication mechanisms.
Techniques to Analyze Legacy Systems
8. Dependency Mapping:

•Identify the external dependencies, libraries, APIs, and third-party components the system
relies on.

9. Code Review and Analysis:

•Conduct a thorough review of the codebase to understand the structure, logic, and coding
practices.
•Use static code analysis tools to identify coding issues, such as code smells, duplication, and
potential weaknesses.
•Identify any outdated programming languages, libraries etc.
Techniques to Analyze Legacy Systems
10. Reverse Engineering:

•Reverse engineer the system's components to generate high-level architectural diagrams and
documentation.
•Use tools to visualize the relationships between different modules, classes, and functions within
the code (Program analysis).

11. Documentation Review:

•Gather and review any existing documentation, including requirements, design documents, and
user manuals.
•Identify gaps in documentation that need to be addressed to improve system understanding
Class activity: Understanding a code snippet
and identifying the problem related to legacy
code characteristics