Change Management Plan		status: draft security: YES safety: ASIL_B
tags: platform_management realizes: PROCESS_wp__chm_plan

doc__platform_change_management_plan		Generic Document

Change Management / Change Management Plan#

This document implements parts of the PROCESS_wp__platform_mgmt.

Purpose#

The purpose of the Change Management Plan is to guide the execution of the Change Requests of a project including their creation, analysis, approval, implementation, and verification.

Objectives and Scope#

Change Management Goals#

Requests for Changes are recorded and identified.
Change Requests are analyzed, dependencies and relationships to work products or other Change Requests are identified, and the impact is estimated.
Change Requests are approved before implementation and prioritized accordingly.
Bidirectional traceability is established between Change Requests and affected work products.
Implementation of Change Requests is confirmed.
Change Requests are tracked to closure and status of Change Requests is communicated to affected parties.
Requests for Changes are properly documented.

Approach#

Change Request Execution#

Contributions in general to the S-CORE project are described here (compare Contribution Guideline (doc__contr_guideline)).

A Change Request is a specific contribution, and it is the ONLY way to contribute new features/components or to modify the scope of existing features/components in the S-CORE project.

Change Request Infrastructure and Types#

GitHub Issues (ISSUE) (doc__issue_guideline) are used for managing Change Requests. The tool is used to create, plan, control, and monitor Change Requests within S-CORE.

GitHub Pull Requests (PR) (doc__pull_request_guideline) are used for the implementation of Change Requests. The tool is used to implement and verify Change Requests within S-CORE.

The next figure gives an overview, how Change Requests are realized in S-CORE. An ISSUE is used to create a Change Request including required attributes as defined in PROCESS_gd_req__change_attr_uid. The ISSUE may be linked to other ISSUEs or SUB-ISSUEs, if required, to manage more complex Change Requests. The implementation of a Change Request requires at least one PR linked to the ISSUE created for the Change Request.

Changes are clustered in the following types:

Table 41 Change Request Types#
Type	Description	Infrastructure
Feature	Created by PROCESS_rl__contributor to change requirements and work products, new feature	ISSUE with label `feature_request`
Feature Modification	Created by PROCESS_rl__contributor to change requirements and work products, scope change	ISSUE with label `feature_modification`
Component	Created by PROCESS_rl__contributor to change requirements and work products, new component	ISSUE with label `component_request`
Component Modification	Created by PROCESS_rl__contributor to change requirements and work products, scope change	ISSUE with label `component_modification`

Change Request Traceability Impact Analysis requires the following tools:

PROCESS_gd_req__change_tool_impact_analysis

Change Request Attributes#

PROCESS_gd_req__change_attr_uid are implemented as follows:

PROCESS_gd_req__change_attr_uid is identical to the ISSUE number.

PROCESS_gd_req__change_attr_status is defined by the combination of the ISSUE state and the states of the linked PRs.

PROCESS_gd_req__change_attr_title is identical to the ISSUE title.

PROCESS_gd_req__change_attr_impact_description is defined in the linked PR or part of the description.

PROCESS_gd_req__change_attr_impact_safety is defined in the linked PR or part of the description.

PROCESS_gd_req__change_attr_impact_security is defined in the linked PR or part of the description.

PROCESS_gd_req__change_attr_types is defined by label of a ISSUE and part of the description.

PROCESS_gd_req__change_attr_affected_wp is defined in the linked PR or part of the description.

PROCESS_gd_req__change_attr_milestone is defined by the Milestone of a ISSUE.

Change Request Workflow#

In General, every Change Request follows the following steps:

1. Create the Change Request
1. Review the Change Request
1. Approve the Change Request

To 1. Create the Change Request:

An ISSUE is the ONLY way to create and manage a Change Request in S-CORE. A PR is the ONLY way to implement a Change Request in S-CORE, thus an ISSUE must be linked at least to one or more PRs.

The figure below shows the workflow for the simplest case of a Change Request.

An ISSUE with the label according to the Change Request type is created in status OPEN. The title of the ISSUE reflects the potential change. The description of the ISSUE may give a brief description of the requested change or modification. Further add here the PROCESS_gd_temp__change_impact_analysis and fill it out accordingly.

The details are part of the Feature/Component Request work product. The Feature/Component Request is provided by a PR, which is linked to the ISSUE in status DRAFT.

For a new Feature/Component Request the provided templates PROCESS_gd_temp__change_feature_request, PROCESS_gd_temp__change_component_request must be used. For a modification of an existing Feature/Component, update the existing work products.

The linked PR in status DRAFT, which contains the Feature/Component Requests, may contain also other required affected and changed work products or implementation and verification proposals.

Planning is done by setting the milestone of the ISSUE accordingly.

As long as the PROCESS_rl__contributor wants to modify the content of the Change Request, the linked PR is kept in status DRAFT.

Change request status: draft is implemented as ISSUE status OPEN and PR status DRAFT.

To trigger the next step the PR status is changed from DRAFT to OPEN.

Fig. 18 Change Request Simple Workflow Overview#

To 2. Review the Change Request:

The Change Request is reviewed from the PROCESS_rl__committer and the review results are resolved by the PROCESS_rl__contributor. The review results are documented in the PR. As long as the information is not sufficient, the related PR is kept in status OPEN.

PROCESS_gd_chklst__change_cr_review can help to verify whether the information is complete.

The realization parts of the Change Request are reviewed according the checklists of the affected work products. Verification of the realization parts must be successful. If the verification is not sufficient, the related PR is kept in status OPEN or may changed back to DRAFT (compare Issue Guideline (doc__issue_guideline)).

Change request status: in review is implemented as ISSUE status OPEN and PR status OPEN.

To 3. Approve the Change Request: PROCESS_rl__technical_lead or PROCESS_rl__module_lead decides finally, if the Change Request is accepted or rejected.

PROCESS_rl__committer checks finally if the Change Request is completed and the required verification measures are executed and successfully passed.

If approved, the status of the concerned PRs change to MERGED, otherwise, if rejected, PR status changes to CLOSED.

If approved the status of the ISSUE is CLOSED. This is also the case for rejected Change Requests.

The figure below shows the workflow for a complex case of a Change Request.

The ISSUE is linked to SUB-ISSUES, and each SUB-ISSUE is linked to a PR. In principle the Change Request workflows applies for all SUB-ISSUEs independently. Finally the ISSUE must be closed manually.

Fig. 19 Change Request Complex Workflow Overview Case 1#

The figure below shows the workflow for another complex case of a Change Request.

Here the Change Request has an impact on work products in different repositories, e.g. the S-CORE repository, contains feature work products and a Module repository, contains Component work products. The ISSUE is linked to SUB-ISSUES in the S-CORE repository, and the SUB-ISSUE is linked to a PR. But in addition the ISSUE is now linked to another ISSUE in the Module repository, also linked to a PR. In principle the Change Request workflows applies for all SUB-ISSUEs, ISSUES in Module repository independently. Finally the ISSUE in the S-CORE repository must be closed manually.

Fig. 20 Change Request Complex Workflow Overview Case 2#

Change Management SW Platform Work Products#

Table 42 SW Platform work products#
work product Id	Link to process	Process status	Link to issue	Link to WP	WP status
PROCESS_wp__issue_track_system	Platform Management Plan	draft	n/a	Project issues	established
PROCESS_wp__platform_mgmt	PROCESS_wf__platform_cr_mt_platform_mgmt_plan	valid	<Link to issue>	Platform Management Plan	draft
PROCESS_wp__process_definition	PROCESS_wf__def_app_process_definition	draft	Process community issues	Process description	<automated>