There are two aspects to documentation quality: the process and the product. Documentation process quality focuses on the manner in which the documentation is produced (for example, whether or not an organization follows a systematic approach to document development that is closely aligned with the rest of the software process). Documentation product quality is concerned with attributes of the final product (for example, whether or not it uses standardized representations like the Unified Modeling Language (UML)  in graphical documentation).
The Documentation Maturity Model (DMM) is specifically targeted towards assessing the quality of software system documentation used in aiding program understanding.
The process component of the DMM is a five-level staged maturity model. It is based on the Software Capability Maturity Model (CMM) created by Carnegie Mellon University’s Software Engineering Institute . The product component of the DMM is centered on a set of key product attributes.
The DMM’s process maturity levels are currently an exact copy of the CMM’s levels. The five process maturity levels of the DMM provide a foundation for continuous documentation quality improvement. The five levels are as follows: Initial, Repeatable, Defined, Managed, Optimizing
A significant amount of work has been done in defining and evaluating documentation quality. However, the focus of much of this work was on guidelines for technical writers and editors producing manuals targeted towards end users; <samir> no source or references given for this statement there are international standards related to documentation products. For example, ISO/IEC 18019 (2000) provides guidelines for the design and preparation of software user documentation.
There is also an ANSI/IEEE standard 1063 (1987) on software user documentation.
In the seminal report IBM produced in 1983, called “Producing Quality Technical Information” (PQTI), they wrote, “technical information that meets all the requirements is quality information” . This concept of documentation quality is illustrated by showing both requirements and examples. At the end of the report, PQTI provides a checklist for reviewers to ascertain whether or not these requirements are met.
In 1998, after several iterations within IBM, a new book called “Developing Quality Technical Information: A Handbook for Writers and Editors” was published . This book expanded the original seven quality attributes into nine, which are grouped into three main categories. The categories are “Easy to Use,” “Easy to Understand,” and “Easy to Find.” The book also provides a procedure for reviewing and evaluating technical information according to these criteria.
Determining and assessing quality is complex, and no single report and checklist can guarantee the development of quality document. A recent article by Karl Smart pointed out one of perceived limitations of the PQTI: its lack of “contextual framing of documents” . Smart classified dimensions of quality into three categories, which suggest their relative importance: essential, conventional, and attractive.
level 1: manual
2: semi-automatic & static
3: semi-automatic & dynamic
4: automatic & static
5: automatic & dynamic
format: textual, graphical