Download Legacy systems-Methods Of Software Engineering-Lecture Notes and more Study notes Software Engineering in PDF only on Docsity!
Lecture No. 38
Legacy systems
A system is considered to be a legacy system if it has been in operation for many years. A legacy system has many components. These include business processes, business rules, application software, application data, support software, and system hardware. The relationship among these components is shown in the following diagram.
Maintaining Legacy System
Maintaining legacy system is expensive. It is often the case that 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. In most cases 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.
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.
As far as the system hardware is concerned, the hardware platform may be outdated and is hard to maintain. In many 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 includes OS, database, and compiler etc. Like hardware, it may be obsolete and no longer supported by the vendors.
A time therefore comes when an organization has to make this decision whether to keep the old legacy system or to move it to new platform and environment. Moving it to new environment is known as legacy system migration.
Legacy migration risks Legacy system migration however is not an easy task and there are a number of risks involved that need to be mitigated. First of all, 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. Thus, important business rules are often embedded
Support Software
Application Software
Business Rules
System Hardware
Application Data
Business Processes
uses
Runson Runson uses uses Constrains
Embeds knowledge of
Support Software
Application Software
Business Rules
System Hardware
Application Data
Business Processes
uses
Runson Runson uses uses Constrains
Embeds knowledge of
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 as changes to one part of the system inevitably involve further changes to other components.
We therefore need to assess a legacy system before a decision for migration is made.
Legacy System Assessment
For each legacy system, there are four strategic options:
- Scrap the system completely: This is the case when system is not making an effective contribution to business processes and business processes have changed significantly and the organization is no longer completely dependent upon the system.
- Continue maintaining the system: This option is used when system is still required, it is stable, and requirements are not changing frequently
- Transform the system in some way to improve its maintainability: this option is exercised when system quality has been degraded and regular changes to the system are required.
- Replace the system with a new system: this path is taken when old system cannot continue in operation and off-the shelf alternative is available or system can be developed at a reasonable cost.
For these decisions, a legacy system can be assessed from two different perspectives – business value and quality. The following four quadrant assessment matrix can be used for this purpose.
Business Value Assessment
- Important for business
- Cannot be scrapped
- Low quality means high operational cost
- Candidates for system transformation or replacement
- Keeping these systems in operation will be expensive
- Rate of return to the business is small
- Candidates for scrapping
Low High
Low
High
Quality
Business Value
- Must be kept in business
- High quality means low cost of maintenance
- Not necessary to transform or replace
- Continue normal operation
- Low business value but not very expensive to maintain
- Not worth the risk of replacing them
- Should be normally maintained or scrapped
- Important for business
- Cannot be scrapped
- Low quality means high operational cost
- Candidates for system transformation or replacement
- Keeping these systems in operation will be expensive
- Rate of return to the business is small
- Candidates for scrapping
Low High
Low
High
Quality
Business Value
- Must be kept in business
- High quality means low cost of maintenance
- Not necessary to transform or replace
- Continue normal operation
- Low business value but not very expensive to maintain
- Not worth the risk of replacing them
- Should be normally maintained or scrapped
Lecture No. 39
Environment Assessment
The legacy system also needs to be assessed from an environment‘s perspective. This involves looking at the supplier, failure rate, age, performance, support requirements, maintenance cost, and interoperability.
These angles are elaborated in the following paragraph:
Supplier stability: Is the supplier still in existence? Is the supplier financially stable and likely to continue in existence? If the supplier is no longer in business, is the system maintained by someone else?
Failure rate: Does the hardware have a high rate of reported failure? Does the support software crash often and force system restarts?
Age: How old is the hardware and software?
Performance: Is the performance of the system adequate? Do performance problems have a significant effect on system users?
Support requirements: What local support is required by hardware and software? If there are high costs associated with this support, it may be worth considering system replacement?
Maintenance Cost: What are the costs of hardware maintenance and software licenses? Interoperability: Are there problems interfacing the system with other systems? Can compilers etc be used with current versions of the operating system? Is system emulation required?
Application software assessment
The application software is assessed on the following parameters:
Understandability: How difficult is it to understand the software code of the current system? How complex are the control structures that are used?
Documentation: What system documentation is available? Is the documentation complete, consistent, and up-to-date?
Data: Is there an explicit data model for the system? To what extent is data duplicated in different files?
Programming Language: Are modern compilers available for the programming language? Is the language still used for new system development?
Test Data: Does test data for the system exist? Is there a record of regression tests carried out when new features have been added to the system?
Personnel skills: Are there people available who have the skills to maintain the system?
As migration is a very costly and risky business, the decision to migrate the system is made after assessing it from all these angles and it is determined that the time has come to migrate this system and it is worth spending the required amount of money and time for undertaking that effort.
Software Reengineering Software solutions often automate the business by implementing business rules and business processes. In many cases, the software makes the business processes. As these rules and processes change, the software must also change. A time comes when these changes become very difficult to handle. So reengineering is re-implementing legacy systems to make them more maintainable. It is a long term activity.
Software Reengineering Process Model The software reengineering is a non-trivial activity. Just like legacy migration, careful analysis must be carried out before a decision for reengineering is taken. The following process model can be used to reengineer a legacy system.
Inventory analysis Inventory analysis is the first step in the reengineering process. At this stage, inventory of all applications is taken a note of their size, age, business criticality, and current maintainability is made. Inventory should be updated regularly as the status of the application can change as a function of time.
Document restructuring
Document restructuring
Reverse engineering
Code restructuring
Data restructuring
Forward Engineering Inventoryanalysis
Document restructuring
Reverse engineering
Code restructuring
Data restructuring
Forward Engineering Inventoryanalysis
Lecture No. 40
Forward Engineering
At the end forward engineering is carried out. It means incorporating the new business processes and rules in the system. Forward engineering requires application of SE principles, methods, and concepts to re-create an existing application. In most cases forward engineering does not simply create a modern equivalent of an older program, rather new user and technology requirements are integrated into the reengineering effort.
The Economics of Reengineering
As reengineering is a costly and risky undertaking, a cost benefit analysis for the reengineering effort must be carried out.
This analysis is carried out in the following manner.
Let P1 : current annual maintenance cost for an application P2 : current annual operation cost for an application P3 : current annual business value of an application P4 : predicted annual maintenance cost after reengineering P5 : predicted annual operations cost after reengineering P6 : predicted annual business value cost after reengineering P7 : estimated reengineering cost P8 : estimated reengineering calendar time P9 : reengineering risk factor (1.0 is nominal) L : expected life of the system
Now the cost of maintenance is calculated as:
C (^) maintenance = [P3 – (P1 + P2)] x L
Cost of reengineering would then be given by the formula:
C (^) reengineering = [P6 – (P4 + P5) x (L – P8) – (P7 x P9)]
Lecture No. 41
Business Process Reengineering
A concept similar to software reengineering is of business process reengineering (BPR). A business process is ―a set of logically related tasks performed to achieve a defined business outcome‖. It is the way certain business is conducted. Purchasing services and supplies, hiring new employees, paying suppliers are examples of business processes.
For BPR the following process model may be used.
As obvious from the diagram, it starts with the business definition where business goals are identified. The key drivers could be cost reduction, time reduction, quality improvement, and personnel development and empowerment. It may be defined at the business level or for a specific component of the business.
The next step is process identification. At this time processes that are critical to achieving the goals are identified and are ranked by importance, and need for change.
The short listed processes are then evaluated. Existing process is analyzed and measured and process tasks are identified. The cost and time consumed is measured as well as the quality and performance problems are identified.
Then, process specification and design is carried out. Use cases are prepared for each process to be redesigned and a new set of tasks are designed for the processes and then they are prototyped.
A redesigned business process must be prototyped before it is fully integrated into the business.
Based on the feedback the business process is refined.
Business definition
Refinement & instantiation
Process Identification
Process Evaluation
Process Specification
Prototyping
Business definition
Refinement & instantiation
Process Identification
Process Evaluation
Process Specification
Prototyping
Refactoring: Where to Start?
The first question that we have to ask ourselves is: how do you identify code that needs to be refactored? Fowler et al has devised a heuristic based approach to this end known as ―Bad Smells‖ in Code. The philosophy is simple: “if it stinks, change it”.
Bad Smells in Code
They have identified many different types of ―bad smells‖. These are briefly described in the following paragraphs:
Duplicated Code
- bad because if you modify one instance of duplicated code but not the others, you (may) have introduced a bug! Long Method
- long methods are more difficult to understand; performance concerns with respect to lots of short methods are largely obsolete Large Class
- Large classes try to do too much, which reduces cohesion Long Parameter List
- hard to understand, can become inconsistent Divergent Change
- Deals with cohesion; symptom: one type of change requires changing one subset of methods; another type of change requires changing another subset Shotgun Surgery
- a change requires lots of little changes in a lot of different classes Feature Envy
- A method requires lots of information from some other class (move it closer!) Data Clumps
- attributes that clump together but are not part of the same class Primitive Obsession
- characterized by a reluctance to use classes instead of primitive data types Switch Statements
- Switch statements are often duplicated in code; they can typically be replaced by use of polymorphism (let OO do your selection for you!) Parallel Inheritance Hierarchies
- Similar to Shotgun Surgery; each time I add a subclass to one hierarchy, I need to do it for all related hierarchies Lazy Class
- A class that no longer ―pays its way‖. e.g. may be a class that was downsized by refactoring, or represented planned functionality that did not pan out Speculative Generality
- ―Oh I think we need the ability to do this kind of thing someday‖ Temporary Field
- An attribute of an object is only set in certain circumstances; but an object should need all of its attributes
