Merge branch 'main' into attifunel_competence_mgm_responsibility_change

Signed-off-by: Philipp Ahmann <[email protected]>

Author: pahmann

process/_assets/score_process_area_overview.drawio.svg

@@ -66,7 +66,7 @@ List of AoUs expected from the environment the platform / module runs on:
 
 Assumptions on the User
 ^^^^^^^^^^^^^^^^^^^^^^^
-| As there is no assumption on which specific OS and HW is used, the integration testing of the stakeholder and feature requirements is expected to be performed by the user of the platform SEooC. Tests covering all stakeholder and feature requirements performed on a reference platform (tbd link to reference platform specification), reviewed and passed are included in the platform SEooC safety case.
+| As there is no assumption on which specific OS and HW is used, the integration testing of the stakeholder and feature requirements is expected to be performed by the user of the platform SEooC. Tests covering all stakeholder and feature requirements performed on a reference platform (tbd link to reference platform specification), reviewed and passed are included in the platform SEooC safety package.
 | Additionally the components of the platform may have additional specific assumptions how they are used. These are part of every module documentation: <link to add>. Assumptions from components to their users can be fulfilled in two ways:
 | 1. There are assumption which need to be fulfilled by all SW components, e.g. "every user of an IPC mechanism needs to make sure that he provides correct data (including appropriate ASIL level)" - in this case the AoU is marked as "platform".
 | 2. There are assumption which can be fulfilled by a safety mechanism realized by some other project platform component and are therefore not relevant for an user who uses the whole platform. But those are relevant if you chose to use the module SEooC stand-alone - in this case the AoU is marked as "module". An example would be the "JSON read" which requires "The user shall provide a string as input which is not corrupted due to HW or QM SW errors." - which is covered when using together with safe project platform persistency feature.

process/folder_templates/modules/module_name/docs/manual/safety_manual.rst

@@ -58,7 +58,7 @@ The purpose of this safety plan formal review checklist is to report status of t
           - <Rationale for result>
 
         * - 3
-          - Does the safety plan define all needed activities for safety management (incl. Confirmation review and Safety Audit)?
+          - Does the safety plan define all needed activities for safety management (incl. formal document review and Safety Audit)?
           - [YES | NO ]
           - <Rationale for result>
 

process/folder_templates/modules/module_name/docs/safety_mgt/module_safety_plan_fdr.rst

@@ -44,7 +44,7 @@ Workflow activities are supported by guidances.
 General Concepts
 ~~~~~~~~~~~~~~~~
 
-General concepts like traceability of work products, life cycle model, building blocks can be found here:
+The general concepts like traceability of work products, life cycle model, building blocks can be found here:
 
 .. toctree::
    :maxdepth: 1
