Software Evolution and BY ASHENAFI C.

APRIL 2024
Maintenance AASTU
 Chapter 2

Evolution and Maintenance

Models
 Introduction
• The traditional software development life cycle (SDLC) comprises two discrete phases,
namely:
• development and

• maintenance

• Maintenance approaching two-thirds of the product life-span.

• The percentages in the Figure indicate relative costs.

Figure: Traditional SDLC model ©Wiley, 1988

 Cont.
• 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 model types

1. Reuse

2. Staged

3. Change Mini Cycle

 1. 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.

• Therefore, 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.
Cont…
• In Quick Fix Model, as illustrated in Figure below.
• source code is modified to fix the problem;

• necessary changes are made to the relevant documents; and

• 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: The quick fix model ©IEEE, 1990

Cont…
• The iterative enhancement model, explained in Figure below, 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: The iterative enhancement model ©IEEE, 1990

Cont…
• 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: The full reuse model ©IEEE, 1990

 Please download and
install the Slido app on
all computers you use

1. Which one is the best

from the 3 maintenance
models? why

ⓘ Start presenting to display the poll results on this slide.

 Please download and
install the Slido app on
all computers you use

1. If you have completed full stack web

project, and you needs to create a mobile
app for this application which model is
best fit? Identify the components reuse
for mobile app?

ⓘ Start presenting to display the poll results on this slide.

 2. The Staged Model for CSS
• Rajlich and Bennett have presented a descriptive model of software evolution
called the 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 four 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 – Simple changes are easily performed and more major changes are possible
too, albeit 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.
 2. The Staged Model for CSS
• 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 and 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.
Cont…

Figure: The simple staged model for the CSS life cycle ©IEEE, 2000
Cont…
• The evolution process is the backbone of the model.

Figure: The versioned staged model for the CSS life cycle ©IEEE, 2000
 The Staged Model for FLOSS
• Three major differences are identified between CSS systems and FLOSS systems.
• In Figure below, 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.
• 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.

• 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.

Figure: The staged model for FLOSS system ©ACM, 2007

 3. 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: The change mini-cycle ©Springer, 2008

 Software Maintenance Standard
• 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.
• ISO/IEC 14764 describes s/w maintenance as an iterative
process for managing and executing software maintenance
activities.
• The activities which comprise the maintenance process are:
• process implementation, problem and modification analysis,
modification implementation, maintenance review/acceptance,
migration and retirement.
• Each of these maintenance activity is made up of tasks. Each
task describes a specific action with inputs and outputs.
 IEEE/EIA 1219 Maintenance Process
• The standard focuses on a seven-phases:
• Problem Identification.
• Analysis.
• Design.
• Implementation.
• System Test.
• Acceptance Test.
• Delivery.
Figure: Seven phases of IEEE
maintenance process ©IEEE, 2004

Each of the seven activities has five associated attributes as follows:

• Activity definition: This refers to the implementation process of the activity.
• Input: This refers to the items that are required as input to the activity.
• Output: This refers to the items that are produced by the activity.
• Control: This refers to those items that provide control over the activity.
• Metrics: This refers to the items that are measured during the execution of the
activity.
Cont…

Figure: Problem identification phase

• A request for change to the software is normally made by the users of the
software system or the customers, and it starts the maintenance process.
• The request for change (CR) is submitted in the form of a modification request
(MR) for a correction or for an enhancement. MR & CR are used
interchangeably.
• Activities included in this phase are as follows:
• reject or accept the MR,
• identify and estimate the resources needed to change the system; and
• put the MR in a batch of changes scheduled for implementation.
Cont…
• The process is viewed to have
two major components:
• feasibility analysis.
• detailed analysis.

• First, feasibility analysis is performed to: Figure: Analysis phase

– determine the impact of the change;
– investigate other possible solutions including prototyping;
– assess both short-term and long-term costs; and
– determine the benefits of making the change.
• The second phase identifies:
– firm modification requirements;
– the software components involved;
– an overall test strategy; and
– an implementation plan.
Cont…

Figure: Design phase

• Activities of this phase are as follows:

– identify the affected software components.
– modify the software components.
– document the changes.
– create a test suite for the new design.
– select test cases for regression testing.
Cont…

Figure: Implementation phase

• The activities executed in this phase are:

– writing new code and performing unit testing,
– integrating changed code,
– conducting integration and regression testing,
– performing risk analysis, and
– reviewing the system for test-readiness.
Cont…

Figure: System test phase

• In this phase tests are performed on the full system to ensure that the
modified system complies with the original requirements as well as the new
modifications.
• System-level testing comprises a broad spectrum of testing activities:
functionality testing, robustness testing, stability testing, load testing,
performance testing, security testing, and regression testing.
Cont…

Figure: Acceptance test phase

• Acceptance testing is performed on a completely integrated system, and it

involves customers, users, or their representatives.
• The main objective of acceptance testing is to assess the overall quality of the
system, rather than actively identify defects.
• An important concept in acceptance testing is the customer’s expectation
from the system.
Cont…

Figure: Delivery phase

• In this phase, the changed system is released to customers for installation

and operation.
• Included in this phase are the following activities: notify the user
community, perform installation and training, and develop an archival
version of the system for backup.
Reading (Self Study)
• ISO/IEC 14764 Maintenance Process
 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.
Cont…
• 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.
Cont…
• The life-cycle of a CR has been illustrated in Figure below, by means of a state-
transition diagram.
• Each state represents a distinct stage in the life-cycle of a CR.

Figure: State transition diagram of a CR