|
It is very important to include all information that is to be used by all actors in the scene. It is also very important to update the documents as any change occurs in the database as well.
No
=== Technical documentation ===
{{Main article|Technical documentation}}
It is important for the code documents associated with the source code (which may include [[README]] files and [[API]] documentation) to be thorough, but not so verbose that it becomes overly time-consuming or difficult to maintain them. Various how-to and overview documentation guides are commonly found specific to the software application or software product being documented by [[API writer]]s. This documentation may be used by developers, testers, and also end-users. Today, a lot of high-end applications are seen in the fields of power, energy, transportation, networks, aerospace, safety, security, industry automation, and a variety of other domains. Technical documentation has become important within such organizations as the basic and advanced level of information may change over a period of time with architecture changes.
Code documents are often organized into a ''reference guide'' style, allowing a programmer to quickly look up an arbitrary function or class.
==== Technical documentation embedded in source code ====
Often, [[Documentation generator|tools]] such as [[Doxygen]], [[NDoc]], [[Visual Expert]], [[Javadoc]], [[JSDoc]], [[EiffelStudio]], [[Sandcastle (software)|Sandcastle]], [[ROBODoc]], [[Plain Old Documentation|POD]], [[TwinText]], or Universal Report can be used to auto-generate the code documents—that is, they extract the comments and [[Design by Contract|software contracts]], where available, from the source code and create reference manuals in such forms as text or [[HTML]] files.
The idea of auto-generating documentation is attractive to programmers for various reasons. For example, because it is extracted from the source code itself (for example, through [[comment (computer programming)|comment]]s), the programmer can write it while referring to the code, and use the same tools used to create the source code to make the documentation. This makes it much easier to keep the documentation up-to-date.
A possible downside is that only programmers can edit this kind of documentation, and it depends on them to refresh the output (for example, by running a [[cron job]] to update the documents nightly). Some would characterize this as a pro rather than a con.
===== Literate programming =====
Respected computer scientist [[Donald Knuth]] has noted that documentation can be a very difficult afterthought process and has advocated [[literate programming]], written at the same time and ___location as the [[source code]] and extracted by automatic means. The programming languages [[Haskell (programming language)|Haskell]] and [[CoffeeScript]] have built-in support for a simple form of literate programming, but this support is not widely used.
===== Elucidative programming =====
Elucidative Programming is the result of practical applications of Literate Programming in real programming contexts. The Elucidative paradigm proposes that source code and documentation be stored separately.
Often, software developers need to be able to create and access information that is not going to be part of the source file itself. Such [[annotation]]s are usually part of several software development activities, such as code walks and porting, where third-party source code is analysed in a functional way. Annotations can therefore help the developer during any stage of software development where a formal documentation system would hinder progress.
=== User documentation ===
| 