-introduction-

SEMESTER 1, 2019/2020 PREPARED BY: DR NORAZLINA KHAMIS

 Describe the overall fundamentals and concepts of software
PLO1
maintenance and evolution (C5, PLO1)

Construct maintenance theoretical concepts for the skills required to

PLO2
effect, control and manage changes to evolving software. (P3, PLO2)

PLO3 Determine the maintenance framework by applying appropriate

maintenance techniques and tools (C5, PLO3)
CONTENTS:
Introduction of software maintenance &
evolution

Distinguish software maintenance from

software development

Outline why maintenance is needed

Software evolution
“There is no such thing as a ‘finished’ computer
program”
Lehman (169, chap 2)
BASIC CONCEPTS
 Software maintenance is the discipline concerned with
changes related to a software system after delivery.
 When there are changes, thus, the evolution of the
software happen
 Changes will usually be required to support quality
factors during the lifetime of a software.
◦ changes maybe necessary to satisfy requests for performance
improvement, functional enhancement, increasing the degree
of portability.
 Maintenance process takes about 40-70% of the costs of
the entire life cycle of the software system
SOFTWARE MAINTENANCE
 Maintenance in general :
◦ the act of keeping an entity in an existing
state of efficiency, validity, to preserve from
failure or decline.
 Software maintenance :
◦ modification of a software product after
delivery in order to:
 improve performance
 correct faults
 adapt the product to a modified
environment
DEFINITION…..
 Maintenance – the act of keeping an entity
in an existing state of repair, efficiency, or
validity; to preserve from failure or decline
 Software Maintenance – modification of a
software product after delivery, to correct
fault, to improve performance or other
quality attributes or to adapt the product to
a new environment
 Maintainability- the ease with which
maintenance can be carried out
 Evolution – a process of continuous change
from a lower, simpler or worse to a higher,
more complex or better state
Misconception…….

‘software comprises
a program or object
code or set of
instructions….’
Program
Documentation
Source code
Operating procedure
Doc of analysis, design
(logical or physical),

Software
implementation, testing User manual,
•URD, Context diagram, installation
ERD, class diagram, SRS,
code listings, test cases, test
procedure,
instruction on
is more
than
results, flow charts, DFD,
Software Project Plan
how to react to
system failures
that….
The programs, documentation and
operating procedures by which
computers can be made useful to human
All those components of software Software artifact limit to tangible
i.e. programs + byproduct produce during
documentation + installation software development process

Software
artifacts

Some artifacts concerned with some concerned with the

the functionalities, architectures, development process e.g. project
design plans, business risk, DR plan
Definition.. Definition… Definition
• The modification of a • The software product
software product after undergoes modification to
delivery: code and associated
• to correct faults, documentation due to a
• to improve performance or problem or the need for
other attributes, or improvement.
• to adapt the product to a • The objective is to modify the
modified environment existing software product
while preserving its integrity

IEEE ISO
Again …. Another definition
 The totality of activities required to
provide cost effective support to a
software system
 Activities are performed during the
pre delivery stage as well as the post-
delivery stage
 Pre delivery activities include
planning for post-delivery operations,
supportability, and logistics
determination
 Post delivery activities include
software modification, training and
operating help desk
Again …. Another definition
 The primary activities of
software maintenance such as
◦ Process implementation
◦ Problem and modification
analysis
◦ Modification implementation
◦ Maintenance review/acceptance
◦ Migration
◦ Retirement
Perception…. We must fix all
the bugs
 Why?
◦ Perception is perpetuated by users submitting problems
reports that in reality are major enhancements to the
system.
◦ However, over 80% from survey shows that the
maintenance effort is used for non-corrective actions
➔ maintenance is similar to software development,
although some unique processes are employed
Reality………
 Focus of SD is to solve problems or to obtain
business advantage through producing code.
 The generated code implements stated requirements
and should operate correctly
 Maintainers look back at the development products
and also the present by working with users and
operators
 Maintainers also look forward to anticipate
problems and to consider functional changes
New Development vs Maintenance
 New development done on a green field site but
maintenance must work within the parameters and
constraints of an existing system
 Impact analysis should be carried out to determine the
ramifications of the new or modified system.
◦ For example what will happen if we increased from 32bit to 64
bit to our encryption algorithm?
 Critical analysis need to be done by the maintenance
