Ch-2: Maintenance Support Process

1
Need for Maintenance
• System requirements are likely to change while the system is being
developed because their environment is changing
• Systems are tightly coupled to their environment
• When a system is installed it changes the environment and that can change
the system requirements
• The delivered system may not meet its requirements
• Systems must be maintained to remain useful in their environment

2
Types of Maintenance

• Corrective Maintenance (21%)

• making changes to repair defects
• Adaptive Maintenance (25%)
• making changes to adapt software to external environment changes
(hardware, business rules, OS, etc.)
• Perfective Maintenance (50%)
• extending system beyond its original functional requirements
• Preventative Maintenance (4%)
• modifying work products so that they are more easily corrected,
adapted, or enhanced
3
Maintenance Developer Tasks

• Understand system.
• Keep system documentation up to date.
• Extend existing functions.
• Add new functions.
• Find sources of errors.
• Correct system errors.
• Restructure design and code.
• Delete obsolete design and code.
• Manage changes.

4
Maintenance Planning
 An important activity for software maintenance is planning.
 Developments typically can last for 1-2 years, the operation and
maintenance phase typically lasts for many years.
 Developing accurate estimates of resources is a key element of maintenance
planning. Those resources, which include costs, should be included in project
planning budgets. Maintenance planning should begin with the decision to
develop a new system and should consider quality objectives.

5
Cont`d
 A concept and then a maintenance plan should be developed. The concept for
maintenance should address:
 The scope of software maintenance.
 The tailoring of the post delivery process.
 The designation of who will provide maintenance.
 An estimate of life cycle costs.

6
Cont`d
 IEEE 1219 provides a framework for planning software maintenance
activities.
 The framework consists of several key elements that organizations can use
to develop their maintenance plans.

7
Cont`d
 Here are the main components of the planning framework according to
IEEE 1219:
 Maintenance Objectives:
 It defines the goals and objectives of the maintenance effort.
 This includes identifying the desired outcomes, such as improving system reliability,
reducing defects, enhancing performance, or adding new features.
 Maintenance Scope:
 Determines the scope of the maintenance activities.
 This involves specifying which software components, modules, or systems will be
covered by the maintenance plan. It also includes defining any exclusions or
limitations.

8
Cont`d
 Maintenance Policies:
 Establish policies and guidelines for maintenance activities.
 This includes defining how changes will be prioritized, how defects will be classified
and managed, how communication and coordination with stakeholders will be
handled, and any other policies specific to the maintenance process.
 Resource Allocation:
 Identify and allocate the necessary resources for maintenance activities.
 This includes human resources, such as personnel with the required skills and
expertise, as well as the tools, equipment, and infrastructure needed to support
maintenance tasks effectively.

9
Cont`d
 Schedule and Milestones:
 Develop a schedule for maintenance activities, including specific milestones and
deadlines. This helps in planning and coordinating tasks, ensuring that maintenance
activities are completed within the desired timeframes.
 Documentation:
 Define the documentation requirements for the maintenance effort. This includes
documenting the maintenance plan itself, as well as any procedures, guidelines, or
reports that need to be created or updated during the maintenance process.

10
Cont`d
 Risk Management:
 Identify and assess potential risks associated with the maintenance activities.
 Develop strategies to mitigate or manage these risks effectively, such as contingency
plans, backup and recovery procedures, and change management processes.
 Quality Assurance:
 Define the quality assurance processes and metrics for evaluating the effectiveness
and efficiency of maintenance activities.
 This includes establishing criteria for measuring the success of maintenance efforts
and ensuring that they align with organizational quality standards.

11
Key Issues in maintenance
 It is important to understand that software maintenance provides unique technical
and management problems for software engineers. Trying to find a defect in a
500K line of code system that the maintainer did not develop is a challenge for the
maintainer.
 Planning for a future release, while coding the next release, and sending out
emergency patches for the current release, is also a challenge.

12
Cont`d
 There are technical and management problems relating to software
evolution and maintenance.
 Technical Problems
 Limited understanding
 Testing
 Impact analysis
 Management Problems
 Alignment with organizational issues
 Staffing
 Organizational Aspects of Maintenance

13
Software Testing

 Testers perform various types of testing, such as functional testing,

performance testing, security testing, and usability testing, to uncover any
issues. Once defects are identified, they are reported to the development
team for resolution.

14
Cont`d
 Developers analyze the bug reports, reproduce the issues, and make
necessary code changes to rectify the problems.
 Maintenance activities may also involve making enhancements, adding
new features, or modifying existing functionality based on user feedback
or evolving requirements.

