1. 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

2. Outline Overview Software evolution processes The research landscape

3. 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

4. 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

5. 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.
In the narrower sense of the word, “evolution” refers to changes that add functionality to the system.
Software Evolution

6. 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

7. 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.
“Maintenance”
“Evolution”
In the narrower sense of the word, “evolution” refers to changes that add functionality to the system.
“Reengineering”
Software Evolution

8. 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

9. Evolutionary development
Concurrent
activities
Validation
Final
version
Development
Intermediate
versions
Specification
Initial
Outline
description
Software Evolution

10. Spiral model of the software process
Risk
anal
ysis Pr
oto-
type 1
ototype 2
ototype 3
Oper a-
tional pr
oto
ype
Concept of a
tion
Sim
ula
tions
, models
, benchmar ks
S/W r
equir
ements R
ement v
alida
Design
V&V
oduct
design
Detailed
Code
Unit test
Integ
test
Acceptance
Service De
elop
, v
erify ne
xt-le
el pr Ev
alua
te alterna ti
es,
identify
, r
esolv
e risks
Determine objectives,
alternatives, and
constraints
Plan ne
xt phase
and test plan
elopment
plan
ements plan
Life-cy
cle plan
EVI EW
Software Evolution

11. An iterative development process
Validate
increment
Build system
Specify system
Design system
architecture
Define system
deliverables
System
complete?
Integrate
system
Delier final v
YES NO
Software Evolution

12. Outline Overview Software evolution processes The research landscape

13. 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

14. Change identification and evolution
Sommerville, Ch. 21
Software Evolution

15. The system evolution process
Release
planning
Change
implementation
System r
elease
Impact
analysis
equests
Platform
adaptation
enhancement
Fault repair
Sommerville, Ch. 21
Software Evolution

16. Change implementation
Proposed
Requirements
Requirements
Software
changes
analysis
updating
development
Sommerville, Ch. 21
Software Evolution

17. 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

18. 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

19. Forward and reverse engineering and reengineering
“Forward Engineering is the traditional process of moving from high-level 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

20. 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

21. 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 sub-systems 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

22. 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

23. The reengineering process
Reverse
engineering
Program
documentation
Data
re-engineering
Original data
structure
improvement
modularization
Structured
program
Re-engineered
data
Modularized
Original
Source code
translation
Sommerville, Ch. 21
Software Evolution

24. 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

25. Outline Overview Software evolution processes The research landscape

26. 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

27. 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

28. 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

29. Management Economics of software evolution Software metrics
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

30. 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

31. 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

32. Our research interests
Empirical studies of software evolution
Mining software repositories
Semantic change analysis
Software Evolution