0% found this document useful (0 votes)
31 views37 pages

Chapter 7

Uploaded by

Sushant Yadav
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
31 views37 pages

Chapter 7

Uploaded by

Sushant Yadav
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 37

Chapter 7

Software Evolution and


maintenance
Software 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
changing and evolving existing software rather than developing new
software.
• Evolution – The stage in a software system’s life cycle where it is in
operational use and is evolving as new requirements are proposed
and implemented in the system.
Evolution processes
• Software evolution processes 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 driver for system evolution.
– Should be linked with components that are affected by the change,
thus allowing the cost and impact of the change to be estimated.
• Change identification and evolution continues throughout the system
lifetime.
Evolution processes
Program Evolution Dynamics
In 1970 and 1980, Lehman and his collaborators formulated some
observations and they introduced them as laws of evolution. The eight
laws are briefly explained as follows:
1. Continuing change. Unless a system is continually modified to satisfy
emerging needs of users, the system becomes increasingly less useful.
2. Increasing complexity. Unless additional work is done to explicitly
reduce the complexity of a system, the system will become increasingly
more complex due to maintenance-related changes.
3. Self-regulation. The evolution process is self-regulating in the sense
that the measures of products and processes, that are produced during
the evolution. System attributes such as size,time between release etc.
Conti..
4. Organizational stability. The average effective global activity rate on an
evolving system is almost constant throughout the lifetime of the system. In
other words, the average amount of additional effort needed to produce a new
release is almost the same.
5. Conservation of familiarity. As a system evolves all kinds of personnel,
namely, developers and users, for example, must gain a desired level of
understanding of the system’s content and behavior to realize satisfactory
evolution. Large incremental growth in a release reduces that understanding.
Therefore, the average incremental growth in an evolving system remains
almost the same.
6. Continuing growth. As time passes, the functional content of a system is
continually increased to satisfy user needs
Conti…
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 system’s evolution process involves multi-
loop, multiagent, multi-level feedback among different kinds of
activities. Developers must recognize those complex interactions in
order to continually evolve an existing system to deliver more
functionalities and higher levels of qualities.
Software maintenance
• Modifying a program after it has been put into use.
• The term is mostly used for changing custom software. Generic
software products are said to evolve to create new versions.
• Maintenance does not normally involve major changes to the
system’s architecture.
• Changes are implemented by modifying existing components and
adding new components to the system.
Why is Maintenance Required?
• Maintenance to repair software faults
– Changing a system to correct deficiencies in the way meets its
requirements.
• Maintenance to 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.
• Maintenance to add to or modify the system’s functionality –
Modifying the system to satisfy new requirements.
Types of Maintenance

Corrective maintenance −
• Here errors that come up after on-site implementation are fixed.
• The errors may be pointed out by the users themselves.
Preventive maintenance −
• Modifications done to avoid errors in future are called preventive
maintenance.
Types of Maintenance

