Skip to content

Fix audit findings prm #628

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
masc2023 wants to merge 2 commits into from
+74 −24
Closed

Fix audit findings prm #628

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
233db1a
fix audit findings action_78
masc2023 Mar 21, 2026
e28a8a0
fix audit findings for prm
masc2023 Mar 30, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 21 additions & 20 deletions process/process_areas/change_management/change_management_workflow.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,8 +24,8 @@ For a detailed explanation of workflows and their role within the process model,
:status: valid
:tags: change_management
:responsible: rl__contributor
:approved_by: rl__committer
:supported_by: rl__project_lead, rl__safety_manager, rl__security_manager, rl__quality_manager
:approved_by: rl__architecture_community
:supported_by: rl__platform_team
:input: wp__policies, wp__issue_track_system, wp__feat_request, wp__cmpt_request
:output: wp__issue_track_system, wp__feat_request, wp__cmpt_request
:contains: gd_guidl__change_change_request, gd_temp__change_feature_request, gd_temp__change_component_request, gd_temp__change_impact_analysis, gd_temp__component_classification, gd_temp__change_decision_record
Expand All @@ -42,9 +42,9 @@ For a detailed explanation of workflows and their role within the process model,
:id: wf__change_analyze_cr
:status: valid
:tags: change_management
:responsible: rl__contributor
:responsible: rl__architecture_community
:approved_by: rl__project_lead
:supported_by: rl__committer, rl__safety_manager, rl__security_manager, rl__quality_manager
:supported_by: rl__platform_team
:input: wp__policies, wp__issue_track_system, wp__feat_request, wp__cmpt_request
:output: wp__issue_track_system, wp__feat_request, wp__cmpt_request
:contains: gd_guidl__change_change_request, gd_temp__change_feature_request, gd_temp__change_component_request, gd_temp__change_impact_analysis, gd_temp__component_classification, gd_temp__change_decision_record
Expand All @@ -53,20 +53,21 @@ For a detailed explanation of workflows and their role within the process model,
The Change Request is analyzed.

Until the template is not filled out properly, the Change Request may be set back to
“open” from the :need:`Committer <rl__committer>`.
“open” from the :need:`Architecture Team <rl__architecture_community>`.

If the Change Request shall be implemented, the Change Request status is set to
"in implementation", otherwise to "rejected".

The author of the Change Request may cancel it, thus the status is set to "rejected".
If the author, :need:`Contributor <rl__contributor>`. of the Change Request decides to
cancel it, thus the status is set to "rejected" too.

.. workflow:: Implement and Monitor Change Request
:id: wf__change_implement_monitor_cr
:status: valid
:tags: change_management
:responsible: rl__contributor
:approved_by: rl__committer
:supported_by: rl__project_lead, rl__safety_manager, rl__security_manager, rl__quality_manager
:responsible: rl__delivery_team, rl__platform_team
:approved_by: rl__delivery_team, rl__platform_team
:supported_by: rl__project_lead
:input: wp__issue_track_system, wp__feat_request, wp__cmpt_request
:output: wp__issue_track_system, wp__feat_request, wp__cmpt_request
:contains: gd_guidl__change_change_request, gd_temp__change_feature_request, gd_temp__change_component_request, gd_temp__change_impact_analysis, gd_temp__component_classification, gd_temp__change_decision_record
Expand All @@ -77,22 +78,21 @@ For a detailed explanation of workflows and their role within the process model,
This may require additional activities, including creating ISSUEs and PRs.
These are linked to the Change Request and monitored until closure.

The Change Request is done, if all linked activities has been closed and confirmed.
Before closing the Change Request, :need:`Committer <rl__committer>` must check the
The Change Request is done, if all linked activities has been closed and confirmed,
which is done by the approval of the selected codeowners.
Before closing the Change Request, :need:`Delivery Team <rl__delivery_team>` must check the
correctness.

The :need:`Committer <rl__committer>` may still reject it, thus the status is set to
"rejected".

The author of the Change Request may cancel it, thus the status is set to "rejected".
The :need:`Delivery Team <rl__delivery_team>` may still reject it, thus the status
is set to "rejected".

.. workflow:: Close Change Request
:id: wf__change_close_cr
:status: valid
:tags: change_management
:responsible: rl__committer
:approved_by: rl__project_lead
:supported_by: rl__safety_manager, rl__security_manager, rl__quality_manager
:responsible: rl__delivery_team, rl__platform_team
:approved_by: rl__delivery_team, rl__platform_team
:supported_by: rl__project_lead
:input: wp__issue_track_system, wp__feat_request, wp__cmpt_request
:output: wp__issue_track_system, wp__feat_request, wp__cmpt_request
:contains: gd_guidl__change_change_request, gd_temp__change_feature_request, gd_temp__change_component_request, gd_temp__change_impact_analysis, gd_temp__component_classification, gd_temp__change_decision_record
Expand All @@ -101,9 +101,10 @@ For a detailed explanation of workflows and their role within the process model,
The Change Request is closed.

