CH-1: Software Evolution and maintenance concepts

 Software maintenance involves the process of updating, fixing, and improving software systems after they have
been deployed.
 The concept of software evolution means a continual change from a lesser, simpler, or worse state to a higher
or better state.
 Software maintenance and software evolution are closely related concepts but they have distinct focuses.
 All support activities carried out after delivery of software are put under the category of
maintenance.
 Goals: primary aims to ensures the software continues to function correctly, meets current user needs, and operates
within new environment
 a border concept that encompasses the overall process of software development and change over time
including maintenance, upgrades, and reengineering.
 Goal: aims to adopt to changing requirement, technologies, and business environment, often involves significant
architectural changes or rethinking of software.
 …

Key differences
Scope: maintenance is a subset of evolution; evolution includes all aspects of software change, includes
maintenance.
Perspective: maintenance is often reactive (fixing issues) while evolution is more proactive( planning for future
needs and improvement)
Evolution: is about long-term growth and adaptability, while maintenance is about keeping the software
functional and efficient in the short term. Both are crucial for a software system's success over its lifecycle.
 Software Evolution

¨ Fundamental work in the field of software evolution was done by Lehman and
his collaborators.
¨ Based on empirical studies, Lehman and his collaborators formulated some observations
and they introduced them as laws of evolution.
¨ The “laws” themselves have “evolved” from three in 1974 to eight by 1997.
¨ Those laws are the results of studies of the evolution of large-scale proprietary
or closed source software (CSS) systems.
¨ The laws concern a category of software systems called E-type systems.
¨ E-type systems, or "evolving-type systems," refer to a category of software that is
particularly complex and subject to continual change over time.
¨ The eight laws are briefly explained as follows:
 Software Evolution…

1. Continuing change: Software must continually change to remain useful and

relevant.
2. Increasing complexity: As software systems evolve, their complexity tends to
increase unless managed carefully.
3. Self-regulation: The evolution of software is often regulated by user
requirements and market demands.
4. Conservation of organizational stability: Organizations need to maintain a
balance between software changes and operational stability.
 Software Evolution…

4. Conservation of familiarity: emphasizing the importance of user familiarity with software

systems. Changes that significantly alter the user interface or functionality can lead to
confusion and reduce productivity. The Law of Conservation of Familiarity underscores
the importance of keeping user experience in mind during software evolution
6. Continuing growth: The size of a software system will continue to grow unless
actively controlled.
7. Declining quality: Unless the design of a system is diligently fine-tuned and
adapted to new operational environments, the system’s qualities will be
perceived as declining over the lifetime of the system.
8. Feedback system: The behavior of software is influenced by external feedback,
such as user interactions and system performance. Effective feedback mechanisms
can help guide future evolution.
 Software Maintenance

 There are defects in delivered software applications, because defect removal

and quality control processes are not perfect.
 Therefore, maintenance is needed to repair those defects in released software.
 E. Burton Swanson initially defined three categories of software maintenance activities,
namely, corrective, adaptive, and perfective.
 Those definitions were later incorporated into the standard software
engineering–software life cycle processes–Maintenance and introduced a fourth
category called preventive maintenance.
 some researchers and developers view preventive maintenance as a subset of perfective
maintenance.
 Software Maintenance…

Types of Maintenance:
¨Corrective: ¨Adaptive:
¨ Definition: Involves fixing defects or bugs in the ¨ Definition: Involves modifying the software to
software. work in a new or changed environment.
¨ Purpose: To ensure that the software performs as ¨ Purpose: To accommodate changes such as new
expected and to resolve issues reported by users hardware, operating systems, or compliance with
new regulations.

¨Perfective:  Preventive:
¨ Definition: Focuses on improving the performance ¨ Definition: Involves making changes to the
or efficiency of the software. Change in software to prevent future issues or failures.
requirement ¨ Purpose: To anticipate potential problems and
¨ Purpose: To enhance features, improve usability, mitigate risks before they affect the system.
or optimize the system based on user feedback and ¨ Example, dealing with legacy system
performance metrics.
 Software Maintenance…

 Swanson’s classification of maintenance activities is intention based because

the maintenance activities reflect the intents of the developer to carry out
specific maintenance tasks on the system.
 In the intention-based classification of maintenance activities, the intention of
an activity depends upon the motivations for the change.
¨ Activities to make corrections: If there are difference between the expected behavior of a
system and the actual behavior, then some activities are performed to eliminate or reduce
the difference.
¨ Activities to make enhancements: A number of activities are performed to implement a
change to the system, thereby changing the behavior or implementation of the system.
 Software Maintenance…

This category of activities is further refined into three subcategories:

 Enhancements that modify existing requirements;

 Enhancements that create new requirements; and

 Enhancements that modify the implementation without changing the requirements.

 Software Maintenance…

 Component based software systems (CBS): New components are developed by combining
Commercial Off-the-Shelf (COTS) software refers to ready-made software products that are available for sale
to the general public, custom-built (in-house) components, and open source software components.
¨ The major differences between component-based software systems (CBS) and custom-built
software systems:
¨ Skills of system maintenance teams: Maintenance of CBS requires specialized skills to monitor and integrate
COTS products.
¨ Infrastructure and organization: Running a support group for in-house products is necessary to manage a large
product.
¨ COTS maintenance cost: This cost includes the costs of purchasing components, licensing components,
upgrading components, and training maintenance personnel.
¨ Larger user community: COTS users are part of a broad community of users, and the community of users can
be considered as a resource, which is a positive factor.
 Software Maintenance…

¨ Modernization: the processes and strategies used to update, improve, or transform software applications to
meet current business needs, technological standards, and user expectations. CBS require high efforts to
modernize than custom-built (in-house) components.
¨ Split maintenance function: refers to the practice of separating the maintenance tasks into different functions or
responsibilities. Including modularity, separation of concern, and version control. In this case component based
software is more suitable for maintenance because it support modularity and separation of concern.
 SOFTWARE EVOLUTION MODELS AND PROCESSES

¨ Software maintenance should have its own software maintenance life cycle (SMLC) model.
¨ A number of SMLC models with some variations are available in literature. Three common features of the
SMLC models found in the literature are:
¨ Understanding the code;
¨ Modifying the code; and
¨ Revalidating the code.
¨ Other models view software development as iterative processes and based on the idea of change mini-cycle as
explained in the following:
¨ Iterative models: Systems are constructed in builds, each of which is a refinement of requirements of
the previous build. A build is refined by considering feedback from users.
¨ Change mini-cycle models: These models consist of five major phases: change request, analyze and
plan change, implement change, verify and validate, and documentation change.
¨ In this process model, several important activities were identified, such as program
comprehension, impact analysis, refactoring, and change propagation.
 SOFTWARE EVOLUTION MODELS …

¨ A different kind of software evolution model, called staged model of maintenance and
evolution, has been proposed by Rajlich and Bennett.
¨ The model is descriptive in nature, and its primary objective is to improve the
understanding of how long-lived software evolves.
¨ The model considers four distinct, sequential stages of the lifetime of a system, as explained
below:
1. Initial development: When the initial version of the system is produced, detailed knowledge about the
system is fresh. Before delivery of the system, it undergoes many changes. Eventually, a system architecture
emerges and soon it stabilizes.
2. Evolution: Significant changes involve higher cost and higher risk. In the period immediately following
the initial delivery, knowledge about the system is still almost fresh in the minds of the developers.
 In general, for many systems, their lifespan are spent in this stage, because the systems continue to be of
importance to the organizations.
 SOFTWARE EVOLUTION MODELS …

3. Servicing: When the knowledge about the system has significantly decreased, the developers mainly focus
on maintenance tasks, such as fixing bugs, whereas architectural changes are rarely effected.
4. Phase out: When even minimal servicing of a system is not an option, the system enters its very final
stage. The organization decides to replace the system for various reasons:
(i) it is too expensive to maintain the system; or
(ii) there is a newer solution available.
 SOFTWARE EVOLUTION MODELS …

 Software Maintenance Standards: A well-defined process for software maintenance can be

observed and measured, and thus improved.
 IEEE and ISO have both addressed s/w maintenance processes.
 IEEE/EIA 1219 and ISO/IEC 14764 as a part of ISO/IEC12207 (life cycle process).
 IEEE/EIA 1219 organizes the maintenance process in seven phases:
 Problem identification, Analysis, Design, Implementation, System test, Acceptance
test and Delivery.
 for each phase, the standard identifies the input and output deliverables, the supporting processes and
the related activities, and a set of evaluation metrics.
 SOFTWARE EVOLUTION MODELS …

 Software Configuration Management: Configuration management (CM) is the discipline of

managing, tracking, and controlling changes in the evolution of software systems.
 The goal of CM is to manage and control the various extensions, adaptations, and corrections
that are applied to a system over its lifetime.
 A SCM system has four different elements, each element addressing a distinct user need as
follows:
 Identification of software configurations: This includes the definitions of the different artifacts,
their baselines or milestones, and the changes to the artifacts.
 Control of software configurations: controlling the ways artifacts or configurations are altered
