Types of Documentation
Documentation is an important part of software engineering. Types of documentation include:
·Architecture/Design - Overview of software. Includes relations to an environment and construction principles to be used in design of software components.
·Technical - Documentation of code, algorithms, interfaces, and APIs.
·End User - Manuals for the end-user, system administrators and support staff.
·Marketing - Product briefs and promotional collateral.
Architecture/Design Documentation
Architecture documentation is a special breed of design documents. In a way, architecture documents are third derivative from the code (design documents being second derivative, and code documents being first). Very little in the architecture documents is specific to the code itself. These documents do not describe how to program a particular routine, or even why that particular routine exists in the form that it does, but instead merely lays out the general requirements that would motivate the existence of such a routine. A good architecture document is short on details but thick on explanation. It may suggest approaches for lower level design,
but leave the actual exploration trade studies to other documents.
Technical Documentation
This is what most programmers mean when using the term software documentation. When creating software, code alone is insufficient. There must be some text along with it to describe various aspects of its intended operation. It is important for the code documents to be thorough, but not so verbose that it becomes difficult to maintain them.
Often, tools such as Doxygen, javadoc, ROBODoc, POD or TwinText can be used to auto-generate the code documents—that is, they extract the comments from the source code and create reference manuals in such forms as text or HTML files. Code documents are often organized into a reference guide style, allowing a programmer to quickly look up an arbitrary function or class
User Documentation
Unlike code documents, user documents are usually far divorced from the source code of the program, and instead simply describe how it is used.
In the case of a software library, the code documents and user documents could be effectively equivalent and are worth conjoining, but for a general application this is not often true. On the other hand, the Lisp machine grew out of a tradition in which every piece of code had an attached documentation string. In combination with
strong search capabilities (based on a Unix-like apropos command), and online sources, Lispm users could look up documentation and paste the associated function directly into their own code. This level of ease of use is unheard of in putatively more modern systems.
Typically, the user documentation describes each feature of the program, and assists the user in realising these features. A good user document can also go so far as to provide thorough troubleshooting assistance. It is very important for user documents to not be confusing, and for them to be up to date. User documents need not be organized in any particular way, but it is very important for them to have a thorough index. Consistency and simplicity are also very valuable. User documentation is considered to constitute a contract specifying what the software will do
Marketing Documentation
For many applications it is necessary to have some promotional materials to encourage casual observers to spend more time learning about the product. This form of documentation has
three purposes:-
1. To excite the potential user about the product and instill in them a desire for becoming more involved with it.
2. To inform them about what exactly the product does, so that their expectations are in line with what they will be receiving.
3. To explain the position of this product with respect to other alternatives.
One good marketing technique is to provide clear and memorable catch phrases that exemplify the point we wish to convey, and also emphasize the interoperability
of the program with anything else provided by the manufacturer
Tuesday, January 20, 2009
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment