Change Management Plan		status: valid security: YES safety: ASIL_B
tags: platform_management version: 1 realizes: wp__chm_plan

doc__platform_change_management_plan		Generic Document

Change Management / Change Management Plan#

This document implements parts of the 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, implementation, closure and control. Where a change is defined as an introduction of a new feature/component or modification of an existing feature/component.

Objectives and Scope#

Change Management Goals#

Change Requests are recorded and identified.
Change Requests are analyzed, affected work products are identified, and the impact is estimated.
Change Requests are approved before implementation.
Change Requests are implemented and monitored.
Changes Requests are tracked until closure and and communicated to affected parties.
Change Requests and affected work products are bidirectionally traced.

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, analyze, implement and monitor Change Requests within S-CORE.

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

The next figure gives an overview, how Change Requests are realized in S-CORE. An ISSUE and PR is used to create a Change Request including required attributes as defined in gd_req__change_attr_uid.

Therefore the Change Template gd_temp__change_feature_request or gd_temp__change_component_request shall be used. In addition gd_temp__change_impact_analysis should be used, if applicable.

Note

Parts of the template are automatically included in the ISSUE Change Request. Use ISSUE Change Request to request a change in S-CORE.

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 96 Change Request Types#
Type	Description	Infrastructure
Feature	Created by rl__contributor to change requirements and work products, new feature	ISSUE with label `feature_request`
Feature Modification	Created by rl__contributor to change requirements and work products, scope change	ISSUE with label `feature_modification`
Component	Created by rl__contributor to change requirements and work products, new component	ISSUE with label `component_request`
Component Modification	Created by rl__contributor to change requirements and work products, scope change	ISSUE with label `component_modification`

Change Request Traceability Impact Analysis requires the following tools:

gd_req__change_tool_impact_analysis

The Decision Record Track (FEP Process)#

Change Requests generally follow the four-step Change Request Workflow below. For most changes, Analyze means a rl__committer reviews the ISSUE/PR and documents the accept/reject decision directly there.

Some changes carry enough governance weight that the decision is worth persisting, and the community needs a structured way to reach agreement before implementation starts, rather than relying on a single Committer’s review. For these, Analyze is specialized into the FEP process: a Shepherd sponsors the proposal, a time-boxed Final Comment Period (silence-as-approval) replaces open-ended review, and the outcome is recorded as a Decision Record rather than only documented in the ISSUE. Create, Implement, and Close are unaffected; only the Analyze step changes shape. See the FEP Process Guide for the full mechanics (roles, phases, template).

Today, the following Change Requests are routed onto this track:

Feature change requests always go through the FEP process.

Feature Modification change requests go through the FEP process when the change has major impact, e.g. affecting the platform or other Feature Teams. Feature Teams retain authority over modifications limited to their own domain.

A clean, exhaustive definition of “major impact” is not achievable up front. This classification is a judgment call made by the responsible rl__committer at the time the change is proposed, including changes proposed directly as a PR without a prior FEP. A change can be waived from the FEP process by community agreement if it is judged not to warrant it, or pulled into the FEP process after the fact if a maintainer judges it major.

Component and Component Modification change requests currently go through the standard Analyze step and are not routed onto the FEP track.

The FEP mechanism itself is not inherently tied to CR type; Feature and major Feature Modification are its first applied case. Extending the FEP track to other CR types would be a separate decision, not implied by this document.

FEP tracking-Issue statuses are a refinement of the generic Change Status mapping described below under Change Request Attributes, not a competing one:

Table 97 FEP Status Mapping#
FEP tracking Issue status	Generic Change status	Notes
`Draft - Needs Shepherd`	open	Refines “open”: PR exists, no Shepherd confirmed yet.
`Draft - Shepherded`	open	Refines “open”: Shepherd confirmed, proposal being shaped.
`Under Review`	in review	The Final Comment Period.
`Accepted`	in implementation	FEP merged and recorded as a Decision Record.
`Rejected` / `Withdrawn`	rejected	FCP closed with unresolved objections, or the author withdrew.
`Implementing`	in implementation	Tracking issue stays open; may carry child Task issues.
`Implemented`	closed	Implementation merged; tracking issue closes.

Change Request Attributes#

gd_req__change_attr_uid are implemented as follows:

gd_req__change_attr_uid is identical to the ISSUE number.

gd_req__change_attr_status is defined by the combination of the ISSUE state, the state in the Projects dashboard view and the PR status.

Table 98 Change Status#
Status	Issue status	Projects dashboard status	Linked PR status
open	`Open`	`No Status`	`Draft` or `Open`
in review	`Open`	`Todo`	`Draft` or `Open`
in implementation	`Open`	`In Progress`	`Draft` or `Open`
closed	`Closed`	`Done`	`Merged`
rejected	`Closed as not planned`	na	na

