1 / 24

CS 425/625 Software Engineering

Software Evolution

Based on Chapter 21 of the textbook [SE-8] Ian Sommerville,Software Engineering, 8th Ed., Addison-Wesley, 2006 and on the“Ch21” PowerPoint presentation available at the book’s web-site

November 14, 2007

2 / 24

Outline

Introduction Program Evolution Dynamics Software Maintenance

Overview Prediction

Evolution Processes Legacy Systems

3 / 24

Introduction

Software evolves continuously due to demands for changes: New requirements surface Existing requirements need be modified Errors found need be fixed

In some cases 90% of software costs are evolution costs

When the transition from development to evolution is not smooth, changing software after delivery is called software maintenance

..

4 / 24

.Introduction

A spiral model of development and evolution [Fig. 21.1, SE-8]

Specification Implemention

ValidationOperation

Start

Release 1

Release 2

Release 3

5 / 24

Program evolution dynamics

Law Description

Continuing change A program that is used in a real-world environment necessarilymust change or become progressively less useful in thatenvironment.

Increasing complexity As an evolving program changes, its structure tends to becomemore complex. Extra resources must be devoted to preservingand simplifying the structure.

Large program evolution Program evolution is a self-regulating process. Systemattributes such as size, time between releases and the number ofreported errors is approximately invariant for each systemrelease.

Organisational stability Over a programÕs lifetime, its rate of development isapproximately constant and independent of the resourcesdevoted to system development.

Conservation offamiliarity

Over the lifetime of a system, the incremental change in eachrelease is approximately constant.

Continuing growth The functionality offered by systems has to continually increaseto maintain user satisfaction.

Declining quality The quality of systems will appear to be declining unless theyare adapted to changes in their operational environment.

Feedback system Evolution processes incorporate multi-agent, multi-loopfeedback systems and you have to treat them as feedbacksystems to achieve significant product improvement.

6 / 24

Software Maintenance: Overview….

Software maintenance = the activities of changing the system after it has been delivered

Types of software maintenance: Corrective maintenance: repair of software faults Adaptive maintenance: modification of software due

to changes in the operating environment (hardware, supporting software)

Perfective maintenance: additions to and/or modifications of system functionality due to organizational or business changes

7 / 24

Software Maintenance: .Overview...

Distribution of maintenance effort [Fig. 21.3, SE-8]

Functionalityaddition or

modification(65%)

Fault repair(17%)

Softwareadaptation

(18%)

8 / 24

Software Maintenance: ..Overview..

Software maintenance is a natural continuation of the development process (specification, design, implementation, testing). Hence the term evolution (applied especially when the transition from development is seamless)

Development and maintenance costs vary from application to application

Investing in development leads to reduction of both maintenance costs and overall project costs [slide 9]

9 / 24

Software Maintenance: …Overview.

Costs of development and maintenance [Fig. 21.4, SE-8]

0 50 100 150 200 250 300 350 400 450 500

System 1

System 2

Development costs Maintenance costs

$

10 / 24

Software Maintenance: ….Overview

Why maintenance costs are higher than development costs? Factors: Team stability: development teams break up after

delivery Contractual responsibility: different teams or

organizations have the responsibility for maintenance Staff skills: more experienced software engineers tend

to avoid maintenance Program age and structure: not structured in the first

place, the program copes poorly with changes and its structure degrades

11 / 24

Software Maintenance: Prediction.

Maintenance prediction [Fig. 21.5, SE-7]

Predictingmaintainability

Predicting systemchanges

Predictingmaintenance

costs

What will be the lifetimemaintenance costs of this

system?

What will be the costs ofmaintaining this system

over the next year?

What parts of the systemwill be the most expensive

to maintain?

How many changerequests can be

expected?

What parts of the system aremost likely to be affected by

change requests?

12 / 24

Software Maintenance: .Prediction

Generally, more complex the software, more expensive its maintenance

The relationship between a system and its environment is also important. This relationship is characterized by: Number and complexity of interfaces Number of inherently volatile requirements The business process in which the system is used

Factors used to assess maintainability: Number of requests for corrective maintenance Average time required for impact analysis Average time taken to implement a change Number of outstanding change requests

13 / 24

Evolution Processes..

The evolution process: overview [Fig. 21.7, SE-8]

System releaseplanning

Changeimplementa tion

Systemrelease

Impactanalysis