15
Cont`d
 Testing
The execution of a program to find its faults
 Verification
The process of proving the programs correctness.
 Validation
The process of finding errors by executing the program in a real
environment
 Debugging
Diagnosing the error and correct it
16
Software test types
 Unit Testing (White Box)
 Integration Testing
 Function Testing (Black Box)
 Regression Testing
 System Test
 Acceptance and Installation Tests

17
Unit Testing (White Box)

 Individual components are tested.

 To focus on a relatively small segment of code and aim to exercise a high
percentage of the internal path
 Disadvantage: the tester may be biased by previous experience. And the
test value may not cover all possible values.

18
Function Testing (Black Box)

Designed to exercise to its external specifications

Testers not biased by knowledge of the program’s design.
Disadvantages:
1. The need for explicitly stated requirements
2. Only cover a small portion of the possible test conditions.

19
Regression Testing

 Test the effects of the newly introduced changes on all the previously
integrated code.
 Maintenance activities, such as bug fixes or enhancements, have the
potential to introduce new defects or impact existing functionality.
 The common strategy is to accumulate a comprehensive regression bucket
but also to define a subset.
Disadvantages:
1. To decide how much of a subset to use and which tests to select

20
Test Planning

 Define the functions, roles and methods for all test phases.
 Test planning usually start during the requirements phase.
Major test plan elements are:
1. Objectives for each test phase
2. Schedules and responsibilities for each test activity
3. Availability of tools, facilities and test libraries.
4. Set the criteria for test completion

21
Test Execution & Reporting

 Testing should be treated like an experiment.

 Testing require that all anomalous behavior be noted and investigated.
 Big companies keep a special library with all copies of test reports, incident
forms, and test plans

22
 Software Configuration Management (SCM)

 In Software Engineering, Software Configuration

Management(SCM) is a process to systematically manage, organize,
and control the changes in the documents, codes, and other entities
during the Software Development Life Cycle.
 The primary goal is to increase productivity with minimal mistakes.

 SCM can accurately determine who made which revision.

23
Purpose of SCM
 The primary reasons for implementing technical software
configuration management system are:
 There are multiple people working on software which is continually updating

 It may be a case where multiple version, branches, authors are involved in a

software config project, and the team is geographically distributed and works
concurrently

24
Cont`d
 Changes in user requirement, policy, budget, schedule need to be
accommodated.
 Helps to develop coordination among stakeholders
 SCM process is also beneficial to control the costs involved in making
changes to a system

25
Cont`d

26
Tasks in SCM process

 Configuration Identification
 Baselines
 Change Control
 Configuration Status Accounting
 Configuration Audits and Reviews

27
Configuration Identification

 Configuration identification is a method of determining the scope of

the software system. It is a description that contains the CSCI type
(Computer Software Configuration Item), a project identifier and
version information.

28
Cont`d
Activities during this process:
 Identification of configuration Items like source code modules, test case, and
requirements specification.
 The process starts with basic objects which are grouped into aggregate objects.
Details of what, why, when and by whom changes in the test are made
 Every object has its own features that identify its name that is explicit to all other
objects
 List of resources required such as the document, the file, tools, etc.

29
Baseline:
 A baseline is a formally accepted version of a software configuration item.
 It is designated and fixed at a specific time while conducting the SCM process. It
can only be changed through formal change control procedures.
Activities during this process:
• Facilitate construction of various versions of an application
• Defining and determining mechanisms for managing various versions of these
work products
• The functional baseline corresponds to the reviewed system requirements
• Widely used baselines include functional, developmental, and product
baselines

30
Change Control

 Change control is a procedural method which ensures quality and consistency

when changes are made in the configuration object. In this step, the change
request is submitted to software configuration manager.
Activities during this process:
 Control ad-hoc change to build stable software development environment.
Changes are committed to the repository
 The request will be checked based on the technical merit, possible side effects and
overall impact on other configuration objects.
 It manages changes and making configuration items available during the software
lifecycle

31
Configuration Status Accounting

 Configuration status accounting tracks each release during the SCM process. This
stage involves tracking what each version has and the changes that lead to this
version.
Activities during this process:
• Keeps a record of all the changes made to the previous baseline to reach a new
baseline
• Monitor status of change requests
• Complete listing of all changes since the last baseline
• Allows tracking of progress to next baseline
• Allows to check previous releases/versions to be extracted for testing

32
Configuration Audits and Reviews

 Software Configuration audits verify that all the software product satisfies
the baseline needs. It ensures that what is built is what is delivered.
Activities during this process:
 Configuration auditing is conducted by auditors by checking that defined processes are being
followed and ensuring that the SCM goals are satisfied.
 SCM audits also ensure that traceability is maintained during the process.
 Ensures that changes made to a baseline comply with the configuration status reports
 Validation of completeness and consistency

33
Participant of SCM process

