Software Evolution_Se lect2 btech
Download as PPT, PDF0 likes287 views
Legacy systems refer to software systems that have been in use for a long time and are often business critical. They pose risks both to replace due to incomplete documentation and embedded business rules, and to maintain as they evolve over time. A full assessment of legacy systems considers their business value, technical quality, and risks of replacement versus maintenance. This informs a strategy of scrapping, maintaining, re-engineering, or replacing the system.
Software Evolution_Se lect2 btech
- 1. SOFTWARE EVOLUTION 1
- 2. 2
- 3. 3
- 4. 4
- 5. 5
- 6. 6
- 7. 7
- 8. 8
- 9. WHAT ARE LEGACY SYSTEMS? 9
- 10. What are legacy systems? • Systems developed for a specific client that have been in service for a long-time • Many of these systems were developed years ago using obsolete technologies • They are likely to be business critical systems required for normal operation of a business • These are the systems that everyone worried about when the Y2K concerns became public 10
- 11. Legacy System Replacement • The business risks associated with the strategy of scrapping a legacy system and replacing it with a new one are not insignificant – legacy systems rarely have complete specifications – changes are not likely to be documented well at all – business processes are reliant on the system – the legacy system may contain embedded business rules that are not formally documented elsewhere – software development is risky and not is always successful 11
- 12. Changing Legacy Systems • All systems must change to remain useful • Changes to legacy systems can be very expensive – components may be implemented with different programming styles as changes are implemented – system may be written in an obsolete language – system documents often out-of-date – system structure may be corrupted by years of maintenance activities – techniques used to save space or increase speed may have obscured understandability – file structures used may be incompatible with each other 12
- 13. Legacy System Risks • Replacing a legacy system is both expensive and risky • Maintaining a legacy system is also expensive and risky • Sometimes a the decision is made (based on the costs and risks involved) to extend system life-time using techniques like re-engineering 13
- 14. Socio-Technical Systems • Lagacy systems are more than just software systems • Sommerville describes legacy systems as socio- technical systems • Socio-Technical System Layers – business processes – application software – support software – hardware 14
- 15. Legacy System Structures 1. System Hardware – could be a mainframe 1. System Software 2. Application Software 3. Application Data – business critical data often used by several programs 1. Business Processes – processes that support a business objective and rely on the legacy systems hardware and software 1. Business Policies and Rules – business operation constraints 15
- 16. Legacy System Components E beds m know dge of le Uses Sup port Application Busin po ess licies software softw are and rules Runs-on Runs-on Uses Uses Constrains System Application Business ha are rdw data processes 16
- 17. System Change • In theory – it should be possible to replace one layer in a socio-technical system without making any changes to the other layers • In practice – changing one layer introduces new facilities that must be used in higher level layers – changing the software may require hardware changes to maintain system performance – it may be impossible to maintain hardware interfaces because of the huge differences between mainframe and client-server architectures 17
- 18. Legacy Application System Pro am1 gr Program2 Program3 File 1 File 2 File 3 File 4 File 5 File 6 Pro am4 gr Pr am5 ogr Program6 Program7 18
- 19. Database Management System P gra ro m Pogr m r a P gra ro m Pogr m r a 1 2 3 4 D ta a a b se d sc s e ribe Logic l a d a n m n ge e t a a mn ph ic l ys a sy m ste da m de ta o ls 19
- 20. Transaction Processing Account queries and updates Serialised transactions Teleprocessing Accounts monitor database ATMs and terminals 20
- 21. Legacy Data Concerns • File-based systems may have several programs accessing and modifying incompatible data files • It would be common to move from a file-based system to a database management system (DBMS) • It is possible that the DBMS itself has become obsolete and needs to be replaced • The DBMS may be incompatible with other database systems used in the business • The teleprocessing monitor used in a transaction processing system may only work with a particular DBMS and mainframe environment 21
- 22. Legacy System Design • Most legacy systems were designed without using object-oriented techniques • A legacy system is not likely to have been designed as a set of interacting objects • A legacy system is more likely to be designed using a function- oriented design strategy • Many software engineering methods and CASE tools support function-oriented design • Function-oriented design is common in MIS applications 22
- 23. A Function-Oriented View of Design Shared m o em ry F1 F2 F3 F4 F5 23
- 24. Functional Design Process • Dataflow Design – used to model information flow • Structural Decomposition – decomposition of functions into sub-functions shown using graphical structure chart that makes use of the input-process-output model • Detailed Design – the entities and their interfaces are recorded in the data dictionary and the processing detail is represented using a program design language (PDL) 24
- 25. Input-Process-Output Model S te ys m In t pu P e roc ss O ut utp 25
- 26. Input-Process-Output • Input Components – read and validate data received file or device • Processing Components – carry out transformations on the input data • Output Components – format and display results of the data transformations • Input, process, and output can be represented as functions with data flowing between them and as a bubble in the dataflow diagram 26
- 27. Using Function-Oriented Design • For some systems (e.g. transaction processing systems) a function-oriented approach may be more natural than an object-oriented approach • Companies with a heavy investment in CASE tools that support function-oriented design may not want to pay the price of moving to an object-oriented approach 27
- 28. Legacy System Assessment • Companies that rely on legacy systems must have a strategy for evolving these systems – scrap the system and modify business practices so it is not needed – continue maintaining the old system – re-engineer the old system to improve maintainability – replace the old system with a new system • The strategy chosen depends on the quality of the system and its business value 28
- 29. Business Value Assessment • Need to take different viewpoints into account – system end-users – business customers – business managers – IT managers – senior management • Process is similar to system feasibility assessment – Interview stakeholders and collate the results 29
- 30. 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 environment? – How costly is it to maintain? • Application Assessment – What is the quality of the application software system? 30
- 31. Business Process Assessment • Interview representatives from each group of stakeholders and ask – Is there a defined process model and is it followed? – Does everyone in the company use the same processes to achieve the same function? – How has the process been adapted to meet local needs? – What are the relationships between this process and other business processes? – Is the process supported effectively by the legacy system? 31
- 32. Environment Assessment • System software or hardware supplier stability • Hardware failure rate • Age of hardware and software • Performance of system • Support requirements for hardware and software • Maintenance costs • Interoperability with other business systems 32
- 33. Application Assessment Factors • Understandability of source code • Documentation quality • Data model (existence and duplication) • Performance • Programming language used • Configuration management controls • Test data existence and regression test results • Team members capable of maintaining application 33
- 34. System Measurement • Collecting quantitative data can help assess the quality of the application – number of system change requests made – number of user interfaces in the system – volume of data used by system – reliability measures – defect detection or removal rates 34
- 35. 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 business value Low quality High quality 2 5 1 3 4 System quality 35
- 36. Legacy System Categories • Low quality, Low business value – scrap the system • Low quality, High business value – should be re-engineered or replaced if a suitable system is available • High-quality, Low business value – replace with COTS, scrap system, or maintain • High-quality, High business value – continue operation using normal maintenance practices 36
- 37. Learning Outcomes • Definition of a “legacy system” • Risks associated with replacing and risks keeping and maintaining legacy systems • Legacy system assessment • Legacy system architectures 37
- 38. Background Reading • Ian Sommerville: Software Engineering 8 ed. – 2.4 - Legacy Systems – 21.4 - Legacy System Evolution – 13.1- Data Processing Systems – 13.2 - Transaction Processing Systems 38
- 39. Definition • A ‘Legacy System’ refers to any computer system (typically, although not always a mini or mainframe computer system), which has been in existence for a long time. • ‘Legacy Data’ relates to information collected by an organisation, which is of value to that organisation, but which has been created or stored by the use of software and/or hardware that has been rendered outmoded or obsolete. 39
- 40. Background to legacy systems • Software systems are a major investment • Systems may be long lived to obtain return on investment (ROI) and thus become “legacy in nature” • They may be critical for operation of an organisation • Legacy systems may have evolved over many years (customisations) 40
- 41. Socio Technical Systems • Legacy Systems have been called “Socio Technical Systems” – Systems that include technical systems but also operational processes and people who use and interact with the technical system. Socio-technical systems are governed by organizational policies and rules. 41
- 42. Socio Technical System Characteristics • Emergent properties – Properties of system as a whole that depend on the system components and their relationships. • Non-deterministic – Same input does not always produce the same output because system’s behavior is partially dependent on human operators. • Complex relationships with organizational objectives – The extent to which the system supports organizational objectives does not just depend on the system itself. 42
- 43. Examples of Emergent Properties Property Description Volume The volume of a system (the total space occupied) varies depending on how the component assemblies are arranged and connected. Reliability System reliability depends on component reliabilit y but unexpected interactions can cause new types of failure and therefore affect the reliability of the system. Security The security of the system (its ability to resist attack) is a complex property that cannot be easily measured. Attacks may be devised that were not anticipated by the system designers and so may defeat built-in safeguards. Repairabilit y This property reflects how easy it is to fix a problem with the system once it has been discovered. It depends on being able to diagnose the problem, access the components that are faulty and modify or replace these components. Usability This property reflects how easy it is to use the system. It depends on the technical system components, its operators and its operating environment. 43
- 44. Replacing a Legacy System • Risks – Difficulty in obtaining specification of legacy system - to clarify new system features – Changes to business processes may be required - existing BP may have evolved to take account peculiarities of legacy system – Identifying business rules embedded in legacy system and not documented elsewhere – Risks with developing/purchasing new systems 44
- 45. Keeping a Legacy System • Risks associated with maintenance: – Inconsistencies in how parts of system have been implemented/changed over the years. – May use obsolete languages or technologies – Poor system documentation available – Years of maintenance may have made system difficult to understand – Optimisations for space or speed may make system difficult to understand – Use of multiple file structures, data duplication 45
- 46. Dilemma • Businesses with multiple legacy systems face a dilemma – Continue using Legacy systems - increased maintenance costs. – Replace Legacy Systems - costly, risks associated with changing business systems • Alternative is to use modern software engineering techniques to extend lifetime of legacy systems 46
- 47. Legacy System Assessment • Strategies for obtaining best ROI – Scrap Legacy System : system is not making a contribution to business – Continue maintaining system: system is stable and minimal changes being requested – Transform system to improve maintainability: changes are degrading quality and changes are still required – Replace System: modern systems / technology provide a viable cost effective alternative 47
- 48. Legacy System Assessment • Low quality, low business value: Expensive to maintain with low business value so candidates for scrapping. • Low quality, high business value: Expensive to maintain but high business value thus cannot be scrapped. Candidates for system transformation or replacement. • High quality, low business value: Inexpensive to maintain with low business value. Avoid risk of replacement by maintaining or scrapping. • High quality, high business value: Must be kept in operation; high quality so transformation or system replacement not necessary. Maintain system. 48
- 49. Business Value Assessment • Establish business value of legacy system by consulting: – End-users: establish level of system usage and perceived effectiveness. – Customers: establish level of transparency; flexibility; responsiveness; errors – Line managers: Establish benefits to business unit; are costs justified; criticality of system. – IT managers: Establish skills availability; level of resource usage – Senior managers: Establish the level of the systems contribution to the business goals 49
- 50. Business Value Assessment • System usage: if legacy system usage is low then it has a low business value. • Business processes: legacy system may not be flexible in accommodating changing business processes, thus has a low business value • System dependability: if legacy system is unreliable then it has a low business value • System outputs: business depends on legacy system outputs (high business value), if output can be produced in alternate way (low business value) 50
- 51. Environmental Assessment • Supplier stability: Still in existence? Financially stable? Alternate supplier providing system maintenance? • Failure rate: Level of failure (reboot v’s random app failure). Hardware / software failures. • Age: With age comes obsolescence, increased maintenance costs • Performance: Is performance adequate? • Support requirements: Is a high level of support required? Are costs high? • Maintenance costs: Costs of hardware/software maintenance increase with system age. • Interoperability: Are there issues interfacing with other systems 51
- 52. Application Technical Assessment • Clarity of source code (understandable?) • Documentation (consistency, quality) • Data (data model?, level of duplication) • Performance (adequate, poor) • Programming Language (modern/obsolete) • Level of Configuration Management (complete, partial, none) • Test Data ( data & regression test availability) • Personnel Skills (availability?) 52
- 53. Legacy System Components • Legacy systems include software, hardware, data and business processes. • Changes to one part of the system inevitably involve further changes to other components 53
- 54. Legacy System Components • System hardware: Possibly obsolete, • Support software: range of tools, utilities, compilers etc. Possibly obsolete. • Application software: Multiple programs developed at different times. Legacy system may mean the application software system rather than the entire system. • Application data: Data processed by application system. May be large volume of data accumulated over time. May be inconsistent and may be duplicated in different files. 54
- 55. Legacy System Structures (cont) • Business processes: Processes used in the business to achieve some business objective. An example of a business process in an insurance company would be issuing an insurance policy. • Business policies and rules: These are definitions of how the business should be carried out and constraints on the business. Use of the legacy application system may be embedded in these policies and rules. 55
- 56. Legacy System Layers • A legacy system may be viewed as a set of layers • Each layer depends on and interfaces with the layer below • If interfaces are “clean” then “in theory” you should be able to make changes within a layer without affecting other layers. Rare in practice! Business processes Application software Support software Hardware 56
- 57. Legacy System Application Software • Typically a legacy system will consist of multiple application programs. • This is especially true in main-frame based legacy systems (.e.g multiple COBOL programs) • These programs may utilise multiple data files/sources 57
- 58. Utilisation of Databases • Many legacy systems are centralised around a database system. Advantages include: – Availability of logical and physical data models. – Reduce redundancy and data duplication – Easier to assess the impact of system changes – Databases also provide transaction-processing** 58
- 59. Utilisation of Databases (cont) • Legacy DBMS may be obsolete and incompatible with other DBMS’s used by a business. – Hierarchical or Network DBMS are common in mainframe legacy systems. – Optimised for performance not simple data management • Relational DBMS now most effective database management systems for business applications. • Costs of changing to a relational data model are very high. 59
- 60. Case Study 1: • Scenario – A bank needs to handle 1000’s of concurrent updates to database systems from branch terminals and ATM’s – A TP monitor job was to serialise requests, buffer transactions and present them as a serialised list to update the database and confirms the transaction. • e.g IBM CICS, Unix Tuxedo 60
- 61. Case Study 1 (cont) • TP monitor may only work with particular database system. • Migration to new RDBMS may not therefore be feasible. IMPLICATION: Technical limitations on possible migration from legacy system 61
- 62. Case Study 2 • Some times a sales contract can be dependant on supporting a legacy system • Company designs hardware devices to monitor fixed or movable devices. • Contract with major customer – Caveat - requirement to support legacy system delivering reports via satellite feed 62
- 63. Case Study Configuration SMTP Internet HTTP GPRS Email Server Asynchronous Message Monitor Server 34 15 00 34 56 08 63
- 64. Case Study Issues • How do we access satellite feed? – Delivery via SMTP as asynchronous email attachment data packet • Data format – How to decode data packet? Code available? – Any test data to confirm decoding algorithms • Costs? • IMPLICATION: Legacy Systems Integration knowledge can win/lose contracts 64
- 65. Summary • Legacy system: an “old system” still providing essential business services. – Encompass business processes, application software, support software and system hardware. – May be a collection of applications and shared data using files or obsolete database management system • Assess business value and quality of a legacy system hardware/software before decision to replace, transform or maintain the system. – Business value of a system is an assessment of the effectiveness of the system in supporting business goals. – System Quality is determined by business processes, application software and hardware and support software. 65
- 66. A Software Process is A structured set of activities required to develop a software system 66
- 67. Ad hoc Software Development • Developing software without planning for each phase, and without specifying tasks, deliverables, or time constraints. • Relies entirely on the skills and experience of the individual staff for performing the work. • The software process is constantly changed or modified as the work progresses. 67
- 68. Software Process Model A Software process Model which is “an abstract representation of a process. It presents a description of a process from some particular perspective.” It provides guidelines to organize how software process activities should be performed and in what order. 68
- 69. SW Process Models • Waterfall model • Evolutionary models • Component-based development model • Iterative Model 69
- 70. The Waterfall Model • Oldest model, it’s been around since 1970. • Called “Linear Sequential Model”. • Most widely used model for SW engineering • Documentation is produced at each stage. 70
- 71. Phases 1. Requirements analysis and definition 2. System and software design 3. Implementation and unit testing 4. Integration and system testing 5. Operation and maintenance 71
- 72. Waterfall model diagram 72
- 73. Disadvantages • Inflexible partitioning of the project into distinct stages makes it difficult to respond to changing customer requirements. • Only appropriate when the requirements are well- understood and changes will be fairly limited during the design process. • The waterfall model is mostly used for large systems engineering projects. 73
- 74. Evolutionary Models 74
- 75. The Exploratory Model Objective is to work with customers and evolve a final system from an initial outline specification. Should start with well-understood requirements and add new features as proposed by the customer. 75
- 76. The Exploratory Model Concurr ent activities Initial Specification version Outline Intermedia te description Development versions Final Valida tion version 76
- 77. The Exploratory Model • Problems – Lack of process visibility; – Systems are often poorly structured; • Applicability – For small or medium-size interactive systems; – For parts of large systems (e.g. the user interface); – For short-lifetime systems. 77
- 78. The Prototyping Model When a customer defines a set of general objectives for a software but does not identify detailed input, processing, or output requirement. It consists of the iterating phases: 1. Requirements gathering 2. Design and build SW prototype 3. Evaluate prototype with customer 4. Refine requirements 78
- 79. The Prototyping Model 79
- 80. The Prototyping Model • Advantages – Users get a feel for the actual system – Developers get to build something immediately – Specifications can be developed incrementally • Disadvantages – The developer may make implementation compromises in order to get a prototype working quickly. – The process in not visible (few documents that reflect every version of the system) – Systems poorly structured 80
- 81. Component Based Software Engineering (CBSE) • Based on systematic reuse where systems are integrated from existing components. • Process stages – Component analysis; – Requirements modification; – System design with reuse; – Development and integration. • This approach is becoming increasingly used as component standards have emerged. 81
- 82. Component Based Software Engineering (CBSE) Requirements Component Requirements System design specification analy sis modification with reuse Development Sy stem and integ ration validation 82
- 83. Component Based Software Engineering (CBSE) • Advantages: – Reduce amount of software to be developed – Reduce costs and risks – Faster delivery • Disadvantages: – Requirements compromises, system does not meet real needs of users – Limited features 83
- 84. Iterative Models 84
- 85. The Incremental Model Rather than deliver the system as a single delivery, the development and delivery is broken down into increments with each increment delivering part of the required functionality. User requirements are prioritised and the highest priority requirements are included in early increments. Once the development of an increment is started, the requirements are frozen though requirements for later increments can continue to evolve. 85
- 86. The Incremental Model Define outline Assign requirements Design sy stem requirements to increments architectur e Develop sy stem Valida te Integ rate Validate increment increment increment sy stem Final sy stem Sy stem incomplete 86
- 87. The Incremental Model Advantages: • Customer value can be delivered with each increment so system functionality is available earlier. • Early increments act as a prototype to help elicit requirements for later increments. • Lower risk of overall project failure. • The highest priority system services tend to receive the most testing. 87
- 88. The Incremental Model Disadvantages: • Increments should be relatively small (20,000 lines of code) • Can be difficult to map the customer’s requirements onto increments of the right size • Hard to identify common functions 88
- 89. The Spiral Model • Defined by Barry Boehm in his 1988 article A Spiral Model of Software Development and Enhancement. • Process is represented as a spiral rather than as a sequence of activities with backtracking. • Each loop in the spiral represents a phase in the process. • Suitable for large, expensive and complicated projects 89
- 90. The Spiral Model Deter mine objecti ves, Evalua te alterna tives, alterna tives and identify, resolv e risks constr aints Risk anal ysis Risk anal ysis Risk Oper a- anal ysis Pr ototype 3 tional Prototype 2 protoype Risk REVIEW anal ysis Proto- type 1 Requir ements plan Simula tions , models , benchmar ks Life-cy cle plan Concept of Oper a tion S/W requir ements Product design Detailed Requir ement design De velopment plan valida tion Code Unit test Integ ra tion Design V&V Integ ra tion and test plan Plan ne xt phase test Acceptance 90 Service test De velop , verify ne xt-le vel pr oduct
- 91. The Spiral Model • Objective setting – Specific objectives for the phase are identified. • Risk assessment and reduction – Risks are assessed and activities put in place to reduce the key risks. • Development and validation – A development model for the system is chosen which can be any of the generic models. • Planning – The project is reviewed and the next phase of the spiral is planned. 91
- 92. The Spiral Model • Risk driven process model – Different risk patterns can lead to choosing different process models • What is a risk? – Situations or possible events that may cause a project to fail to meet its goal. – Example risks: • Experienced staff leave the project • Hardware which is essential for the system will not be delivered on schedule – (more about risks in Chapter 3) 92
- 93. The Spiral Model Advantages: • Risks are explicitly assessed and resolved throughout the process. • Software engineers can start working on the project earlier rather than wading through a lengthy early design process. 93
- 94. The Spiral Model Disadvantages: • Requires highly skilled people in risk analysis and planning • Requires more time, and is more expensive • Estimates of budget and time are harder to judge at the beginning of the project since the requirements evolve through the process 94