Software Evolution and Maintenance

A Practitioner’s Approach

Chapter 3
Evolution and Maintenance Models
 General Idea

• One traditional software development life cycle (SDLC) is

shown in Figure, which comprises two phases, namely:
– development and
– maintenance
• Maintenance approaching two-thirds of the product life-span.

• The percentages in Figure 3.1 indicate relative costs.

Figure 3.1: Traditional SDLC model ©Wiley, 1988

 General Idea
Software maintenance has unique characteristics:
• Constraints of an existing system: Maintenance is performed on
an operational system. Therefore, all modifications must be
compatible with the constraints of the existing architecture,
design, and code.

• Shorter time frame: A maintenance activity may span from a

few hours to a few months, whereas software development may
span one or more years.

• Available test data: In software development, test cases are

designed from scratch, whereas software maintenance can select
a subset of these test cases and execute them as regression tests.

Software maintenance should have its own Software

Maintenance
Life Cycle (SMLC) model as it involves many unique activities.
 Reuse Oriented Models
• One obtains a new version of an old system by modifying one
or several components of the old system and possibly adding
new components.
• Based on this concept, three process models for maintenance
have
been proposed by Basili:

– Quick fix model: In this model, necessary changes are quickly

made to the code and then to the accompanying
documentation.
– Iterative enhancement model: In this model, first changes
are made to the highest level documents. Eventually, changes
are propagated down to the code level.
– Full reuse model: In this model, a new system is built
from components of the old system and others available in
the repository.
 Reuse Oriented Models
In Quick Fix Model, as illustrated in Figure 3.2
(i) source code is modified to fix the problem;
(ii) necessary changes are made to the relevant documents; and
(iii) the new code is recompiled to produce a new version.
Often changes to the source code are made with no prior
investigation such as analysis of impact of the changes,
ripple effects of the changes, and regression testing.

Figure 3.2 The quick fix model ©IEEE,

1990
 Reuse Oriented Models
Iterative Vs. Incremental
• The terms iteration and increment are liberally used
when discussing iterative and incremental development.
• However, they are not synonyms in the field of
software engineering.
• Iteration implies that a process is basically cyclic, thereby
meaning that the activities of the process are repeatedly
executed in a structured manner.
• Incremental parts of the system are developed at
different times and/or paces, and integrated as they are
completed.
 Reuse Oriented Models
The iterative enhancement model, explained in Figure 3.3, shows how
changes flow from the very top level documents to the lowest-level
documents.
The model works as follows:
• It begins with the existing system’s artifacts, namely, requirements,
design, code, test, and analysis documents.
• It revises the highest-level documents affected by the changes and
propagates the changes down through the lower-level documents.
• The model allows maintainers to redesign the system, based on the analysis
of the existing system.

Figure 3.3 The iterative enhancement model ©IEEE,

1990
 Reuse Oriented Models
• The main assumption in this model is the availability of a
repository
of artifacts describing the earlier versions of the systems.
• In the full reuse model, reuse is explicit and the following
activities are performed:
– identify the components of the old system that are candidates for reuse
– understand the identified system components.
– modify the old system components to support the new requirements.
– integrate the modified components to form the newly developed system.

Figure 3.4 The full reuse model ©IEEE,

1990
Software Stages (staged model)
 Initial Development

• Built system from scratch to satisfy initial system requirements

• This stage is well documented by using different tools and
methods
• The key challenges in this phase are
• System should be easy to understand
• Should be easily extendable for future changes
• The predicated changes should be anticipated in the
design
• The hard problem is copying with unanticipated changes
 Initial Development

• In this phase two things are considered that are team

knowledge and software architecture
• During development team knowledge and expertise in domain
is
very significant for future evolution
• Software architecture should clearly define components and
their properties
• Use of ADLs make software architectures more explicit
 Evolution Stage

• Implement possible major changes to the system according to

new requirements
• Customer demands and competitive pressure also cause evolution
• Sometimes evolution required due to change in
business environment or operating environment
• New functional and nonfunctional requirements in the
system should not corrupt system
 Serving Stage

• Only minor corrections and enhancements

• Senior designers and architects do not need (and are unlikely) to be
available ·
• The staff do not require the same level of domain engineering or
software
engineering expertise
• A typical engineer will be assigned only part of the software to
support,
and thus will have partial knowledge of the system.
• The process is (or should be) now stable, well understood and mature. Its
iterative nature means it is well suited to process improvement, and
measurement.
• Accurate cost prediction is needed.
 Phaseout

• Declining stage
• Company does not provide no more serving
• Try to generate revenue or other benefits from unchanged software
• After some time, it is difficult to return on serving stage because
of large backlog
 Closedown

• Company shuts down the software and directs users for replacement
of system
• Company must carefully plan and organize migration of data to
a new system.
 Staff expertise

Staff expertise is critical during both initial development and

evolution.
The staff must understand
1. the domain
2. solutions to domain problems
3. program properties
4. including software architecture
5. concept location within the code
6. basic computer science principles
Staff expertise is less important during servicing
 Change Mini-Cycle Model

Software change is a process

that may introduce new
requirements to the existing
system, or may need to alter
the software system if
requirements are not correctly
implemented. In order to
capture this, an evolutionary
model known as change mini-
cycle was proposed by Yau et
al. in the late seventies.

Figure 3.8 The change mini-cycle ©Springer,

2008
 Change Request Workflow
• A change request (CR), also called a modification request (MR), is a vehicle
for recording information about a system defect, requested enhancement, or
quality improvement.
• Change requests are placed under the control of a change management system.
• Change management systems control changes by an automated system in the
form of work-flow.
• The basic objective of change management is to uniquely identify, describe,
and track the status of each requested change.
• The objectives of change management are as follows:
• Provide a common method for communication among stakeholders.
• Uniquely identify and track the status of each CR. This feature simplifies
progress reporting and provides better control over changes.
• Maintain a database about all changes to the system. This information can be used for
monitoring and measuring metrics.
 Change Request Workflow
• A change request describes the desires and needs of users which the system is
expected to implement.
• While describing a CR, two factors need to be taken into account:
• Correctness of CRs, and
• Clear communication of CRs to the stakeholders.
• The results of interpreting a CR in different ways are as follows:
• The team carrying out actual changes to the system and the team performing tests
may develop contradicting views about the new system’s quality.
• The changed system may not meet the needs and desires of the end users.
• CRs need to be represented in an unambiguous manner, and made available in
a centralized repository.
• Wide availability of CRs to all the stakeholders is likely to reveal differences
in
interpretations by different groups.
 Change Request Workflow
• The life-cycle of a CR has been illustrated in Figure 3.27, by means of a
state- transition diagram.
• Each state represents a distinct stage in the life-cycle of a CR.
 Summary
• General Idea
• Reuse Oriented Model
• The Staged Model
• Change Mini-Cycle Model
• Change Request Work-Flow