Wollo University, Kombolcha Institute Of

Technology
Departments of Software Engineering
A lecture note for Advanced Software Engineering
By
Tilahun Ayalew (MSC in Software Engineering)

itsmetilahun@gmail.com
1

Kombolcha, Ethiopia
Chapter 2:Software maintenance Introduction
Definition:
THE IEEE Standard for Software Maintenance (IEEE 1219)
“The process of modifying a software system or component after
delivery to correct faults, improves performance or other attributes,
or adapt to a changed environments”

Maintenance principles

2
Chapter 2:Software maintenance Introduction
Why software maintenance? :
Correct faults.
Improve design.
Implement enhancements.
Interface with other systems.
Adapt programs so that different hardware, software, system features,
and 

telecommunications facilities can be used.
Migrate legacy software.
Retire software 


3
Chapter 2:Software maintenance Introduction
Categories of software maintenance?
•Corrective maintenance : Reactive modification of a software product performed after delivery
to correct discovered problems.
•Adaptive maintenance :Modification of a software product performed after delivery to keep a
software product usable in a changed or changing environment.
•Perfective maintenance : Modification of a software product after delivery to improve
performance or maintainability.
• Preventive maintenance : Modification of a software product after delivery to detect and
correct latent faults in the software product before they become effective faults.

4
Chapter 2:Software maintenance Introduction
Key to software maintenance?
• The key to effective maintenance lies in development.
• Depending upon the development of the product the maintenance of the
product is determined.

Maintenance types

5
Chapter 2:Software maintenance Introduction

Software maintenance process

6
Chapter 2:Software maintenance Introduction
Major factors cause problem in software
maintenance /models/
Unstructured code
Insufficient domain knowledge
Insufficient documentation

7
Chapter 2:Software maintenance Introduction
Major factors cause problem in software maintenance /models/
Iterative models:
• share the ideas that a complete set of requirements for a system cannot be completely
understood, or the developers do not know how to build the full system.
• Therefore, systems are constructed in builds, each of which is a refinement of
requirements of the previous build.
• A build is refined by considering feedback from users.
• One may note that maintenance and evolution activities do not exist as distinct phases.
Rather, they are closely intertwined.

8
Chapter 2:Software maintenance Introduction
Major factors cause problem in software maintenance /models/
Change mini-cycle models:
• First proposed by Yau et al. in the late 1970s these models were recently re-visited
by Bennet et al. and Mens among others.
• These models consist of five major phases: change request, analyse and plan change,
implement change, verify and validate, and documentation change.
• In this process model, several important activities were identified, such as program
comprehension, impact analysis, refactoring, and change propagation.

9
 Change Mini cycle model

10
Chapter 2:Software maintenance Introduction
Keys challenges in software maintenance?
•Limited Understanding
• Shift in type of maintenance
• Impact Analysis
• Maintainability
• Alignment with organisational objectives
• Staffing
• Process

11
Chapter 2:Software maintenance Introduction
Keys challenges in software maintenance?
Organisational aspects of maintenance
Outsourcing
Cost estimation
Specific measurements

12
Chapter 2:Software maintenance Introduction
Keys challenges in software maintenance?
IEEE [IEEE610.12-90] defines maintainability as the ease
with which software can be maintained, enhanced, adapted,
or corrected to satisfy specified requirements and the
presence of systematic and mature processes, techniques,
and tools helps to enhance the maintainability of a system.

13
Chapter 2:Software maintenance Introduction
Four distinct, sequential stages of the lifetime of a system
Initial development.
• When the initial version of the system is produced, detailed knowledge about the system is fresh.
• Before delivery of the system, it undergoes many changes.
• Eventually, a system architecture emerges and soon it stabilises.
Evolution.
• After the initial stability, it is easy to perform simple changes to the system.
• Significant changes involve higher cost and higher risk.
• In the period immediately following the initial delivery, knowledge about the system is still almost fresh in the minds of the developers.
• It is possible that the development team as a whole does not exist, because many original developers have taken up new responsibilities in the
organisation and some might have left the organisation.

14
 Chapter 2:Software maintenance Introduction
Four distinct, sequential stages of the lifetime of a system
Servicing.
• When the knowledge about the system has significantly decreased, the developers mainly focus on maintenance tasks,
such as fixing bugs, whereas architectural changes are rarely effected.
• The developers do not consider the system to be a key asset. In this stage, the effects of changes are very difficult to
predict.
• Moreover, the costs and risks of making changes are very significant.
Phaseout.
• When even minimal servicing of a system is not an option ,the system enters its very final stage.
• The organisation decides to replace the system for various reasons: (i) it is too expensive to maintain the system; or (ii)
there is a newer solution available.
• Therefore, the organisation develops an exit strategy to move from the current system to a new system.
• Moving from an existing, difficult-to-maintain system to a modern solution system has its own challenges involving
wrapping and data migration.
• After the new system keeps running satisfactorily, sometimes in parallel with the old system, the old system isf finally
completely shut down.

15
Chapter 2:Software maintenance Introduction

Maintenance affecting factors

16
 Chapter 2:Software maintenance Introduction

Legacy systems
Is an old program that continues to be used.
Because it still meets the users’ needs, in spite of the availability of
newer technology or more efficient methods of performing the task.
Are vital to orgnisation and the systems significantly resist
modification and evolution to meet new and constantly changing
business requirements

17
 Chapter 2:Software maintenance Introduction

Legacy systems
To manage legacy systems, number of options are available
• Freeze,
• Outsource,
• wrap,
• Discard and redevelop,
• Migrate

18
 Chapter 2:Software maintenance Introduction

Re Engineering
• Implies a single cycle of taking an existing system and generating from it a new system,
whereas evolution can go forever.
• Hongji Yang and Martin Ward, defined software evolution as “ ... the process of conducting
continuous software reengineering”
• To a large extent, software evolution can be seen as repeated software reengineering
• Done to transform an existing “lesser or simpler” system into a new “better” system
Reengineering = Reverse engineering + Δ + Forward engineering.

19
 Chapter 2:Software maintenance Introduction

Re Engineering
Among many repeatable paradigms in re engineering,
Goals=> analyse the motivation and information needed to construct
abstracts to be produced
tools=>excute the model and transform it to the program
models=> analyse the abstraction to construct the representations

20
21
22
 Reverse Engineering
•First applied in electrical engineering to produce schematics from an electrical circuit.
•The process of developing a set of specifications for a complex hardware system by an
orderly examination of specimens of that system.

23
 Reverse Engineering
A process to :
(i) Identify the components of an operational software;
(ii) Identify the relationships among those components; and
(iii) represent the system at a higher level of abstraction or in another form.

24
Reverse Engineering

Factors necessary for reverse engineering

25
Relationship between re engineering and reverse Engineering

26
 Techniques for reverse Engineering
Lexical analysis :
• Decomposition to its constituting lexical Units
Syntactical analysis:
• Done using parser for each modules, expressions, statements etc..
• Having two type representations: parse tree and abstract syntax tree
Control flow analysis: Intraprocedural and Interprocedural analysis
Data flow analysis: concerns on how values of defined variable constructed

27
 Techniques for reverse Engineering
Program slicing :
• The slice of a program for a given variable at a given line of code is
the portion of the program that gives a value to the variable at that
point.
Visualisations:-
• Represented by means of a visual object to gain some insight into how
the system has been structured.
Program metrics: complexity metric, C = (fan-in × fan-out)
p

28
Thanks You!

29