Changerequests

Adaptivemaintenance

Correctivemaintenance

Perfectivemaintenance

14 / 24

.Evolution Processes.

Change implementation [Fig. 21.8, SE-8]

Requirementsupdating

Softwaredevelopment

Requirementsanalysis

Proposedchanges

15 / 24

..Evolution Processes

Emergency repair [Fig. 21.9, SE-8]. Prompted by: System faults Business changes Environmental changesall requiring urgent treatment.

The dangers of emergency repair: Software becomes inconsistent Changes are not reflected in documentation Software ageing is accelerated by workaround solutions

Modifysource code

Deliver modifiedsystem

Analyzesource code

Changerequests

16 / 24

Legacy Systems: Introduction..

Legacy systems: old computer-based systems still in use by organizations Many of them still business critical Incorporate many changes made over the years Many people have been involved in these changes Replacing legacy systems with new systems is risky,

yet keeping them means new changes become more and more expensive

17 / 24

Legacy Systems: .Introduction.

Risks of replacing a legacy system: Specification is difficult because existing

documentation is typically incomplete Changing business processes (now adjusted to the

system) may entail high costs Undocumented, yet important business rules may be

embedded in the system; a new system may break these rules

The new system may be delivered late, may cost more than expected, and may not function properly

18 / 24

Legacy Systems: ..Introduction Factors that make changes to legacy systems expensive:

In large systems, different parts were implemented by different teams, without consistent programming style

It is difficult to find personnel who knows the obsolete programming languages used in old systems

In may cases the only documentation is provided by the source code; even this may be missing

It is difficult to understand the system given its ad hoc updating over the years

Data used by the system is difficult to understand and manipulate; it can also be obsolete and/or redundant

19 / 24

Legacy system assessment…..

Strategic approaches for dealing with legacy systems: Scrap the system completely

When business practices have changed and no longer depend significantly on the system (they may be supported by new COTS)

Continue to maintain the system The system works well, is fairly stable, and users do not request

many changes Transform the system to improve maintainability

When system quality was affected negatively by changes, yet changes are still required

Replace the system with a new one When obsolete hardware precludes further operation or the new

system can be built at reasonable cost

20 / 24

.Legacy system assessment….

Assessing legacy systems example [Fig. 21.13 SE-8]

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

21 / 24

..Legacy system assessment…

Assessment of legacy systems includes: Business value assessment (subjective). Viewpoints:

End-users: look at system’s functionality and performance Customers: look at the quality of services provided Business managers: assess the usefulness of the system in

terms of business support IT managers: are concerned with the availability of technical

support for the system Senior managers: interested in system’s contribution to the

business goals System quality assessment (next)

22 / 24

…Legacy system assessment..

System quality assessment. Look at all components of the system. Hence: Business process assessment. Possible questions:

Are defined process models and procedures in place? Are processes applied consistently across the company? What adaptations have been made? Are relationships with other business processes necessary? Are processes suitably supported by application software?

Environment assessment: support software & hardware platform (maintenance costs, faults, etc. – slide 23)

Application software assessment. Factors considered as in slide 24 and quantitative data such as:

Number of system change requests Number of different user interfaces Volume of data used by the system

23 / 24

….Legacy system assessment. Factors in environment assessment [Fig. 21.14 SE-8]

Factor QuestionsSupplierstability

Is the supplier is still in existence? Is the supplier financially stable andlikely to continue in existence? If the supplier is no longer in business,are the systems maintained by someone else?

Failure rate Does the hardware have a high rate of reported failures? Does thesupport software crash and force system restarts?

Age How old is the hardware and software? The older the hardware andsupport software, the more obsolete it will be. It may still functioncorrectly but there could be significant economic and business benefitsto moving to more modern systems.

Performance Is the performance of the system adequate? Do performance problemshave a significant effect on system users?

Supportrequirements

What local support is required by the hardware and software? If thereare high costs associated with this support, it may be worth consideringsystem replacement.

Maintenancecosts

What are the costs of hardware maintenance and support softwarelicences? Older hardware may have higher maintenance costs thanmodern systems. Support software may have high annual licensingcosts.

Interoperability Are there problems interfacing the system to other systems? Cancompilers etc. be used with current versions of the operating system? Ishardware emulation required?

24 / 24

…..Legacy system assessment Factors in application software assessment [Fig. 21.15 SE-8]