Currently, no one is surprised, that the release of the first stable version of a software does not only cease its development, but most often constitutes a milestone that initiates further work phases. One could seem, that at the beginnings of IT history, the situation was quite different. However, this belief is not exactly correct - support and maintenance have been with us for decades, evolving with subsequent norm iterations.
What do we need maintenance for?
You could say that one of the first attempts to notify on the necessity of maintenance works are the laws formulated by Manny Lehman, a Computing Science professor at the Imperial College London and Middlesex University, as well as, an expert in software evolution. Already in 1974, Lehman formulated his first law regarding the so-called Continuing Change. The law states, that an E-type system must be continually adapted or it becomes progressively less satisfactory. In all, Lehman proposed eight laws, the last of which seeing the light of day in 1996.
The following Lehman’s laws state i.a. that as long as there are no maintenance works performed, as long the complexity of software will increase. It leads in a straight line to the software entropy phenomenon, and to erase this issue proves to be a very complex, time-consuming and costly process. In the majority of cases even refactoring the entire code is necessary. That is the kind of thing, maintenance works are supposed to prevent.
Therefore, let us look, what maintenance types are accomplished currently, what are the most popular strategies, as well as – how to select them properly.
Types of maintenance
What seems obvious in terms of procedures related to software development, it is difficult to create unified and coherent systematic. Particularly – as we have already established – maintenance works are a phenomenon that is long-lasting, evolving and adjusting to the current reality. The initial point is to establish, that maintenance begins when providing the end customer with a fully-fledged stable version of the product. Then, the path may go in two different ways.
According to the distinction adopted by the Road to Reliability organisation, the first path is focused on preventive measures. It can be presented as all actions leading to the modification of the code that had already been released to the customer, in order to correct any mistakes, which were found, e.g. during functional testing. According to numerous paradigms, the preventive actions also include such works on optimisation and changes resulting from risk evaluation regarding the expansion of functionalities of the program in the future.
Second approach is corrective maintenance. The strategy does not refer to actions aiming to i.a. evaluate the risk of a problem occurring, or whether it requires fixing. Contrary to preventive maintenance in corrective maintenance, an element is fixed only if it fails. Obviously, that refers only to a situation, when the given issue does not affect the stability of the entire programme, or its security. Within corrective maintenance, large role may be played by feedback data gathering software. If the issue is not severe, but users tend to post about it, the corrective approach is used.
A different taxonomy from the one proposed by RtR, is presented by the currently operational norm regulating maintenance works, i.e. ISO/IEC 14764. The norm introduces a division into four main categories: apart from already known preventive and corrective maintenance, adaptive maintenance was added – activities aiming at such software modification, in order to adjust it to changing reality, along with customer’s new clients – as well as, perfective maintenance, i.e. all sorts of optimizations that translate to increase in performance, broadly perceived perfecting of already existing and working code.
What is effective support and maintenance?
On the issue of strategy of maintenance works, there is plenty to choose from. As in the case of numerous aspects of works on software development, it is necessary to adjust work mode to the specifics of the solution itself, as well as, the capabilities of the organisation which will take on maintenance tasks – it is not simply about finances (however, we must remember, that maintenance may generate enormous cost, often surpassing the cost of pre-release development), but also about organisation and staff. Therefore, a reasonably planned maintenance strategy must be accompanied by high quality support.
In the recent years, the methods of offering support have diversified. Apart from phones and e-mails known for years, there are plenty of new trends: social media, chats, videoconferencing as well as chatbots are being used on a broad scale. Hence, high quality support will be backed not only by a qualified staff of consultants, but also the largest and most varied number of channels possible, due to which customers may contact support specialists. Already, numerous companies are proactive, and in the case of central infrastructure breaking down, informs the users on the issues before they even contact the company, or even realise the issues with accessibility to the solution.
Numerous, often free instruments for automation of the technical support process, e.g. the aforementioned bots, are helpful in providing high quality technical support. No more are they primitive machines used to respond to the most submitted issues – they are backed by advanced, self-learning engines for natural language processing, causing each customer’s contact with the bot to be better than the previous one. This way, using modern support tools, we not only provide information for the maintenance department but also increase the satisfaction of end users.
We believe that the real-life of your product begins with its implementation. By entrusting it with experienced support and maintenance specialists you can observe its success but also ensure that it is well protected and taken care of if before the unexpected happens.
Read more about the support and maintenance services and fully benefit from your product’s possibilities!