Legacy Systems

q

Older software systems that  remain vital to an organisation

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 26

Slide 1

Objectives
q

q q q

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

Legacy system structures Legacy system design Legacy system assessment

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 26

Slide 3

Legacy systems
q

q

q

q

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

©Ian Sommerville 2000 

Legacy system replacement
q

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
q

q q

q

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

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 26

Slide 5

Legacy system change
q q

Systems must change in order to remain useful However, changing legacy systems is often  expensive
q q q q

q

q

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

©Ian Sommerville 2000 

The legacy dilemma
q

q q

q

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

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 26

Slide 7

Legacy system structures
q

Legacy systems can be considered to be socio­ technical systems and not simply software  systems
q q q q

q

q

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

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 26

Slide 8

Eistn me bso eac dee sns k B ous wC o o Ucnfds sntnUii eAlgrr SRa su u up ep p nfo n o ssi la r ­o s t oU lr is se A B o pu f ltn s tm w is w ie n a c e R  a p u dr n eo sr i c ­a o o n S y s t e h a r d w
Legacy system components
©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 26 Slide 9

Layered model

©Ian Sommerville 2000 

Spse oiles cBa ie tp ­no tcm cyr h c af so te e ut sr isw n   A lra irr c a ie o n S u H a d w
Software Engineering, 6th edition. Chapter 26

Slide 10

System change
q

q

In principle, it should be possible to replace a  layer in the system leaving the other layers  unchanged In practice, this is usually impossible
q q

q

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

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 26

Slide 11

Legacy application system

PFrmPF rmPFrm oi2gi4gi6 gl ol ol aeFeFe     i3  i5  1 l  l  ae 2a 3 F PP P i1 rmmm lg o r  r  e go o  a a g g ea a   67 P  rm5 o   4
Software Engineering, 6th edition. Chapter 26 Slide 12

©Ian Sommerville 2000 

Database­centred system

PPPP rm rm orm rm gooo aggg a34 aa 12 bg eh DdL a eds ta so b cad s rp e ists i n c a l m  o n y g m m e n t s y
Software Engineering, 6th edition. Chapter 26 Slide 13

©Ian Sommerville 2000 

Transaction processing

©Ian Sommerville 2000 

Airtrec cTSA oped urina noitnu tasata  unso qgob e ldn rnc t icise s s ate dt p d e l m Al Tn M srs  d ai n  m ta e
Software Engineering, 6th edition. Chapter 26 Slide 14

Legacy data
q

q

q

The system may be file­based with incompatible  files. The change required may be to move to a  database­management system In legacy systems nthat 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
Software Engineering, 6th edition. Chapter 26 Slide 15

©Ian Sommerville 2000 

Legacy system design
q

q

q

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

©Ian Sommerville 2000 

A function­oriented view of design

©Ian Sommerville 2000 

So hr ay re e d   m 3 FFF 1 2F F 5 4
Software Engineering, 6th edition. Chapter 26 Slide 17

Functional design process
q

Data­flow design
q

Model the data processing in the system using data­flow  diagrams Model how functions are decomposed to sub­functions using  graphical structure charts 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

q

Structural decomposition
q

q

Detailed design
q

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 26

Slide 18

Input­process­output model

S y s t e m I PO nr u po t uc p te s
Software Engineering, 6th edition. Chapter 26 Slide 19

©Ian Sommerville 2000 

Input­process­output
q

q

q

q

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
q

Data­flow design
q

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 The functions in the design and their interfaces are described in  detail. 

q

Structural decomposition
q

q

Detailed design
q

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 26

Slide 21

Data flow diagrams
q

q

q

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

©Ian Sommerville 2000 

