Software Maintenance Best Practices

Software Maintenance Best Practices

In our last post we took a look at The 4 Types of Software Maintenance, In this post we are going to dive into what some of the best practices are that actually save time and money in the long run. Our software maintenance best practices are;


Testing

Testing is a critical part of software development. The idea behind testing is simple enough to understand, it is there to stop issues in the software reaching live code. From the development point of view there are a couple of well used methods of testing:

Manual Testing:

Although this can be prone to human error, with a good testing plan it can be very effective. It is probably best suited to simpler software but is also used frequently in new projects with the idea that the second type of testing, below, will be implemented at a later date.

Automated Testing:

This has a huge speed advantage over manual testing, but is heavily dependent on both the quality of the tests written, and the coverage (how much the software is tested). The big disadvantage is that they take time and money to set up in the first place. There is no hard and fast rule but, automated testing for 75% coverage of the software will easily add 30% to the development time. It is nearly always worth it in the long run though.

Automated testing sounds like the best practice. However, in reality it is very difficult to get to above 90% coverage in all but the simplest applications. Therefore, a combination of manual and automated testing normally strikes the right balance for both coverage and cost to implement.


Documentation

Always up to date technical documentation for the software application can have a huge impact on both maintenance and new feature development. Developers are often working on multiple projects; new developers join the team and others leave, the role of the technical documentation is to bring someone up to speed on the software without having to spend hours going through lines of code to work it out. In fact, there are more than developers that need to know how the application works and they probably can't even code.

Good documentation will cover everything, from the development stack through to more specific details about how and why the software does what it does. It should include; system architecture diagrams, brand guidelines, test plans and details of what automated tests cover, the regular maintenance plan, release processes and so much more! Of course, this is changing all the time so it also needs to be regularly updated. A lot of development environments now include a wiki style feature that allows this all to be kept with the code of the software and updated changes are made.


User Training

This is not training the user how to use the software. This is training the users how to report an issue. The goal is that they report the issue in enough detail so that the issue can be replicated before being fixed. It doesn't have to be complex, just a quick guide into what makes up a great bug report.


Regular Maintenance

You may have thought that regular maintenance would have been top of our list rather than the bottom. The reason we put it last is that it includes a lot of what we have covered above, it is not just working on the code itself.

The trick to regular maintenance is to have a checklist to work through at set intervals. On smaller software applications you might have one checklist that you do on a monthly basis. On larger applications you might have several checklists, for example a weekly list, a monthly and an annual list.

Here are a few things we would include on our recommended plan;

Check Backups:

On a regular basis you should check that the backups you are expecting to be created are in fact being created. Modern backup procedures should notify you when something has gone wrong. This doesn't mean no manual checks should be made but it does mean this can be done very quickly.

At least once a year you should check that you can restore backup.

With every release, especially when new features are added, you should make sure the backup is still covering everything you need it to do.

Adaptive Maintenance:

We covered this in our previous post, to summarise, this is updating the complete software environment and making changes to the software, to keep it working as the rest of the environment changes.

Testing:

All new features and corrective maintenance will probably need the testing plan, covered above, modified and extended.

Documentation:

The technical documentation should be updated on a regular basis in line with the above.


Summary

Hopefully you are already at least doing some of the above bit don't worry if you are not. All of them can be implemented at any stage and the most important takeaway should be that the getting them in place will be more than worth the work involved. If you need help in implementing any of the above then please get in touch!

+44 (0) 1604 663690 | [email protected] | Unit 2 Basset Court, Grange Park, Northampton, NN4 5EZ

Instagram | Facebook | Full Metal Software





要查看或添加评论,请登录

社区洞察

其他会员也浏览了