Adaptive maintenance −
• Changes in the working environment sometimes require modifications
in the software.
• For example, if government education policy changes, corresponding
changes have to be made in student result processing module of school
management software.
Perfective maintenance −
• Changes done in the existing software to incorporate new requirements
from the client is called perfective maintenance.
• Aim here is to be always be up-to-date with the latest technology.
Software maintenance cost factors:
• Complexity of the software system: The more complex the software
system, the more effort and resources will be required to maintain it.
• Size of the software system: The larger the software system, the
more effort and resources will be required to maintain it.
• Number of users: The more users a software system has, the more
effort and resources will be required to maintain it.
• Change rate of the software system: The more frequently the
software system changes, the more effort and resources will be
required to maintain it.
Software maintenance cost factors:
• Availability of personnel: The availability of personnel with the necessary skills and
experience to maintain the software system can affect the cost of maintenance.
• Tools and technologies: The cost of maintenance can be affected by the tools and
technologies used to maintain the software system, such as automated testing tools and
configuration management tools.
• Maintenance plan: Having a clear and well-defined maintenance plan can help to reduce
the cost of maintenance by allowing for more efficient use of resources.
• Age of the software system: Older systems may require more effort to maintain as the
technology may be outdated.
• Type of maintenance: The type of maintenance being performed can also affect the cost, for
example, corrective maintenance is typically less expensive than perfective maintenance.
• Location: The cost of maintenance can be affected by the location of the system and the
cost of labor in that area
Maintenance Effort distribution
• Distribution of Maintenance Effort illustrates that for any software,
the changes are always expected.
• Lifetime of software is elongated when there is high maintainability
thus lowering development risks.
• Maintainability is also considered as a quality attribute that only
focuses on the existing short-range attempts for changes but does not
emphasize on the long-standing conservation of the software.
• For example, the maintainability of a software system can be
enhanced by improving the quality of designs and code but it would
not have any sufficient affect on the capability of the software.
Maintenance Effort distribution
Maintenance Predication
• Unexpected maintenance costs may lead to an unexpected increase in
costs
• It is important to predict the effect of modifications in the software
system.
• Software maintenance prediction refers to the study of software
maintainability, the modifications in the software system, and the
maintenance costs that are required to maintain the software system.
Maintenance Predication
Maintenance Predication
Various predictions are closely related and specify the following.
1.The decision to accept a system change depends on the
maintainability of the system components affected by that change up
to a certain extent.
2.Implementation of changes results in degradation of system structure
as well as reduction in system maintainability.
3.Costs involved in implementing changes depend on the
maintainability of the system components.
Maintenance Predication
The relationship between the system and its external environment should be
properly understood to predict the number of changes requested for a system.
To know the kind of relationship that exists, organizations should assess the
following.
1.Number and the complexity involved in the system interface. More interfaces
mean more complexity, which in turn means more demand for change.
2.Number of system requirements. Changes required in organizational policies
and procedures tend to be more volatile than the requirements based on a
particular domain.
3.Number of business processes in which the system operates. More business
processes implies more demands for system change.
Maintenance Predication
• To predict maintainability of a software system, it is important to consider the
relationship among the different components and the complexity involved in them.
• Generally, it is observed that a software system having complex components is difficult
and expensive to maintain.
• The complexity in a software system occurs due to the size of procedures and
functions, the size and the number of modules, and the nested structures in the
software code.
• On the other hand, a software system developed by using good programming practices
reduces not only the complexity but also the effort required in software maintenance.
• As a result, such software systems minimize the maintenance cost. For maintaining the
individual components in software systems, it is essential to identify the complexity
measurements of components.
Maintenance Predication
After a system has been put into operation, several process metrics are used to predict the
software maintainability
1. Corrective maintenance: Sometimes more errors are introduced rather than being
repaired during the maintenance process. This shows decline in maintainability.
2. Average time required for impact analysis: Before starting the software maintenance
process, it is essential to analyze the impact of modifications in the software system. This is
known as impact analysis, which reflects the number of components affected by the change.
3. Number of outstanding change requests: If the number of outstanding change requests
increases with time, it may imply decline in maintainability.
4. Average time taken to implement a change request: This involves activities· concerned
with making changes to the system and its documentation rather than simply assessing the
components which are affected. If the time taken to implement a change increases, it may
imply a decline in maintainability.
Legacy system
• In software engineering, a legacy system refers to an existing software
application or system that has been in use for a long time and is
considered outdated or no longer actively supported or maintained by
the original developers.
• Legacy systems often have outdated technologies, architectures, and
programming languages that may not be compatible with modern
hardware or software platforms.
Legacy system
Legacy system
Appropriate strategies for evolving legacy system.
1. Scrap the system completely
2. Reengineer the system to improve its maintainability
3. Leave the system unchanged and continue with regular
maintenance
4. Replace all or part of system a new system
Software Re- engineering
• Software reengineering, also known as software reverse engineering,
is the process of analyzing and transforming an existing software
system to improve its quality, maintainability, performance, or other
attributes without changing its external behavior.
• It involves understanding the existing system, its structure, and
functionality and making modifications to enhance it.
Objectives of software reengineering are as follows:

