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

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

5. 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.
This is covered in Chapters 27 and 28

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

7. Legacy system components

8. Layered model

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

10. Legacy application system

11. Database-centred system

12. Transaction processing

13. 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
The teleprocessing monitor may be designed for a particular DB and mainframe. Changing to a new DB may require a new TP monitor

14. 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 CASE tools are available to support function-oriented design and the approach is still used for many business applications

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

16. System quality and business value

17. 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
Replace with COTS, scrap completely or maintain
High-quality, high business value
Continue in operation using normal system maintenance

18. 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 collate results

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

20. 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?

21. Environment assessment

22. Application assessment

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

24. Software maintenance
Managing the processes of system change

25. Software maintenance
Modifying a program after it has been put into use
Maintenance management is concerned with planning and predicting the process of change
Configuration management is the management of products undergoing change. Covered in the following chapter

26. Maintenance is inevitable
The system requirements are likely to change while the system is being developed because the environment is changing. Therefore a delivered system won't meet its requirements!
Systems are tightly coupled with their environment. When a system is installed in an environment it changes that environment and therefore changes the system requirements.
Systems MUST be maintained therefore if they are to remain useful in an environment

27. Types of maintenance Perfective maintenance Adaptive maintenance
Changing a system to make it meet its requirements more effectively
Adaptive maintenance
Changing a system to meet new requirements
Corrective maintenance
Changing a system to correct deficiencies in the way meets its requirements

28. Distribution of maintenance effort

29. Evolving systems
It is usually more expensive to add functionality after a system has been developed rather than design this into the system
Maintenance staff are often inexperienced and unfamiliar with the application domain
Programs may be poorly structured and hard to understand
Changes may introduce new faults as the complexity of the system makes impact assessment difficult
The structure may be degraded due to continual change
There may be no documentation available to describe the program

30. Maintenance management
Maintenance has a poor image amongst development staff as it is not seen as challenging and creative
Maintenance costs increase as the software is maintained
The amount of software which has to be maintained increases with time
Inadequate configuration management often means that the different representations of a system are out of step

31. Staff motivation
Relate software development to organizational goals - maintenance rationale
Relate rewards to organizational performance
Integrate maintenance with development
Create a discretionary preventative maintenance budget
Plan for maintenance early in the development process
Plan to expend effort on program maintainability

32. The maintenance process
Maintenance is triggered by change requests from customers or marketing requirements
Changes are normally batched and implemented in a new release of the system
Programs sometimes need to be repaired without a complete process iteration but this is dangerous as it leads to documentation and programs getting out of step

33. The maintenance process

34. Change processes
Fault repair process
Iterative development process

35. System documentation Requirements document
System architecture description
Program design documentation
Source code listings
Test plans and validation reports
System maintenance guide

36. Document production
Structure documents with overviews leading the reader into more detailed technical descriptions
Produce good quality, readable manuals - they may have to last 20 years
Use tool-generated documentation whenever possible

37. Program evolution dynamics
Program evolution dynamics is the study of the processes of system change
After major empirical study, Lehman and Belady proposed that there were a number of ‘laws’ which applied to all systems as they evolved
There are sensible observations rather than laws. They are applicable to large systems developed by large organisations. Perhaps less applicable in other cases

38. Lehman’s laws

39. Maintenance costs
Usually greater than development costs (2* to 100* depending on the application)
Affected by both technical and non-technical factors
Increases as software is maintained. Maintenance corrupts the software structure so makes further maintenance more difficult.
Ageing software can have high support costs (e.g. old languages, compilers etc.)

40. Development/maintenance costs

41. Maintenance cost factors
Module independence
It should be possible to change one module without affecting others
Programming language
High-level language programs are easier to maintain
Programming style
Well-structured programs are easier to maintain
Program validation and testing
Well-validated programs tend to require fewer changes due to corrective maintenance

42. Maintenance cost factors
Documentation
Good documentation makes programs easier to understand
Configuration management
Good CM means that links between programs and their documentation are maintained
Application domain
Maintenance is easier in mature and well-understood application domains
Staff stability
Maintenance costs are reduced if the same staff are involved with them for some time

43. Maintenance cost factors
Program age
The older the program, the more expensive it is to maintain (usually)
External environment
If a program is dependent on its external environment, it may have to be changed to reflect environmental changes
Hardware stability
Programs designed for stable hardware will not require to change as the hardware changes

