Legacy Systems  Older software systems that remain vital to an

Legacy Systems Older software systems that remain vital to an organisation Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 1

Objectives To explain what is meant by a legacy system and why these systems are important To introduce common legacy system structures To briefly describe function-oriented design To explain how the value of legacy systems can be assessed Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 2

Topics covered Legacy system structures Legacy system design Legacy system assessment Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 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 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 Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 4

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 Ian Sommerville 2000 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 Software Engineering, 6th edition. Chapter 26 Slide 5

Legacy system change Systems must change in order to remain useful However, changing legacy systems is often expensive Ian Sommerville 2000 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 Software Engineering, 6th edition. Chapter 26 Slide 6

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. Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 7

Legacy system structures Legacy systems can be considered to be sociotechnical systems and not simply software systems Ian Sommerville 2000 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 Software Engineering, 6th edition. Chapter 26 Slide 8

Legacy system components Support software Runs-on System hardware Ian Sommerville 2000 Embeds knowledge of Uses Application software Runs-on Uses Application data Software Engineering, 6th edition. Chapter 26 Business policies and rules Uses Constrains Business processes Slide 9

Layered model Socio-technical system Business processes Application software Support software Hardware Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 10

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 Ian Sommerville 2000 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 Software Engineering, 6th edition. Chapter 26 Slide 11

Legacy application system Program 1 File 1 Program 4 Ian Sommerville 2000 Program 2 File 2 File 3 Program 5 Program 3 File 4 Program 6 Software Engineering, 6th edition. Chapter 26 File 5 File 6 Program 7 Slide 12

Database-centred system Program 1 Program 2 Program 3 Database management system Ian Sommerville 2000 Program 4 describes Software Engineering, 6th edition. Chapter 26 Logical and physical data models Slide 13

Transaction processing Account queries and updates Serialised transactions Teleprocessing monitor Accounts database ATM s and terminals Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 14

Legacy data The system may be file-based with incompatible files. The change required may be to move to a databasemanagement 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 Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 15

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 Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 16

A function-oriented view of design Shared memory F1 F2 F4 Ian Sommerville 2000 F3 F5 Software Engineering, 6th edition. Chapter 26 Slide 17

Functional design process Data-flow design Structural decomposition Model the data processing in the system using data-flow diagrams Model how functions are decomposed to sub-functions using graphical structure charts Detailed design Ian Sommerville 2000 The entities in the design and their interfaces are described in detail. These may be recorded in a data dictionary and the design expressed using a PDL Software Engineering, 6th edition. Chapter 26 Slide 18

Input-process-output model System Input Ian Sommerville 2000 Process Software Engineering, 6th edition. Chapter 26 Output Slide 19

Input-process-output Input components read and validate data from a terminal or file Processing components carry out some transformations on that data Output components format and print the results of the computation Input, process and output can all be represented as functions with data ‘flowing’ between them Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 20

Functional design process Data-flow design Structural decomposition Model the data processing in the system using data-flow diagrams Model how functions are decomposed to sub-functions using graphical structure charts that reflect the input/process/output structure Detailed design Ian Sommerville 2000 The functions in the design and their interfaces are described in detail. Software Engineering, 6th edition. Chapter 26 Slide 21

Data flow diagrams Show how an input data item is functionally transformed by a system into an output data item Are an integral part of many design methods and are supported by many CASE systems May be translated into either a sequential or parallel design. In a sequential design, processing elements are functions or procedures; in a parallel design, processing elements are tasks or processes Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 22

Payroll system DFD Tax deduction SS number tax office Employee records Read employee record Read monthly pay data Decoded employee record Write pension data Monthly pay rates Valid employee record Validate Compute employee data salary Empoyee data deductions Pension data Print payslip PRINTER Net payment bank account info. Tax tables Ian Sommerville 2000 Tax transactions Pension deduction SS number Pay information Monthly pay data Write tax transaction Social security deduction SS number Write bank transaction Bank transactions Write social security data Social security data Software Engineering, 6th edition. Chapter 26 Slide 23

