Concept Description#

Concept Description
status: valid
tags: change_management, change_management, change_management, change_management

In this section a concept for the Change Management will be discussed. Inputs for this concepts are both the requirements of ISO26262 Part-8 and ASPICE Requirements from SUP.10 additionally including the requirements of the different stakeholders for the Change Management process.

Key concept#

A Change Request is the ONLY way to contribute new features or to modify the scope of existing features in the project. As features are built-up by components a Change Request is also needed to add new components or to modify the scope of existing components. All statements here for components are also valid for SW Modules.

Inputs#

  1. Stakeholders for the Change Requests?

  2. Which attributes are required?

  3. Which activities are required?

Stakeholders for the Change Requests#

  1. Contributor

    • In general contributes features and components to grow the project content

    • Creates change requests

    • Supports all change request activities

  2. Architecture Team

    • Supports all change request activities

    • Approves the creation of the change request

    • Verifies that the contribution including change requests fulfills the project policies

  3. Platform Team

    • Supports creation and the analysis of change requests

    • Is responsible and approves the implementation and the closure of the feature change request

  4. Delivery Team

    • Is responsible and approves the implementation and the closure of the component change request

  5. Project Lead

    • Supports all change request activities

    • Approves the analysis of the change request

    • Verifies that the contribution including change requests fulfills the project policies

Standard Requirements#

Also requirements of standards need to be taken into consideration:

  • ISO 26262

  • ASPICE

  • ISO SAE 21434

Attributes of Change Requests#

The required attributes for the Change Request are defined here: Process Requirements.

Activities for a Change Request#

Creation of the Change Request#

Use the content Feature Request Template or Component Request Template to create a Change Request.

In case safety or security is affected, in addition the impact analysis template : Impact Analysis Template can be used to detail out the impact on safety/security.

The impact analysis tool (Change Requests Impact Anal...) can support to here to identify the affected work products.

Analysis of the Change Request#

Based on the analysis results decision about the acceptance or rejection must be taken by authorized persons.

Authorized person, as members of the Platform Team, includes

  1. Project Lead

  2. Safety Manager

  3. Security Manager

  4. Quality Manager

  5. Committer

Further prioritization must be done, e.g. based on release planning.

Implementation and Monitoring of the Change Request#

If the Change Request is accepted, the implementation of the change must be initiated and monitored.

The Change Request implementation must be tracked until it is closed.

The status of the Change Request must be communicated by the Project Lead (for feature requests) and the lead of the Delivery Team (for component requests) until the implementation is completed and confirmed.

Closing of the Change Request#

Use the Change Request Review Checklist to control the completeness of the Change Request to be closed.

Especially the effectiveness of the solution measures must be shown, based on convincing arguments, e.g. verification measures must be used to confirm the implementation.

The standards require that a Change Request can be traced throughout the complete hierarchy levels including all affected work products.

In general the traceability is visualized in the general traceability concept (Traceability concept).