Transcript Legacy Systems - University of Houston
Chapter 26
Legacy Systems Older software systems that remain vital to an organization ©IS&JCH040423 Software Engineering. Chapter 26 Slide 0 of 37
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 ©IS&JCH040423 Software Engineering. Chapter 26 Slide 1 of 37
Topics covered
Legacy system structures Legacy system design Legacy system assessment ©IS&JCH040423 Software Engineering. Chapter 26 Slide 2 of 37
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, i.e., they are essential for the normal functioning of the business They have been given the name legacy systems ©IS&JCH040423 Software Engineering. Chapter 26 Slide 3 of 37
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 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 ©IS&JCH040423 Software Engineering. Chapter 26 Slide 4 of 37
Legacy system change
Systems must change in order to remain useful Changing legacy systems, however, is often expensive 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 ©IS&JCH040423 Software Engineering. Chapter 26 Slide 5 of 37
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.
©IS&JCH040423 Software Engineering. Chapter 26 Slide 6 of 37
Legacy system structures
Legacy systems can be considered to be socio technical systems and not simply software systems 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 ©IS&JCH040423 Software Engineering. Chapter 26 Slide 7 of 37
Legacy system components
Support software Runs-on System hardware Uses Runs-on Application software Embeds knowledge of Business policies and rules Uses Uses Constrains Application data Business processes ©IS&JCH040423 Software Engineering. Chapter 26 Slide 8 of 37
Layered model
Socio-technical system
Business processes Application software Support software Hardware ©IS&JCH040423 Software Engineering. Chapter 26 Slide 9 of 37
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 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 ©IS&JCH040423 Software Engineering. Chapter 26 Slide 10 of 37
Legacy application system
Program 1 Program 2 Program 3 File 1 File 2 File 3 File 4 File 5 File 6 Program 4 ©IS&JCH040423 Program 5 Program 6 Software Engineering. Chapter 26 Program 7 Slide 11 of 37
Database-centred system
Program 1 Program 2 Program 3 Program 4 ©IS&JCH040423 Database management system describes Software Engineering. Chapter 26 Logical and physical data models Slide 12 of 37
Transaction processing
Account queries and updates Teleprocessing monitor Serialised transactions Accounts database ATM s and terminals ©IS&JCH040423 Software Engineering. Chapter 26 Slide 13 of 37
Legacy data
The system may be file-based with incompatible files. The change required may be to move to a database management 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 teleprocessing monitor.
©IS&JCH040423 Software Engineering. Chapter 26 Slide 14 of 37
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 ©IS&JCH040423 Software Engineering. Chapter 26 Slide 15 of 37
A function-oriented view of design
Shared memory F1 F4 ©IS&JCH040423 F2 F3 Software Engineering. Chapter 26 F5 Slide 16 of 37
Functional design process
Data-flow design Model the data processing in the system using data-flow diagrams Structural decomposition Model how functions are decomposed to sub-functions using graphical structure charts Detailed design 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 ©IS&JCH040423 Software Engineering. Chapter 26 Slide 17 of 37
Input-process-output model
System Input Process Output ©IS&JCH040423 Software Engineering. Chapter 26 Slide 18 of 37
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 ©IS&JCH040423 Software Engineering. Chapter 26 Slide 19 of 37
Functional design process
Data-flow design Model the data processing in the system using data-flow diagrams Structural decomposition Model how functions are decomposed to sub-functions using graphical structure charts that reflect the input/process/output structure Detailed design The functions in the design and their interfaces are described in detail. ©IS&JCH040423 Software Engineering. Chapter 26 Slide 20 of 37
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 ©IS&JCH040423 Software Engineering. Chapter 26 Slide 21 of 37
Payroll system DFD
Employee records Read employee record Read monthly pay data Decoded employee record Validate employee data Pay information Tax deduction +SS number +tax office Monthly pay Valid employee record rates Compute salary Tax tables Write tax transaction Tax transactions Write pension data Pension deduction + SS number Pension data Print payslip Empoyee data + deductions Net payment + bank account info.
Write bank transaction PRINTER Bank transactions Monthly pay data ©IS&JCH040423 Social security deduction + SS number Write social security data Software Engineering. Chapter 26 Social security data Slide 22 of 37
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 Write tax transaction, Write pension data, Print payslip, Write bank transaction, Write social security data ©IS&JCH040423 Software Engineering. Chapter 26 Slide 23 of 37
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.
©IS&JCH040423 Software Engineering. Chapter 26 Slide 24 of 37
INPUT loop re pe at
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)
the n
Retain_card ; Print ("Card retained - please contact your bank") ;
e ls e re pe at
Print_operation_select_message ; Button := Get_button ;
cas e
Get_button
is w he n
Cash_only => Dispense_cash (Cash_available, Amount_dispensed) ;
w he n
Print_customer_balance (Account_balance) ;
w he n
Statement => Order_statement (Account_number) ;
w he n
Print_balance => Check_book => Order_checkbook (Account_number) ;
e nd cas e
Print ("Press CONTINUE f or more services or STOP to f inish"); Button := Get_button ;
until
Button = STOP ;
OUTPUT
Eject_card ; Print (“Please take your card ) ; , Amount_dispensed) ;
e nd loop
; Design description of an ATM
Using function-oriented design
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 ©IS&JCH040423 Software Engineering. Chapter 26 Slide 26 of 37
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 ©IS&JCH040423 Software Engineering. Chapter 26 Slide 27 of 37
System quality and business value
Business value High business value Low quality High business value High quality 9 10 8 6 7 Low business value Low quality Low business value High quality 2 3 4 5 1 Software Engineering. Chapter 26 System quality Slide 28 of 37 ©IS&JCH040423
Legacy system categories
Low quality, low business value These systems should be scrapped 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 Replace with COTS, scrap completely or maintain High-quality, high business value Continue in operation using normal system maintenance ©IS&JCH040423 Software Engineering. Chapter 26 Slide 29 of 37
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 ©IS&JCH040423 Software Engineering. Chapter 26 Slide 30 of 37
System quality assessment
Business process assessment How well does the business process support the current goals of the business?
Environment assessment How effective is the system’s environment and how expensive is it to maintain Application assessment What is the quality of the application software system ©IS&JCH040423 Software Engineering. Chapter 26 Slide 31 of 37
Business process assessment
Use a viewpoint-oriented approach and seek answers from system stakeholders 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?
©IS&JCH040423 Software Engineering. Chapter 26 Slide 32 of 37
Environment assessment
Factor
Suppli er stability Failure rate Age Performance Support requir ements Main tenan ce costs Interoperability ©IS&JCH040423
Questions
Is the suppl ier is still in existence? Is the supp lier financi ally stable and likely to cont inue in existence? If the supp lier is no longe r in bu siness, are the systems main tain ed by so meone e lse?
Does the h ardware have a high rate of reported failures? Does the support software crash and force system r estarts?
How old is the h ardware and software? The o lder the hardware and support software, the mo re obsolete it will be. It may still func tion correctly but th ere could b e signi ficant econom ic and bu siness benefits to moving to more mod ern sy stems.
Is the p erforman ce of the system adequate? Do performan ce proble ms hav e a signi fi cant effect on sy stem u sers?
What lo cal support is requi red by th e hardware and so ft ware? If t here are high co sts associated with thi s support, it may be worth cons idering system repla cement.
What are the co sts of hardware mainten ance and suppo rt soft ware licences? Olde r hardware may h ave high er mainten ance co sts than mod ern sy stems. Suppo rt soft ware may have h igh annual licensing costs.
Are there problems int erfa cing the system to othe r systems? Can compil ers etc. be used with cu rrent version s of the op erating sy stem? Is hardware emu lation r equi red?
Software Engineering. Chapter 26 Slide 33 of 37
Application assessment
Factor Questions
Unde rstand abil ity How diff icu lt is it to unde rstand the source code of the current system?
How compl ex a re the cont rol structu res which a re used? Do variab les hav e meaning ful n ames tha t reflect thei r function ?
Docum enta tion Data What system do cumen tation i s ava ilabl e? Is the do cumen tation comple te, con sistent and up -to-date?
Is the re an exp licit data mode l f or the system? To what ext ent i s data dupl icated in d iff erent files? Is the data used by the system up-to-date and cons istent ?
Performance Programming language Configu ration manage ment Is the p erforman ce of the appli cation adequ ate? Do performanc e problems have a signi ficant e ffe ct on system users?
Are mod ern comp ilers ava ilab le for the programming l anguage u sed to develop th e system? Is the programm ing langu age still u sed for ne w system d evelop ment ?
Are all ve rsion s of all pa rts of t he sy stem m anaged by a configu ration manage ment system? Is the re an expl icit description o f the version s of component s that are used in the current system?
Test data Personnel skills Does test data for the system exist? Is the re a record of regression t ests carried ou t when new fe atures have be en added to the system?
Are there peop le ava ilab le who have the skil ls to ma inta in the application ? Are the re only a l imited numb er of peopl e who und erstand the system?
©IS&JCH040423 Software Engineering. Chapter 26 Slide 34 of 37
System measurement
You may collect quantitative data to make an assessment of the quality of the application system The number of system change requests The number of different user interfaces used by the system The volume of data used by the system ©IS&JCH040423 Software Engineering. Chapter 26 Slide 35 of 37
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 ©IS&JCH040423 Software Engineering. Chapter 26 Slide 36 of 37
Key points
(continued) 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 ©IS&JCH040423 Software Engineering. Chapter 26 Slide 37 of 37