engineer to abstract the architectural and the low level
designs.
→the maintenance engineer needs to have comprehension
and analytical skills than just computer programming.
Software Architecture and Software
Maintenance
 Software architecture can be seen as a set
of structures + data flows + controls flows,
then we put it together into sub-system to
solve the broadly problem domain. It
represents a common high-level abstraction
of the system
 Software architecture represents the
embodiment of the early design decisions
that far outweigh the impact and activities
on development, service and maintenance
Software Architecture and Software
Maintenance
 One of the problem is to identify the most
significant non-functional requirement issues such
as maintainability, flexibility, performance,
scalability.
 If the software architecture is good then the
software maintenance is easy to manage.
 There are implicit relationship between Software
Architecture and Software Maintenance
 Why software maintenance is needed
To provide To support To support user To facilitate future
continuity of mandatory requests for maintenance work
service upgrades improvements • To save a cost, e.g
• System need to keep • Needed because of • The better the system financial and effort
running. an amendments to is, the more it will be for a long term by
Maintenance government used and the more making future
activities such as big regulations, e.g user will request maintenance easier
fixing, recovering changes in tax laws enhancements in and less-effort
from failure and functionality e.g
accommodating improving
changes in the OS performance and
and hardware reliability
Nature of maintenance
 Maintenance has a broader scope than
development, with more changes to track
and control.
 Thus, configuration management is an
important aspect of software evolution and
maintenance.
 Contact with the developers and early
involvement by the maintainer helps the
maintenance effort.
 However, it is difficult sometimes when the
developers are no longer around
 2. Maintaining control over
1. Maintaining control over the
software
software's day to-day functions
modification

Maintainer’s
activities

4. Preventing software
performance from
3. Perfecting existing functions
degrading to unacceptable levels
Quality attributes – consideration before the software development start
Quality attributes.. more

• Lack of bugs and defects

• Measured in terms of defect
rate (# bugs per line of
code)
CORRECTNESS • E.g: The probability for a
non accurate output will
not exceed 1% from all the
total output displayed by
the system
Quality attributes.. more

• Does not fail or crash often

• Measured in terms of
failure rate (# failures per
hour)
RELIABILITY
• e.g: The downtime rate for
SMART2 UMS website is
required to be less than
one in 100 years
Quality attributes.. more

• Does all that is required

• Measured in terms of
requirements coverage
(% of required operations
implemented)
CAPABILITY
• e.g: The system that will
be developed should
perform all the
requirements stated in
the specification
Quality attributes.. more

•Is fast and small

enough
•Measured in terms of
speed and space usage
EFFICIENCY (seconds of CPU time,
Mb of memory, etc)
•e.g: The system should
return a query results
less than 1 seconds
Quality attributes.. more
• Is easy to change and adapt to
new requirements
• Measured in terms of
• Change logs (time and effort
required to add new feature)
• Impact analysis (#lines affected
MAINTAINABILITY by a new feature)
• e.g: if the system need to be
upgraded or added new features,
it should be done less than a
week and impact changes should
be less than 10% of KLOC per
module
Quality attributes.. more

• Is sufficiently convenient for

the intended users
• Measured in terms of user
satisfaction (% of users happy
with interface and ease of use)
USABILITY • E.g: The time required for the
user to learn this new system
will take no more than 16
training hours with 100%
knowing all the features
provided by the system
Quality attributes.. more
• is convenient and fast to
install
• measured in terms of user
satisfaction (#install
problems reported per
INSTALLABILITY installation)
• E.g: The time required for
the installation should be
less than 5 hours with zero
installation problem
Quality attributes.. more
• is well documented
• measured in terms of user
satisfaction
(% of users happy with
documentation)
DOCUMENTATION
• E.g: The documentation of
the per said system should
be easily read and
understood by 95% from
the total audience
Quality attributes.. more
• is easy to access and
available when needed
• measured in terms of user
satisfaction (% of users
reporting access problems)
AVAILABILITY • E.g: The reporting access
problems should be less
than 10 times in first year of
system deployment and 4
times in second year and 1
time in the third year of
system deployment
Software evolution
 No standard definitions.
 Broad definition of evolution: Generally, software evolution refers to
the study and management of the process of making changes to
software over time.
◦ In this definition, software evolution comprises:
 Development activities
 Maintenance activities
 Reengineering activities
 Narrow definition of evolution: Sometimes, software evolution is
