0. Introduction

Introduction
Many organisations have had applications developed by non professional developers without the foresight to properly document their applications (if at all); over time the applications grow and change beyond their original minimal remit, sometimes to the stage of becoming critical to the operation of an organisation in all or part. It gets even more difficult if the original developer leaves and other people need to maintain their work without having the time to redevelop it from scratch properly.
The tools, tips and tricks can also be useful if it is a commercial system but the supplier goes out of business or de supports the system and refuses to provide alternative cover.

This guide goes through the steps needed to understand an application and document it properly. In essence, it is simply the application to computer software of evidence based principles as used in scientific research. It is not a quick process at all, but the effort in doing this will reap rewards in terms of understanding your application and easing future maintenance and new development work. Not all examples will apply to all pieces of software or development platforms, so apply common sense to your own investigations.

I have written this without reference to specific technologies or platforms, so instructions for using them will not appear, but product names as examples of what I mean may show up from time to time.

This is designed as a high level set of steps to follow, with some details on what to do at that stage. It is split into separate sections, but they are not to be read and executed in a linear order - this is a highly iterative process.

As you progress through and get a greater understanding of aspects of your application, document it and put it somewhere obvious.
Don't let other people have to repeat your work in the future. Don't make any changes to the code until you have seen an application itself from end to end as changes may have unforeseen consequences.
Equally, if you find bugs or get issues reported to you while doing this process, just log them in the corporate standard issue tracking software. Don't attempt to remedy the situation until you are comfortable with the application from end to end.

The aim of this set of FAQs is that by doing this, you can get to a stage where:
i) the application is understood enough that it can be supported until such a time that it can be retired or replaced
or
ii) the application is good enough to meet corporate requirements for a supported system.

Good luck

Next section: faq669-7710