Good software is never finished. The need for software maintenance arises the moment a software solution goes into productive operation. A number of actions need to be taken so that patches and updates can be applied as required. Updates also frequently become necessary due to changes outside the organisation. New browser versions, security vulnerabilities in participating software products and new operating system versions make it necessary to constantly check all functionalities.
And neglecting software maintenance can lead to serious problems. So how should you plan your maintenance effort so that the solution continues to operate sufficiently well and the economic and technical risks remain at a level that is acceptable?
Definition of software maintenance
The term “software maintenance” often means different things to different people. In this article, we use the following definition to bring about a uniform understanding:
Software maintenance includes all software development activities that aim to ensure that the software will continue to meet all requirements that are currently being met.
In short, successful software maintenance maintains the “status quo”, that is, it ensures that the solution can continue to be used without modification.
In contrast to software maintenance, we always use the term “change” when the aim of the software development activities is to add, modify or eliminate one or more requirements that the solution is supposed to meet.
Various maintenance requirements in each operating phase
Start-up phase
At the beginning of the operating phase, referred to here as the start-up phase, two special effects can occur:
The first effect occurs when not all requirements are fully met at the time of the go-live (placement into service with nonconformities). If you apply the previously specified definition of software maintenance to this effect, you will see that these nonconformities are not formally an issue for software maintenance (as these requirements were never met). It is therefore of great importance in the go-live to not only determine nonconformities of a functional nature but also to record the nonconformities relating to all other requirements and thus determine the precise goal of future software maintenance.
The second effect could also be referred to as “maintenance gridlock”. It comes about when changes in the boundary conditions that occur during the production phase of the custom solution are not continuously taken into account or cannot be taken into account due to the contractual situation. In this case, the need for software maintenance arises immediately after the solution is put into service, which can occasionally lead to a lack of understanding on the part of the client.
Productive phase/operating phase
In terms of content, software maintenance is a standard process in the productive phase. However, the organisational framework is crucial for successful maintenance. Can and should maintenance activities be carried out on a defined schedule? Can maintenance activities be carried out in parallel, and thus more cost-effectively, with planned changes to the solution? Are maintenance activities related to a release cycle of other software components that are independent of the solution? The wide variety of questions shows that it is not possible to give a blanket answer to the question of the best way of doing things – rather, a tailored and flexible approach must be taken.
End-of-life phase (and beyond)
No later than the last productive phase of the solution, the question arises as to whether software maintenance is still worthwhile at all. After all, the solution will be switched off in the near future, so minor deviations from the requirements can be tolerated to save costs and effort.
This argument is correct. However, you always need to consider the risk that the schedule for taking the software out of service may be delayed (such as due to the delayed rollout of a successor solution) or that non-productive operation of the solution may be required for some time after decommissioning.
In this case as well, experience has shown us that the costs for maintenance expenses rise disproportionately if they have been neglected over an extended period of time.
Bottom line
Software maintenance is a crucial way to ensure the long-term functionality and business utility of a custom system. Since maintenance is not the primary focus of business users, it is advisable already during the rollout phase to define a strategy for attendant maintenance according to your risk assessment. Particularly for systems with medium to high business criticality, it is worthwhile to perform explicit software maintenance on a regular basis over the entire lifetime of the solution.
0 Comments