2. Legacy Systems IS301 – Software Engineering Lecture # 24 – 2003-11-13 M. E. Kabay, PhD, CISSP Dept of Computer Information Systems Norwich University mkabay@norwich.edu

3. 2 Copyright © 2003 M. E. Kabay. All rights reserved. Acknowledgement  All of the material in this presentation is based directly on slides kindly provided by Prof. Ian Sommerville on his Web site at http://www.software-engin.com  Used with Sommerville’s permission as extended by him for all non-commercial educational use  Copyright in Kabay’s name applies solely to appearance and minor changes in Sommerville’s work or to original materials and is used solely to prevent commercial exploitation of this material

4. 3 Copyright © 2003 M. E. Kabay. All rights reserved. Topics  Legacy Systems  Legacy System Structures  Legacy System Design  Legacy System Assessment

5. 4 Copyright © 2003 M. E. Kabay. All rights reserved. Legacy Systems (1)  Older software systems that remain vital to an organization

6. 5 Copyright © 2003 M. E. Kabay. All rights reserved. Legacy Systems (2)  Software systems developed especially for organization have long lifetimes  Many still in use  Developed many years ago  Using technologies now obsolete  Still business critical  Essential for normal functioning of business  Called legacy systems

7. 6 Copyright © 2003 M. E. Kabay. All rights reserved. Legacy System Replacement  Why not simply scrap legacy systems?  Replace with new system  Develop using modern technology  Problems  Business processes reliant on legacy system  Legacy systems rarely have complete specification Usually undergone major changes which may not have been documented System may embed business rules that not formally documented elsewhere  New software development risky and may not be successful  Older workers may resist change MK story about COBOL vs 4GL

8. 7 Copyright © 2003 M. E. Kabay. All rights reserved. Legacy System Change  Systems must change in order to remain useful  However, changing legacy systems often expensive  System may use obsolete programming language  Different parts implemented by different teams so no consistent programming style  File structures used may be incompatible  Techniques to save space or increase speed at expense of understandability may have been used  System structure may be corrupted by many years of maintenance  System documentation often out-of-date

9. 8 Copyright © 2003 M. E. Kabay. All rights reserved. Legacy Dilemma  Businesses must weigh up costs and risks  May choose to extend system lifetime using techniques such as re-engineering.  Covered in Chapters 27 and 28 Expensive and risky to replace legacy system Expensive to maintain legacy system Expensive and risky to replace legacy system Expensive to maintain legacy system

10. 9 Copyright © 2003 M. E. Kabay. All rights reserved. Topics  Legacy Systems  Legacy System Structures  Legacy System Design  Legacy System Assessment

11. 10 Copyright © 2003 M. E. Kabay. All rights reserved. Legacy System Structures Legacy systems not simply software systems: are socio-technical systems  System hardware: may be mainframe hardware  Support software: operating systems and utilities  Application software: several different programs  Application data: data often critical business information  Business processes: support business objectives  Business policies and rules: constraints on business operations  Old programmers: sense of pride & ownership  Old users: sense of comfort and confidence

12. 11 Copyright © 2003 M. E. Kabay. All rights reserved. Legacy System Components

13. 12 Copyright © 2003 M. E. Kabay. All rights reserved. Layered Model Think of other layered models

14. 13 Copyright © 2003 M. E. Kabay. All rights reserved. System Change  In principle, should be possible to replace layer in system leaving other layers unchanged  In practice, usually impossible  Changing one layer introduces new facilities Higher level layers must change to make use of these  Changing software may slow it down Hardware changes required  Often impossible to maintain hardware interfaces Wide gap between mainframes and client- server systems

15. 14 Copyright © 2003 M. E. Kabay. All rights reserved. Legacy Application Systems

16. 15 Copyright © 2003 M. E. Kabay. All rights reserved. Older DB-Centered Systems

17. 16 Copyright © 2003 M. E. Kabay. All rights reserved. Older Transaction Processing Systems

18. 17 Copyright © 2003 M. E. Kabay. All rights reserved. Legacy Data  System may be file-based with incompatible files  May have to move to DBMS  Legacy system DBMS  May be obsolete  Incompatible with modern DBMS in use  Teleprocessing monitor  May be designed for particular DB  May run only on specific mainframe  New DB may require new TP monitor

19. 18 Copyright © 2003 M. E. Kabay. All rights reserved. Topics  Legacy Systems  Legacy System Structures  Legacy System Design  Legacy System Assessment

20. 19 Copyright © 2003 M. E. Kabay. All rights reserved. Legacy System Design  Most legacy systems designed before object- oriented development used  Use function-oriented design strategy  Not organized as set of interacting objects  Tools still available to support function- oriented design  Methodologies  CASE tools

21. 20 Copyright © 2003 M. E. Kabay. All rights reserved. Function-Oriented View of Design Global variable s Top-down structured design Local variables used and discarded Easy to cause pathological side effects