gd_req__change_attr_title is identical to the ISSUE title.

gd_req__change_attr_impact_description is initially provided in the Description and Impact analysis part of the ISSUE. Further detailed analysis results are part of the linked PR, provided as part of the feature/request templates.

Further information about detailed implementation can be provided in the Realize part of the ISSUE.

gd_req__change_attr_impact_safety, gd_req__change_attr_impact_security are provided in the Safety or Security relevance part of the ISSUE.

Combinations of them are allowed. If nothing is selected, Quality is relevant by default.

Use the ASIL classification part of the ISSUE to document the ASIL level concerned, e.g. ASIL_B.

gd_req__change_attr_types is provided in the Change Request Type part of the ISSUE, further in the linked PR for feature or component request.

gd_req__change_attr_affected_wp is initially provided in the Affected work products part of the ISSUE. Further detailed affected work products are part of the linked PR or other ISSUEs.

gd_req__change_attr_milestone is provided in the Expected Implementation Version part of the ISSUE. Optionally the Milestone part of the ISSUE can be set.

Change Request Workflow#

In general, every Change Request follows the following steps:

(color is referring to the following figure: Problem Resolution Simple Workflow Overview)

1. Create the Change Request (grey color)
1. Analyze the Change Request (blue color)
1. Initiate the implementation of the Change Request and track it to closure (yellow color)
1. Close Change Request (purple color)

gd_guidl__change_change_request can give additional help.

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 document and 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 with the type Enhancement is created in status Open. The title of the ISSUE reflects the potential change. Further fill out the provided template content accordingly.

The description of the ISSUE may give a brief description and impact analysis of the requested change. The details are part of the Feature/Component Request and Impact Analysis provided by a PR, which is linked to the ISSUE in status Draft or Open.

For a new Feature/Component Request the provided templates gd_temp__change_feature_request, or gd_temp__change_component_request must be used. For a modification of an existing Feature/Component, update the existing work products. Further add here the gd_temp__change_impact_analysis and fill it out accordingly, if applicable.

The description of the ISSUE may give a brief description of the affected work products and also details about the intended realization for the change. The linked PR in status Draft, which contains the Feature/Component Requests, may contain also more details about the affected work products or realization and verification proposals.

Planning is done by setting the Expected Implementation Version. Optionally the Milestone of the ISSUE can be set.

Change request status: open is implemented as ISSUE status Open and Projects status No Status. The linked PR status is either Draft or Open.

To trigger the next step: Change request status: in review keep the ISSUE status Open and set the Projects status Todo.

To reject the change request: Change request status: rejected set the ISSUE status to Closed as not planned.

Fig. 27 Change Request Simple Workflow Overview#

To 2. Analyze the Change Request:

The Change Request is reviewed and analyzed from the rl__committer and the review results are resolved by the rl__contributor. The results are documented in the ISSUE and/or linked PR. As long as the information is not sufficient, the related ISSUE is kept in status Open and Projects status Todo, means in review.

For Change Requests routed onto the Decision Record Track, this step is performed as described in the FEP Process Guide instead: a Shepherd, not a single Committer, guides the analysis, and the review window is the time-boxed Final Comment Period rather than an open-ended in review state.

If the information is sufficient and it is decided to implement the change request, the ISSUE status is kept Open and the Projects status is set to In Progress.

The decision, if the change request is accepted or rejected must be documented. Safety/Security experts must confirm or deny, if safety/security relevance is set correctly.

gd_chklst__change_cr_review can help to verify whether the information is complete.

Otherwise, if the change requested is not accepted, the change request is rejected. To reject the Change Request: Change Request status: rejected set the ISSUE status to Closed as not planned.

To 3. Initiate the implementation of the Change Request and track it to closure:

rl__contributor starts all required activities to implement the change request. These may include further planning activities by creating ISSUEs and required PRs. All additional ISSUEs or PRs created to implement are linked to the Change Request ISSUE to enable monitoring of the activities.

All activities defined are tracked until closure, means that all linked ISSUEs or PRs are closed or merged, respectively.

If all are closed or merged rl__contributor sets Projects status to Done to trigger the final review from the rl__committer to close the Change Request.

The Change Request may also rejected in this phase, then the ISSUE status is set to Closed as not planned.

To 4. Close Change Request :

rl__committer checks finally if the change request is completely implemented. In this case all linked ISSUEs or PRs are closed or merged, respectively.

Especially the verification measures must be checked for their effectiveness and the argumentation is convincing.

gd_chklst__change_cr_review can help to verify whether it can be closed. 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 this is the case the ISSUE status is set to Closed, otherwise the Projects status is set back to In Progress.

Change Management SW Platform Work Products#

not applicable