The moment when a painstakingly crafted application starts its public life is a major event. After months of work, the final product finally sees the daylight and is ready to perform its role. But... what comes next? One might think that it is the moment when the collaboration with a software house ends. But that would be very far from the truth.
The moment when a painstakingly crafted application starts its public life is a major event. After months of work, the final product finally sees the daylight and is ready to perform its role. But... what comes next? One might think that it is the moment when the collaboration with a software house ends. But that would be very far from the truth.
A natural and (necessary) step to be taken soon after launching the finished application is reformatting the collaboration with its authors in the direction of code maintenance and ongoing supervision over it. It is worth noting here that the fact that the application has been launched does not mean it will be working perfectly and in a bug-free manner. The productive start is preceded by a series of tests (which we wrote more about HERE) performed by software house specialists, while the final version of the application is tested by end users.
In spite of making the best effort to eliminate any possible shortcomings, it may happen that certain defects are discovered in the course of using the product. What is the cause of that? Even if an application is created according to client’s requirements and tested with taking the majority of possible scenarios into account, it may still surprise us in “field” conditions. The user may initiate a scenario that was not predicted at the test phase and thus generate the necessity to fix the gap so discovered.
These and other surprises are what accompanies the launch of almost every application. It is worth underlining that they do not result from insufficient knowledge or negligence on part of the developers. Every IT project is a very complex implementation that is modified and improved multiple times in the course of its creation. Thus, certain errors are impossible to avoid and, in a way, they are an inherent element of application life cycle. What testifies to professionalism of a software house is its efficiency in removal of malfunctions and proactive approach towards this important and difficult stage of collaboration.
After finishing the comprehensive testing stage we might ask ourselves: “What is the point of maintaining a new application if everything is brand new and working?”. However, it is worth paying attention to the fact that an application with all its complexity requires consent supervision, updating and development in order to remain useful to a given business for many years.
The application maintenance process starts smoothly. On one hand, it seems to be begun at the moment when user tests are finished and project documentation is created. On the other, however, maintenance is already in progress as of the moment of introducing the initial patches, when developers introduce the first improvements.
Usually, the application maintenance processes are handled by the same software house that created a given tool. It is a natural course of collaboration continuation, providing the client with access to specialists they already know (although it may happen that the solution maintenance processes are handled by a different team within the same company), the same collaborations standards, and, first and foremost, to creators of a given solution, which is often of utmost importance. All in all, no one knows an application as well as its creators.
Irrespective of whether it is the same software house that undertakes maintenance or a new partner that the client starts collaboration with, the process of handing the application over from production to maintenance has its own set of rules and should proceed in accordance with the art.
During the application creation process, a detailed documentation of the whole project is created that describes in detail the individual functions and relations between them - which entails describing every single element of the application created. It is both an indispensable source of knowledge for the maintenance team, and for the users themselves, who should find, out of principle, the answers to many of their questions there. Depending on the degree of technological advancement of a given application, the project documentation may be even hundreds of pages long, and the quality of its execution is also a measure of quality of a software house’s work.
When the documentation is ready, it is time to transfer the knowledge. It consists in a cycle of trainings and passing on the know-how of the whole project between developers and maintenance engineers on one hand, and on the other in trainings of end users who need to learn well all the complexities of the new solution in order to be able to use it efficiently.
The knowledge transfer stage is extremely important and must not be omitted. The developers have to provide both the team that is supposed to handle maintenance and the user, within the scope of their needs, with the maximum support possible, answers to all the questions and the whole set of information required to use the finished product successfully.
Although we already know how important it is to entrust the sphere of maintenance to a team of professionals, it is worth making a brief summary of the fields under its “jurisdiction”:
The notions of an “incident” and an “error/defect” are often used next to each other and confused: To start, one should underline that every error is considered an incident, but not all incidents are errors.
According to the “Dictionary of tester notions”, incident is any event within the system that requires investigation. It does not necessarily have to lead to detecting an error or even a software malfunction, but according to the art and all the rules of maintenance, it has to be verified and classified, either as a minor bug or warning, or as a prelude to actual problems.
Detecting incidents often takes place thanks to IT environment monitoring systems, which alert the maintenance team of the indicators set being exceeded. They are also detected by the users themselves, who report potential hazards to the team of specialists, who check and describe them and - if necessary - implement the appropriate actions.
Incident monitoring is the key to efficient functioning of every IT solution. It often enables reacting on time to a potential threat even before it leads to a serious malfunction, the consequences of which would have had a severe negative impact on functioning of the client’s business.
A change request, commonly referred to as a CR, means minor and major improvements and changes initiated by the users that have impact on the comfort of using the system. In the course of using the application it may turn out that, for example, the “Print” button should be located in the bottom section of the window, not the top one, or that there is no “Print” button at all and the user has to make a number of unnecessary clicks to use that command.
That is exactly the kind of moment when it is necessary to submit a CR the object of which is moving the button or adding it. It seems to be a simple action, but on one hand it increases the comfort of using the application tremendously, and on the other it requires implementing the change execution procedure by the maintenance team. For every change in a given application has to be included in the design documentation and described in detail, as well as subjected to standard test procedures.
It is a good thing if a software house has a special system for managing CRs, that is, a place where they can be reported and where the progress of works can be monitored. However, in case of small projects it is often sufficient to communicate via e-mail or make arrangements during meetings.
Service Level Agreement (SLA) is one of the basic notions related to establishing collaboration with a software house, especially with regard to the sphere of maintenance. SLA helps establish the framework of collaboration and the indicators desired, as well as specify the client’s expectations and translate them to contractual provisions.
SLA may indicate the minimum system availability time, time of reaction to individual reports, or percentage of errors removed from the system prior to expiration of a specific period. This field of the collaboration contract is often subject to hard negotiations but is indispensable for the purposes of a well-planned collaboration.
Without the framework provided by the SLA, the collaboration could be disappointing to the client and the lack of rigid framework could lead to many misunderstandings that might in turn make the collaboration, the incident resolution process and other activities much more difficult. That is why it is worth dedicating as much time to negotiating the SLA as necessary.
We now know what the mysterious CRs and SLA are and what the meaning of maintenance is. But how is one supposed to choose the company that would take over the care over the application maintenance field and provide the highest possible standard of provision of such services?
We often decide to continue collaboration with the software house that created a given piece of software. However, if for some reason we have to seek a different one on the market, it is a good idea to remember the following three hints on what to pay attention to: