Lectures Software Engineering - Chapter 26: Legacy Systems

38 trang hoanguyen 5050

Download

Bạn đang xem 20 trang mẫu của tài liệu "Lectures Software Engineering - Chapter 26: Legacy Systems", để tải tài liệu gốc về máy bạn click vào nút DOWNLOAD ở trên

Tài liệu đính kèm:

lectures_software_engineering_chapter_25_legacy_systems.ppt

Nội dung text: Lectures Software Engineering - Chapter 26: Legacy Systems

Legacy Systems l Older software systems that remain vital to an organisation ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 1
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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 2
Topics covered l Legacy system structures l Legacy system design l Legacy system assessment ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 3
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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 4
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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 5
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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 6
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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 7
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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 8
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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 11
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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 15
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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 16
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 ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 18
Input-process-output l Input components read and validate data from a terminal or file l Processing components carry out some transformations on that data l Output components format and print the results of the computation l 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 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 that reflect the input/process/output structure l Detailed design l The functions in the design and their interfaces are described in detail. ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 21
Data flow diagrams l Show how an input data item is functionally transformed by a system into an output data item l Are an integral part of many design methods and are supported by many CASE systems l 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 batch processing l The functions on the left of the DFD are input functions l Read employee record, Read monthly pay data, Validate employee data l The central function - Compute salary - carries out the processing l The functions to the right are output functions l Write tax transaction, Write pension data, Print payslip, Write bank transaction, Write social security data ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 24
Transaction processing l A ban ATM system is an example of a transaction processing system l 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
Design description of an ATM
Using function-oriented design l For some classes of system, such as some transaction processing systems, a function- oriented approach may be a better approach to design than an object-oriented approach l 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 l Organisations that rely on legacy systems must choose a strategy for evolving these systems l Scrap the system completely and modify business processes so that it is no longer required l Continue maintaining the system l Transform the system by re-engineering to improve its maintainability l Replace the system with a new system l The strategy chosen should depend on the system quality and its business value ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 28
Legacy system categories l Low quality, low business value l These systems should be scrapped l Low-quality, high-business value l These make an important business contribution but are expensive to maintain. Should be re-engineered or replaced if a suitable system is available l High-quality, low-business value l Replace with COTS, scrap completely or maintain l High-quality, high business value l Continue in operation using normal system maintenance ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 30
Business value assessment l Assessment should take different viewpoints into account l System end-users l Business customers l Line managers l IT managers l Senior managers l Interview different stakeholders and collate results ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 31
System quality assessment l Business process assessment l How well does the business process support the current goals of the business? l Environment assessment l How effective is the system’s environment and how expensive is it to maintain l Application assessment l What is the quality of the application software system ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 32
Business process assessment l Use a viewpoint-oriented approach and seek answers from system stakeholders l Is there a defined process model and is it followed? l Do different parts of the organisation use different processes for the same function? l How has the process been adapted? l What are the relationships with other business processes and are these necessary? l Is the process effectively supported by the legacy application software? ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 33
System measurement l You may collect quantitative data to make an assessment of the quality of the application system l The number of system change requests l The number of different user interfaces used by the system l The volume of data used by the system ©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 26 Slide 36
Key points l A legacy system is an old system that still provides essential business services l Legacy systems are not just application software but also include business processes, support software and hardware l Most legacy systems are made up of several different programs and shared data l 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 l The structure of legacy business systems normally follows an input-process-output model l The business value of a system and its quality should be used to choose an evolution strategy l The business value reflects the system’s effectiveness in supporting business goals l 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