Legacy system components

Slides:



Advertisements
Similar presentations
Chapter 26 Legacy Systems.
Advertisements

Chapter 26 Legacy Systems.
CIS 376 Bruce R. Maxim UM-Dearborn
Legacy Systems Older software systems that remain vital to an organisation.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 2 Slide 1 Systems engineering 2.
GreenWor ds This Old Application Front-End Quality Management and Your Mission-Critical Fixer-Uppers.
1 / 24 CS 425/625 Software Engineering Software Evolution Based on Chapter 21 of the textbook [SE-8] Ian Sommerville, Software Engineering, 8 th Ed., Addison-Wesley,
Software Evolution Managing the processes of software system change
Dr Kettani, Spring 2002 Software Engineering IIFrom Sommerville, 6th edition Software change l Managing the processes of software system change.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
CSEM01 SE Evolution & Management Anne Comer Helen Edwards
Chapter 2.
Modified from Sommerville’s originalsSoftware Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
Software evolution.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 17 Slide 1 Rapid software development.
Software maintenance Managing the processes of system change.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 1 Chapter 27 Software Change.
Chapter 9 – Software Evolution and Maintenance
Software Evolution Planning CIS 376 Bruce R. Maxim UM-Dearborn.
Software evolution. Objectives l To explain why change is inevitable if software systems are to remain useful l To discuss software maintenance and maintenance.
Software change  Managing the processes of software system change.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 1 Software change l Managing the processes of software system change.
Software Engineering Lecture 20 Software Maintenance.
CS 425/625 Software Engineering Legacy Systems
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 27Slide 1 Software change l Managing the processes of software system change.
Chapter 11 Maintaining the System System evolution Legacy systems Software rejuvenation.
Manag ing Software Change CIS 376 Bruce R. Maxim UM-Dearborn.
Legacy Systems An Introduction. Legacy Systems Why do you think the agents are after his life ??
Chapter 9 – Software Evolution Chapter 9 Software Evolution1.
HNDIT23082 Lecture 06:Software Maintenance. Reasons for changes Errors in the existing system Changes in requirements Technological advances Legislation.
1 Software Maintenance The process of changing the system after it has been delivered and in operation Software change is inevitable –New requirements.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution 2.
Chapter 9 – Software Evolution Chapter 9 Software Evolution130/10/2014.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 21 Slide 1 Software evolution.
Chapter 9 – Software Evolution 1Chapter 9 Software evolution.
Reverse Engineering. Reverse engineering is the general process of analyzing a technology specifically to ascertain how it was designed or how it operates.
Legacy Systems IS301 – Software Engineering Lecture # 24 – M. E. Kabay, PhD, CISSP Dept of Computer Information Systems Norwich University.
Software change Software change is inevitable –New requirements emerge when the software is used –The business environment changes –Errors must be repaired.
© SERG Reverse Engineering (Software Maintenance & Reengineering) Software Maintenance Managing the processes of system change.
Software Development Module Code: CST 240 Chapter 6: Software Maintenance Al Khawarizmi International College, AL AIN, U.A.E Lecturer: Karamath Ateeq.
Laurea Triennale in Informatica – Corso di Ingegneria del Software I – A.A. 2006/2007 Andrea Polini XVI. Software Evolution.
Tutorial 4 IT323.  Q1. As a software project manager in a company that specializes in the development of software for the offshore oil industry, you.
Chapter 9 – Software Evolution
Environment Assessment
Chapter 18 Maintaining Information Systems
Introduction to Software Evolution and Maintenance
Software Maintenance.
Chapter 9 – Software Evolution
Software Maintenance
Chapter 9 – Software Evolution
CS 425/625 Software Engineering Software Evolution
Software Testing and Maintenance Maintenance and Evolution Overview
Legacy Systems Older software systems that remain vital to an organisation.
Chapter 9 – Software Evolution and Maintenance
IS301 – Software Engineering V:
Software Re-Engineering
Program Restructuring
Error Tracking Defect removal efficiency DRE = E / (E+D)
Chapter 27 Software Change.
Lecture 1 File Systems and Databases.
Chapter 9 – Software Evolution
Chapter 8 Software Evolution.
Lecture 06:Software Maintenance
Software Engineering I Session 8
Chapter 9 – Software Evolution
Rapid software development
Chapter 9 – Software Evolution
Software Re-engineering and Reverse Engineering
Presentation transcript:

Legacy system components Support Software uses Application Software Embeds knowledge of Business Rules Runs on Runs on uses uses Constrains System Hardware Application Data Business Processes

Recap

Maintaining Legacy System Maintaining legacy system is expensive. Different parts of the system have been implemented by different teams, lacking consistency. Part or all of the system may be implemented using an obsolete language. System documentation is inadequate and out of date. In some cases the only documentation is the source code. In some cases even the source code is not available

Software Engineering II Lecture 38 Fakhar Lodhi

Maintaining Legacy System Many years of maintenance have usually corrupted the system structure, making it increasingly difficult to understand The data processed by the system may be maintained in different files which have incompatible structures There may be data duplication and the documentation of the data itself may be out of date, inaccurate, and incomplete.

Maintaining Legacy System System Hardware The hardware platform may be outdated and is hard to maintain. In may cases, the legacy systems have been written for mainframe hardware which is no longer available, expensive to maintain, and not be compatible with current organizational IT purchasing policies. Support software OS, database, and compiler etc May be obsolete and no longer supported by the vendors

Legacy migration risks There is rarely a complete specification of the system available. Therefore, there is no straight forward way of specifying the services provided by a legacy system. Important business rules are often embedded in the software and may not be documented elsewhere. Business processes and the way legacy systems operate are often intertwined. New software development may take several years New software development is itself risky Changes to one part of the system inevitably involve further changes to other components

Legacy System Assessment 4 strategic options Scrap the system completely Continue maintaining the system Transform the system in some way to improve its maintainability Replace the system with a new system

Legacy System Assessment Scrap the system completely System is not making an effective contribution to business processes Business processes have changed significantly and the organization is no longer completely dependent upon the system Continue maintaining the system System is still required It is stable Requirements are not changing frequently

Legacy System Assessment Transform the system in some way to improve its maintainability System quality has been degraded Regular changes to the system are required Replace the system with a new system Old system cannot continue in operation Off-the shelf alternative is available or system can be developed at a reasonable cost

Legacy system assessment Assess the system from two different perspectives Business value and quality Important for business Cannot be scrapped Low quality means high operational cost Candidates for system transformation or replacement Must be kept in business High quality means low cost of maintenance Not necessary to transform or replace Continue normal operation High Business Value Keeping these systems in operation will be expensive Rate of return to the business is small Candidates for scrapping Low business value but not very expensive to maintain Not worth the risk of replacing them Should be normally maintained or scrapped Low Low High Quality

Business Value Assessment Subjective judgment Different business viewpoints End-users Customers Line managers IT managers Senior managers

End Users How effective do they find the system in supporting their business processes How much of the system functionality is used

Customers Is the use of the system transparent to customer or are their interaction constrained by the system Are they kept waiting because of the system Do system errors have a direct impact on the customer

IT Managers Are there difficulties in finding people to work on the system Does the system consume resources which could be deployed more effectively on other systems

Line Managers Do managers think that the system is effective in contributing to success of their unit Is the cost of keeping the system in use justified Is the data managed by the system critical for the functioning of the manager’s unit

Senior Managers Does the system and associated business process make an effective contribution to the business goal