used to refer to the activity of adding new functionality to existing
software.
 Maintenance refers to the activity of modifying software after it has
been put to use in order to maintain its usefulness.
Importance of evolution
 Organizations have huge investments in their
software systems - they are critical business assets.
 To maintain the value of these assets to the business,
they must be changed and updated.
 The majority of the software budget in large
companies is devoted to evolving existing software
rather than developing new software.
 Studies indicate that up to 75% of all software
professionals are involved in some form of
maintenance/evolution activity.
 Types of changes
 Repair software faults
“Maintenance” ◦ Changing a system to correct deficiencies in the way meets
its requirements.
 Adapt software to a different operating environment
◦ Changing a system so that it operates in a different
environment (computer, OS, etc.) from its initial
implementation.
“Evolution”

 Add to or modify the system’s functionality

◦ Modifying the system to satisfy new requirements.
“Reengineering”

 Improve the program structure and system

performance
◦ Rewriting all or parts of the system to make it more efficient
and maintainable.
History
 1960s – 1970s
◦ Inclusion of maintenance in waterfall lifecycle after delivery of the software
product.
◦ Perception that post-delivery activities only consisted of bug fixes and minor
adjustments.
◦ Did not account for the need to add functionality due to new and changed
requirements.
 1970s
◦ Lehman postulated the initial laws of program evolution.
◦ Stressed the need for continuous evolution due to changes in the software’s
operational environment.
 Late 1970s – 1980s
◦ Initial process models that handled change requests.
 1990s
◦ General acceptance of software evolution.
◦ Development of new process models that accounted for evolution activities:
evolutionary development, spiral model, agile software development.
 Evolution processes
 Processes for evolving a software product 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 drivers for system
evolution. Change identification and evolution
continue throughout the system lifetime.

Sommerville, Ch. 21 Software Evolution 37

 Change identification and evolution

Sommerville, Ch. 21 Software Evolution 38

 The system evolution process

Change Impact Release Change System

requests analysis planning implementation release

Platform System
Fault repair
adaptation enhancement

Sommerville, Ch. 21 Software Evolution 39

 Change implementation

Proposed Requirements Requirements Software

changes analysis updating development

Sommerville, Ch. 21 Software Evolution 40

 Two aspects of software evolution
 “What and why”
◦ Focuses on software evolution as a scientific discipline.
◦ Studies the nature of the software evolution phenomenon to understand its
driving factors.
◦ Key interests include the formulation and refinement of fundamental theories
and laws of software evolution.
 “How”
◦ Focuses on software evolution as an engineering discipline.
◦ Studies how to support the daily tasks of the software developer or project
manager.
◦ Key interests include the development and validation of tools and techniques to
guide, implement and control software evolution.

Mens & Demeyer, Ch. 1 Software Evolution 41

 Management
 Economics of software evolution
◦ Developing economic models to support evolution-related management
decisions.
◦ Comparing the cost of different strategies for changes.
◦ Assessing the cost-benefits of investing in reengineering.
 Software metrics
◦ Measuring the quality of a change.
◦ Measuring the degree of modularity.
 Configuration management
◦ Change management processes.
◦ Management of multiple versions.
◦ Merging versions together.
◦ Release management.

Mens & Demeyer, Ch. 1 Software Evolution 42

 Evolution of software artifacts
 Requirements evolution
◦ Managing requirements changes.
 Architecture evolution
◦ Reengineering the architectures of legacy systems.
◦ Migration to distributed architectures, e.g., service-oriented architectures.
◦ Maintenance issues with modern architectures.
 Design evolution
◦ Evolution of design models.
 Test case evolution
◦ Adding and modifying test cases to verify that the system behavior was changed
as intended.
 Traceability management
◦ How to assure the consistency of the different artifacts.

Mens & Demeyer, Ch. 1 Software Evolution 43

 Other evolution issues
 Data evolution
◦ Migrating to a new database schema.
◦ Verifying that the information in the existing databases are preserved.
 Runtime evolution
◦ How to modify a system without stopping it.
◦ Encompasses runtime reconfiguration, dynamic adaptation, dynamic upgrading.
 Language evolution
◦ Dealing with changes in the programming language definition.
◦ Especially an issue in multi-language systems.
◦ Designing languages to make them more robust to evolution.

Mens & Demeyer, Ch. 1 Software Evolution 44