SENG 203:Software

Evolution & Maintenance

By
Dr. J.V. Joshua
 Texts

• Software Evolution and Maintenance: A Practitioner’s Approach by

PRIYADARSHI TRIPATHY KSHIRASAGAR NAIK Copyright © 2015 by John
Wiley & Sons, Inc.
• Software Engineering: Theory and Practice 4th edition by Forrest Shull
and Roseanne Tesoriero copyright ©2010 Pearson
• Software Engineering 10th edition by Ian Sommerville, Pearson 2016
 Software
Definition:
• Software is more than just a program code. A program is an
executable code, which serves some computational purpose.
Software is considered to be collection of executable programming
code, associated libraries and documentations. Software, when made
for a specific requirement is called software product.
 Evolution of Software Systems
• In 1965, Mark Halpern introduced the concept of software evolution
to describe the growth characteristics of software
• Later, the term evolution in the context of application software was
widely used
• The concept further attracted the attentions of researchers after
Belady and Lehman published a set of principles determining
evolution of software systems
 Evolution of Software Systems

• some researchers and practitioners used the phrases

“software evolution” and “software maintenance”
interchangeably
 Evolution of Software Systems
• However, key semantic differences exist between the two. The two
are distinguished as follows:
• software maintenance means preventing software from failing to deliver the
intended functionalities by means of bug fixing
• All support activities carried out after delivery of software are put under the category of
maintenance
• software evolution means a continual change from a lesser, simpler, or
worse state to a higher or better state
• All activities carried out to effect changes in requirements are put under the category of
evolution
 Evolution of Software Systems
• maintenance and evolution are generally differentiated as follows:
• Software maintenance primarily means fixing bugs but preserving their
functionalities. Maintenance tasks are planned. Fixing bugs must be done
and is a planned activity
• maintenance means keeping an installed system running with no change to its design
• Generally, maintenance does not involve making major changes to the architecture of
the system
• Evolution of software systems means creating new but related designs from
existing ones.
• The objectives include supporting new functionalities, making the system perform
better, and making the system run on a different operating system. Basically, as time
passes, the stakeholders develop more knowledge about the system.
• Therefore, the system evolves in several ways. As time passes, not only new usages
emerge, but also the users become more knowledgeable
 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 all organizations is implementing and managing change to their
existing software systems
 Evolution of Software Systems
• Exercises:
• Discuss the differences between software evolution and software
maintenance.
• Explain why a software system which is used in a real-world environment
must be changed
• What are some characteristics of maintaining software as opposed to new
software systems?
• What are the attributes that makes software changes inevitable?
 Software Evolution
• Definition:
• The process of developing a software product using software engineering
principles and methods is referred to as software evolution
• This includes the initial development of software and its maintenance and
updates, till desired software product is developed, which satisfies the
expected requirements.
 Evolution of Software Systems
Software evolution is studied with two broad, complementary approaches:

• Explanatory (What/Why):

1. This approach attempts to explain the causes of software evolution,

the processes used, and the effects of software evolution.
2. The explanatory approach studies evolution from a scientific view point.

• Process improvement (How):

1. This approach attempts to manage the effects of software evolution by developing

better methods and tools, namely, design, maintenance, refactoring, and
reengineering.
2. The process improvement approach studies evolution from an engineering view
point.
 SPE Taxonomy
• Lehman proposed an SPE classification scheme to explain the ways in
which programs vary in their evolutionary characteristics
• This leads to identification of three types
• S-type (specified-type)
• P-type (problem-type)
• E-type (embedded-type)
 SPE Taxonomy - S-type
This is a software, which works strictly according to defined specifications and solutions.
The s-type software is least subjected to changes hence this is the simplest of all.
S-type (Specified) programs have the following characteristics:
• All the non-functional and functional program properties, that are important to its stakeholders, are
formally and completely defined.
• Correctness of the program with respect to its formal specification is the only criterion of the
acceptability of the solution to its stakeholders.

Examples of S-type programs:

(i) Calculation of the lowest common

multiple of two integers.

(ii) Perform matrix addition, multiplication,

and inversion.

(iii) Calculator program

Fig S-type programs

 SPE Taxonomy - P-type