with the necessary technical and administrative support.
 Auditing software configurations: Making the current status of the software system in its life cycle
visible to management and determining whether or not the baselines meet their requirements.
 Accounting software configuration status: providing an administrative history of how the
 REENGINEERING

 Reengineering in the context of software refers to the process of redesigning and restructuring existing
software systems to improve their performance, maintainability, and adaptability. This practice is often
employed to update legacy systems, enhance functionality, or align software with changing business
requirements
 To a large extent, software evolution can be seen as repeated software reengineering.
 Reengineering includes some kind of reverse engineering activities to design an abstract view of a given
system.
 The new abstract view is restructured, and forward engineering activities are performed to implement the
system in its new form.
 The aforementioned process is captured by Jacobson and Lindst¨orm with the following expression:
 Reengineering = Reverse engineering+Δ+Forward engineering.
 REENGINEERING…

¨ The first element “Reverse engineering” is the activity of defining a more abstract and easier
to understand representation of the system.
¨ For example, the input to the reverse engineering process is the source code of the system, and the output is
the system architecture.
¨ The core of reverse engineering is the process of examination of the system, and it is not a process of
change.
¨ The third element “forward engineering” is the traditional process of moving from a high-
level abstraction and logical, implementation-independent design to the physical
implementation of the system.
 The second element “Δ” captures alterations performed to the original system.
 LEGACY SYSTEMS

¨ A legacy software system is an old program that continues to be used because it still meets
the users’ needs, in spite of the availability of newer technology or more efficient
methods of performing the task.
¨ It is the phase out stage of the software evolution model of Rajlich and Bennet described
earlier.
 There are a number of options available to manage legacy systems. Typical solution include:
 Freeze: The organization decides no further work on the legacy system should be performed.
 Outsource: engage with third-party vendors that specialize in legacy systems management to provide support.
Modernization or migration services.
 LEGACY SYSTEMS…

 Carry on maintenance: Despite all the problems of support, the organization decides to carry on maintenance
for another period.
 Discard and redevelop: Throw all the software away and redevelop the application once again from scratch.
 Wrap: It is a black-box modernization technique – surrounds the legacy system with a software layer that
hides the unwanted complexity of the existing data, individual programs, application systems, and
interfaces with the new interfaces.
 Migrate: Legacy system migration basically moves an existing, operational system to a new platform, retaining
the legacy system’s functionality and causing minimal disruption to the existing operational business
environment as possible.
 IMPACT ANALYSIS

¨ Impact analysis is the task of estimating the parts of the software that can be affected if a
proposed change request is made.
¨ Impact analysis techniques can be partitioned into two classes:
¨ Traceability analysis: In this approach the high-level artifacts such as requirements, design, code and test
cases related to the feature to be changed are identified.
¨ A model of inter-artifacts such that each artifact in one level links to other artifacts is constructed, which
helps to locate a pieces of design, code and test cases that need to be maintained.
¨ Dependency (or source-code) analysis is a critical practice in software development that involves
examining the relationships between different components, modules, or packages in a software system.
This analysis helps developers understand how changes in one part of the codebase can affect other parts,
facilitating better maintenance, refactoring, and overall system reliability.
¨ The two dependency-based impact analysis techniques are: call graph based analysis and
dependency graph based analysis.
 REFACTORING

 Refactoring: is the process of making a change to the internal structure of software to make it
easier to understand and cheaper to modify without changing its observable behavior.
 It is the object-oriented equivalent of restructuring.
 Refactoring, which aims to improve the internal structure of the code, achieve through the
removal of duplicate code, simplification, making code easier to understand, help to find
defects and adding flexibility to program faster.
 There are two aspects of the above definition:
 It must preserve the “observable behavior” of the software system (through regression).
 To improve the internal structure of a software system (improve maintainability).
 SOFTWARE REUSE

 Software reuse was introduced by Dough McIlroy in his 1968 seminal paper:
¨ The development of an industry of reusable source-code software components and the
industrialization of the production of application software from off-the-shelf components.
¨ Software reuse is using existing artifacts or software knowledge during the construction of a
new software system.
¨ Reusable assets can be either reusable artifacts or software knowledge.
 Capers Jones identified four types of reusable artifacts:
 data reuse, involving a standardization of data formats,
 architectural reuse, which consists of standardizing a set of design and programming
conventions dealing with the logical organization of software,
 design reuse, for some common business applications, and
 program reuse, which deals with reusing executable code.
 SOFTWARE REUSE…

Benefits of Reuse
 Increased reliability
 Reduced process risk
 Increase productivity
 Standards compliance
 Accelerated development
 Improve maintainability
 Reduction in maintenance time and effort