Software Evolution

Evolution

Stage in a software system's life cycle where it is in operational use and is evolving as new requirements are proposed and implemented in the system

Servicing

Software remains useful but the only changes made are those required to keep it operational to reflect changes in the software's environment

Phase-Out

Software may still be used but no further changes are made to it

Change implementation

• Iteration of the development process where the revisions to the system are designed, implemented and tested

• Critical difference is that the first stage of change implementation may involve program understanding especially if the original system developers are not responsible for the change implementation

Program Understanding Phase

Understanding how the program is structured, how it delivers functionality, and how the proposed change might affect the program

Urgent Change Requests

• If a serious system fault has to be repaired to allow normal operation to continue

• If changes to the system's environment have unexpected effects

• If there are business changes that require a very rapid response

Agile Methods

Based on incremental development so the transition from development to evolution is seamless

Evolution

Continuation of development process based on frequent system releases

Automated regression testing

valuable when changes are made to a system

Handover Problems

• Where the development team have used an agile approach but the evolution team is unfamiliar with agile methods and prefer a plan-based approach

• Where a plan-based approach has been used for development but the evolution team prefer to use agile methods

Program evolution dynamics

Study of processes of system change

Lehman's Laws

• Generally applicable to large tailored systems developed by large organisations

• describe a number of insights derived from long-term studies of system evolution.

Conservation of familiarity

-Over the lifetime of a system, incremental change in each release is approximately constant

Continuing growth

-Functionality offered by systems has to continually increase to maintain user satisfaction

Declining quality

-Quality of systems will decline unless they are modified to reflect changes in their operational environment

Feedback System

-Evolution processes incorporate multiagent, multiloop feedback systems and we have to treat them as feedback systems to achieve significant product improvement

Software development and Evolution

Integrated, iterative process that can be represented using a spiral model

Software maintenance

• Modifies the program after being put into use

• used for changing custom software

• does not normally involve major changes to the system's architecture

• Changes are implemented by modifying existing components and adding new components to the system.

Generic Software Products

Said to evolve to create new versions

Maintenance to repair software faults

Changing a system to correct deficiencies in the way meets its requirements

Maintenance to adapt software to a different operating environment

Changing a system so that it operates in a different environment (computer, OS, etc.) from its initial implementation.

Maintenance to add to or modify the system’s functionality

Modifying the system to satisfy new requirements.

Maintenance Costs

• Usually greater than development costs (2* to 100* depending on the application).

• Affected by both technical and non-technical factors.

• Increases as software is maintained.

• Maintenance corrupts the software structure so makes further maintenance more difficult.

• Ageing software can have high support costs

Team Stability

Maintenance costs are reduced if the same staff are involved with them for some time.

Contractual Responsibility

The developers of a system may have no contractual responsibility for maintenance so there is no incentive to design for future change

Staff Skills

Maintenance staff are often inexperienced and have limited domain knowledge.

Program age and structure

As programs age, their structure is degraded and they become harder to understand and change

Maintenance Prediction

concerned with assessing which parts of the system may cause problems and have high maintenance costs

Change Acceptance

depends on the maintainability of the components affected by the change

Implementing changes

degrades the system and reduces its maintainability

Maintenance Costs

depend on the number of changes and costs of change depend on maintainability.

Change prediction

• requires and understanding of the relationships between a system and its environment.

• Tightly coupled systems require changes whenever the environment is changed.

Factors influencing this are:

• Number and complexity of system interfaces;

• Number of inherently volatile system requirements;

• The business processes where the system is used.

Complexity Metrics

• Predictions of maintainability can be made by assessing the complexity of system components

• Studies have shown that most maintenance effort is spent on a relatively small number of system components.

Complexity depends on:

• Complexity of control structures;

• Complexity of data structures;

• Object, method (procedure) and module size.

Process Metrics

• may be used to assess maintainability

• Number of requests for corrective maintenance;

• Average time required for impact analysis;

• Average time taken to implement a change request;

• Number of outstanding change requests

System re-engineering

• Re-structuring or re-writing part or all of a legacy system without changing its functionality

• Applicable where some but not all sub-systems of a larger system require frequent maintenance.

• involves adding effort to make them easier to maintain. The system may be re-structured and re-documented.

Reduced Risk

high risk in new software development. There may be development problems, staffing problems and specification problems.

Reduced Cost

The cost of re-engineering is often significantly less than the costs of developing new software.

Source code translation

Convert code to a new language.

Reverse engineering

Analyse the program to understand it;

Program structure improvement

Restructure automatically for understandability;

Program modularisation

Reorganise the program structure;

Data reengineering

Clean-up and restructure system data.

Cost factors

• The quality of the software to be reengineered.

• The tool support available for reengineering.

• The extent of the data conversion which is required.

• The availability of expert staff for reengineering

Data Clumping

• occur when the same group of data items (fields in classes, parameters in methods) re-occur in several places in a program.

• These can often be replaced with an object that encapsulates all of the data.

Speculative Generality

occurs when developers include generality in a program in case it is required in the future. This can often simply be removed

Low Quality, Low Business Value

These systems should be scrapped.

Low-quality, high-business value

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.

Use of system

If systems are only used occasionally or by a small number of people, they may have a low business value.

Business processes that are supported

A system may have a low business value if it forces the use of inefficient business processes.

System dependability

If a system is not dependable and the problems directly affect business customers, the system has a low business value.

System Outputs

If the business depends on system outputs, then the system has a high business value.

Business Process Assessment

• How well does the business process support the current goals of the business?

• Use a viewpoint-oriented approach and seek answers from system stakeholders

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?