CH 9 Software Evolution

Evolution

The stage in a software system’s life cycle where it is in operational use and is evolving as new requirements are proposed and implemented

Servicing

At this stage, the software remains useful but the only changes made are those required to keep it operational (bug fixes etc), no new functionality is added

Phase-out and Retirement

The software may still be used but no further changes are made to it (have to ‘live with’ any problems)

eventually, the software (and the system it runs on) is taken out of service

Evolution Processes

processes depend on

• type of software being maintained

• the development processes used

• the skills and exp of ppl involved

proposals for change are driver for system evolution

Change Identification and Evolution

depending on organization, the change request process may be informal or formal

General Model of Software Evolution Process

documentation should be updated

new requirements added, analyzed, and validated

Change Implentation

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

critical difference: 1st stage of change imp may involve program understanding, especially if the original system developers are not responsible for the change implementation

Urgent Change Request

urgent changes may have been implemented without going through all the stages of the software engineering process

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

Legacy Systems (LS)

older systems that rely on languages and tech that are no longer used for new systems development

replacing LS is expensive and risky

Legacy Systems Assessment Categories

Low-quality, high-business value: should be re-engineering or replaced is suitable system is available

Low-quality, low-business value: should be scrapped

High-quality, low-business value: replace with COTS, scrap completely or maintain

High-quality, high-business value: continue in operation using normal system maintenance

Assessing Business Value

The use of the system: lower use = low business value

the business processes that are supported: LBV if it forces the use of inefficient business processes

system dependability: if not dependable and directly affects customers, LBV

the system outputs: if depends on system outputs, then the system had HBV

Environmental Assessment Factors

supplier stability, failure rate, age, performance, support requirements, maintenance costs, interoperability

Application Assessment Factors

understandability, documentation, data, performance, programming language, configuration management, test data, personnel skills

System Measurement

number of system change requests: higher value = lower sys quality

number of different user interfaces used by system: more interfaces = more inconsistencies and redundancies

volume of data used by the system: as the volume of data processed by the system increases, so too do the inconsistencies and errors in that data

cleaning up old data is a very expensive and time consuming process

Types of Maintenance

to repair SW faults, to adapt SW to a different operating environment, to add or to modify the system’s functionality

Maintenance Cost Factors

team stability, contractual responsibility, staff skills, program age and structure

Maintenance Costs

it is usually more expensive to add new features to a system during maintenance than it is to add the same features during development

Maintenance Prediction

assess which parts of the system may cause problems and have higher maintenance costs

costs depend on maintainability and number of changes

Change Prediction

predicting the number of changes requires an understanding of relationships between system and its environment

factors include number and complexity of sys interfaces, number of inherently volatile sys req, business processes where system is used

Process Metrics

process measurements may be used to assess maintainability

• number of requests for corrective maintenance

• average time req for impact analysis

• average time taken to implement a change request

• number of outstanding change requests

if any of these increase, there may be a decline in maintainability

SW Re-engineering

restructuring or rewriting part or all of a legacy system without changing its functionality

takes place after a system has been maintained for some time and maintenance costs are increasing

pros: reduced risk and cost

Re-engineering Approaches

organized from lower to higher cost options

cost factors

• quality of software

• tool support available

• extent of the data conversion

• availability of expert staff

Refactoring

process of making improvements to a program to slow down degradation through change (preventative maintenance)

should not add functionality, concentrate on improvement

continuous process of improvement throughout the development and evolution process

“Bad Smells”

duplicate code, long methods, switch (case) statements, data clumping, speculative generality