Transcript Software Maintenance

Introduction to Software Evolution
and Maintenance
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.
“Much of the software we depend on today is on average
10 to 15 years old”
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 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 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
SEG4210 - Software Maintenance
5
Types of changes
Repair software faults
• Changing a system to correct deficiencies in the way it
meets its requirements. – corrective maintenance

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

“Reengineering”
“Evolution”
“Maintenance”

Add to or modify the system’s functionality
• Modifying the system to satisfy new requirements. –
perfective maintenance

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

Unstructured code

Insufficient domain knowledge

Insufficient documentation
Maintenance Examples

Y2K
• many, many systems had to be updated
• language analyzers (find where changes need to be made)

Anti-Virus Software
• don't usually have to update software, but must send virus
definitions

Operating System Patching
• Microsoft, Apple, Linux/Unix
• OS is core to use of computer, so it must be constantly
maintained

Commercial Software in General
• customers need to be informed of updates
• updates have to be easily available - web is good tool
Maintenance costs




Usually greater than development costs (2* to
100* depending on the application).
Affected by both technical and non-technical
factors.
Increases as software is maintained.
Maintenance corrupts the software structure so
makes further maintenance more difficult.
Ageing software can have high support costs
(e.g. old languages, compilers etc.).
Maintenance cost factors

Team stability
• Maintenance costs are reduced if the same staff are involved
with them for some time.

Contractual responsibility
• The developers of a system may have no contractual
responsibility for maintenance so there is no incentive to design
for future change.

Staff skills
• Maintenance staff are often inexperienced and have limited
domain knowledge.

Program age and structure
• As programs age, their structure is degraded and they become
harder to understand and change.
Lehman’s laws


After major empirical studies, Lehman and
Belady proposed that there were a number of
‘laws’ which applied to all systems as they
evolved.
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
familiarity
Over the lifetime of a system, the incremental change in each
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
requests
Sommerville, Ch. 21
Impact
analysis
Release
planning
Change
implementation
Fault repair
Platform
adaptation
System
enhancement
System
release
Change implementation
Proposed
changes
Sommerville, Ch. 21
Requirements
analysis
Requirements
updating
Software
development
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
SEG4210 - Software Maintenance
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
SEG4210 - Software Maintenance
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
SEG4210 - Software Maintenance
19
Forward and reverse engineering
and reengineering
“Forward Engineering is the traditional process of moving
from high-level abstractions and logical, implementationindependent 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




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, etc.
Reverse engineering is often the initial activity in a
reengineering project.
System re-engineering



Re-structuring or re-writing part or all of a legacy system
without changing its functionality.
Applicable where some but not all sub-systems
of a larger system require frequent maintenance.
Re-engineering involves adding effort to make them
easier to maintain. The system may be re-structured and
re-documented.
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.
Forward and re-engineering
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
Re-engineered
data
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
Reengineering cost factors




The quality of the software to be reengineered.
The tool support available for reengineering.
The extent of the data conversion which is
required.
The availability of expert staff for reengineering.
• This can be a problem with old systems based on
technology that is no longer widely used.
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
28
Reverse engineering
Reverse engineering

Does not involve any adaptation of the system

similar to reconstruction of a blueprint


Design recovery: result is at higher level of
abstraction
Redocumentation: result is at same level of
abstraction
Reengineering (renovation)


Functionality does change
Then reverse engineering step is followed by a
forward engineering step in which the changes
are made
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.
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.
Legacy system evolution

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.

The strategy chosen should depend on the system
quality and its business value.
Key points



Three types of maintenance are bug fixing,
modifying software for a new environment and
implementing new requirements.
For custom systems, maintenance costs usually
exceed development costs.
Lehman’s Laws describe a number of insights
into system evolution.
Key points



The process of evolution is driven by requests
for changes from system stakeholders.
Software re-engineering is concerned with restructuring and re-documenting software to
make it easier to change.
The business value of a legacy system and its
quality should determine the evolution strategy
that is used.