• Understanding the System: The first step in software reengineering is


to gain a comprehensive understanding of the existing system. This
involves examining the codebase, documentation, and any available
artifacts to comprehend how the system works.
• Documentation Improvement: Legacy systems often lack sufficient
documentation, which can make maintenance and further
development challenging. During reengineering, efforts are made to
improve documentation by capturing system specifications,
architectural diagrams, data flow diagrams, and other relevant
information.
Objectives of software reengineering are as follows:

• Code Restructuring: Legacy systems may have poor code quality, lack
of modularity, or design flaws. Reengineering aims to refactor and
restructure the code to improve its readability, maintainability, and
extensibility. This may involve techniques such as identifying and
removing code duplication, improving naming conventions, and
applying design patterns.
• Performance Optimization: Reengineering provides an opportunity to
identify and address performance bottlenecks in the existing system.
This may involve profiling the application, identifying inefficient
algorithms or database queries, and optimizing them to improve
overall performance
Objectives of software reengineering are as follows:

• Technology Upgrade: In some cases, legacy systems may be built on outdated


technologies or platforms that are no longer supported. Reengineering can
involve upgrading or migrating the system to newer technologies to ensure
compatibility, security, and leverage the benefits of modern tools and
frameworks.
• Integration with Modern Systems: Legacy systems may need to integrate with
newer systems or platforms. Reengineering involves modifying the existing
system to facilitate seamless integration with other systems through the use of
APIs, web services, or other integration techniques.
• Compliance and Security: Reengineering can address compliance requirements
and security vulnerabilities by implementing necessary security measures, data
protection mechanisms, and adhering to relevant standards or regulations.
Software Reengineering Process
Software Reengineering Process
1) Source code translation:
Automatic conversion of a program written in one programming
language to another language.
It may be necessary when the original programming language is
obsolete.
Using a translation tool, the program is converted from an old
programming language to a more modern version of the same
language or to a different language e.g FORTRAN to C.
Software Reengineering Process
2) Program structure improvement:
It focuses on the design details of individual modules and on local data
structures defined within modules.
The program is analyzed and modified to make it easier to read and
understand
Software Reengineering Process
3) Program modularization:
Repeated parts of the program are grouped together and redundancy is
removed where ever it is appropriate.
The system that uses several different data stores may be re-factored to
use a single repository.
Software Reengineering Process
4) Data reengineering:
Data reengineering is the process of changing the data structure
organization without changing the data values.
It is necessary because of inconsistent data management. It involves
analysis and reorganizing the data structure (Sometimes data values) in
a program.
Maybe part of the process of migrating from a file-based system to a
DBMS-based system or changing from one DBMS to another.
Different approaches to data reengineering are Data Clean up, Data
extension, and Data migration.
Software Reengineering Process
5) Reverse engineering:
Reverse engineering is the process of deriving the system design and
specification from its source code.
The purpose of reverse engineering is to facilitate the maintenance work by
improving the understandability of a system and to produce the necessary
documents for a legacy system.
In this, the software is analyzed with a view to understanding its design and
specification but may also be used to re-specify a system for re-implementation.
This process is usually completely automatic. The design and specification of a
system may be reverse-engineered so that they can be an input to the
requirement specification process for the replacement of the system.
Configuration Management
• Software Configuration Management(SCM) is a process to
systematically manage, organize, and control the changes in the
documents, codes, and other entities during the Software
Development Life Cycle.
• The primary goal is to increase productivity with minimal mistakes.
Why do we need Configuration
management?
• There are multiple people working on software which is continually updating
• It may be a case where multiple version, branches, authors are involved in a
software configuration project, and the team is geographically distributed and
works concurrently
• Changes in user requirement, policy, budget, schedule need to be
accommodated.
• Software should able to run on various machines and Operating Systems
• Helps to develop coordination among stakeholders
• SCM process is also beneficial to control the costs involved in making changes
to a system
Configuration Management Activities
• Change Management
• Version Management
• System Building
• Release Management

You might also like