Concept Description#

Concept Description
status: valid
status: valid
tags: change_management
relates to: wf__change__cr_an_change_request, wf__change__rv_ap_change_request
doc_concept__change__process
Concept Definition

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 (compare Contribution Request Guideline (gd_guidl__contr_request_guideline)) new features or to modify the scope of existing features in the S-CORE project. As features are built-up by Components a Change Request is also needed to add a new Components or to modify the scope of existing Components. As a Software Module isd defined as the top-level Component, all statements here for Components are also valid for Software Modules.

Inputs#

  1. Stakeholders for the Change Requests?

  2. Who needs which information?

  3. Which Change Requests types can we derive from that?

  4. Which attributes are required?

  5. How do the different Change Requests types correlate to each other?

Stakeholders for the Change Requests#

  1. Contributor (rl__contributor)

    • Contributes features and components to grow the S-CORE content

    Contribution include scope modification of existing features/components or adding new features/components.

  2. Committer (rl__committer)

    • Verifies that the contribution fulfills the S-CORE policies

    • Approves the contribution

Standard Requirements#

Also requirements of standards need to be taken into consideration:

  • ISO 26262

  • ASPICE

  • ISO SAE 21434

Change Request Types#

Feature#

This Change Request describes a potential new feature for the platform. The Change Request uses the Feature request template: Feature Template.

Feature Modification#

This Change Request describes a scope modification of an existing feature (requirement or work product). The Change Request modifies the already existing Feature Request template: Feature Template.

Component#

This Change Request describes a potential new component for the platform. The Change Request uses the Component request template: Component Template.

Component Modification#

This Change Request describes a scope modification of an existing component (requirement or work product). The Change Request modifies the already existing Component Request template: Component Template.

Attributes of Change Requests#

The required attributes for the Change Requests are defined in this subchapter.

Following attributes need to be filled manually for each Change Request:

Table 12 Manual Attributes#

Attribute

Description

Unique ID

The unique id

Status

The status of a Change Request can either be “draft”, “in review”, “accepted” or “rejected”.

Title

Reason for the Change Request

Description

Exact description of the Change Request

Safety

These attribute describes the impact on functional safety.

Security

This attribute describes the impact on security

Change Request Type

Following types are defined: [Feature, Feature Modification, Component, Component Modification]

Affected work products

Links to the work products affected by the Change Request

Milestone

Planned date (milestone) of deployment of the Change Request

Analysis of the Change Request#

The affected work products must be identified. The potential impact on functional safety and security must be addressed. Schedule, risks, resources for the realization must be evaluated. Verification measures must be defined. Use therefore the : Impact Analysis Template.

Evaluation of the Change Request#

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

Authorized person includes

  1. Technical Lead (rl__technical_lead)

  2. Module Lead (rl__module_lead)

  3. Safety Manager (rl__safety_manager)

  4. Security Manager (rl__security_manager)

  5. Quality Manager (rl__quality_manager)

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

Implementation of the Change Request#

If the Change Request is accepted, it must be implemented.

Verification of the Change Request#

The defined verification measures must be use to confirm the implementation.

Reporting of the Change Request#

The status of the Change Request must be communicated by the Technical Lead (rl__technical_lead) or Module Lead (rl__module_lead) until the implementation is completed and confirmed.

Traceability Concept for Change Requests#

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).