Payroll batch processing The functions on the left of the DFD are input functions Read employee record, Read monthly pay data, Validate employee data The central function - Compute salary - carries out the processing The functions to the right are output functions Ian Sommerville 2000 Write tax transaction, Write pension data, Print payslip, Write bank transaction, Write social security data Software Engineering, 6th edition. Chapter 26 Slide 24

Transaction processing A bank ATM system is an example of a transaction processing system Transactions are stateless in that they do not rely on the result of previous transactions. Therefore, a functional approach is a natural way to implement transaction processing Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 25

INPUT loop repeat Print input message (” Welcome - Please enter your card”) ; until Card input ; Account number : Read card ; Get account details (PIN, Account balance, Cash available) ; PROCE SS if Invalid card (PIN) then Retain card ; Print ("Card retained - please contact your bank") ; else repeat Print operation select message ; Button : Get button ; case Get button is when Cash only Dispense cash (Cash available, Amount dispensed) ; when Print balance Print customer balance (Account balance) ; when Statement Order statement (Account number) ; when Check book Order checkbook (Account number) ; end case ; Print ("Press CONTINUE for more services or STOP to finish"); Button : Get button ; until Button STOP ; OUTPUT Eject card ; Print (“Please take your card ) ; Update account information (Account number, Amount dispensed) ; end loop ; Design description of an ATM

Using function-oriented design For some classes of system, such as some transaction processing systems, a functionoriented approach may be a better approach to design than an object-oriented approach Companies may have invested in CASE tools and methods for function-oriented design and may not wish to incur the costs and risks of moving to an object-oriented approach Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 27

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 Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 28

System quality and business value Business value High business value Low quality 9 10 High business value High quality 8 6 7 Low business value High quality Low business value Low quality 2 1 3 4 5 System quality Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 29

Legacy system categories Low quality, low business value 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 These systems should be scrapped Replace with COTS, scrap completely or maintain High-quality, high business value Ian Sommerville 2000 Continue in operation using normal system maintenance Software Engineering, 6th edition. Chapter 26 Slide 30

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 Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 31

System quality assessment Business process assessment Environment assessment How well does the business process support the current goals of the business? How effective is the system’s environment and how expensive is it to maintain Application assessment Ian Sommerville 2000 What is the quality of the application software system Software Engineering, 6th edition. Chapter 26 Slide 32

Business process assessment Use a viewpoint-oriented approach and seek answers from system stakeholders Ian Sommerville 2000 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? Software Engineering, 6th edition. Chapter 26 Slide 33

Environment assessment Factor Supplier stability Failure rate Age Performance Support requirements Maintenance costs Interoperability Ian Sommerville 2000 Questions Is the supplier is still in existence? Is the supplier financially stable and likely to continue in existence? If the supplier is no longer in business, are the systems maintained by someone else? Does the hardware have a high rate of reported failures? Does the support software crash and force system restarts? How old is the hardware and software? The older the hardware and support software, the more obsolete it will be. It may still function correctly but there could be significant economic and business benefits to moving to more modern systems. Is the performance of the system adequate? Do performance problems have a significant effect on system users? What local support is required by the hardware and software? If there are high costs associated with this support, it may be worth considering system replacement. What are the costs of hardware maintenance and support software licences? Older hardware may have higher maintenance costs than modern systems. Support software may have high annual licensing costs. Are there problems interfacing the system to other systems? Can compilers etc. be used with current versions of the operating system? Is hardware emulation required? Software Engineering, 6th edition. Chapter 26 Slide 34

Application assessment Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 35

System measurement You may collect quantitative data to make an assessment of the quality of the application system Ian Sommerville 2000 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 Engineering, 6th edition. Chapter 26 Slide 36

Key points A legacy system is an old system that still provides essential business services Legacy systems are not just application software but also include business processes, support software and hardware Most legacy systems are made up of several different programs and shared data A function-oriented approach has been used in the design of most legacy systems Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 37

Key points The structure of legacy business systems normally follows an input-process-output model The business value of a system and its quality should be used to choose an evolution strategy The business value reflects the system’s effectiveness in supporting business goals System quality depends on business processes, the system’s environment and the application software Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 38