What are the core elements to include in Support Documentation?

Question

I have created an application which needs 'hand-over' to the support group in the next month.

The application is fairly small (2 months development), and consists of two client side applications and a database, it's written in c# for the windows platform.

I have a broad idea of what to include in a support document, but I haven't needed to make very many support documents so far in my career and I want a solid list of items to include.

I guess my goal is to make the lives of everyone in the support group easier and as stress free as possible.

So I guess my questions are:

1. What should a support document absolutely contain

2. What additional things have you put in support documents to make them extra useful.

3. What other activities can be done before hand-over to make all our lives easier?

Solution 1

Having been on both sides of this process professionally, I can say that the following should be mandatory:

• the documentation of the code (javadoc, doxygen, etc)
• details on build process
  • where to get current source
  • how to file bugs (they will happen)
  • route to provide patches either to the source or to customers
• how it works (simple, but often overlooked)
• user-customizable portions (eg there is a scripting component)
• primary contacts for each component, aka escalation path
• encouragement for feedback from Support as to what else they want to see

I'm sure lots of other things can be added, but these are the top priority in my mind.

Solution 2

1. Functional Specification (If you have one)
2. User Manual. Create one if you don't have
3. Technical Manual, Containing
   • Deployment Diagram
   • Softwares Used
   • Configuration and build details
   • Deatils of Server ip and admin / oracle / websphere passwords
4. Testing Document
5. Over view document giving out
   • Where all documents are kept
   • Version Control repository and its project/ user details
   • Application usernames / password
6. Any support SQL's/tools etc created by the development team, for analysis, loading data etc.

Solution 3

1. Include Screenshots of operations and output.
2. Prefer "online easily update-able" doc (wiki-like) instead of paper or pdf.
3. If online, make it searchable and cross-linked.

Comments

[warren]

see also cnx.org/content/col11350/latest

[Grateful]

Could someone elaborate "user-customizable portions (eg there is a scripting component)"? In particular, what does it mean by "user"?

[warren]

@Grateful - a "user" == "enduser". Ie a "customer" - or whomever is going to be stuck with using this thing later :)