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

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

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 It is often impossible to maintain hardware interfaces because of the wide gap between mainframes and client-server systems

Legacy application system

Database-centred system

Transaction processing

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

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

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

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

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

Software maintenance Managing the processes of system change

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

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

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

Distribution of maintenance effort

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

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

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

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

The maintenance process

Change processes Fault repair process Iterative development process

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

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

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

Lehman’s laws

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

Development/maintenance costs

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

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

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

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

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

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

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

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

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

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

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

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

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

Forward engineering and re-engineering

The re-engineering process

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

Re-engineering approaches

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

The program translation process

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

The reverse engineering process

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

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

Spaghetti logic

Structured control logic

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

Automatic program restructuring

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

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

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

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

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

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

Approaches to data re-engineering

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

Data migration

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

Data value inconsistencies

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

The data re-engineering process