Presentation is loading. Please wait.

Presentation is loading. Please wait.

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26Slide 1 Chapter 26 Legacy Systems.

Similar presentations


Presentation on theme: "©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26Slide 1 Chapter 26 Legacy Systems."— Presentation transcript:

1 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26Slide 1 Chapter 26 Legacy Systems

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

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

4 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26Slide 4 Topics covered l Legacy system structures l Legacy system design l Legacy system assessment

5 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26Slide 5 Legacy systems l Software systems that are developed specially for an organisation have a long lifetime l Many software systems that are still in use were developed many years ago using technologies that are now obsolete l These systems are still business critical that is, they are essential for the normal functioning of the business l They have been given the name legacy systems

6 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26Slide 6 Legacy system replacement l 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 l Legacy systems rarely have a complete specification. During their lifetime they have undergone major changes which may not have been documented l Business processes are reliant on the legacy system l The system may embed business rules that are not formally documented elsewhere l New software development is risky and may not be successful

7 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26Slide 7 Legacy system change l Systems must change in order to remain useful l However, changing legacy systems is often expensive l Different parts implemented by different teams so no consistent programming style l The system may use an obsolete programming language l The system documentation is often out-of-date l The system structure may be corrupted by many years of maintenance l Techniques to save space or increase speed at the expense of understandability may have been used l File structures used may be incompatible

8 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26Slide 8 The legacy dilemma l It is expensive and risky to replace the legacy system l It is expensive to maintain the legacy system l Businesses must weigh up the costs and risks and may choose to extend the system lifetime using techniques such as re-engineering. l This is covered in Chapters 27 and 28

9 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26Slide 9 Legacy system structures l Legacy systems can be considered to be socio- technical systems and not simply software systems l System hardware - may be mainframe hardware l Support software - operating systems and utilities l Application software - several different programs l Application data - data used by these programs that is often critical business information l Business processes - the processes that support a business objective and which rely on the legacy software and hardware l Business policies and rules - constraints on business operations

10 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26Slide 10 Legacy system components

11 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26Slide 11 Layered model

12 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26Slide 12 System change l In principle, it should be possible to replace a layer in the system leaving the other layers unchanged l In practice, this is usually impossible l Changing one layer introduces new facilities and higher level layers must then change to make use of these l Changing the software may slow it down so hardware changes are then required l It is often impossible to maintain hardware interfaces because of the wide gap between mainframes and client-server systems

13 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26Slide 13 Legacy application system

14 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26Slide 14 Database-centred system

15 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26Slide 15 Transaction processing

16 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26Slide 16 Legacy data l The system may be file-based with incompatible files. The change required may be to move to a database-management system l In legacy systems nthat use a DBMS the database management system may be obsolete and incompatible with other DBMSs used by the business l The teleprocessing monitor may be designed for a particular DB and mainframe. Changing to a new DB may require a new TP monitor

17 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26Slide 17 Legacy system design l Most legacy systems were designed before object-oriented development was used l Rather than being organised as a set of interacting objects, these systems have been designed using a function-oriented design strategy l Several methods and CASE tools are available to support function-oriented design and the approach is still used for many business applications

18 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26Slide 18 A function-oriented view of design

19 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26Slide 19 Functional design process l Data-flow design l Model the data processing in the system using data-flow diagrams l Structural decomposition l Model how functions are decomposed to sub-functions using graphical structure charts l Detailed design l 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

20 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26Slide 20 Input-process-output model


Download ppt "©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26Slide 1 Chapter 26 Legacy Systems."

Similar presentations


Ads by Google