SYSTEM MAINTENANCE

Systems Maintenance

ALSO CALLED: IT Maintenance, System Maintenance, Support, Maintenance Management

Software, Information Technology Maintenance
DEFINITION: The modification of a system to correct faults, to improve performance, or to
adapt the system to a changed environment or changed requirements.

Software maintenance in software engineering is the modification of a software product after

delivery to correct faults, to improve performance or other attributes.[1]

A common perception of maintenance is that it merely involves fixing defects. However, one
study indicated that over 80% of maintenance effort is used for non-corrective actions.[2] This
perception is perpetuated by users submitting problem reports that in reality are functionality
enhancements to the system.[citation needed] More recent studies put the bug-fixing proportion closer
to 21%.

Also system maintenance can be sais as

Involves checking, changing, and enhancing the system to make it more useful in achieving user and
organizational goals.

IMPORTANCE OF SYSTEM MAINTENAMNCE

Importance of software maintenance

The key software maintenance issues are both managerial and technical. Key management issues
are: alignment with customer priorities, staffing, which organization does maintenance,
estimating costs. Key technical issues are: limited understanding, impact analysis, testing,
maintainability measurement.

Software maintenance is a very broad activity that includes error correction, enhancements of
capabilities, deletion of obsolete capabilities, and optimization. Because change is inevitable,
mechanisms must be developed for evaluation, controlling and making modifications.

So any work done to change the software after it is in operation is considered to be maintenance
work. The purpose is to preserve the value of software over the time. The value can be enhanced
by expanding the customer base, meeting additional requirements, becoming easier to use, more
efficient and employing newer technology. Maintenance may span for 20 years,[citation needed]
whereas development may be 1–2 years.

The results obtained from the evaluation process help the organization to determine
whether its information systems are effective and efficient or otherwise. The process of
monitoring, evaluating, and modifying of existing information systems to make required
or desirable improvements may be termed as System Maintenance.

Software maintenance planning

An integral part of software is maintenance, which requires an accurate maintenance plan to be
constructed during the software development. It should specify how users will request
modifications or report problems. The budget should include resource and cost estimates, and a
new decision should be addressed for the development of every new system feature and its
quality objectives. The software maintenance, which can last for 5+ years (or even decades) after
the development process, calls for an effective plan which can address the scope of software
maintenance, the tailoring of the post delivery/deployment process, the designation of who will
provide maintenance, and an estimate of the life-cycle costs.

Software maintenance processes

This section describes the six software maintenance processes as:

1. The implementation process contains software preparation and transition activities, such
as the conception and creation of the maintenance plan; the preparation for handling
problems identified during development; and the follow-up on product configuration
management.
2. The problem and modification analysis process, which is executed once the application
has become the responsibility of the maintenance group. The maintenance programmer
must analyze each request, confirm it (by reproducing the situation) and check its
validity, investigate it and propose a solution, document the request and the solution
proposal, and finally, obtain all the required authorizations to apply the modifications.
3. The process considering the implementation of the modification itself.
4. The process acceptance of the modification, by confirming the modified work with the
individual who submitted the request in order to make sure the modification provided a
solution.
5. The migration process (platform migration, for example) is exceptional, and is not part of
daily maintenance tasks. If the software must be ported to another platform without any
change in functionality, this process will be used and a maintenance project team is likely
to be assigned to this task.
 6. Finally, the last maintenance process, also an event which does not occur on a daily basis,
is the retirement of a piece of software.

There are a number of processes, activities, and practices that are unique to maintainers, for
example:

 Transition: a controlled and coordinated sequence of activities during which a system is

transferred progressively from the developer to the maintainer
 Service Level Agreements (SLAs) and specialized (domain-specific) maintenance
contracts negotiated by maintainers
 Modification Request and Problem Report Help Desk: a problem-handling process used
by maintainers to prioritize, document, and route the requests they receive

Reasons for maintenance

 Changes in business processes

 New requests from stakeholders, users, and managers
 Bugs or errors in the program
 Technical and hardware problems
 Corporate mergers and acquisitions
 Government regulations
 Change in operating system or hardware on which the application runs

TYPE OF SYSTEM MAINTENANCE

System maintenance is an ongoing activity, which covers a wide variety of activities,

including removing program and design errors, updating documentation and test data
and updating user support. For the purpose of convenience, maintenance may be
categorized into three classes, namely:

i) Corrective Maintenance: This type of maintenance implies removing errors in a

program, which might have crept in the system due to faulty design or wrong
assumptions. Thus, in corrective maintenance, processing or performance failures are
repaired.
ii) Adaptive Maintenance: In adaptive maintenance, program functions are changed to
enable the information system to satisfy the information needs of the user. This type of
maintenance may become necessary because of organizational changes which may
include:
a) Change in the organizational procedures,

b) Change in organizational objectives, goals, policies, etc.

c) Change in forms,

d) Change in information needs of managers.

e) Change in system controls and security needs, etc.

iii)Perfective Maintenance: Perfective maintenance means adding new programs or

modifying the existing programs to enhance the performance of the information system.
This type of maintenance undertaken to respond to user’s additional needs which may
be due to the changes within or outside of the organization. Outside changes are
primarily environmental changes, which may in the absence of system maintenance,
render the information system ineffective and inefficient. These environmental changes
include:
a) Changes in governmental policies, laws, etc.,