22. 21 Copyright © 2003 M. E. Kabay. All rights reserved. Functional Design Process  Data-flow design  Model data processing in system using data-flow diagrams (DFD)  Structural decomposition  Model how functions decomposed to sub- functions using graphical structure charts  Detailed design  Entities in design and their interfaces described in detail  May be recorded in data dictionary and design expressed using PDL Program Descriptio n Language

23. 22 Copyright © 2003 M. E. Kabay. All rights reserved. Input-Process-Output Model

24. 23 Copyright © 2003 M. E. Kabay. All rights reserved. Input-Process-Output Model  Input components  Read and validate data from terminal or file  Processing components  Carry out transformations on data  Output components  Format and print results of computation  Input, process and output  Can all be represented as functions with data ‘flowing’ between them

25. 24 Copyright © 2003 M. E. Kabay. All rights reserved. Functional Design Process  Data-flow design  Model data processing in system using data-flow diagrams  Structural decomposition  Model how functions decomposed to sub- functions  Use graphical structure charts Reflect input/process/output structure  Detailed design  Functions in design and their interfaces described in detail

26. 25 Copyright © 2003 M. E. Kabay. All rights reserved. Data Flow Diagrams  Show how input data item functionally transformed by system into output data item  Are integral part of many design methods and supported by many CASE systems  May be translated into either sequential or parallel design.  In sequential design, processing elements are functions or procedures;  In parallel design, processing elements are tasks or processes

27. 26 Copyright © 2003 M. E. Kabay. All rights reserved. Payroll System DFD Input Functions Output Functions

28. 27 Copyright © 2003 M. E. Kabay. All rights reserved. Payroll Batch Processing  Functions on left of DFD are input functions  Read employee record  Read monthly pay data  Validate employee data  Central function (Compute salary) carries out processing  Functions to right are output functions  Write tax transaction  Write pension data  Print pay slip  Write bank transaction  Write social security data

29. 28 Copyright © 2003 M. E. Kabay. All rights reserved. Transaction Processing  Bank ATM system example of transaction processing system  Transactions are stateless  Do not rely on result of previous transactions  Functional approach is therefore natural way to implement transaction processing

30. Design Description of ATM

31. 30 Copyright © 2003 M. E. Kabay. All rights reserved. Topics  Legacy Systems  Legacy System Structures  Legacy System Design  Legacy System Assessment

32. 31 Copyright © 2003 M. E. Kabay. All rights reserved. Legacy System Assessment  Need strategy for evolving legacy systems  Scrap system completely and modify business processes  Continue maintaining system  Transform system by re-engineering to improve its maintainability  Replace system with new system  Strategy chosen should depend on system quality and its business value

33. 32 Copyright © 2003 M. E. Kabay. All rights reserved. System Quality and Business Value Example uses 10 projects

34. 33 Copyright © 2003 M. E. Kabay. All rights reserved. Legacy System Categories  Low quality, low business value  These systems should be scrapped  Low quality, high business value  Important business contribution but expensive to maintain  Should be re-engineered or replaced if suitable system 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

35. 34 Copyright © 2003 M. E. Kabay. All rights reserved. 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

36. 35 Copyright © 2003 M. E. Kabay. All rights reserved. System Quality Assessment  Business process assessment  How well does business process support current goals of business?  Environment assessment  How effective is system’s environment?  How expensive is it to maintain?  Application assessment  What is quality of application software system?

37. 36 Copyright © 2003 M. E. Kabay. All rights reserved. Business Process Assessment Use viewpoint-oriented approach and seek answers from system stakeholders  Is there defined process model? Is it followed?  Do different parts of organization use different processes for same function?  How has process been adapted?  What relationships with other business processes and these necessary?  Is process effectively supported by legacy application software?

38. 37 Copyright © 2003 M. E. Kabay. All rights reserved. Environment Assessment  Supplier Stability  Failure Rate  Age  Performance  Support Requirements  Maintenance Costs  Interoperability

39. 38 Copyright © 2003 M. E. Kabay. All rights reserved. Application Assessment  Understandability  Documentation  Data  Performance  Programming language  Configuration management  Test data  Personnel skills

40. 39 Copyright © 2003 M. E. Kabay. All rights reserved. System Measurement May collect quantitative data to make assessment of quality of application system  Number of system change requests  Number of different user interfaces used by system  Volume of data used by system

41. 40 Copyright © 2003 M. E. Kabay. All rights reserved. Homework  Apply complete SQ3R to Chapter 26  Survey-question Chapter 27 on SW Change  REQUIRED: For next Thursday 20 Nov 2003,  Complete Exercises 26.1-26.5 for 3 points each  Complete Exercise 26.6 for 6 points  OPTIONAL: For Tuesday 2 Dec:  All or any of 26.7 – 26.10 at 2 pts each (¼-½ page each)

42. 41 Copyright © 2003 M. E. Kabay. All rights reserved. DISCUSSION