Introduction to Software Evolution
and Maintenance
Importance of evolution
l Organizations have huge investments in their software
systems - they are critical business assets.
l To maintain the value of these assets to the business, they
must be changed and updated.
l The majority of the software budget in large companies is
devoted to evolving existing software rather than
developing new software.
l Studies indicate that up to 75% of all software
professionals are involved in some form of
maintenance/evolution activity.
l “Much of the software we depend on today is on average
10 to 15 years old”
Software change
l Software change is inevitable
• New requirements emerge when the software is used;
• The business environment changes;
• Errors must be repaired;
• New computers and equipment are added to the
system;
• The performance or reliability of the system may have
to be improved.
l A key problem for organizations is implementing
and managing change to their existing software
systems.
Software evolution and software maintenance
l No standard definitions.
l 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
l Narrow definition of evolution: Sometimes, software
evolution is used to refer to the activity of adding new
functionality to existing software.
l Maintenance refers to the activity of modifying software after
it has been put to use in order to maintain its usefulness.
Software Maintenance
“The modification of a software product after
delivery to correct faults, to improve performance or
other attributes, or to adapt the product to a changed
environment”
ANSI/IEEE Standard 729-1983
5
Types of changes
l Repair software faults
• Changing a system to correct deficiencies in the way it
“Maintenance
meets its requirements. – corrective maintenance
l 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. – adaptive maintenance
l Add to or modify the system’s functionality
“Evolution”
• Modifying the system to satisfy new requirements. –
perfective maintenance
“Reengineering
l Improve the program structure and system
performance
• Rewriting all or parts of the system to make it more efficient
”
and maintainable.
Distribution of maintenance
activities
corrective 21%
perfective 50%
adaptive 25%
preventive 4%
Preventive Maintenance
• Preventing failures by fixing defects in advance of
failures
• A kind of perfective maintenance
• Key examples: Y2K and Daylight Savings adjustments
SEG4210 - Software Maintenance 8
Major causes of maintenance
problems
l Unstructured code
l Insufficient domain knowledge
l Insufficient documentation
Maintenance Examples
l Y2K
• many, many systems had to be updated
• language analyzers (find where changes need to be made)
l Anti-Virus Software
• don't usually have to update software, but must send virus
definitions
l Operating System Patching
• Microsoft, Apple, Linux/Unix
• OS is core to use of computer, so it must be constantly
maintained
l Commercial Software in General
• customers need to be informed of updates
• updates have to be easily available - web is good tool
Maintenance costs
l Usually greater than development costs (2* to
100* depending on the application).
l Affected by both technical and non-technical
factors.
l Increases as software is maintained.
Maintenance corrupts the software structure so
makes further maintenance more difficult.
l Ageing software can have high support costs
(e.g. old languages, compilers etc.).
Maintenance cost factors
l Team stability
• Maintenance costs are reduced if the same staff are
involved with them for some time.
l Contractual responsibility
• The developers of a system may have no contractual
responsibility for maintenance so there is no incentive
to design for future change.
l Staff skills
• Maintenance staff are often inexperienced and have
limited domain knowledge.
l Program age and structure
• As programs age, their structure is degraded and
they become harder to understand and change.
Lehman’s laws
l After major empirical studies, Lehman and
Belady proposed that there were a number of
‘laws’ which applied to all systems as they
evolved.
l These are sensible observations rather than
laws. They are applicable to large systems
developed by large organisations. Perhaps less
applicable in other cases.
Lehman’s laws
Law Description
Continuing change A program that is used in a real-world environment necessarily
must change or become progressively less useful in that
environment.
Increasing complexity As an evolving program changes, its structure tends to become
more complex. Extra resources must be devoted to preserving
and simplifying the structure.
Large program evolution Program evolution is a self-regulating process. System
attributes such as size, time between releases and the number of
reported errors is approximately invariant for each system
release.
Organisational stability Over a program’s lifetime, its rate of development is
approximately constant and independent of the resources
devoted to system development.
Conservation of Over the lifetime of a system, the incremental change in each
familiarity release is approximately constant.
Continuing growth The functionality offered by systems has to continually increase
to maintain user satisfaction.
Declining quality The quality of systems will appear to be declining unless they
are adapted to changes in their operational environment.
Feedback system Evolution processes incorporate multi-agent, multi-loop
feedback systems and you have to treat them as feedback
systems to achieve significant product improvement.
The system evolution process
Change Impact Release Change System
equests
r analysis planning implementation er lease
Platform System
Fault repair
adaptation enhancement
Sommerville, Ch. 21
Change implementation
Proposed Requirements Requirements Software
changes analysis updating development
Sommerville, Ch. 21
Software Maintenance Steps 1
Understand the existing system
• Study whatever form of documentation exists about the
system to be modified
—Often the only reliable source of information is the
source code
• Use tools to recover the high-level design models of the
system
Define the maintenance objectives
• Set the requirements
17
Software Maintenance Steps 2
Analysis
• Evaluate alternatives for handling the modification
— Estimate the costs and benefits of the
alternative modifications
— Perform impact analysis
- Determine the effect of the change on the rest of the
system
Design, implement, and test the changes
18
Software Maintenance Steps 3
Revalidate
• Running regression tests to make sure that the
unchanged code still works and is not adversely
affected by the new changes
Train
• Inform users of the changes
Convert and release
• Generate and release/install a new version with the
modified parts
• May involve migrating data at the same time
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
Reverse engineering and Reengineering
l Reverse Engineering
• Analyzing a system to extract information about the
behavior and/or structure
• also Design Recovery - recreation of design abstractions
from code, documentation, and domain knowledge
• Generates:
• structure charts, entity relationship diagrams, DFDs,
requirements models
l Re-engineering
• Examination and alteration of a system to
reconstitute it in another form
• Also known as renovation, reclamation
System Re-engineering
l Re-structuring or re-writing part or all of a
legacy system without changing its
functionality
l Applicable where some but not all sub-systems
of a larger system require frequent
maintenance
l Re-engineering involves adding effort to make
them easier to maintain. The system may be re-
structured and re-documented
When to Re-engineer
l When system changes are mostly confined to
part of the system then re-engineer that part
l When hardware or software support becomes
obsolete
l When tools to support re-structuring are
available
Advantages of reengineering
l Reduced risk
• There is a high risk in new software development.
There may be development problems, staffing
problems and specification problems.
l Reduced cost
• The cost of re-engineering is often significantly less
than the costs of developing new software.
Forward and re-engineering
System Design and New
specifica
tion implementation system
Forward engineering
Existing Understanding and Re-engineere d
software system transfo rmation system
Software re-engineering
The reengineering process
Original Program Modularized Original data
program documentation program
Reverse
engineering
Data
Source code Program re-engineering
translation modularization
Program
structure
improvement
Structured Re-engineered
program data
Sommerville, Ch. 21
Reengineering process activities
l Source code translation
• Convert code to a new language.
l Reverse engineering
• Analyze the program to understand it;
l Program structure improvement
• Restructure automatically for understandability;
l Program modularization
• Reorganize the program structure;
l Data reengineering
• Clean-up and restructure system data.
Sommerville, Ch. 21
Source Code Translation
l Involves converting the code from one
language (or language version) to another e.g.
FORTRAN to C
l May be necessary because of:
• Hardware platform update
• Staff skill shortages
• Organisational policy changes
l Only realistic if an automatic translator is
available
Reverse engineering
l In many legacy systems, the only reliable information
about the system is the source code.
l Reverse engineering reconstructs requirements, design
models, test cases and user documentation consistent
with the current state of the source code.
l Reverse engineering encompasses several activities:
program comprehension, software visualization, etc.
l Reverse engineering is often the initial activity in a
reengineering project.
Reverse Engineering Objectives
Recover lost information:
• Changes made to the system are often
undocumented;
—This enlarges the gap between the design and the
implementation
• Reverse engineering techniques retrieve the lost
information
SEG4210 - Software Maintenance 31
Reverse engineering
Reverse engineering
l Does not involve any adaptation of the system
l similar to reconstruction of a blueprint
l Design recovery: result is at higher level of
abstraction
l Re-documentation
• Creation or revision of alternative representations of
software
• Result is at the same level of abstraction
Reverse engineering
l Restructuring:
l transformation of the system’s code without changing
its behavior
l Functionality does not change
l From one representation to another, at the same level
of abstraction, such as:
• From spaghetti code to structured code
• With platform change: migration
34
Legacy systems
l 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.
l 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.
l Two complementary techniques are employed to support the
continued evolution of legacy systems:
• Reverse engineering.
• Reengineering.
Obsolete system components
l Hardware - may be obsolete mainframe hardware.
l Support software - may rely on support software from
suppliers who are no longer in business.
l Application software - may be written in obsolete
programming languages.
l Application data - often incomplete and inconsistent.
l Business processes - may be constrained by software
structure and functionality.
l Business policies and rules - may be implicit and
embedded in the system software.
Legacy system evolution
l Organisations that rely on legacy systems must choose
a strategy for evolving these systems
• Scrap the system completely and modify business processes so
that it is no longer required;
• Continue maintaining the system;
• Transform the system by re-engineering to improve its
maintainability;
• Replace the system with a new system.
l The strategy chosen should depend on the system
quality and its business value.
Key points
l Three types of maintenance are bug fixing,
modifying software for a new environment and
implementing new requirements.
l For custom systems, maintenance costs usually
exceed development costs.
l Lehman’s Laws describe a number of insights
into system evolution.
Key points
l The process of evolution is driven by requests
for changes from system stakeholders.
l Software re-engineering is concerned with re-
structuring and re-documenting software to
make it easier to change.
l The business value of a legacy system and its
quality should determine the evolution strategy
that is used.
