software maintenance takes up 60-70% of software organization resources. To avoid surplus efforts in maintaining a legacy system we use a method of re-engineering the old software so that it can adapt to the new environment. Slides describes the re-engineering process which is considered to be a pro for legacy systems but they do even have risks which has to be accounted for.

1. Reengineering Pros and Cons
Neema Volvoikar
162113018
1

2. Introduction
• When changes are demanded by the end users, the challenge
of software maintenance begins.
• Growing queue of bug fixes, adaptation requests, and outright
enhancements that must be planned, scheduled, and
ultimately accomplished.
• The queue has grown long and the work it implies threatens
to overwhelm the available resources.
• As time passes, your organization finds that it’s spending
more money and time maintaining existing programs than it is
engineering new applications.
2

3. Software Maintenance
3
It is common for a software organization to expend as much as
60 to 70 percent of all resources on software maintenance.

4. Legacy system
• Legacy systems are the old software systems which are
essential for business process support.
• Software re-engineering is concerned with re-implementing
legacy systems to make them more maintainable.
• It is the only viable way to ensure that legacy systems can
continue in service.
4

5. Reengineering
Reengineering occurs at two different level of abstraction
• Business level: A business process is “a set of logically related
tasks performed to achieve a defined business outcome”.
• Software level
5

6. Business re-engineering process
6
Figure: A BRP Model

7. Software Reengineering
7
Figure 3: A general model for software re-engineering
Software re-engineering is the examination and the
alteration of a system to reconstitute it in a new form to
improve the maintainability of a software system.

8. Why do we need software Reengineering
• It is sometimes a cost effective option for software evolution.
• Applicable when some (but not all) subsystems of larger
system require frequent maintenance.
• It involves putting in effort to make it easier to maintain.
8

9. The process model
9

10. Inventory analysis
• Spreadsheet model containing information providing detailed
description of applications.
Example: size, age, business criticality.
• Deciding for candidate applications based on this factors
allocating resources to them.
• Inventory should be revisited on a regular cycle.
10

11. Document restructuring
Weak documentation is the trademark of many legacy systems.
• Creating documentation is far too time consuming. It is not
possible to re-create documentation for hundreds of
computer programs.
• Documentation must be updated, but your organization has
limited resources. You’ll use a “document when touched”
approach and is not necessary to fully redocument an
application.
• The system is business critical and must be fully
redocumented. Even in this case, an intelligent approach is to
pare documentation to an essential minimum.
11

12. Reverse engineering
• Reverse engineering for software is the process of analyzing a
program in an effort to create a representation of the
program at a higher level of abstraction than source code.
• It is a process of design recovery.
• The program itself is unchanged by reverse engineering
process.
• The software source code is usually available as an input.
12

13. Code restructuring
• The source code is analyzed using a restructuring tool.
• Violations of structured programming constructs are noted
and code is then restructured or even rewritten in a more
modern programming language.
• The resultant restructured code is reviewed and tested to
ensure that no anomalies have been introduced.
• Internal code documentation is updated.
13

14. Data restructuring
• A program with weak data architecture will be difficult to
adapt and enhance.
• Data restructuring is a full-scale reengineering activity begins
with a reverse engineering activity.
• Current data architecture is dissected, data objects and
attributes are identified, and existing data structures are
reviewed for quality.
• When data structure is weak, the data are reengineered.
• changes to the data will invariably result in either
architectural or code-level changes.
14

15. Forward reengineering
• Forward Engineering is a traditional technique of moving from
high-level abstractions and logical, implementation-
independent designs to the physical implementation of a
system.
• For example building from a model into an implementation
language.
15

16. Advantages
There are two key advantages
• Reduced risk: As the software is already existing, the risk is
less as compared to developing a new software.
• Reduced cost: The cost of engineering is significantly less than
the cost of developing a new software.
16

17. Re-engineering risks
17
These potential risks can be categorized in the following areas
as depicted below

18. User satisfaction
• Customer satisfaction is an integral key element for any
business strategy, therefore it is essential for any business to
effectively manage reliable measures for customer
satisfaction.
User satisfaction risks are as below :
• Lack of user friendliness
• Budget overflow in un-managed processes
• Unexpected result of the target system
18

19. Cost
• Legacy software is reengineered in order to face the market
with latest technology and tools to make it more cost
benefitted.
Risks involved in cost benefit are as follow below:
• Less benefit from the cost of re-engineering
• High maintenance cost after re-engineering
• Expensive backup.
• High cost to finance report
• Poor quality processes for re-engineering and inconsistency of
business plans
• Loss of investments on legacy transformation.
19

20. Forward engineering
Risks involved in FE are listed as follow.
• Captured objects do not integrate to new system.
• Difficulty in migrating existing data to for new system
• Degree of preparation for transformation and reverse
engineering are not sufficient.
20

21. Reverse engineering
The RE risk factors are:
• Abstract information cannot be expressed in the designed
language for requirements and design specifications.
• It is quite difficult to capture efficient design and few
requirements from the source code.
• Existing business knowledge embedded in source code is lost
due to inappropriate processes.
• Recovered information is not useful or not used at all.
21

22. Performance
The Performance risks factors are listed below.
• Non portability in new system
• Result not matched with the previous system
• Reliability mismatch
• Inappropriate Re-engineering approach and data
restructuring.
22

23. Maintenance
• Decisions are aided by understanding what happens to any
software systems over time according to new requirements.
• The key software maintenance issues can be either
managerial or technical or both.
The maintenance risks are listed as follow.
• Scheduled Backup
• Recovery of legacy systems
• Improper Re-documentation and data restructuring
23

24. References
• Nasir Rashid Department of CS and I.T University of Malakand
Pakistan, Analysis of Risks in Re-Engineering Software
Systems, Pakistan International Journal of Computer
Applications (0975 – 8887) Volume 73– No.11, July 2013
• Roger S. Pressman, Software Engineering A Practitioner’s
Approach (Seventh Editiion), McGraw-Hill Education.
24

25. THANK YOU!
25