• P-type (Problem) program is based on a practical
abstraction of the problem, instead of relying on a
completely defined specification.

Examples:
• A program That play chess.
• Numerical problems, except computations with
integers and rational numbers, are resolved through
approximations

• The P-type program resulting from the changes

cannot be considered a new solution to a new
problem. Rather, it is a modification of the old
solution to better fit the existing problem.

• In addition, the real world may change, hence the

problem changes.

Fig. P-type programs

 SPE Taxonomy - E-type
An E-type (Evolving) program is one that is embedded in the real world and it changes as the
world does. This software has a high degree of evolution as there are various changes in laws,
taxes etc. in the real world situations. For example, Payroll software

• These programs mechanize a human or society

activity, make simplifying assumptions, and
interface with the external world by requiring or
providing services.

• The acceptance of an E-type program entirely

depends upon the stakeholders’ opinion and
judgment of the solution.

Fig E-type programs

 Laws of Software Evolution
• Lehman formulated a set of observations that he called laws of evolution.
• The laws themselves have evolved from three in 1974 to eight by 1997.
• These laws are the results of studies of the evolution of large-scale proprietary or closed
source system (CSS).
• The laws concern what Lehman called E-type systems:

“Monolithic systems produced by a team within an organization that solve a

real world problem and have human users.”

• Lehman’s laws were not meant to be used in a mathematical sense, as, say, Newton’s laws are
used in physics.
• The term “laws” was used because the observed phenomena were beyond the influence of
managers and developers.
• The laws were an attempt to study the nature of software evolutions and the evolutionary
trajectory likely taken by software.
 E-Type software evolution
• Lehman and his colleagues studied large-scale proprietary software system or CSS
and postulated eight laws for evolution of E-type software system:
1. Continuing change
2. Increasing complexity
3. Self-regulation
4. Conservation of organizational stability
5. Conservation of familiarity
6. Continuing growth
7. Declining/Reducing quality
8. Feedback systems
 Laws of Software Evolution
First Law Continuing change: E-type programs must be continually adapted, else they become
progressively less satisfactory.

• Many assumptions are embedded in an E-type program.

• A subset of those assumptions may be complete and valid at the initial release of the product.
• As the application’s environment changes in terms of the number of sophisticated users, a growing
number of assumptions become invalid.
• Consequently, new requirements and new change requests will emerge.
• When the updated and modified program is reintroduced into the operational domain, it continues to
satisfy user needs for a while.
• Next, more changes occur in the operation environment, additional user needs are identified, and
additional change requests are made.
• As a result, the evolution process moves into a vicious cycle.
 Laws of Software Evolution
Second Law Increasing complexity: As an E-type program evolves, its complexity increases unless work
is done to maintain or reduce it.

• As the program evolves, its complexity grows because of the imposition of changes after changes
on the program.
• In order to incorporate new changes, more objects, modules, and sub-systems are added to the
system.
• These changes lead to a decline in the product quality, unless additional work is performed to arrest
the decline.
• The only way to avoid this from happening is to invest in preventive maintenance.
• In preventive maintenance, one spends time to improve the structure of the software without adding
to its functionality.
 Laws of Software Evolution
Third Law Self regulation: The evolution process of E-type programs is self regulating, with the
time distribution of measures of processes and products being close to normal.

• This law states that large programs have a dynamics of their own.
• Attributes such as size, time between releases, and the number of reported faults are
approximately invariant from release to release.
• The various groups within the large organization apply constraining information controls
and reinforcing information controls influenced by past and present performance indicators.
• Their actions control, check, and balance the resource usage, which is a kind of feedback-
driven growth and stabilization mechanism.
• This establishes a self-controlled dynamic system whose process and product parameters
are normally distributed as a result of a huge number of largely independent
implementation and managerial decisions.
 Laws of Software Evolution
Fourth Law Conservation of organizational stability: The average effective global activity rate
in an evolving E-type program is invariant over the product’s lifetime.

• This law suggests that most large software projects work in a “stationary” state, which
means that changes in resources or staffing have small effects on long-term evolution of the
software.

• To a certain extent management certainly do control resource allocation and planning of

activities. However, as suggested by the third law, program evolution is essentially
independent of management decisions..

