| 1.
Documentation
Plan Scope |
This
Software Documentation Plan (i.e., Plan) was developed for Project XYZ
and complies with company requirements for software documentation
management. NOTE:
“plan” (small “p”) refers to other plans.
This section identifies the policy; objective; purpose; assumptions,
constraints, risks and dependencies; and overview of this Plan.
This section identifies for this Plan’s users the extent and
limitations of the documentation management methodology and must contain
a clear, concise description of the documentation management
methodology. It is critical
for readers of this Plan to clearly understand the terminology and
methodology used.
This Plan must fit in with any other plans, e.g., Configuration
Management and Project Management Plans.
Prior to, or as part of, writing this Plan, a set of clearly defined
processes must be established. As
defined later, it is recommended that this Plan make reference to these
processes (rather than include them in this Plan) and provide a summary
of the key processes. This
is to minimize changes to this Plan if any process changes.
Thus, try to be as comprehensive as possible, but some detailed
information is better presented in a Reference Section/Appendix or made
part of the referenced processes used to implement this Plan.
This Plan may be updated due to a change in planning, e.g., managed
documentation or tools. As
with any documentation, changes to this Plan follow the documentation
change control process described in this Plan.
The approved review results are documented in the Amendment
History Section. As much as
possible, figures and tables are used to provide documentation
management information to help in the maintenance of this Plan.
|
2.
Documentation
Plan Objective
|
This Plan defines
the required project documentation and the processes, resources,
schedule, etc., needed to produce this Plan’s identified documentation
(see the Managed Plans, Documents and Reports for this Project Section),
including change control and documentation maintenance.
This Plan contains all the material or references needed for a
person to understand the Project’s documentation management
methodology. This Plan’s
contents are based on user and Project requirements, standards and
expectations. As the
Project evolves, this Plan is evaluated by the Documentation Manager for
consistency with Project changes and to ensure consistency with other
Project plans.
This plan emphasizes the users’
needs, and ensures the Plan’s objectives and purpose are consistent
and complement Project requirements and other Project plans.
|
| 3.
Documentation
Plan Purpose |
| This
Plan satisfies ISO/IEC 12207:2008, Software life cycle processes (2008) Clause 6.3.6 Information Management
Process. This Plan identifies and describes: |
| a. |
What
is managed, i.e., the software documentation under configuration control
of this Plan. |
| b. |
a.
How to manage this controlled documentation, i.e., high-level
description of the main processes and tools.
References are given for process details. |
| c. |
Documentation
management roles and responsibilities. |
| d, |
When
key documentation milestones and activities occur
|
For
this Plan, the term “product” includes all documentation prepared
for delivery to a customer (e.g., hardcopies (paper) and electronic
copies, and the final product) and documentation used internally (by the
developing or maintaining organization) to build a user product.
Even for small projects, documenting what was done, is being done, or
how to operate products, is not always completed in a timely or in a
useful manner. A major
exception is Off-the-Shelf-Software (OTS) products that require
sophisticated (electronic) explanation on how to use the OTS product; a
must to sell the product to people with little or no experience with the
product. When producers of
OTS products work on a complex or large project, many times they find
the user asking for documentation the producers have no experience in
producing, e.g., detailed designs, requirement trace abilities and
plans.
Another major concern is documentation change control.
History has shown producers provide change control (even if
weakly done) for the initial software products, but documentation
changes are often after the fact and are poorly implemented.
For instance, the template author has witnessed a situation in
which engineers modified old, approved documentation amendment history
information without going through any change-control process; even
though the producing company said they implemented and enforced a
change-control process.
One of the major problems this Plan will assist a project with is the
minimization of review cycles. Each
unplanned review increases cost, can greatly impact schedules, ties up
valuable resources and impacts team morale.
The management of this Plan may only require one person.
The key is the development of quality documentation with the help
of the entire Project team, not just the documentation management group.
This Plan describes the processes used to manage the identified
documentation, including the development, maintenance and retirement of
this documentation. This
Plan takes precedence over any documentation, process, etc., dealing
with documentation management that may affect this Project.
This Plan consolidates the methodology, requirements and processes used
to manage the development, packaging, delivery and maintenance of
documentation, including documentation change control.
As a result, the documentation management methodology is
organized to provide proper control of information development,
dissemination, changes and retirement.
This Plan provides management with visibility on documentation status
and cost; including a clear picture of future documentation management
needs. This Plan helps
control documentation scope creep and documentation expectations.
For this Plan, the term “documentation” includes processes,
delivered documentation, any data placed under documentation
management control, and the internal documentation used to help
produce delivered documentation, or used to manage the Project.
The term “management” is used since this Plan includes how to manage
and develop useful documentation while maintaining a system for uniquely
identifying the documentation and related changes.
At the same time, the Documentation Manager manages the
related resources and schedules.
This Plan addresses the documentation that is covered.
It is critical that a Plan delineate what will not
be covered, e.g., the change control process may use the Configuration
Management change control process or some documentation may not be
controlled by Documentation Management.
Consideration must be given to factors affecting how to go about
working on a project, any specific concerns needing to be addressed for
the stakeholders (e.g., users, management and Project sponsor) and what
is needed to make the documentation useful.
|
| 4.
Documentation
Plan Overview |
Identify
the major sections of this Plan and briefly describe the purpose of each
major section. Ensure the
identified sections are listed in the same order as presented in this
Plan.
The developers of this Plan
worked closely with the customers and developers of other Project plans
to ensure consistency of terms, schedule, use of resources and content.
This Plan is divided into the following major sections:
|
| h |
Documentation
Management Scope |
| h |
Documentation
Plan Objectives |
| h |
Documentation
Plan Purpose |
| h |
Documentation
Plan Overview |
| h |
Documentation
Management Policy |
| h |
Documentation
Assumptions, Constraints, Risk and Dependencies |
| h |
Managed
Plans, Documents and Records for this Project: this Plan addresses
covered items |
| h |
Documentation
Processes: a list and summary of key documentation processes |
| h |
Documentation
Management Tools and Aids: list of the key tools and aids used to
create, manage and maintain documentation, along with a brief
description of each tool or aid |
| h |
Documentation
Management Organization and Key Team Personnel: description of how the
company, Project and Documentation Management organizations relate,
along with a list of key positions involved with Documentation
Management and where they fit within the Project |
| h |
Documentation
Management Schedule: the Documentation Management Schedule is introduced |
| h |
Documentation
Management Budget: a description of the Documentation Management budget
and cost accounting system as it applies to documentation |
| h |
Amendment
History for this Documentation Plan: a summary of when and what changes
were made to this Plan |
| h |
Appendix
A: References: list of standards and requirements relevant to this Plan |
| h |
Appendix
B: Definitions and Abbreviations: definition of key terms and a list of
abbreviations and their meaning
|
| 5.
.Documentation
Management Policy |
|
The
following is the policy for managing documentation:
Insert the company documentation policy here.
This policy should be signed at highest company level as
possible, e.g., Vice President of Product Assurance.
“It is the policy of company/project name that the Documentation
Manager is responsible for the implementation of this policy and all
documentation that will: |
| h |
Be
managed, produced and maintained to ensure the highest quality possible |
| h |
Satisfy
the requirements and defined expectations of the customers and users.”
|
| 6.
Documentation
Assumptions, Constraints, Risks and Dependencies |
|
This section
identifies perceived documentation problems areas and plans to resolve
the problems. Include what
obstacles users may face in terms of implementing this Plan.
The following assumptions (for planning purposes, are considered to
be true, real or certain) are made:
|
| h |
Over
time, customer documentation expectations change.
This could impact previously published documentation. |
| h |
Over
time, product requirements change, thus impacting documentation contents
|
| The
following constraints (application restrictions affecting the
Project’s performance) are made: |
| h |
The
user quickly accepts this Plan. |
| h |
Coordination
between the user and the Project team is timely, open and documented. |
| h |
There
are no more than two customer reviews prior to the documentation being
published as final and baselined. |
| h |
The
Documentation Plan and Schedule are updated for the customer’s review
on a schedule set by the Project Manager.
|
| The
following risks have been identified: |
| h |
Risk:
documentation Authors are technically qualified, but do not know how to
write readable documentation. Resolution:
the Documentation Manager provides writing-training classes, has
highly-qualified editors and has established processes and checklists to
help authors. The established review cycle emphasizes quality, readability,
and content accuracy and consistency |
| h |
Risk:
inconsistency between documentation.
Resolution: terms,
abbreviations, strategies, figures, tables, etc., are pre-defined, as
much as possible. As
requirements or information change, this is distributed to all authors,
authors’ manager and the Documentation Manager - for distribution to
the appropriate Documentation Editor |
| h |
Risk:
a key Project person is not available (e.g., death or leaving the
Project) to continue the documentation effort.
Resolution: work is
identified through the use of Work Requests (to start a task) and a
recording process, which includes documentation, recommendations,
issues, etc. This allows for new and replacement people to quickly “get
up to speed” on their new assignments
|
| This
Plan has the following dependencies: |
| h |
Documentation
Management Schedule is dependent on the Project Schedule |
| h |
Project
plans depend on each other for consistency and accuracy |
| h |
Adequate
resources at the scheduled time to ensure documentation stays on
schedule and within budget
|
| 7.
Managed
Plans, Documents and Records for this Project |
|
Tables 1, 2, and 3
identify the plans, documents and records of this project.
“Managed documentation” is documentation delivered or used by
this Project. Any
documentation not listed in Tables 1, 2, or 3 is not within the scope of
this Plan. As needed, the
Documentation Manager updates this list, which is based on satisfies
ISO/IEC 12207:2008, Software life
cycle processes (2008) Clause 6.3.6 Information Management Process
A table is beneficial if there is a need to identify the purpose,
provide a summary description or goal of each item of documentation.
It may be advisable to group this documentation by some logical
schema, e.g., phase.
Table 1, 2, and 3 considerations:
|
| h |
General: |
|
| h |
Examine
the given list to ensure it matches the appropriate
documentation for this Plan |
|
|
| h |
Ensure
compliance with the standards, processes, etc., identified in
this Plan |
|
| h |
Identifier:
enter the Project schema for uniquely identifying each item of
documentation.
It is recommended that the listed documentation relate to the
Project’s Work Breakdown Structure (WBS) |
| h |
Title:
Enter the unique title for each item of documentation.
See the notes at the end of the table explaining the genesis of
the documentation items |
| h |
Description
and Purpose: provide a brief documentation description and purpose.
Do not assume the template provided descriptions are valid for
the subject project |
| h |
Example
(specific) contents: An example of what the plan should contain. .
Do not assume the template provided contents are valid for the
subject project |
| h |
Phase:
enter the lifecycle phase where the documentation is to be first
baselined. For this
template, the sequence of phases is: concept, planning, requirements
analysis, design, development, testing, implementation, maintenance and
then retirement. Do not
assume the template provided phases are valid for the subject project.
|
| h |
Intended
Audience: identifies who is the intended audience of this documentation.
Do not assume the template provided groups are valid for the
subject project |
| h |
Prime
Responsible group: identify the group who has the prime responsibility
for the development of this documentation.
Do not assume the template provided groups are valid for the
subject project
|
| It
may be helpful to readers if a “documentation tree” is provided,
e.g.: |
| h |
The
Project Management Plan is based on the Project Charter, Contract,
schedule, availability of resources, WBS and company processes |
| h |
All
plans are based on the Project Management Plan, this Plan and the
Contract.
A plan may relate to other plans |
| h |
All
documentation is based on this Plan and other related plans, documents
and reports
|
|
Consideration
should be given to add a column to Tables 1, 2, and 3 to show
documentation dependences, e.g., Documentation A depends on
Documentation B (e.g., Implementation Plan depends on the Installation
and Training Plans). Another
consideration is documentation hierarchy, especially if documentation
has duplication of information, delineate which documentation has
precedence if one or more of the documentation has erroneous information
due to project evaluation, i.e., to minimize updating.
Tables 1, 2, and 3 were developed from the view of a seller or a
producer of software. Change
the wording if a buyer’s view is required.
For
Tables 1, 2, and 3:
|
| 1. |
A
plan describes the “what,
when and how” a task/activity will be performed |
| 2. |
A
document contains information
on a
particular subject.
|
| 3. |
A
report or record
provides the status or history of the subject topic |
|
|
|