SOFTWARE MAINTENANCE PLAN PROPOSAL FOR THE DISTRICT MUNICIPALITY

OF PAUCARCOLLA BASED ON THE ISO/IEC 14764:2006 STANDARD

Justification

Since software has been developed, software maintenance has occurred, there is nothing
in theory or practice that indicates that this will change. During these last six decades,
academic and industrial projects based on software maintenance have been presented,
resulting in: research articles, documents, conferences, regulations, etc.; However,
software maintenance continues to be invisible and undeclared in many companies,
municipalities and government entities, causing problems in their computer systems if
software maintenance is not carried out that can even lead to the complete shutdown of
the system.

The ISO/IEC 14764:2006 standard details how to manage the software maintenance
process in an appropriate manner, however the steps are developed depending on the
software application. Other standards such as ISO/IEC 12207 refer to maintenance as part
of the concept of various types of maintenance.

Carrying out a customized software maintenance plan will improve the quality of the final
product, since software maintenance can be done by combining software tools, methods
and techniques; but all this is subject to the background of the developed software
application.

Definition of the problem

The software development and maintenance plan must be carried out at the same time in
any organization; both generate a large amount of information that must be managed and
documented. Ignorance of these activities in software maintenance can lead to
undervaluing its importance, and there is a tendency to associate software maintenance
only with the correction of errors in the programs.

Goals
• Design a maintenance plan for the District Municipality of Paucarcolla.
• Evaluation of computer tools that automate maintenance.
• Identify the types of software maintenance available today.
Scope

The maintenance plan will be used in those products that will be maintained as long as
possible within the District Municipality of Paucarcolla. Maintenance will apply to computer
programs, administration documentation and later in time to software products that are
created during the development of new software.
Software Maintenance

Features of software maintenance

The ISO 12207 Software Life Cycle Processes standard defines maintenance as: The
maintenance process contains the activities and tasks performed by the maintainer. This
process is activated when the software product undergoes modifications in the code and
associated documentation, due to a problem or the need for improvement or adaptation.
The objective is to modify the existing software product while preserving its integrity. This
process includes the migration and retirement of the software product. The process ends
with the withdrawal of the software product.

While the ISO/IEC 14764 standard emphasizes software maintenance planning: A set of
activities aimed at providing economically profitable support for a given software product.
These activities are carried out both before the delivery of the product and after its
delivery. Pre-delivery activities include activities intended to plan, anticipate, and prepare
for subsequent maintenance activities. Post-delivery activities include software product
modifications, training, and user support.

Maintenance need

Maintenance is necessary so that the software continues to satisfy the user's

requirements, maintenance is applicable to the developed software. The system changes
due to corrective and non-corrective actions on the software. Maintenance must be carried
out with the objective of:
• Correct errors.
• Improve the design.
• To implement improvements.
• Define interfaces with other systems.
• Migrate legacy software.
• Remove the software.
Maintenance costs

Maintenance costs consume a large part of the financial resources of the software life
cycle. Understanding the factors that influence the maintenance of a system can help to
properly set costs, some of these factors are:

• Type of application.
• Software maintenance availability.
• Software life cycle.
• Hardware characteristics.
• Quality of software design, construction, documentation and testing.
 Operations and maintenance (67%)
Types of software maintenance

The type of maintenance is based on the activity and what is intended to be achieved with
that action. In the ISO/IEC 14764 standard for Software Maintenance there are four
categories of maintenance activities, and they are:

• Corrective.
• Adaptive.
• Perfect.
• Preventive.
Software maintenance plan

The ISO/IEC 14764 standard for the maintenance process

The ISO/IEC 14764 document is an international standard for software maintenance, and it
describes maintenance using the same concepts as IEEE/EIA 1219, except that they are
represented slightly differently. An iterative process to execute and manage maintenance
activities is described in the document.

The basic structure of an ISO process is made up of activities, and an activity is made up
of tasks. To change operating software without breaking its integrity, the necessary
activities are described in the maintenance process.

Upon activation of the maintenance process, plans and procedures are developed and
resources are allocated to carry out the maintenance. In response to a CR (change
request), the code is modified along with the relevant documentation. Modification of the
software executed without losing the integrity of the system is considered to be the general
objective of maintenance. The maintenance process allows the software product to
migrate from its initial environment at its inception to new environments. The maintenance
process is terminated upon possible decommissioning of the product, commonly known as
being retired. The maintenance process includes high-level activities:

a) Implementation process.
b) Problem and modification analysis.
c) Application modification
d) Opinion Maintenance and acceptance.
 e) Migration.
f) Withdrawal.

Maintenance Plan: The maintenance plan describes a strategy for maintaining the
system, while the maintenance procedures describe in detail how to actually accomplish
the maintenance. The plan is also described as:

• Organize maintenance team staff

• Assign responsibilities among team members
• Programming resources.
Software Maintenance Plan Template

➢ Implementation process.
➢ Analysis of modification and problems.
➢ Implementation of the modification.
➢ Acceptance and maintenance review.
➢ Migration.
➢ Retirement.

