An application maintenance has multiple purposes, support the end users, fix/repair newly detected bugs and deploy new features.

Support the end users:

The first goal of the application maintenance is to support the end users much like inform the garden visitors on our plants. To do this we will help our users to understand how the application works or by training them or even by assisting them to use a complex feature like configuring their very own report.

Repair newly detected bugs

It can sound counterintuitive, but even after a good testing campaign it is still possible to find some bugs in the application. This is due to a multitude of factors:

  • We now have more users in the application that can find and report bugs
  • The pesticide effects the more we test one place the fewer bugs you find in it but you don’t know if you would have found other bugs if you had tested differently
  • It is not possible to test everything in the application as it would take too much time
  • Some operations can fail due to external factors requiring the system to be re-started for example
  • New features that were not part of the initial test campaign

Luckily for us, unlike a real garden, bugs will not constantly come back as time goes the occurrence of bugs will slowly but surely decrease.

New features

Finally, just as the business grows and evolves the users follow the same path thus requiring new features in the application. These new capabilities will probably turn around enhancing the existing ones or implementing new modules for which the time lacked during the implementation phase, or a new business process linked to new products. In a garden, this would translate in optimizing the plant disposition or creating a new pound to host different plants that wasn’t in the initial design.

The essential Concepts

To organize and lead a successful applicative maintenance there are a few concepts which need to be mastered by all the people implied on the project, just like the gardener who knows when to water or cut a plant.

When presenting the concepts and the activities in the section below we will refer to tickets as a task to be completed to maintain the application. These tickets are managed in a system where all the stakeholders of the project have access to them and know in which state each ticket is. This system can be hosted by different software like Jira or Azure DevOps or any other software manager.

The four levels of maintenance:

Apart from the level 0, the other three levels can be completed by an external entity. When running a maintenance project, it is important to know who, or which entity is responsible for each level of maintenance.

The difference between an anomaly (bug) and an evolution:

An anomaly refers to any failure, incident, malfunction, incompatibility, bug or blockage, degradation of performance or security level, and/or non-compliance of all or part of the solution to the specifications which prevents the normal use and/or operation of the solution. Anomalies are categorized into three levels, based on criticality, or impact on user activity, see next concept. This would be the weeds and bugs that are sprawling all around the garden.

An evolution is a request that is not expressed in the original solution definition or that is in contradiction with a previous requirement. Indeed, an evolution cannot be reproduced in the application as there are no implemented user story that answers this need, but they can be some workarounds.

The three levels of severity of an anomaly are …

Critical anomaly is characterized by the following elements:

  • Anomaly which makes it impossible to operate or use all or part of solution and required urgent correction, without any workaround.
  • There is a freeze on the activity of the company

Major anomaly is characterized by the following elements:

  • Anomaly which blocks one or more stages of the process and thus degrades the normal operation or use of all or part of the Solution.
  • Business can continue, but with deteriorated conditions that must remain temporary.

Minor anomaly is characterized by the following elements:

  • Anomaly that is neither Critical nor Major, and in particular any anomaly that does not affect the operation or use of the solution.
  • Users can use all or part of the solution, with minimal impact on business execution.

We can note that from on organization to another depending on the severity of the anomaly a specific deployment can be prepared this is due to the different service levels agreement that have been agreed upon the users and the organization that will treat the tickets.

The life cycle of a ticket

Like plants the tickets have their very own life cycle from the seed to the majestic plant. The life cycle can change from one project to another but the are some essentials states that they have to go through before being Closed/Deployed:

How is an applicative maintenance run?

Now that we know why and that we master the concepts of the maintenance let’s take a look at which activities the maintenance governance will organize on top of the road map.

When operating the maintenance, we can find four activities that each have their own specificities.

Reporting

The reporting activity consist in collecting all the incidents found by the users and gathering all the available information on it in order, to reproduce it or document an eventual specification. Not all the incidents will become tickets in the system as some of these incidents could be due to a lack of training form the user or depending on the organization in place it is possible that level 1 and level 2 incidents will not be reported in the ticketing system.

Qualification

The qualification of a ticket is a sorting step where the team decides together on some characteristics of the ticket like bug/evolution, software editor incident or not, attribute the ticket to a domain of the application like the change process in a PLM software,… The idea behind is to attribute the ticket to the correct team to find/test the solution.

From one project to another a sub activity could also be necessary, it’s the validation of the implementation of the tickets, this consideration applies mostly for the evolution tickets.

Implementation

The implementation is where all the fixing or the designing is done by the development team on the tickets it has been agreed to work on. It is important to note that once it is ready it is then available for the process owners or product owner to test so that they can accept the tickets to be deployed in the production environment.

Deployment

Once a ticket is ready it is then sent in a waiting list for the next deployments. We can think of each deployment as a preparing a planting season where each seed is a correction/enhancement to deploy that is waiting for the correct season to be put in the ground. The size and the complexity of the application will determine the frequency of the deployments.

In conclusion

Maintaining the application is essential to support the software users, fix the bugs and implement new features in the application. To do this it is important to report the incidents, categorize them, implement the solution and deploy them in the solution while applying the different concepts all the long of the ticket’s life. The key factors for a successful maintenance are visible key users that will directly help/support the users and a governance that will establish a clear road map and efficiently orchestrate the different parties to fix and enhance the application. So just like a well-kept garden which is the keeper of a diverse biodiversity and host for new wildlife, a well-kept software will be the guardian of your information and be the place that will spark new ideas.

 

Author: Jonathan Munoz, Inensia PLM Consultant 

About Polina Todorova