COMP3211
10. Software Evolution
Dr. Max Yu Pei
Intended Learning Outcomes
❖ Upon completion of this lecture, you should be able to
1. understand that software systems have to adapt and evolve if
they are to remain useful and that software change and
evolution should be considered as an integral part of software
engineering;
2. have learned about different types of software maintenance and
the factors that affect the costs of making changes to legacy
software systems.
3. understand the essential functionality that should be provided
by a version control system, and how this is realized in
centralized and distributed systems;
4. understand what is meant by legacy systems and why these
systems are important to businesses;
5. understand how legacy systems can be assessed to decide
whether they should be scrapped, maintained, reengineered, or
replaced;
2
Software Change and Evolution
❖ Software change is inevitable
➢ Errors must be repaired;
➢ The performance or reliability of the system may have to be improved.
➢ The business environment changes;
➢ New computers and equipment is added to the system;
➢ New requirements emerge when the software is used;
❖ The importance of evolution
➢ Software systems are critical business
assets to organizations.
➢ To maintain the value of these assets,
they must be changed and updated.
➢ Most of the software budget in large
companies is devoted to changing and A spiral model of development
evolving existing software rather than and evolution
developing new software.
3
Evolution and Servicing
An alternative view of the software evolution life cycle
❖ Evolution
➢ The software system is in operational use
➢ Significant changes to the architecture and functionality are made
❖ Servicing
➢ The software remains useful
➢ Only small tactical changes are made
❖ Retirement
➢ Only essential changes are made, and users must work around
problems
➢ The software is taken out of use after its data is transferred
4
EVOLUTION PROCESSES
5
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.
➢ bug reports from system stakeholders
➢ requests for adaptation to the new environment
➢ new ideas for software improvement from
the system development team
➢ requests for new requirements
6
A General Model
❖ A general model of the software evolution process
➢ Change implementation
▪ Iteration of the development process where the revisions to
the system are designed, implemented, and tested.
▪ A critical difference between development and evolution is
that the first stage of change implementation may involve
program understanding
7
The Change Management Process
❖ The process of analyzing the costs and benefits of proposed
changes, approving those changes that are cost-effective, and
tracking which components in the system have been changed.
Customer support
Stakeholder
Change Control Board (CCB)
8
Agile Methods and Evolution
❖ Agile methods are based on incremental development so the
transition from development to evolution is a seamless one.
➢ Evolution is simply a continuation of the development process
based on frequent system releases.
➢ Automated regression testing is particularly valuable when
changes are made to a system.
➢ Changes may be expressed as additional user stories.
❖ Handover problems
➢ The development team have used an agile approach, but the
evolution team prefers a plan-based approach
➢ A plan-based approach has been used for development, but the
evolution team prefer to use agile methods.
9
SOFTWARE MAINTENANCE
10
Software Maintenance
❖ Generic software products evolve to create new versions.
❖ Modifying a custom software after it has been put into use is
called software maintenance.
➢ 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.
❖ Types of maintenance
➢ Fault repairs
➢ Environmental adaptation
➢ Functionality addition and modification
11
Maintenance Costs
❖ Usually greater than development costs (2* to 100* depending
on the application).
❖ Increases as software is maintained.
❖ It is usually more expensive to add new features to a system
during maintenance than it is to add the same features during
development
➢ Program maintenance work is unpopular: Maintenance staff are
often inexperienced and have limited domain knowledge.
➢ Separating maintenance and development means there is no
incentive for the development team to write maintainable
software
➢ A new team has to understand the programs being maintained
➢ As programs age, their structure degrades, and they become
harder to change
12
Software Reengineering (1)
❖ Restructuring or rewriting part or all of a legacy system without
changing its functionality—to make them easier to maintain .
➢ Applicable where some but not all sub-systems of a larger
system require frequent maintenance.
❖ Advantages of reengineering over replacement
➢ Reduced risk
➢ Reduced cost
13
Software Reengineering (2)
❖ 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.
❖ Limitations of software reengineering
➢ Converting the programming paradigm is impossible
➢ Major architectural or data management changes are expensive
➢ The resulting system probably is not as maintainable as a new
system
14
Refactoring vs. Re-engineering
❖ Refactoring
➢ A continuous process of improvement throughout the
development and evolution process
▪ When refactoring a program, you should not add functionality
but rather concentrate on program improvement.
▪ “preventative maintenance”
➢ It is intended to avoid the structure and code degradation that
increases the costs and difficulties of maintaining a system.
❖ Re-engineering
➢ It takes place after a system has been maintained for some time
and maintenance costs are increasing
➢ It uses automated tools to process and re-engineer a legacy
system to create a new, more maintainable system.
15
VERSION MANAGEMENT
16
Version Management
❖ The process of keeping track of different versions of software
components or configuration items and the systems in which
these components are used.
➢ Ensures that changes made by different developers to these
versions do not interfere with each other.
➢ Manages codelines and baselines.
▪ A codeline is a sequence of versions of source code with later
versions in the sequence derived from earlier versions.
▪ A baseline specifies the component versions included in a
specific system and the libraries and configuration files, etc.,
used.
17
Codelines and Baselines
❖ The mainline is a sequence of system versions developed from
an original baseline.
18
Version Control Systems
❖ Version control (VC) systems identify, store and control access
to the different versions of components.
❖ There are two types of modern version control system
➢ Centralized systems: There is a single master repository that
maintains all versions of the software components that are being
developed.
▪ Example: Subversion
➢ Distributed systems: Multiple versions of the component
repository exist simultaneously.
▪ Example: Git
❖ Version control systems vs. cloud storage systems
19
Key Features of Version Control Systems
❖ Version and release identification
❖ Change history recording
❖ Support for independent development
❖ Project support
❖ Storage management
20
Project Repository and Private Workspace
❖ The project repository maintains the ‘master’ version of all
components, which is used to create baselines for system
building.
➢ When modifying components, developers copy (check-out)
these from the repository into their workspace and work on
these copies.
➢ When they have finished their changes, the changed
components are returned (checked-in) to the repository.
❖ Centralized vs. distributed
➢ In centralized version control, a private workspace contains only
components from the project repository.
➢ In distributed version control, a private workspace is a clone of
the project repository.
21
Repository Check-in/Check-out
❖ Centralized ❖ Distributed
Workspace
commit update
push pull
pull push
update commit
Workspace
22
Benefits of Centralized vs Distributed VC
❖ Centralized ❖ Distributed
➢ It is easier to learn and set ➢ It provides a backup
up mechanism for the
➢ It takes less time and space repository
to download part of a ➢ It allows for offline working
project ➢ It is faster
➢ Project support is the
default way of working
➢ Working on branches is
easier
➢ Fewer merge conflicts with
other developer’s code
23
Organization of Open-Source Development
❖ Charlie is the integration manager for the open-source system.
1. Alice and Bob work independently on system development and
clone the definitive project repository
2. As well as their private repositories, both Alice and Bob
maintain a public repository on a server that can be accessed
by Charlie. When they have made and tested changes, they
push the changed versions from their private repositories to
their personal public repositories and tell Charlie that these
repositories are available
3. Charlie pulls the changes from
their repositories into his own
private repository for testing
4. Once he is satisfied that the
changes are acceptable,
he then updates the definitive
project repository
24
Branching and Merging
❖ Rather than a linear sequence of versions that reflect changes
to the component over time, there may be several
independent sequences.
➢ At some stage, it may be necessary to merge codeline branches
to create a new version of a component that includes all changes
that have been made.
➢ Depending on the complexity and relation of the changes in
individual branches, merging can be easy or difficult
25
Storage Management
❖ When version control systems were first developed, storage
management was one of their most important functions.
➢ Instead of keeping a complete copy of each version, the system
stores a list of differences (deltas) between one version and
another, because disk space was expensive.
➢ By applying these to a master version (usually the most recent
version), a target version can be recreated.
26
Storage Management in Git
❖ As disk storage is now relatively cheap, Git uses an alternative,
faster approach.
➢ Git does not use deltas but applies a standard compression
algorithm to stored files and their associated meta-information.
➢ It does not store duplicate copies of files. Retrieving a file simply
involves decompressing it, with no need to apply a chain of
operations.
27
LEGACY SYSTEMS
28
Legacy Systems
❖ Older systems that rely on languages and technology that are
no longer used for new systems development.
➢ They are not just software systems but are broader socio-technical
systems that include hardware, software, libraries and other
supporting software and business processes.
29
Legacy System Replacement and Change
❖ Legacy system replacement is risky and expensive
➢ Lack of complete system specification
➢ Tight integration of system and business processes
➢ Undocumented business rules embedded in the legacy system
➢ New software development may be late and/or over budget
❖ Legacy systems are expensive to change
➢ No consistent programming style
➢ Use of obsolete programming languages with few people
available with these language skills
➢ Inadequate system documentation
➢ System structure degradation
➢ Program optimizations may make them hard to understand
➢ Data errors, duplication, and inconsistency
30
Legacy System Management
❖ Organisations that rely on legacy systems must choose a
strategy for evolving these systems
➢ Continue maintaining the system;
➢ Transform the system by re-engineering to improve its
maintainability;
➢ Replace the system with a new system.
➢ Scrap the system completely and modify business processes so
that it is no longer required;
31
Selection of Evolving Strategy
❖ Depends on the system’s business value and its quality.
➢ Business value assessment: Interview stakeholders about
▪ The use of the system
▪ The business processes that are supported
▪ System dependability
▪ The system outputs
➢ System quality assessment:
▪ Assess factors like understandability, documentation, data,
performance, programming language, configuration
management, test data, personnel skills
▪ Consider the number of system change requests, the number
of user interfaces, and the volume of data used by the system
32
Legacy System Categories
❖ Low quality, low business value
➢ Scrap
❖ Low-quality, high-business value
➢ Re-engineer or replace if a suitable system is available.
❖ High-quality, low-business value
➢ Scrap completely or maintain.
❖ High-quality, high business value
➢ Keep in operation with
normal system maintenance.
33
Key Points (1)
❖ Software development and evolution can be thought of as an
integrated, iterative process that can be represented using a spiral
model.
❖ For custom systems, the costs of software maintenance usually
exceed the software development costs.
❖ The process of software evolution is driven by requests for changes
and includes change impact analysis, release planning and change
implementation.
❖ Legacy systems are older software systems, developed using
obsolete software and hardware technologies, that remain useful for
a business.
❖ It is often cheaper and less risky to maintain a legacy system than to
develop a replacement system using modern technology.
34
Key Points (2)
❖ The business value of a legacy system and the quality of the
application should be assessed to help decide if a system should be
replaced, transformed or maintained.
❖ There are 3 types of software maintenance, namely bug fixing,
modifying software to work in a new environment, and
implementing new or changed requirements.
❖ Software re-engineering is concerned with re-structuring and re-
documenting software to make it easier to understand and change.
❖ Refactoring, making program changes that preserve functionality, is
a form of preventative maintenance.
❖ Version management involves keeping track of the different versions
of software components as changes are made to them.
35
END
36