The Change Request is closed only, if the implementation is sufficient. That is verified
by the :need:`Committer <rl__committer>` finally.
by the :need:`Delivery Team <rl__delivery_team>` finally, especially the selected
codeowners of the team must approve.

Otherwise the :need:`Committer <rl__committer>` keeps the status "in implementation".
Otherwise the :need:`Delivery Team <rl__delivery_team>` keeps the status "in implementation".

.. needextend:: docname is not None and "process_areas/change_management" in docname
:+tags: change_management
Expand Down
20 changes: 20 additions & 0 deletions process/process_areas/problem_resolution/guidance/problem_resolution_guideline.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -177,6 +177,26 @@ If applicable, the features affected should be identified too.

The description shall reflect the result of the analysis.

Topics to checked (critical topics are marked with *):

- [*] Is the problem description clear and detailed enough to understand the problem and its impact?
- [*] Is the problem root cause clearly described?
- [*] Is the problem impact clearly described?
- [ ] Is notification of affected parties required? If yes, are the affected parties notified?
- [ ] Are there any proposed solutions provided?
- [ ] Are there any further linked issues or pull requests provided?
- [*] Is the error occurrence rate provided? If yes, is it high enough to accept the problem?
- [*] Is the problem reproducible?
- [ ] Are there any further supporting information provided?
- [*] Is the problem classification correct?
- [*] Is information for the affected version of the release provided? If yes, is it correct?
- [ ] Is the information for the expected closure version provided? If yes, is it correct?
- [*] Is the problem affecting safety or security? If yes, is the classification correct?

The analysis phase can not be closed, until all critical topics are
clarified and provided in the description. If not, the problem report should be rejected
and closed with the reason "Closed as not planned".

.. note::
| For the Problem Report Example:
| * The descriptions has a section for the analysis results: **Accepted**
Expand Down
37 changes: 33 additions & 4 deletions process/roles/index.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -108,6 +108,28 @@ Project Development Roles
The testing community members are responsible for the test case development from component to
platform level. They shall be included in any requirements reviews. They can also improve
independence argumentation when involved in the development of unit testing on safety critical
units. In this way the testing community takes a supportive role for unit testing.

.. role:: Architecture Community Member
:id: rl__architecture_community
:status: valid
:tags: architecture_design
:contains: rl__committer

The architecture community members are responsible for the features and components of
the platform. Feature and Components requests, which add new ones or modifications, are
in their responsibility. They are aligned with the Project Leads.

About Features

Feature Request issue template

Component Request

A Component Request represents an independent work package used to describe modifications inside a Feature, either adding new components or modifying existing ones. Component Request work packages can be linked to other work packages, but they must not be treated as parent work packages. They shall be discussed with Architecture Community and the issues are owned by a Team and are part of the Team`s main repository..

They shall be included in any requirements reviews. They can also improve
independence argumentation when involved in the development of unit testing on safety critical
units. In this way the testing community takes a supportive role for unit testing

.. role:: Project Security Team
Expand All @@ -126,18 +148,25 @@ Project Teams
:id: rl__platform_team
:status: valid
:tags: cross_functional
:contains: rl__project_lead, rl__safety_manager, rl__quality_manager, rl__security_manager, rl__contributor, rl__committer, rl__infrastructure_tooling_community, rl__process_community
:contains: rl__project_lead, rl__safety_manager, rl__quality_manager, rl__security_manager, rl__contributor, rl__committer, rl__infrastructure_tooling_community, rl__process_community, rl__architecture_community

The platform team is responsible for all artifacts within the platform SEooC. Additionally it is also responsible for the overall process including its support by tooling.
The platform team is responsible for all artifacts within the platform SEooC.
Additionally it is also responsible for the overall process including its support
by tooling.
Depending on the platform artifacts, some of them are assigned as codeowner.

.. role:: Delivery Team
:id: rl__delivery_team
:status: valid
:tags: cross_functional
:contains: rl__safety_manager, rl__quality_manager, rl__security_manager, rl__contributor, rl__committer

The delivery team is responsible for all artifacts within the Delivery Container SEooCs containing the Dependable Elements. Each Delivery Container has only one responsible team.
One of the committers in the team acts as the "Project Manager" and is responsible for planning and reporting.
The delivery team is responsible for all artifacts within the Delivery Container
SEooCs containing the Dependable Elements. Each Delivery Container has only one
responsible team.
One of the committers in the team acts as the "Project Manager" and is responsible
for planning and reporting.
Depending on the delivery container artifacts, some of them are assigned as codeowner.

.. role:: Release Team
:id: rl__release_team
Expand Down
Loading