software evolution_se lect2 btech

SOFTWARE EVOLUTION

1

WHAT ARE LEGACY SYSTEMS?

9

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

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

successful11

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

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

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

Legacy System Structures

1. System Hardware– could be a mainframe

2. System Software

3. Application Software

4. Application Data– business critical data often used by several programs

5. Business Processes– processes that support a business objective and rely on the legacy

systems hardware and software

6. Business Policies and Rules– business operation constraints

15

Legacy System Components

Systemhardware

Businessprocesses

Applicationsoftware

Business policiesand rules

Supportsoftware

Application data

ConstrainsUsesUsesRuns-onRuns-on

Embedsknowledge of

Uses

16

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

Legacy Application System

File 1 File 2 File 3 File 4 File 5 File 6

Program 2Program 1 Program 3

Program 4 Program 5 Program 6 Program 7

18

Database Management System

Program1

Program2

Program3

Program4

Databasemanagement

system

Logical andphysical

data models

describes

19

Transaction Processing

Serialisedtransactions

Teleprocessingmonitor

Accountsdatabase

ATMs and terminals

Account queriesand updates

20

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

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

A Function-Oriented View of Design

F2F1 F3

F4 F5

Shared memory

23

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

Input-Process-Output Model

System

Input Process Output

25

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

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

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

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

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

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

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

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

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

System quality and business value

12

3 45

67

89

10

System quality

Business valueHigh business valueLow quality High business value

High quality

Low business valueLow quality

Low business valueHigh quality

35

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

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

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

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

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

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

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

Examples of Emergent Properties

Property Description

Volume The volume of a system (the total space occupied) varies depending on how thecomponent assemblies are arranged and connected.

Reliability System reliability depends on component reliability but unexpected interactions cancause 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 thatcannot be easily measured. Attacks may be devised that were not anticipated by thesystem designers and so may defeat built-in safeguards.

Repairability This property reflects how easy it is to fix a problem with the system once it has beendiscovered. It depends on being able to diagnose the problem, access the componentsthat are faulty and modify or replace these components.

Usability This property reflects how easy it is to use the system. It depends on the technicalsystem components, its operators and its operating environment.

43

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

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

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


• 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


• 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


• 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 goals49


• 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

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

systems51

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


• Legacy systems include software, hardware, data and business processes.

• Changes to one part of the system inevitably involve further changes to other components

53


• 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

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

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

Hardware56

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

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

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

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

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

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

Case Study Configuration

Internet

GPRS

Monitor Server

34 15 00 34 56 08

Email ServerAsynchronous Message

SMTP

HTTP

63

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

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

A Software Process is

A structured set of activities required to develop a software system

66

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

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

SW Process Models

• Waterfall model• Evolutionary models• Component-based development model• Iterative Model

69

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

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

Waterfall model diagram

Requirements

Operation & Maintenance

Test & Integration

Code & Unit Test

Design

72

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

Evolutionary Models

74

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


Concurrentactivities

ValidationFinal

version

DevelopmentIntermediate

versions

SpecificationInitial

version

Outlinedescription

76


• 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

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 gathering2. Design and build SW prototype3. Evaluate prototype with customer4. Refine requirements

78


79


• 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

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


Requirementsspecification

Componentanalysis

Developmentand integration

System designwith reuse

Requirementsmodification

Systemvalidation

82


• 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

Iterative Models

84

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


Validateincrement

Develop systemincrement

Design systemarchitecture

Integrateincrement

Validatesystem

Define outline requirements

Assign requirements to increments

System incomplete

Finalsystem

86


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


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

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

http://en.wikipedia.org/wiki/Barry_Boehm

The Spiral Model

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2

Prototype 3Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

Code

Unit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternatives,identify, resolve risks

Determine objectives,alternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW

90

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

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

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

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

software evolution_se lect2 btech

Education

system software

legacy system design

legacy system risks

legacy system structures

legacy system replacement

system hardware

system change

system performance