34
Cont`d

Configuration Manager
 Configuration Manager is the head who is Responsible for identifying
configuration items.
 CM ensures team follows the SCM process
 He/She needs to approve or reject change requests

35
Cont`d
Developer
 The developer needs to change the code as per standard development activities
or change requests. He is responsible for maintaining configuration of code.
 The developer should check the changes and resolves conflicts
User
 The end user should understand the key SCM terms to ensure he has the
latest version of the software

36
Cont`d
Auditor
 The auditor is responsible for SCM audits and reviews.
 Need to ensure the consistency and completeness of release.
Project Manager:
 Ensure that the product is developed within a certain time frame
 Monitors the progress of development and recognizes issues in the SCM process
 Generate reports about the status of the software system
 Make sure that processes and policies are followed for creating, changing, and testing

37
Software Configuration Management Tools

Any Change management software should have the following 3 Key features:
Concurrency Management:
 When two or more tasks are happening at the same time, it is known as concurrent
operation. Concurrency in context to SCM means that the same file being edited
by multiple persons at the same time.
 If concurrency is not managed correctly with SCM tools, then it may create many
pressing issues.

38
Cont`d
Version Control:
 SCM uses archiving method or saves every change made to file. With the
help of archiving or save feature, it is possible to roll back to the previous
version in case of issues.
Synchronization:
 Users can checkout more than one files or an entire copy of the repository.
The user then works on the needed file and checks in the changes back to
the repository. They can synchronize their local copy to stay updated with
the changes made by other team members.

39
SCM Tools
1. Git:
 Git is a free and open source tool which helps version control. It is designed to handle
all types of projects with speed and efficiency.
link: https://git-scm.com/
2. Team Foundation Server:
 Team Foundation is a group of tools and technologies that enable the team to
collaborate and coordinate for building a product.
link: https://azure.microsoft.com/en-us/services/devops/server/
3. Ansible:
 It is an open source Software configuration management tool. Apart from
configuration management it also offers application deployment & task automation.
link: https://www.ansible.com/
40
Taxonomy of Maintenance
 The ISO/IEC 14764 standard defines software maintenance as “… 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”

 The standard further defines software maintainability as “… the

capability of the software product to be modified. Modification may
include corrections, improvements or adaptation of the software to
changes in environment, and in requirements and functional
specification”

41
Cont’d…
 A major difference exists between software maintenance and software
development: maintenance is event driven, whereas development is
requirements driven
 The inputs that invoke maintenance activities are unscheduled events;
execution of the actual maintenance activities might be scheduled
according to a plan
 A maintenance activity accepts some existing artifacts as inputs and
generates some new and/or modified artifacts.

42
Classification of Maintenance
 Maintenance activities can be categorized into four groups based on
what we intend to achieve with those activities
 Based on the Standard for Software Engineering–Software
Maintenance, ISO/IEC 14764 , the four categories of maintenance
activities are
 corrective
 adaptive
 perfective and
 preventive

43
Cont’d…
Corrective maintenance
 The purpose of corrective maintenance is to correct failures:
processing failures and performance failures
 A program producing a wrong output is an example of processing
failure. Similarly, a program not being able to meet real-time
requirements is an example of performance failure. The process of
corrective maintenance includes isolation and correction of defective
elements in the software. The software product is repaired to satisfy
requirements

44
Cont’d…
Adaptive maintenance
 The purpose of adaptive maintenance is to enable the system to adapt to
changes in its data environment or processing environment. This process
modifies the software to properly interface with a changing or changed
environment
 Adaptive maintenance includes system changes, additions, deletions,
modifications, extensions, and enhancements to meet the evolving needs of
the environment in which the system must operate.

45
Cont’d…
 Some generic examples are:
 changing the system to support new hardware configuration
 converting the system from batch to online operation and
 changing the system to be compatible with other applications.

46
Cont’d…
 Perfective maintenance
 The purpose of perfective maintenance is to make a variety of improvements, namely,
user experience, processing efficiency, and maintainability.
 Example
 The program outputs can be made more readable for better user experience;
 The program can be modified to make it faster, thereby increasing the processing
efficiency
 The program can be restructured to improve its readability, thereby increasing its
maintainability.

47
Cont’d
 In general, activities for perfective maintenance include restructuring
of the code, creating and updating documentations, and tuning the
system to improve performance
 It is also called “maintenance for the sake of maintenance” or
“reengineering”

48
Cont’d…
 Preventive maintenance
 The purpose of preventive maintenance is to prevent problems from occurring by
modifying software products. Basically, one should look ahead, identify future risks
and unknown problems, and take actions so that those problems do not occur.
 For example, good programming styles can reduce the impact of change, thereby
