Guideline#

This document describes the general guidances for Change Management based on the concept which is defined Concept Description.

General Hints#

The detailed implementation of the Change Management for the project shall be described in the Workflow Platform Management.

Templates#

To create a change request, the project shall provide the content of the following templates in a pull request (PR) linked to an issue in the project’s selected Issue Tracking System: Feature Request Template and Component Request Template.

The project’s selected Issue Tracking System may also use the content of these templates to provide e.g. a change request issue template.

Note

An example template for the Issue Tracking System in GitHub (GitHub Issues) can be found here: Issue Template Change Request

Improvements including Process Improvements are not Change Requests. The project’s selected Issue Tracking System may also provide a template for improvements, e.g. an improvement issue template.

Note

An example template for the Issue Tracking System in GitHub (GitHub Issues) can be found here: Issue Template Improvement

Attributes#

For all Change Requests following mandatory attributes need to be defined:

Overview of mandatory change request attributes#

Title

Change Request attribute: Affected Work Products

Change Request attribute: description

Change Request attribute: safety

Change Request attribute: security

Change Request attribute: Milestone

Change Request attribute: status

Change Request attribute: title

Change Request attribute: Types

Change Request attribute: UID

A more detailed description can be found here: Process Requirements.

Activities for Change Requests#

This section describes in detail which steps need to be performed for a Change Request.

Table 11 Activities for Change Request#

Step

Description

Responsible

Approver

1.

Create Change Request

Contributor

Committer

2.

Analyze Change Request

Contributor

Project Lead

3.

Implement and Monitor Change Request

Contributor

Committer

4.

Close Change Request

Committer

Project Lead

Create Change Request#

Contributor (as author, submitter) creates the Change Request as a pull request (PR) based on the content of the provided templates: Feature Request Template or Component Request Template. This PR is linked to an issue of the selected Issue Tracking System of the project.

It is expected, that the status of the pull request is set to “draft” or “open” automatically.

To start the process only to open the issue is allowed. But the issue shall then provide already the content of the mentioned templates above.

It is expected, that the status of the issue is set to “open” automatically.

It is expected that the selected Issue Tracking system supports template definition. Best practice is to define a template with the required content, so that it can be either automatically included or copied by the different users.

Note

For the Issue Tracking System in GitHub, there is a template created, which can be be found here: Issue Template Change

Note

A Change Request Example based on that template is here: Example Change Request

It is expected, that

  • UID will be provided automatically by the Issue Tracking System.

  • The status of the change request is set to “open” automatically. As long as the content is updated, the status of the change request is kept “open”.

  • The change request submitter will be set automatically by the Issue Tracking System.

  • The title of the change request reflects the topic accordingly.

  • The change request type reflects level of the change: feature or component.

  • The description reflects in detail: Exact description of the Change Request including reason, impact analysis on user, effort for implementation (schedule, risks, resources) and verification (measures defined).

  • A detailed impact analysis is available.

    • If the change affects safety or security it should be stated explicitly.

    • If safety is affected, the ASIL classification should be added, if applicable.

Note

For the Change Request Example:
* The UID is provided by the Issue Tracking System as: #168
* The status of the issue is provided by the Issue Tracking System as: Open
* The submitter is provided by the Issue Tracking System as: masc2023
* the title contains the change reason, as API of a component modified
* The change request type is selected as Component Modification
* The descriptions considers details of the change and how the user is impacted
* Estimations for realization are given
* The affected high level work products are identified: Requirements, Architecture and Detailed Design
* The detailed affected work products are listed.
* Checkboxes are selected to highlight, that Safety is affected with classification ASIL_B
* The expected implementation version is defined

When ready to review and to analyze, the author sets the status to “in review” manually.

Note

For the Change Request Example:
* The “Process Development Community” dashboard is added and the status must be changed to Todo
* The combination of the issue status Open and “Process Development Community” Todo defines the status in review

Analyze Change Request#

The projects Project Lead supported by Committer (includes Safety, Security and Quality Manager) analyzes the change request together with the Contributor and takes a decision with the submitting/authoring contributor for accepting or rejecting it.

The analysis will start by reviewing all the information given during the creation of the change request. All topics are revisited and checked for correctness, completeness and consistency.

If required, the information is updated accordingly.

If accepted, the stakeholder of the change and the expected release, where the change should be closed, shall be defined. Optionally, the corresponding milestone can be set.

Note

For the Change Request Example:
* The stakeholder are provided using Assignees field: masc2023
* The expected closure version is provided: 0.5
* The “Milestone” is provided: Release 2.0.0 - Maturity Level 2

If accepted, Contributor can start with the implementation of the Change Request.

The author has the freedom to cancel the change request at any time by setting the status to “rejected”.

Note

For the Change Request Example:
* For rejection the status of the issue must be changed to Closed as not planned
* The combination of issue status Closed as not planned and any “Process Development Community” status defines the status rejected

Implement and Monitor Change Request#

If accepted, the projects Committer initiates the implementation of the change together with the Contributor.

The description may reflect details for the implementation.

Note

For the Change Request Example:
* The descriptions has a section for How is the change realized, but it is empty.

The concrete implementation of the solution may require several additional activities. In this case additional issues may created and linked to the Change Request.

Note

For the Change Request Example:
* The Create sub-issue should be used to create further linked issues.

Minimal a pull request is sufficient to implement the change, which shall be linked to the Change Request. It is expected, that the status of the pull request is set to “draft” or “open” automatically.

When ready to implement, the author sets the status to “in implementation” manually.

Note

For the Change Request Example:
* The “Process Development Community” status must be changed to In Progress
* The linked Pull Request status is either “Draft” or “Open”
* The combination of issue status Open and “Process Development Community” status In Progress and the pull request status Draft or Open defines the status in implementation

Note

For the Change Request Example:
* The Development section should be used to link to an pull request
* The Create a branch action may used to create automatically a linked pull request

During the implementation of the change the responsible lead Project Lead reports regularly the status to the affected projects teams.

The author has the freedom to cancel the change request at any time by setting the status to “rejected”.

Close Change Request#

During implementation the Contributor monitors all activities linked to the change, until they are closed.

Committer finally checks if the Change Request implementation is sufficient before the status is changed to closed. To check, if it is sufficient, Change Request Checklist (gd_chklst__change_cr_review) can be used. Further the effectiveness of the implemented measure is confirmed and the availability of the required reports, as well as verification results, if applicable.

When confirmed, the Project Lead sets the status to “closed” manually, if not done automatically.

Note

For the Change Request Example:
* For closing the status of the issue must be changed to Closed
* The “Process Development Community” status must be changed to Done
* The PR status must be changed to Merged
* The combination of issue status Closed and “Process Development Community” status Done and the pull request status Merged defines the status closed

Committer has the freedom to reject it at any time by setting the status to “reject”.