• Activities during the lifecycle of a system are not exclusively decided

by management, but by a wide spectrum of controls and feedback inputs.
 Laws of Software Evolution
Fifth Law Conservation of familiarity: The average content of successive releases is constant during the
life-cycle of an evolving E-type program.

The law suggests that one should not include a large number of features in a new release without taking
into account the need for fixing the newly introduced faults.

Conservation of familiarity implies that maintenance engineers need to have the same high level of
understanding of a new release even if more functionalities have been added to it.
 Laws of Software Evolution
Sixth Law Continuing growth: To maintain user satisfaction with the program over its
lifetime, the functional content of an E-type program must be continually increased.

• It is important to distinguish this law from the first law which focuses on “Continuing
Change.”
• The first law captures the fact that an E-type software’s operational domain undergoes
continual changes.
• Those changes are partly driven by installation and operation of the system and partly
by other forces.
• An example of other forces is human desire for improvement and perfection.
• These two laws – the first and the sixth – reflect distinct phenomena and different
mechanisms.
• When phenomena are observed, it is often difficult to determine which of the two laws
underlies the observation.
 Laws of Software Evolution
Seventh Law Declining quality: An E-type program is perceived by its stakeholders to have
declining quality if it is not maintained and adapted to its environment.

• This law directly follows from the first and the sixth laws.
• An E-Type program must undergo changes in the forms of adaptations and extensions
to remain satisfactory in a changing operational domain.
• Those changes are very likely to degrade the performance and will potentially inject
more faults into the evolving program.
• In addition, the complexity of the program in terms of interactions between its
components increases, and the program structure deteriorates.
• The term for this increase in complexity over time is called entropy.
• The average rate at which software entropy increases is about 1-3 percent per calendar
year.
 Laws of Software Evolution
Seventh Law Declining quality: An E-type program is perceived by its stakeholders to have
declining quality if it is not maintained and adapted to its environment.

• There is significant decline in stakeholder satisfaction because of growing entropy,

declining performance, increasing number of faults, and mismatch of operational
domains.
• The above factors also cause a decline in software quality from the user’s perspective.
• The decline of software quality over time is related to the growth in entropy associated
with software product aging or code decay.
• Therefore, it is important to continually undertake preventive measures to reduce the
entropy by improving the software’s overall architecture, high-level and low-level
design, and coding.
 Laws of Software Evolution
There are two types of aging in software lifecycles:
• software process execution aging: It manifests in degradation in performance or
transient failures in continuously running the software system,
• software product aging: It manifests in degradation of quality of software code and
documentation due to frequent changes.
The symptoms of Aging in software were:
• Pollution: Pollution means that there are many modules or components in a system
which are not used in the delivery of the business functions of the system.
• Embedded knowledge: Embedded knowledge is the knowledge about the application
domain that has been spread throughout the program such that the knowledge can not
be precisely gathered from the documentation.
• Poor lexicon: Poor lexicon means that the component identifiers have little lexical
meaning or are incompatible with the commonly understood meaning of the
components that they identify.
• Coupling: Coupling means that the programs and their components are linked by an
elaborate network of control flows and data flows.
 Laws of Software Evolution
Code decay

The code is said to have decayed if it is very difficult to change it, as reflected by the
following three key responses:

(i) the cost of the change, which is effective only on the personnel cost for the developers
who implement it;
(ii) the calendar or clock time to make the changes; and
(iii) the quality of the changed software.

It is important to note that code decay is antithesis of evolution in the sense that while the
evolution process is intended to make the code better, changes are generally
degenerative thereby leading to code decay.
 Laws of Software Evolution
Eighth Law Feedback system: The evolution processes in E-type programs constitute multi-
agent, multi-level, multi-loop feedback systems.

The eighth law is based on the observation that evolution process of the E-type software
constitutes a multi-level, multi-loop, multi-agent feedback system:
(i) multi-loop means that it is an iterative process;
(ii) multi-level refers to the fact that it occurs in more than one aspect of the software and
its documentation; and
(iii) a multi-agent software system is a computational system where software agents
cooperate and compete to achieve some individual or collective tasks. Feedback will
determine and constrain the manner in which the software agents communicate among
themselves to change their behavior.