reducing the number of failures
 Preventive maintenance is very often performed on safety critical and high available
software systems

49
Cont’d…
 The concept of “software rejuvenation” is a preventive maintenance
measure to prevent, or at least postpone, the occurrences of failures due to
continuously running the software system.

 Software rejuvenation is a proactive fault management technique aimed at

cleaning up the system internal state to prevent the occurrence of more
severe crash in the future

 Rejuvenation may increase the downtime of the application; however, it

prevents the occurrence of more severe and costly failures

50
Cont’d…
 The purpose of software maintenance activities of preventive
maintenance of a safety critical software system is to eliminate hazard
or reduce their associated risk to an acceptable level.
 hazard is a state of a system or a physical situation which, when
combined with certain environment conditions, could lead to an
accident.

51
CATEGORIES OF MAINTENANCE CONCEPTS

52
Cont’d…
 Maintained Product
 The maintained product dimension is characterized by three concepts:
product, product upgrade, and artifacts.
 Product. A product is a coherent collection of several different artifacts.
Source code is the key component of a software product. Other artifacts of
interest include print manuals and online help.
 Product upgrade. Baseline is an arrangement of related entities that make up
a particular software configuration. Any change or upgrade made to a
software product relates to a specific baseline
 upgrade can create a new version of the system being maintained, a patch
code for an object, or even a notice explaining a restriction on the use of the
system.
53
Cont’d…
 Artifacts
 One can find the following types of artifacts: textual and graphical documents,
component off-the-shelf products, and object code components.
 The key elements of the maintained product are size, age, application
type, composition, and quality.
 The size of a software system affects the number of personnel needed
to maintain the system.
 The age of a software product, also known as software geriatrics, is
the number of calendar years elapsed since its first release.
 It is difficult to maintain too old products
54
Cont’d…
 Application domains put constraints on maintenance of products and
artifacts.
 For example, while maintaining a safety critical system, such as air
traffic control, one must preserve—and, even increase—the product’s
reliability On the other hand, in another application domain the
concept of time-to-market may cause early deployment of a newer
version of a system.
 The level of abstraction of the product component determines the
skills required by the maintenance personnel and the tools they need to
support the component.

55
Cont’d…
 The product quality initially delivered to the customer places
constraints on the subsequent maintenance activities. Intuitively, good
quality artifacts are easier to maintain than poor quality ones.

56
Cont’d…
 Maintenance Types
 Activity. A number of different broad classes of maintenance activities are
performed on software products, including investigation, modification,
management, and quality assurance.
 Four kind of activities:
 Investigation activity. This kind of activities evaluate the impact of making a certain
change to the system.
 Modification activity. This kind of activities change the system’s implementation.
 Management activity. This kind of activities relate to the configuration control of the
maintained system or the management of the maintenance process.
 Quality assurance activity. This kind of activities ensure that modifications performed on
a system do not damage the integrity of the system.

57
Cont’d…
 Maintenance Organization Processes
 Two different levels of maintenance processes are followed within a
maintenance organization:
 The individual-level maintenance processes followed by maintenance personnel to
implement a specific CR and

 The organization-level process followed to manage the CRs from maintenance personnel,
users, and customers/clients; this higher level of process is referred to as the maintenance
organization process.

58
Cont’d
 The performance of maintenance activities are impacted by the selection of
development paradigm and development technology. It is also impacted by
the degree of automation of procedures.
 In general, development paradigm and development technologies put limitations on
maintenance activities and skill requirements.
 For example, if the service-oriented architecture (SOA) paradigm is used for the
software development process, then the maintenance engineers must be well versed
with the SOA.

59
Cont’d…
 we briefly define the concepts of the maintenance organization processes and then
discuss the impact of these concepts on maintenance.
 Service-level agreement (SLA). This is a contract between the customers and the providers
of a maintenance service. Performance targets for the maintenance services are specified in
the SLA.
 Maintenance management. This process is used to manage the maintenance service, which is
not the same as managing individual CRs. An organization process is set up and run by the
senior management.
 Change control. Evaluation of results of investigations of maintenance events is performed
in a process called change control.
 Configuration management. A system’s integrity is maintained by means of a configuration
management process.
 Event management. The stream of events, namely, all the CRs from various sources,
received by the maintenance organization, is handled in an event management process.
60
Cont’d…
 Peopleware
 Maintenance activities cannot ignore the human element, because
software production and maintenance are human-intensive activities.
 The three people-centric concepts related to maintenance are as
follows:
 Maintenance organization. This is the organization that maintains the
product(s).
 Client organization. A client organization uses the maintained system and it
has a clear relationship with the maintenance organization.
 Human resource. Human resource includes personnel from the maintenance
and client organizations.
61