@@ -64,7 +64,7 @@ The process description for the project (e.g. requirements, architecture, safety
 Process Role definition
 ~~~~~~~~~~~~~~~~~~~~~~~
 
-General roles not part of any process area.
+The general roles that are not part of any process area and the project roles list can be found here:
 
 .. toctree::
    :maxdepth: 1
@@ -74,7 +74,7 @@ General roles not part of any process area.
 Work Products
 ~~~~~~~~~~~~~
 
-General work products not part of any process area and work product overview list.
+The general work products that are not part of any process area and the work product overview list can be found here:
 
 .. toctree::
    :maxdepth: 1
@@ -84,7 +84,7 @@ General work products not part of any process area and work product overview lis
 Workflows
 ~~~~~~~~~
 
-General workflows not part of any process area and workflow overview list.
+The general workflows that are not part of any process area and workflow overview list can be found here:
 
 .. toctree::
    :maxdepth: 1
@@ -94,7 +94,7 @@ General workflows not part of any process area and workflow overview list.
 Standards
 ---------
 
-The the standard references the project's processes are derived from can be found here:
+The standard references the project's processes are derived from and the coverage of the requirements and the work products from the standards can be found here:
 
 .. toctree::
    :maxdepth: 1

process/index.rst

@@ -28,16 +28,19 @@ Introduction
 
 Motivation
 ----------
-| The process model aims to establish organization rules for developing
-| open source software in the automotive industry, which can be used in safety and security context.
+
+The process model aims to establish organization rules for developing
+open source software in the automotive industry, which can be used in safety and security context.
 
 Objectives
 ----------
-| The process model shall provide processes, which conform to state-of the art standards
-| * ASPICE
-| * ISO 26262
-| * ISO 21434
-| * ISO PAS 8926
+
+The process model shall provide processes, which conform to state-of the art standards
+
+* :ref:`ASPICE<standard_aspice_pam4>`
+* :ref:`ISO 26262<standard_iso26262>`
+* :ref:`ISO 21434<standard_isosae21434>`
+* :ref:`ISO PAS 8926<standard_isopas8926>`
 
 Approach
 --------
@@ -47,7 +50,7 @@ Approach
 3. We aim to develop the process in conformance to the targeted standards (compare figure below).
 4. We aim to establish traceability from the begin (compare :ref:`general_concepts_traceability`).
 5. We aim to verify conformity and traceability by tool automation as much as possible (compare figure below).
-6. We aim for an iterative collaboration model initiated by change requests (compare :need:`gd_guidl__change_change_request`)
+6. We aim for an iterative collaboration model initiated by change requests (compare :need:`gd_guidl__change_change_request`).
 
 
 .. figure:: _assets/score_process_model.drawio.svg
@@ -56,3 +59,15 @@ Approach
   :alt: Overview process model
 
   Overview process model
+
+The process model is structured around the concept of :ref:`workflows<workflows>`, which form the core of each :ref:`process<process_areas>`. Each workflow defines the sequence of activities required to achieve specific objectives within the project. The activities linked from these workflows are directly linked to roles, ensuring that responsibilities and accountabilities are clearly assigned throughout the process.
+
+Workflows also establish connections to :ref:`work products<work_products>`, which are often inputs and the tangible outputs or artifacts generated during process execution. Each work product is associated with or requested by relevant :ref:`standards<external_standards>` and :ref:`requirements<process_req>` of these standards, ensuring compliance and traceability.
+
+To facilitate onboarding and understanding, the process model provides dedicated sections for a "Getting Started" and a detailed "Concept Description" for each process. These resources help Contributors, Committers and other Users quickly familiarize themselves with the process, understand key concepts, and apply best practices throughout process execution and should be read in this order. See :need:`Requirements process getting started<doc_getstrt__req_process>`, :need:`Requirement concept description<doc_concept__req_process>` as examples.
+
+The model further integrates an comprehensive guideline (within the "Guidance" section), :ref:`templates<folder_templates>`, checklists and methods for each workflow to support the consistent and efficient execution of processes. See the :need:`Requirement process guideline<gd_guidl__req_engineering>`, the :need:`requirement inspection checklist<doc__feature_name_req_inspection>` and :need:`verification methods<gd_meth__verification_methods>` as examples.
+
+Additionally, the process model incorporates traceability mechanisms, allowing for the verification of conformity to standards such as ASPICE, ISO 26262, and others. The relationships between workflows, roles, work products, and supporting materials are visualized in the process model diagram above, providing a clear overview of how all elements interact to support process development and continuous improvement within the organization.
+
+The process model follows a code-centric, iterative approach that establishes :ref:`traceability<general_concepts_traceability>` according to the :ref:`meta model of the building blocks<general_concepts_building_blocks>` from the beginning and leverages tool automation to verify conformity and traceability as much as possible. Tools are evaluated and :ref:`qualified<tools_template>` by Committers, used by Contributors to execute workflows, and must fulfill defined process requirements to support efficient and compliant process execution.

process/introduction/_assets/score_process_model.drawio.svg

@@ -14,8 +14,10 @@
 
 .. _arch_workflow:
 
-Architecture Workflow
-=====================
+Architecture Workflows
+######################
+
+For a detailed explanation of workflows and their role within the process model, please refer to the :ref:`processes_introduction`.
 
 .. workflow:: Create/Maintain Feature architecture
    :id: wf__cr_mt_featarch

process/introduction/index.rst

@@ -14,8 +14,8 @@
 
 .. _arch_workproducts:
 
-Architecture Workproducts
-=========================
+Architecture Work Products
+##########################
 
 .. workproduct:: Feature Architecture
    :id: wp__feature_arch

process/process_areas/architecture_design/architecture_workflow.rst

@@ -20,7 +20,7 @@ Architecture Guideline
 .. gd_guidl:: Architectural Design
    :id: gd_guidl__arch_design
    :status: valid
-   :complies: std_req__isopas8926__44411, std_req__isopas8926__44412
+   :complies: std_req__isopas8926__44411, std_req__isopas8926__44412, std_req__iso26262__software_745
 
 The guideline focuses on the steps which need to be performed in order to create the architectural design. The concept behind those steps is described in the :need:`[[title]] <doc_concept__arch_process>`.
 

process/process_areas/architecture_design/architecture_workproducts.rst

@@ -127,7 +127,7 @@ Attributes of Architectural Elements
    :id: gd_req__arch_attr_safety
    :status: valid
    :tags: manual_prio_1, attribute, mandatory
-   :complies: std_req__iso26262__support_6421, std_req__iso26262__support_6425
+   :complies: std_req__iso26262__support_6421, std_req__iso26262__support_6425, std_req__iso26262__software_746
    :satisfies: wf__cr_mt_featarch, wf__cr_mt_comparch
 
    Each architectural element shall have a automotive safety integrity level (ASIL) identifier: