Transcript Introduction to Software Evolution and Maintenance

Introduction to Software Evolution
and Maintenance
Software Evolution
Chapter 1: History and Challenges of Software Evolution
Tom Mens
Software Engineering, 7th Edition
Chapter 21: Software Evolution
Ian Sommerville
Software Evolution
1
Outline



Overview
Software evolution processes
The research landscape
Software Evolution
2
Importance of evolution




Organizations have huge investments in their
software systems - they are critical business
assets.
To maintain the value of these assets to the
business, they must be changed and updated.
The majority of the software budget in large
companies is devoted to evolving existing
software rather than developing new software.
Studies indicate that up to 75% of all software
professionals are involved in some form of
maintenance/evolution activity.
Software Evolution
3
Software change

Software change is inevitable
•
•
•
•
New requirements emerge when the software is used;
The business environment changes;
Errors must be repaired;
New computers and equipment is added to the
system;
• The performance or reliability of the system may have
to be improved.

A key problem for organizations is implementing
and managing change to their existing software
systems.
Software Evolution
4
Types of changes

Repair software faults
• Changing a system to correct deficiencies in the way meets
its requirements.

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.

Add to or modify the system’s functionality
• Modifying the system to satisfy new requirements.

Improve the program structure and system
performance
• Rewriting all or parts of the system to make it more efficient
and maintainable.
Software Evolution
5
Software evolution and
software maintenance


No standard definitions.
Broad definition of evolution: Generally, software evolution refers to
the study and management of the process of making changes to
software over time.
• In this definition, software evolution comprises:
• Development activities
• Maintenance activities
• Reengineering activities


Narrow definition of evolution: Sometimes, software evolution is
used to refer to the activity of adding new functionality to existing
software.
Maintenance refers to the activity of modifying software after it has
been put to use in order to maintain its usefulness.
Software Evolution
6
Types of changes
Repair software faults
• Changing a system to correct deficiencies in the way meets
its requirements.

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.

“Reengineering”
“Evolution”
“Maintenance”

Add to or modify the system’s functionality
• Modifying the system to satisfy new requirements.

Improve the program structure and system
performance
• Rewriting all or parts of the system to make it more efficient
and maintainable.
Software Evolution
7
History

1960s – 1970s
• Inclusion of maintenance in waterfall lifecycle after delivery of the software
product.
• Perception that post-delivery activities only consisted of bug fixes and minor
adjustments.
• Did not account for the need to add functionality due to new and changed
requirements.

1970s
• Lehman postulated the initial laws of program evolution.
• Stressed the need for continuous evolution due to changes in the software’s
operational environment.

Late 1970s – 1980s
• Initial process models that handled change requests.

1990s
• General acceptance of software evolution.
• Development of new process models that accounted for evolution activities:
evolutionary development, spiral model, agile software development.
Software Evolution
8
Outline



Overview
Software evolution processes
The research landscape
Software Evolution
12
Evolution processes

Processes for evolving a software product
depend on
• The type of software being maintained;
• The development processes used;
• The skills and experience of the people involved.

Proposals for change are the drivers for system
evolution. Change identification and evolution
continue throughout the system lifetime.
Sommerville, Ch. 21
Software Evolution
13
Change identification and evolution
Sommerville, Ch. 21
Software Evolution
14
The system evolution process
Change
requests
Sommerville, Ch. 21
Impact
analysis
Release
planning
Change
implementation
Fault repair
Platform
adaptation
System
enhancement
Software Evolution
System
release
15
Change implementation
Proposed
changes
Sommerville, Ch. 21
Requirements
analysis
Requirements
updating
Software Evolution
Software
development
16
Legacy systems

For many systems, the software evolution process is not as straightforward
as described.
• Associated models and documentation of the software may be missing or
hopelessly outdated.
• The new requirements may not be anticipated by the design of the software,
making the resulting changes difficult to implement correctly.

Legacy systems are old systems that have become significantly difficult to
modify.
• Accumulation of changes have eroded the modularity of the original design.
• The documentation has not been maintained and has become obsolete.
• One or more pieces of its underlying technologies have become obsolete.

Two complementary techniques are employed to support the continued
evolution of legacy systems:
• Reverse engineering.
• Reengineering.
Software Evolution
17
Obsolete system components






Hardware - may be obsolete mainframe hardware.
Support software - may rely on support software from
suppliers who are no longer in business.
Application software - may be written in obsolete
programming languages.
Application data - often incomplete and inconsistent.
Business processes - may be constrained by software
structure and functionality.
Business policies and rules - may be implicit and
embedded in the system software.
Software Evolution
18
Forward and reverse engineering
and reengineering
“Forward Engineering is the traditional process of moving from highlevel abstractions and logical, implementation-independent designs
to the physical implementation of a system.”
“Reverse Engineering is the process of analyzing a subject system to
identify the system’s components and their interrelationships and
create representations of the system in another form or at a higher
level of abstraction.”
“Reengineering ... is the examination and alteration of a subject system
to reconstitute it in a new form and the subsequent implementation
of the new form.”
— Chikofsky and Cross
[R.S. Arnold, Software Reengineering, IEEE CS Press, 1993]
Software Evolution
19
Reverse engineering




In many legacy systems, the only reliable information
about the system is the source code.
Reverse engineering reconstructs requirements, design
models, test cases and user documentation consistent
with the current state of the source code.
Reverse engineering encompasses several activities:
program comprehension, software visualization, static
and dynamic slicing, etc.
Reverse engineering is often the initial activity in a
reengineering project.
Software Evolution
20
System reengineering

Rewriting parts or all of a legacy system to make it more
evolvable, so that it can more easily accommodate
future change requests.
• Some authors [e.g., Sommerville] define it more strictly as the
process of restructuring legacy software without changing its
functionality.
• Others include a forward engineering phase as part of
reengineering.


Reengineering is applicable where some but not all subsystems of a larger system require frequent
maintenance.
Reengineering involves adding effort to make them
easier to maintain. The system may be restructured and
redocumented.
Sommerville, Ch. 21
Software Evolution
21
Advantages of reengineering

Reduced risk
• There is a 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.
Sommerville, Ch. 21
Software Evolution
22
The reengineering process
Program
documentation
Original
program
Modularized
program
Original data
Reverse
engineering
Program
modularization
Source code
translation
Data
re-engineering
Program
structure
improvement
Structured
program
Sommerville, Ch. 21
Software Evolution
Re-engineered
data
23
Reengineering process activities

Source code translation
• Convert code to a new language.

Reverse engineering
• Analyze the program to understand it;

Program structure improvement
• Restructure automatically for understandability;

Program modularization
• Reorganize the program structure;

Data reengineering
• Clean-up and restructure system data.
Sommerville, Ch. 21
Software Evolution
24
Outline



Overview
Software evolution processes
The research landscape
Software Evolution
25
Research landscape





Two aspects of software evolution research
Reverse engineering and reengineering
techniques
Techniques for dealing with change
Process and change management
Evolution of software artifacts
Mens & Demeyer, Ch. 1
Software Evolution
26
Two aspects of software evolution

“What and why”
• Focuses on software evolution as a scientific discipline.
• Studies the nature of the software evolution phenomenon to
understand its driving factors.
• Key interests include the formulation and refinement of
fundamental theories and laws of software evolution.

“How”
• Focuses on software evolution as an engineering discipline.
• Studies how to support the daily tasks of the software developer
or project manager.
• Key interests include the development and validation of tools and
techniques to guide, implement and control software evolution.
Mens & Demeyer, Ch. 1
Software Evolution
27
Techniques for dealing with change

Program comprehension
• Understanding the existing program in order to change it.

Change impact analysis
• Identification of the parts of the system that will be affected by a
proposed change.

Change propagation
• Making sure that all affected parts are changed correctly.

Restructuring/Refactoring
• Improving the software structure or architecture without changing
the behavior.

Regression testing
• Efficiently verifying that the change preserved the behavior of
functionalities that should not be impacted.
Mens & Demeyer, Ch. 1
Software Evolution
28
Management

Economics of software evolution
• Developing economic models to support evolution-related
management decisions.
• Comparing the cost of different strategies for changes.
• Assessing the cost-benefits of investing in reengineering.

Software metrics
• Measuring the quality of a change.
• Measuring the degree of modularity.

Configuration management
•
•
•
•
Change management processes.
Management of multiple versions.
Merging versions together.
Release management.
Mens & Demeyer, Ch. 1
Software Evolution
29
Evolution of software artifacts

Requirements evolution
• Managing requirements changes.

Architecture evolution
• Reengineering the architectures of legacy systems.
• Migration to distributed architectures, e.g., service-oriented
architectures.
• Maintenance issues with modern architectures.

Design evolution
• Evolution of design models.

Test case evolution
• Adding and modifying test cases to verify that the system
behavior was changed as intended.

Traceability management
• How to assure the consistency of the different artifacts.
Mens & Demeyer, Ch. 1
Software Evolution
30
Other evolution issues

Data evolution
• Migrating to a new database schema.
• Verifying that the information in the existing databases are
preserved.

Runtime evolution
• How to modify a system without stopping it.
• Encompasses runtime reconfiguration, dynamic adaptation,
dynamic upgrading.

Language evolution
• Dealing with changes in the programming language definition.
• Especially an issue in multi-language systems.
• Designing languages to make them more robust to evolution.
Mens & Demeyer, Ch. 1
Software Evolution
31
Our research interests



Empirical studies of software evolution
Mining software repositories
Semantic change analysis
Software Evolution
32