The main purpose of software maintenance is to modify and update software applications after

delivery to correct errors and improve performance.

Reasons for maintaining code

Software solutions need to be regularly upgraded to add new functionality, improve existing
weak aspects of the software and to adjust to new and evolving technologies.

Possible reasons for maintenance (as subheadings):

- Changing user requirements
- Upgrading user interface
- Changes in data to be processed
- Introduction of new IT
- Changing organisational focus
- Changes in government requirements
- Poorly implemented code
#Reasons will be overlapping

Changing User Requirements

When users’ requirements change, modification of the existing functionality and/or adding new
functionality into the software is required in order to respond to the users.
For example:
- Users need to run the software on different platforms, software needs to adjust and
adapt to that platform
- Users use new operating systems etc.

Upgrading User Interface

As UI is the medium in which users would interact with to use any software, adjustments made
to the UI will affect the users’ ways of interacting with the software. Developers must upgrade
the software so that it is still consistent with the new UI.
For example:
- Windows 10 introduced dark theme, it is best for the software to include this functionality
as well to keep consistent with the UI

Changes in the Data to be Processed

When the structure and/or format of the input data changes, modification to the software is
needed. This often occurs as many system uses the output from another system as data input,
when the other system changes, it will affect the data input of the system.
For example:
- defining a new field in a database will change the output
- Change of real-life data, NSW postcode including 1xxx
Introduction of New Hardware or Software
As hardware is intimately linked to software, new hardware alters the ways in which software
operates, such as, new CPUs, memory, peripheral devices.
Software applications also rely on other software to operate, namely the OS.
Maintenance is required to allow the software to utilise the new features that the new
technologies have.

Changing Organisational Focus

Organisations itself changes over time, some grow, others shift their ways of operation or
changes industry. Software solutions need to update along with those changes.
Continuous maintenance is especially critical in large organisations.

Changes in Government Requirements

Government legislation may directly impact on software solutions, it is the developer’s
responsibility to make sure the software is modified to comply with the law. Some legislations
are direct to the software itself, others may be more common for example, changes in tax rates
and privacy/security online.

Poorly Implemented Code

Although software has been tested and evaluated prior to release, it is almost never free of
problems. Modifications should be made as the problems are being discovered. One reason
why the code may be poorly implemented is due to the age of the software, better ways of
implementing the code could have been not discovered yet, thus, it is preferable to modify such
software if understanding isn’t a problem.

Features in source code that improve its maintainability

Maintainability is a measure of how easily code can be understood and modified by future
developers.

Use of Variables or Constants Instead of Literal Constants

Constants are the values that do not change (and do not want to change). Eg. 𝝅
Literal constants are particular values. E.g. (‘a string’ , 123) The use of literal constants
throughout the code is independent of each other, if the developer wishes to change the value
of the literal constant, changes must be made manually to all the literal constants. E.g. change
in 10% of GST.
To overcome this need for manual change, programmers use variables instead of literal
constants so that when the identifier of the variable is called, the reference is passed to the
code and all the references lead to the 1 variable only, hence, altering the variable can alter all
areas of code at once. Modern languages include the facility of a declared constant which
allows the constant to be unchangeable in case of future mistake accidentally changing the
value of the variable. In this way, the need for meaningful identifier names is vital for the code to
be understood whilst avoiding predefined constants in the language itself, this applies to
variables, subroutines and module names.
Explanatory Comments in the Code
Comments should be integrated throughout to explain many components of the source code,
especially if it involves nested loops/functions. It is best to comment on what this part of the
code does instead of describing how it does this. This is because the process may alter in the
future and will create confusion if the comments don’t match and because it's likely to be
unnecessary as it is a programmer reading it. It is also necessary to comment on where
changes have been made, when and why including the developers’ name. In this way, the
source code is accounting for the evolution itself.

Use of Standard Control Structures

Standard control structures include sequence, decision and repetition in each of their
recommended form. (when to use post-test/pre-test, when to use if in/while …) All problems can
be solved using standard control structures so there is no reason not to use it even if it works.
Be mindful of the future disasters that legacy code may cause.

Appropriate Use of White Space within Source Code

Legibility is important. Space out between separate groups of code. Don’t fit everything
squashed in 1 line even if it’s possible. (not clever)

The mainline (main program) needs to be uncluttered. This should be done easily as it is most
likely a series of function/module calls and is a great determiner of the top-down approach.
Thus, it should be one logical task per subroutine.