Documentation Management Plan
status: draft
safety: ASIL_B
status: draft
tags: platform_management
safety: ASIL_B

Documentation Management Plan#

Purpose#

The documentation management plan describes how documents are handled in the S-CORE project.

Objectives and scope#

Goal of this plan is to describe

  • which documents exist

  • which attributes and lifecycle they have

  • how they are reviewed

Approach#

Some of the work products of the S-CORE project are modelled specifically (e.g. the requirements and architecture have a specific set of attributes) Others are modelled as general documents (e.g. the plans which are part of the program management plan or the verification reports).

This plan deals with these documents, which have the following manually set attributes:

  • Title: the name of the document (mandatory)

  • Unique Id: Id following the naming pattern of the document Title (mandatory)

  • Safety: which ASIL the document supports (mandatory)

  • Author: Who is the main committer to the document (mandatory)

  • Status: describing where in the lifecycle of the document it currently is (mandatory)

  • Tags: can be used to group documents for subsequent filtering (optional)

Also the “Documentation Management” is a document, so an example for a correct document definition can be seen in the header section above, see Documentation Management Plan (doc__documentation_mgt_plan).

The following additional attributes of the document are generated automatically during the documentation build:

  • Approver: from the github information on who was the last CODEOWNER performing the github review

  • Reviewer: any additional reviewer performing the github review without CODEOWNER rights

The lifecycle of S-CORE documents has two states:

  • Draft: The document is filled with content but not completed, the existing content is reviewed and already applicable

  • Valid: The document is completed and approved

If a document is invalidated it is removed from the project entirely. A document can also transition from Valid to Draft, for example if a release was done with a Valid verification report and then the development for the next release is started.

Invalidated documents are still observable as part of the git history in the unlikely case of later referral (e.g. for design decisions or audit). In this way, there is even an option to recover the content.

The review of each document is done as defined for this type of work product in the respective process description. This means that for some of the work products dedicated checklists are defined, but for others there are not. In any case the reviews are done in a github review at least by one CODEOWNER who is not the author of the document.

Generally all work products (specific and general documents) are subject to a documentation build, which always contains the latest version of the documents for each pull-request. Versioning of documents is done as for every work product with github means and is defined in the configuration management plan.

The following table lists all documents of the S-CORE project:

Title

ID

Status

Tags

[Your Feature Name]

doc__change__component_name

draft

change_management

[Your Feature Name]

doc__change__feature_name

draft

change_management

Change Management Plan

doc__platform_change_management_plan

draft

platform_management

Documentation Management Plan

doc__documentation_mgt_plan

draft

platform_management

Inter-process Communication

doc__ipc

valid

contribution_request; feature_request

Platform Management Plan

doc__platform_mgt_plan

draft

platform_management

Platform Safety Plan

doc__platform_safety_plan

draft

platform_management

Project Management Plan

doc__project_mgt_plan

draft

platform_management

Software Verification Plan

doc__verification_plan

draft

platform_management