Software Evolution

and Maintenance
Lecture 3
Evolution and Maintenance Models

1
Subject Code: SWE3053
Bachelor of Software Engineering (Hons)
Lecturer: Dr. Muhammed Basheer Jasser
 Outline of the Lecture
2
3.1 General Idea
3.2 Reuse Oriented Model
3.3 The Staged Model for CSS
3.4 The Staged Model for FLOSS
3.5 Change Mini-Cycle Model
3.6 IEEE/EIA 1219 Maintenance Process
3.7 ISO/IEC 14764 Maintenance Process
3.8 Change Request Workflow
 3.1 General Idea
3  One traditional software development life cycle (SDLC) is shown in
Figure, which comprises two discrete 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

 3.1 General Idea
4
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.

Therefore, Software maintenance should have its own Software Maintenance Life
Cycle (SMLC) model as it involves many unique activities.
 3.2 Reuse Oriented Models
5
 One obtains a new version of an old system by modifying one or several components of
the old system and possibly adding new components.
 As a consequence, the new system is likely to reuse many components of the old system
 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.
 3.2 Reuse Oriented Models
6 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

 3.2 Reuse Oriented Models
7
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.

 Iterative development is based on scheduling strategies in which time is set aside

to improve and revise parts of the system under development.

 Incremental development is based on staging and scheduling strategies in which

parts of the system are developed at different times and/or paces, and
integrated as they are completed.
 3.2 Reuse Oriented Models
8 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

 3.2 Reuse Oriented Models
9
 Visaggio [5] compared the iterative model and the quick fix model with respect to
maintainability.

 It has been shown that maintainability of systems degrade faster with the quick fix
model.

 In addition, the iterative enhancement model requires more efforts from organizations
to perform maintenance modifications compared to the quick fix model.
 3.2 Reuse Oriented Models (Full Reuse Model)
10  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

 3.3 The Staged Model for CSS
 Rajlich and Bennett have presented a descriptive model of software evolution called the
11 staged model of maintenance and evolution.
 Its primary objective is at improving understanding of how long-lived software evolves, rather
than aiding in its management.

 Their model divides the lifespan of a typical system into five stages:

 Initial development –
 The first delivered version is produced.
 Knowledge about the system is fresh and constantly changing.
 In fact, change is the rule rather than the exception. Eventually, an architecture
emerge and stabilizes.

 Evolution –
 Changes are performed to: add functionalities to meet user expectations, adapt to
new environment, etc..
 Simple changes are easily performed and more major changes are possible too,
although the cost and risk are now greater than in the previous stage.
 Knowledge about the system is still good, although many of the original developers
will have moved on.
 For many systems, most of its lifespan is spent in this phase.
 3.3 The Staged Model for CSS
 Their model divides the lifespan of a typical system into five stages:
12

 Servicing –
 The system is no longer a key asset for the developers, who concentrate mainly
on maintenance tasks rather than architectural or functional change.
 Knowledge about the system has lessened
 The effects of change have become harder to predict. The costs and risks of
change have increased significantly.

 Phase out –
 It has been decided to replace or eliminate the system entirely, either because
the costs of maintaining the old system have become prohibitive or because
there is a newer solution waiting in the pipeline.
 An exit strategy is devised and implemented, often involving techniques such as
wrapping and data migration. Ultimately, the system is shut down.

 Closedown.
 The software is withdrawn from the market, and customers are directed to
migrate to a replacement.
 3.3 The Staged Model for CSS
13

Figure 3.5 The simple staged model for the CSS life cycle ©IEEE, 2000
 3.3 The Versioned Staged Model for CSS
 It has essentially the same stages as found in Simple Staged Model, but separate
14
evolution tracks from the initial development are found in the Versioned Staged Model.

 The evolution process is the backbone of the model. Each evolution track includes
servicing, phaseout, and closedown

 At certain time frames, a version of the software is completed and released to the
customers.

 The evolution of the software does not stop at that point; rather, it continues and
eventually produces the next version.

 The released version is no longer evolved but only serviced

 3.3 The Staged Model for CSS
15
The evolution process is the backbone
of the model.

Figure 3.6 The versioned staged model for the CSS life cycle ©IEEE, 2000
 3.4 The Staged Model for FLOSS (Free Libre Open Source Software)
 Three major differences are identified between CSS systems and FLOSS systems.
16
 First Difference: The availability of releases
 (CSS systems are available to the customers in a running condition after
having been tested enough)
 On the other hand, a FLOSS system is posted on the versioning system
repositories much before the official release.
 In Figure 3.7, the rectangle with the label “Initial development” has been
visually highlighted because it can be the only initial development stage in
the evolution of FLOSS systems. In other words, it does not have any
evolution track for FLOSS system.
 Second Difference: the transition from the evolution to the servicing stage. Figure 3.7 The staged model for
FLOSS system ©ACM, 2007
 Based on empirical studies with some systems that were analyzed, after a
transition from Evolution to Servicing, a new period of evolution was
observed. This possibility is depicted in Figure as a broken arc from the
Servicing stage to the Evolution stage.
 Third Difference: a possibility of a transition from phaseout stage to evolution
stage for FLOSS systems
 In general, the active developers of FLOSS systems get frequently
replaced by new developers.
 Therefore, the dashed line in Figure exhibits this possibility of a transition
from Phaseout stage to Evolution stage.
 3.5 Change Mini-Cycle Model
• Software
17 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.

• The change mini-cycle model consists of five major

phases:
– Change Request,
– analyze and plan change,
– implement change, Figure 3.8 The change mini-cycle
– verify and validate, and
– documentation change.
 3.5 Change Mini-Cycle Model
• Change
18 Request.
• A CR generally originates from the management, users
of the software, or customers.

• A CR may take one of the following two forms:

– Defect report: describes the defect and software system actions
that are out of line with requirements.
– Enhancement request: describes a change to the requirements,
functionality, or quality of the system.

Figure 3.8 The change mini-cycle

 3.5 Change Mini-Cycle Model
• Analyze
19 and plan change.
• Program comprehension and impact analysis are conducted.

• Program comprehension is essential to understanding

which parts of the software will be affected by a CR
– As an example, let us consider the CR “Add a debit card payment.”
In order to change the implementation, the maintenance engineer
must locate those system components that implement the concepts
“debit card,” “payment,” and issued” embedded in the CR.

• Impact analysis is conducted to identify the potential

consequences of a change and estimate the resources needed
to accomplish the change
– a software system is analyzed by maintenance personnel to identify
the software components that will be affected by a CR. Figure 3.8 The change mini-cycle
 3.5 Change Mini-Cycle Model
• Implement
20 change.
• The CR is implemented after the feasibility of a change is
established.

• However, before the implementation of the CR, restructuring

or refactoring of the software is performed in order to
accommodate the requested modification
– restructuring improves the software structure without changing
their behavior

Figure 3.8 The change mini-cycle

 3.5 Change Mini-Cycle Model
• Verify
21and validate.
• The software system is verified and validated in order to
assure that the integrity of the system has not been
compromised

• This activity includes code review, regression testing, and

execution of new tests if necessary
– If the results are unsatisfactory, then the actualization of the request
is rejected which in turn is investigated and further changes are
implemented.

Figure 3.8 The change mini-cycle

 3.5 Change Mini-Cycle Model
• Documentation
22 change.

• In this phase, complete the documentation aspect which

may include updating the requirements, functional
specifications, and design specifications to be consistent
with the code.

• user manuals and installation and troubleshooting guides are

accordingly updated.

Figure 3.8 The change mini-cycle