44. Maintenance metrics
Measurements of program characteristics which would allow maintainability to be predicted
Essentially technical, how can technical factors above be quantified
Any software components whose measurements are out of line with other components may be excessively expensive to maintain. Perhaps perfective maintenance effort should be devoted to these components

45. Maintenance metrics
Control complexity Can be measured by examining the conditional statements in the program
Data complexity Complexity of data structures and component interfaces.
Length of identifier names Longer names imply readability
Program comments Perhaps more comments mean easier maintenance

46. Maintenance metrics
Coupling How much use is made of other components or data structures
Degree of user interaction The more user I/O, the more likely the component is to require change
Speed and space requirements Require tricky programming, harder to maintain

47. Process metrics Number of requests for corrective maintenance
Average time required for impact analysis
Average time taken to implement a change request
Number of outstanding change requests
If any or all of these is increasing, this may indicate a decline in maintainability

48. Maintenance metrics Log maintenance effort on a per component basis
Choose set of possible metrics which may be related to maintenance
Assess possible metrics for each maintained components
Look for correlation between maintenance effort and metric values

49. Software re-engineering
Reorganising and modifying existing software systems to make them more maintainable

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

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

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

53. Business process re-engineering
Concerned with re-designing business processes to make them more responsive and more efficient
Often reliant on the introduction of new computer systems to support the revised processes
May force software re-engineering as the legacy systems are designed to support existing processes

54. Forward engineering and re-engineering

55. The re-engineering process

56. Re-engineering cost factors
The quality of the software to be re-engineered
The tool support available for re-engineering
The extent of the data conversion which is required
The availability of expert staff for re-engineering

57. Re-engineering approaches

58. Source code translation
Involves converting the code from one language (or language version) to another e.g. FORTRAN to C
May be necessary because of:
Hardware platform update
Staff skill shortages
Organisational policy changes
Only realistic if an automatic translator is available

59. The program translation process

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

61. The reverse engineering process

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

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

64. Spaghetti logic

65. Structured control logic

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

67. Automatic program restructuring

68. Restructuring problems
Problems with re-structuring are:
Loss of comments
Loss of documentation
Heavy computational demands
Restructuring doesn’t help with poor modularisation where related components are dispersed throughout the code
The understandability of data-driven programs may not be improved by re-structuring

69. Program modularisation
The process of re-organising a program so that related program parts are collected together in a single module
Usually a manual process that is carried out by program inspection and re-organisation

70. Module types Data abstractions Hardware modules Functional modules
Abstract data types where datastructures and associated operations are grouped
Hardware modules
All functions required to interface with a hardware unit
Functional modules
Modules containing functions that carry out closely related tasks
Process support modules
Modules where the functions support a business process or process fragment

71. Recovering data abstractions
Many legacy systems use shared tables and global data to save memory space
Causes problems because changes have a wide impact in the system
Shared global data may be converted to objects or ADTs
Analyse common data areas to identify logical abstractions
Create an ADT or object for these abstractions
Use a browser to find all data references and replace with reference to the data abstraction

72. Data abstraction recovery
Analyse common data areas to identify logical abstractions
Create an abstract data type or object class for each of these abstractions
Provide functions to access and update each field of the data abstraction
Use a program browser to find calls to these data abstractions and replace these with the new defined functions

73. Data re-engineering
Involves analysing and reorganising the data structures (and sometimes the data values) in a program
May be part of the process of migrating from a file-based system to a DBMS-based system or changing from one DBMS to another
Objective is to create a managed data environment

74. Approaches to data re-engineering

75. Data problems
End-users want data on their desktop machines rather than in a file system. They need to be able to download this data from a DBMS
Systems may have to process much more data than was originally intended by their designers
Redundant data may be stored in different formats in different places in the system

76. Data migration

77. Data problems Data naming problems Field length problems
Names may be hard to understand. The same data may have different names in different programs
Field length problems
The same item may be assigned different lengths in different programs
Record organisation problems
Records representing the same entity may be organised differently in different programs
Hard-coded literals
No data dictionary

78. Data value inconsistencies

79. Data conversion
Data re-engineering may involve changing the data structure organisation without changing the data values
Data value conversion is very expensive. Special-purpose programs have to be written to carry out the conversion

80. The data re-engineering process