b) Economic and competitive conditions, and

c) New technology.

iv. Slipstream Upgrade

 Minor upgrade not worth announcing.

v.Patch

 Minor change to correct a problem or make a small enhancement.

vi.Release

 Significant program change that often requires changes in the documentation.

vii.Version

 A major program change, typically encompassing many new features.

Categories of software maintenance
E.B. Swanson initially identified three categories of maintenance: corrective, adaptive, and
perfective.[7] The IEEE 1219 standard was superseded in June 2010 by P14764.[8] These have
since been updated and ISO/IEC 14764 presents:

 Corrective maintenance: Reactive modification of a software product performed after

delivery to correct discovered problems. Corrective maintenance can be automated with
automatic bug fixing.
 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.

There is also a notion of pre-delivery/pre-release maintenance which is all the good things you
do to lower the total cost of ownership of the software. Things like compliance with coding
standards that includes software maintainability goals. The management of coupling and
cohesion of the software. The attainment of software supportability goals (SAE JA1004, JA1005
and JA1006 for example). Some academic institutions[who?] are carrying out research to quantify
the cost to ongoing software maintenance due to the lack of resources such as design documents
and system/software comprehension training and resources (multiply costs by approx. 1.5-2.0
where there is no design data available).

Maintenance factors
Impact of key adjustment factors on maintenance (sorted in order of maximum positive impact)

Maintenance Factors Plus Range

Maintenance specialists 35%
High staff experience 34%
Table-driven variables and data 33%
Low complexity of base code 32%
Y2K and special search engines 30%
Code restructuring tools 29%
Re-engineering tools 27%
High level programming languages 25%
Reverse engineering tools 23%
Complexity analysis tools 20%
Defect tracking tools 20%
Y2K “mass update” specialists 20%
Automated change control tools 18%
Unpaid overtime 18%
Quality measurements 16%
Formal base code inspections 15%
Regression test libraries 15%
Excellent response time 12%
Annual training of > 10 days 12%
High management experience 12%
HELP desk automation 12%
No error prone modules 10%
On-line defect reporting 10%
Productivity measurements 8%
Excellent ease of use 7%
User satisfaction measurements 5%
High team morale 5%
Sum 503%

Not only are error-prone modules troublesome, but many other factors can degrade performance
too. For example, very complex spaghetti code is quite difficult to maintain safely. A very
common situation which often degrades performance is lack of suitable maintenance tools, such
as defect tracking software, change management software, and test library software. Below
describe some of the factors and the range of impact on software maintenance.

Impact of key adjustment factors on maintenance (sorted in order of maximum negative impact)

Maintenance Factors Minus Range

Error prone modules -50%
Embedded variables and data -45%
Staff inexperience -40%
High code complexity -30%
No Y2K of special search engines -28%
Manual change control methods -27%
Low level programming languages -25%
No defect tracking tools -24%
No Y2K “mass update” specialists -22%
Poor ease of use -18%
No quality measurements -18%
No maintenance specialists -18%
Poor response time -16%
No code inspections -15%
No regression test libraries -15%
No help desk automation -15%
No on-line defect reporting -12%
Management inexperience -15%
No code restructuring tools -10%
No annual training -10%
No reengineering tools -10%
No reverse-engineering tools -10%
No complexity analysis tools -10%
No productivity measurements -7%
Poor team morale -6%
No user satisfaction measurements -4%
No unpaid overtime 0%
Sum -500%
[9]

Maintenance debt
In a paper for the 27th International Conference on Software Quality Management in 2019,[10]
John Estdale introduced the term “maintenance debt” for maintenance needs generated by an
implementation’s dependence on external IT factors such as libraries, platforms and tools, that
have become obsolescent.[11] The application continues to run, and the IT department forgets this
theoretical liability, focussing on more urgent requirements and problems elsewhere. Such debt
accumulates over time, silently eating away at the value of the software asset. Eventually
something happens that makes system change unavoidable.

The owner may then discover that the system can no longer be modified – it is literally
unmaintainable. Less dramatically, it may take too long, or cost too much, for maintenance to
solve the business problem, and an alternative solution must be found. The software has
suddenly crashed to £0 value.

Estdale defines "Maintenance Debt"[11] as: the gap between the current implementation state of
an application and the ideal, using only functionality of external components that is fully
maintained and supported. This debt is often hidden or not recognized. An application’s overall
maintainability is dependent on the continuing obtainability of components of all sorts from
other suppliers, including:

 Development tools: source editing, configuration management, compilation and build

 Testing tools: test selection, execution/verification/reporting
 Platforms to execute the above: hardware, operating system and other services
 Production environment and any standby/Disaster Recovery facilities, including the
source code language’s Run-Time Support Environment, and the wider ecosystem of job
scheduling, file transfer, replicated storage, backup and archive, single sign-on, etc etc.
 Separately acquired packages, eg DBMS, graphics, comms, middleware
  Bought in source-code, object code libraries, and other invocable services
 Any requirements arising from other applications sharing the production environment or
interworking with the application in question

and of course

 The availability of relevant skills, in-house, or in the marketplace.

The complete disappearance of a component could make the application un-rebuildable, or

imminently unmaintainable.