Purpose

Provide the appropriate criteria and direction for maintenance activities in each of their
phases. This plan must be cited in the project management plan of the Systems
Department.
Necessary documents with which this maintenance plan must be worked are the following:

✓ Software Maintenance Organization Process Manual

✓ Quality management systems operation manual
✓ IEEE Standard 610, 12 (Software Engineering Standard Glossary)
✓ ISO/IEC 14764:2006 (software maintenance)
✓ ISO/IEC 12207:2008 (software life cycle processes)

Content
Name and logo of the company that will
apply the guide
Software maintenance plan
Product name
Version
Produced by
Date
System Description

This section explains the operation of the system to be maintained.

A modification request (MR)

Priority table

Priority Table
Priority Applies if a problem:
✓ Prevents the performance of an activity essential for the
1 operation of the software.
✓ Compromise software security

✓ Negatively affect the performance of an essential operating

2
activity and there is no known temporary solution

✓ Negatively affect the performance of an activity essential to

the operation of the software, but there is a temporary
3
solution
✓ It may be inconvenient or annoying for the technician in
charge of the system, but a temporary solution is known.
✓ It presents discomfort to the user, but does not affect the
4 execution of essential activities and does not prevent the
fulfillment of their responsibilities.
5 Any other effect.
Modification request table

MODIFICATION REQUEST
Section I
Applicant's name: Reception date: System: Creator:

description of the problem Priority

1 2 3 4 5
Section II
MR number: Maintainer:

Priority Maintenance type:

Section III
Id option MR Status Date:

Analysis results:

Approved by:

Medium

The Process Implementation phase uses the following processes:

• Documentation
• Quality assurance
• Joint Review
• Management

Exit

✓ MR received
check

Fill out the MR History Record. This records the information generated from the moment it is
received until the MR is resolved.
MR HISTORY RECORD
MR ID Date of Date of State of Affected
reception analysis M.R. Documents

✓ Obtain the affected software and install it.

✓ Perform tests on the software to verify the reported failure and document the results
obtained in the MR Test Log.
MR TESTING RECORD

Test ID: MR ID: System Name:

Test Manager:
Aim:
Result
Obtained:

Task 1: Assign a priority to the MR. This priority will depend on the organization's policy
and will be recorded in the MR. Unlike the priorities in phase 1, the assignment of this
priority depends on who delivers it.

Task 2: Define the organization's requirements and propose at least three options to make
the modification.

Task 3: For each option, an estimate of the extent and magnitude of the modification must
be made, the impacts they will have on the system hardware and an analysis of the risks
that may arise.

Task 4: The maintainer recommends which would be the most viable option. All these
tasks must be recorded in template 4.
 OPTIONS REGISTRATION
MR ID: System name: Responsible:
Organization requirements:

ID Option Description Extension Impact Risks

Recommendation:

Task 5: Estimate the human and cost resources required by each option and
document them in the Resource Allocation Record. This estimate can also influence the
choice of the solution to implement.

RESOURCE ALLOCATION RECORD

Id MR: System name: Responsible:
Id Option No. People No. Hours Cost Observation

Documentation

Task 1: Verify that all proposed tests and options are properly documented in the
templates and update the MR History Record

Approval

Before making the modification to the system, the maintainer should obtain approval from
the MR. For this, the following tasks must be carried out.

Task 1: Present the MR, MR Test Record, Options Record and Resource
Allocation Record, for analysis by the Systems Department.
 Task 2: The maintainer will participate in discussions about the modification.

Task 3: Document the result of the MR analysis in the Modification Request

Analysis Record. In addition, Section II of the MR) and the MR History Record must
be updated. If the MR was approved, the rest of the activities will continue,
however, if the MR was denied, the reason will be recorded and the maintenance
process will end.

RECORD OF THE ANALYSIS OF THE MODIFICATION REQUEST

System Name:

Responsible):
MR receipt date:

Date
approval/denial:
Deadline:
Solution Description Reason for rejection
MR ID MR Status
Approved
Denied

Analysis Responsible:

Task 4: Detail the people who will be involved in modifying the system and the role
they will play and document it in the Work Team Registry.
WORK TEAM REGISTRATION
System Name: Id MR:
Maintainer:
Maintenance Detail Name and surname Role Observation
Conclusions and recommendations

The proposed software maintenance plan contributes directly to addressing quality

problems in the maintenance function of the Systems Department of the Salesian
Polytechnic University, suggesting a process methodology based on the ISO/IEC 14764
standard, and with this, continuous improvement in maintenance management in future
requirements.

The interpretation of the ISO/IEC 14746 standard in the process of generating this
maintenance plan will achieve results, quality, and productivity based on the iterations and
maintenance that occur. To the above, we can add analyzing the effects of the changes
made in maintenance on the personnel and applications involved over time.

Given the enormous efforts and costs dedicated to software maintenance, every company
must evaluate and consider best practices for maintenance. Thus, the creation of a
maintenance section/department or contracting maintenance is a topic of analysis.