a x Wss rotn iprc ta aa eP  ti n a et xT c i T+nns at iPoi  xftrn td  eSss o dcen i uWn ca o ien n ED Mu md nxd pm ooc lee uns op n t  yc mi  be +d rdre V S e l ar a m c o ltr i+ r r ia tr s y d a o h ba ly ny y es pP eEipP smtl R RPte ced mIR eoadoa pynN ayyors oekT d e net yni E  mVo utb e iam c   p ppd  an leoyl isa rd falemeup c mCN rl nary ta+ lt T of a ii p Wn u to k o tl dktB y b tibrc e a noas r p. n +s Rr xc t eh me ra i ay a s n o d  lt m  i o n y p St to n y oi s a cyc nsit M dsml ea o e Ssoc n u bis u t a tlcrWr h a ei o y +u c p utc y d ieerdS a n ca tl re a n t   yd
Payroll system DFD
©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 26 Slide 23

Payroll batch processing
q

The functions on the left of the DFD are input  functions
q

Read employee record, Read monthly pay data, Validate  employee data

q

q

The central function ­ Compute salary ­ carries  out the processing The functions to the right are output functions
q

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
q

q

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

IP NT U lorepeat elcome ­ Please enter y o Print_input_message (Ó W p        Card_input ;   until Account_balance, Cash_   Account_number := Read_card   Get_account_details (PIN,  PCS RE OS   if Retain_card ;  Invalid_card (PIN)  then Print ("Card retained ­ please  else      Print_operation_select_messa repeat         Get_button  Button := Get_button ;        when case is         Dispense_cash (Cash_avail  Cash_only =>             Amount_dispensed)         Print_customer_balance (Ac when  Print_balance =>                   when  Statement =>            Order_statement (Account_        when  Check_book =>          Order_checkbook (Account_         ; end case OP Print ("Press CONTINUE for m  to finish"); Button := Get_button ; untilOP  Button = ST  ; Design  OP UU TT description of an  Eject_card ;,         Print (ÒPlease take your card )  ATM Update_account_information (A Amount_dispensed     ; end loop

Using function­oriented design
q

q

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

Organisations that rely on legacy systems must  choose a strategy for evolving these systems
q q q

q

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

q

The strategy chosen should depend on the system  quality and its business value

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 26

Slide 28

B9is He uuw 6s saHei uu iseg ag a nLvhv eol bl  li0uq v1 7 h s  u a bi s l nn et q e a 8 l y t y iy n e La La o34hl w He  uu 5s bl o u se i u is gv n w e b   q v s q a a l l t t y 2 St 1 yi sa t l ey m q u
System quality and business value
©Ian Sommerville 2000  Software Engineering, 6th edition. Chapter 26 Slide 29

Legacy system categories
q

Low quality, low business value
q

These systems should be scrapped  These make an important business contribution but are  expensive to maintain. Should be re­engineered or replaced if a  suitable system is available Replace with COTS, scrap completely or maintain Continue in operation using normal system maintenance

q

Low­quality, high­business value
q

q

High­quality, low­business value
q

q

High­quality, high business value
q

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 26

Slide 30

Business value assessment
q

Assessment should take different viewpoints into  account
q q q q q

System end­users Business customers Line managers IT managers Senior managers

q

Interview different stakeholders and collate  results

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 26

Slide 31

System quality assessment
q

Business process assessment
q

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 What is the quality of the application software system

q

Environment assessment
q

q

Application assessment
q

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 26

Slide 32

Business process assessment
q

Use a viewpoint­oriented approach and seek  answers from system stakeholders
q q

q q

q

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?

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 26

Slide 33

Environment assessment
Factor Supplier stability Failure rate Age 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

Performance Support requirements Maintenance costs Interoperability

©Ian Sommerville 2000 

Application assessment

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 26

Slide 35

System measurement
q

You may collect quantitative data to make an  assessment of the quality of the application  system
q q q

The number of system change requests  The number of different user interfaces used by the system The volume of data used by the system

©Ian Sommerville 2000 

Software Engineering, 6th edition. Chapter 26

Slide 36

Key points
q

q

q

q

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

©Ian Sommerville 2000 

Key points
q

q

q

q

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

©Ian Sommerville 2000 

Sign up to vote on this title
UsefulNot useful