Adapt module term usage

process/process_areas/architecture_design/architecture_concept.rst

@@ -123,7 +123,7 @@ The feature architecture contain the following views:
 Static View
 -----------
 
-The first viewpoint is named as *feature architecture*. It displays the SW Components within the SW modules (= top level SW components) which are required to realize the feature including their interactions. Also the *logical interfaces* and the interaction between the feature and the user are included in this view. On this architectural level the feature requirements shall be allocated. An example for the static architecture is shown here:
+The first viewpoint is named as *feature architecture*. It displays the SW Components within the SW modules (= dependable elements) which are required to realize the feature including their interactions. Also the *logical interfaces* and the interaction between the feature and the user are included in this view. On this architectural level the feature requirements shall be allocated. An example for the static architecture is shown here:
 
 .. feat_arc_sta:: Feature 1 Architecture
    :id: feat_arc_sta__example_feature__feature_1
@@ -182,7 +182,7 @@ On the feature level only *logical interfaces* shall be displayed. This means th
 SW Module View
 ==============
 
-A SW Module represents a outcome of an component or a set of components realizing a feature and all belonging parts of CI build tool. It serves only as a container (or package) which can include components. It is not meant to be an architectural element which includes that no requirements can be allocated to it.
+A SW Module (=dependable element) is packaging a component or a set of components which is developed, documented and released together. It is not meant to be an architectural element which means that no requirements can be allocated to it.
 
 On this level also a view shall be defined which is called *Module View*. It represents the allocation of components into modules and displays the dependencies between the single modules. In this view also cyclic dependencies between modules can be identified.
 
@@ -295,7 +295,7 @@ The *static view* shows the *building blocks* of the architecture. It shall be c
    * - Component Architecture
      - comp_arc_sta
 
-To represent the CI build tool module (for example a `Bazel Modules <https://bazel.build/external/module>`_) an additional container (or package) is introduced. It can only contain components:
+To represent the SW module an additional package view is introduced. It can only contain components:
 
 .. list-table:: Definition of the static module view
    :header-rows: 1

process/process_areas/architecture_design/guidance/architecture_guideline.rst

@@ -78,7 +78,7 @@ Those steps are:
      - :ref:`Review architectural design <review_architectural_design>`
      - :need:`[[title]] <rl__committer>`
    * - 5.
-     - Merge architectural design into score repository
+     - Merge architectural design into score delivery container
      - :need:`[[title]] <rl__committer>`
    * - 6.
      - | :ref:`Create component architecture (Concept) <create_component_architecture>`
@@ -91,15 +91,15 @@ Those steps are:
      - :ref:`Review component architecture <review_component_architecture>`
      - :need:`[[title]] <rl__committer>`
    * - 9.
-     - Merge component architectural design into module
+     - Merge component architectural design into module's delivery container
      - :need:`[[title]]  <rl__committer>`
 
 .. _create_feature_architecture:
 
 Create feature architecture (Concept)
 ----------------------------------------
 
-The feature architecture (= high-level architecture) shall be created in the feature tree of the platform repository.
+The feature architecture (= high-level architecture) shall be created in the feature tree of the platform delivery container.
 
 For this step, the following guidance is available: :need:`Feature Architecture Template <gd_temp__arch_feature>`. Based on this template, the feature architecture shall describe the concept of the feature, including supporting figures and drawings. If multiple solutions are possible, these should be documented here with the rationale for the final decision. A design decision template is provided in :need:`Decision Record Template <gd_temp__change_decision_record>`.
 
@@ -149,7 +149,7 @@ Review architectural design
 ---------------------------
 
 As soon as the design is in a mature state, it can be reviewed according to :need:`doc_concept__wp_inspections`
-and merged into the main branch of the score repository. See also the document life-cycle guideline :need:`gd_guidl__documentation` for more information about the documentation for the feature architecture :need:`wp__feature_arch`.
+and merged into the main branch of the platform delivery container. See also the document life-cycle guideline :need:`gd_guidl__documentation` for more information about the documentation for the feature architecture :need:`wp__feature_arch`.
 
 For the review process, a checklist template is available: :need:`Architecture Inspection Checklist Template <gd_chklst__arch_inspection_checklist>`.
 
@@ -165,7 +165,7 @@ The following roles should be included in the review:
 Create component architecture (Concept)
 ---------------------------------------
 
-Based on the *feature architecture*, the concept for the *component architecture* shall be created in the SW module. It shall describe which components need to be created and how they correlate with each other in order to provide the required functionality. As a starting point, a :need:`template <gd_temp__arch_comp>` is provided.
+Based on the *feature architecture*, the concept for the *component architecture* shall be created in the module's delivery container. It shall describe which components need to be created and how they correlate with each other in order to provide the required functionality. As a starting point, a :need:`template <gd_temp__arch_comp>` is provided.
 
 For this step, the following guidance is available: :need:`Feature Architecture Template <gd_temp__arch_feature>`. Additionally, you should consult your project's specific guidelines, e.g., for using the version management tooling or architecture element naming conventions, which should be defined (or linked) in the :need:`Project SW development Plan <wp__sw_development_plan>`.
 
@@ -203,7 +203,7 @@ The relations of the static elements are described in :ref:`metamodel_architectu
 Review component architecture
 -----------------------------
 
-As soon as the design is in a mature state, it can be :ref:`reviewed <review_concept>` and merged into the main branch of the module repository. See also the document life-cycle guideline :need:`gd_guidl__documentation` for more information about the documentation for the component architecture :need:`wp__component_arch`.
+As soon as the design is in a mature state, it can be :ref:`reviewed <review_concept>` and merged into the main branch of the module's delivery container. See also the document life-cycle guideline :need:`gd_guidl__documentation` for more information about the documentation for the component architecture :need:`wp__component_arch`.
 
 Following roles should be included in the review:
 

process/process_areas/change_management/change_management_concept.rst

@@ -30,8 +30,7 @@ A *Change Request* is the **ONLY** way to contribute new features or to modify t
 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.
-As a *Software Module* is defined as the top-level component, all statements here for
-components are also valid for Software Modules.
+All statements here for components are also valid for *SW Modules*.
 
 Inputs
 ******

process/process_areas/change_management/change_management_workproducts.rst

@@ -63,4 +63,4 @@ Change Management Work Products
    |
    | Change Request for a new component or a modification of an existing component,
    | which changes the scope of the component.
-   | Software Modules are also components (top-level component).
+   | This includes the allocation of components into SW Modules.

process/process_areas/configuration_management/guidance/configuration_templates.rst

@@ -126,7 +126,7 @@ In <project name> project all configuration items are kept in the version manage
 <Describe how baselines are created by using the version management tool.>
 See also <link to doc__platform_release_management_plan>.
 
-Every change in the release repository is also taken over into the main branch. The module development team
+Every change in the release repository is also taken over into the main branch. The :need:`rl__delivery_team` responsible for the repository
 can decide how to ensure this (e.g. by development in main and cherrypick to release branch).
 
 

process/process_areas/release_management/guidance/release_guideline.rst

@@ -27,7 +27,7 @@ Software Module Release
 
 1. **Repository Management**:
 
-   * Each software module is contained in its own repository.
+   * Each software module is contained in one repository.
    * Ensure that the repository follows the standard naming conventions and structure.
 
 2. **Release Planning**:
@@ -44,7 +44,7 @@ Software Module Release
 
 4. **Release Preparation**:
 
-   * Update the version number according to the versioning policy of your module (defined in release management part of the :need:`gd_temp__platform_mgmt_plan`).
+   * Update the version number according to the versioning policy of your module's delivery container (defined in release management part of the :need:`gd_temp__platform_mgmt_plan`).
    * Prepare release notes documenting the changes, improvements, and bug fixes.
    * Check if all planned configuration items are in correct state (i.e. work products are valid, external libraries/tools are used in the correct released version).
    * Ensure the module's safety package is available and complete.

process/process_areas/release_management/release_concept.rst

@@ -64,15 +64,16 @@ Platform Release
 
 The Platform Release contains the full <Project> scope which spans over many modules. The releases
 are proposed and approved by *Project Leads*. Every software module
-has its own repository which contains multiple components, their requirements, architecture,
-implementation and tests.
+is located in one repository (= delivery container) which contains multiple components, their requirements, architecture,
+implementation and tests. There may be more than one software module (=dependable element) in one repository,
+but this is not the recommended configuration.
 
 #. :need:`Project Lead Circle <rl__project_lead>`
 
    * Define and proposes scope of release
    * Writes platform release notes
    * Approves the platform release notes
-   * Adds and removes software modules to the platform
+   * Adds and removes delivery containers to the platform
    * Releases the platform
 
 Module Release Plan
@@ -103,7 +104,7 @@ Only released software modules can be included into a platform release.
 #. :need:`Project Lead Circle <rl__project_lead>`
 
    * Approves the module release notes
-   * Adds and removes Software modules to the Platform
+   * Adds and removes delivery containers to the Platform
    * Releases the module
 
 Branching Strategy

process/process_areas/requirements_engineering/guidance/requirements_guideline.rst

@@ -162,7 +162,7 @@ Following roles should be included in the review:
 Derive child requirement and establish traceability
 ---------------------------------------------------
 
-In an upcoming step the child requirements shall be derived from the parent requirements. Feature requirements shall be placed in the main project's repository again, while component requirements shall be placed in the module repository. During this process the derived requirements shall also be linked according to the defined traceability matrix to the parent requirements.
+In an upcoming step the child requirements shall be derived from the parent requirements. Feature requirements shall be placed in the main project's repository again, while component requirements shall be placed in the module's repository. During this process the derived requirements shall also be linked according to the defined traceability matrix to the parent requirements.
 
 For this the following templates are available:
 
@@ -211,7 +211,7 @@ This is different for AoU created on SW-platform level, these are also coming fr
 As it can not be fulfilled by the architecture element (e.g. component) itself, it needs to be fulfilled by the user of the element.
 In Safety Elements out of Context (SEooC) the AoUs will normally be part of the safety manual.
 In this process description (as it describes SEooC development) these AoUs are created both internally and externally - the latter if existing SEooCs are integrated into the platform (e.g. a qualified Operating System).
-For AoU which arise internally (i.e. from project specific modules) the template is almost identical to the one for feature/component requirements. The only difference is that it is defined such that the attribute "satisfies" is replaced with the attribute "mitigates" (see picture below).
+For AoU which arise internally (i.e. from project specific architecture) the template is almost identical to the one for feature/component requirements. The only difference is that it is defined such that the attribute "satisfies" is replaced with the attribute "mitigates" (see picture below).
 For externally provided AoUs of course the sentence template cannot be taken into account, as these are only imported from an external safety manual. It is also not possible to link it to other development artifacts via the attribute "mitigates".
 
 AoUs can be of different class and shall be handled by tracing those

process/process_areas/requirements_engineering/requirements_concept.rst

@@ -113,11 +113,11 @@ i.e. the assumption on what content is needed, which shall be matched by the use
 Feature Requirements
 ====================
 
-The *Feature Requirements* derived from stakeholder requirements address mainly the integration level of SW modules and components. These shall describe the behaviour of the feature on platform level shall be described including the correlations of the integrated components. They serves mainly as an input for (SW + Safety) Architects, Testers, Integrators and are derived from the *Stakeholder Requirements*. To provide an example
+The *Feature Requirements* derived from stakeholder requirements address mainly the integration level of SW components. These shall describe the behaviour of the feature on platform level independent from a decomposition into components. They serves mainly as an input for (SW + Safety) Architects, Testers, Integrators. Example:
 
 .. code-block:: text
 
-   The feature shall accept JSON formatted string input according to RFC-8259
+   The feature shall use JSON formatted string according to RFC-8259 for configuration
 
 However the detailed interaction of the underlying components itself which is required to form a feature shall be defined in the feature architecture.
 

process/process_areas/safety_analysis/guidance/dfa_failure_initiators.rst

@@ -48,7 +48,7 @@ DFA failure initiators
     - Violation cause shared resources
     - Importance (can be used for prioritization)
   * - SR_01_01
-    - Reused software modules
+    - Reused software components
     - Medium
   * - SR_01_02
     - Libraries

process/process_areas/safety_analysis/guidance/safety_analysis_guideline.rst

@@ -141,7 +141,7 @@ In the static view of the example could be seen that component 1 uses component
 
     The shall be possible to detect and report data corruption.
 
-* Failure initiator SR_01_01 "reused software modules" is not applicable, no software modules are reused in the feature.
+* Failure initiator SR_01_01 "reused software components" is not applicable, no software components are reused in the feature.
 * Failure initiator SI_01_03 "constants, or variables, being global to the two software functions" is not applicable, because it's not possible to create constants or variables that being global to the two software functions in Rust.
 
 

process/process_areas/safety_analysis/safety_analysis_concept.rst

@@ -144,7 +144,7 @@ The Safety Analysis (DFA and FMEA) shall consider the architectural elements on
 
 1. **Platform Level**: At this level, the focus is on the overall feature architecture to analyse if there are failures that effects more than one feature.
 
-    | **Example DFA:** Dependencies between features shall be analysed. This could be the usage of modules by different features, shared libraries or shared services. A common cause failure could be a erroneous signal that effects the behaviour of several functions.
+    | **Example DFA:** Dependencies between features shall be analysed. This could be the usage of feature interfaces by multiple features, shared libraries or shared services. A common cause failure could be a erroneous signal that effects the behaviour of several functions.
 
 2. **Feature Level**: This level involves a more detailed analysis of individual components within the feature. The analysis shall consider the internal structure of components and their interactions with other components in the feature.
 

process/process_areas/safety_analysis/safety_analysis_workproducts.rst

@@ -21,7 +21,7 @@ Safety Analysis Work Products
    :tags: doc_lifecycle_model_2
    :complies: std_wp__iso26262__software_751, std_wp__iso26262__software_753, std_wp__isopas8926__4524
 
-   Analyse the dependencies between features that references all platform feature static architecture diagrams, highlighting potential shared use of modules.
+   Analyse the dependencies between features that references all platform feature static architecture diagrams, highlighting potential shared use of features.
 
 .. workproduct:: Feature FMEA
    :id: wp__feature_fmea
@@ -43,7 +43,7 @@ Safety Analysis Work Products
 
    Detections, preventions, mitigations linked to Software Feature Requirements or Feature Assumptions of Use.
 
-   Perform analysis on interactions between safety related and non-safety related modules or modules with different ASIL of one feature.
+   Perform analysis on interactions between safety related and non-safety related components or components with different ASIL of one feature.
 
 .. workproduct:: Component FMEA
    :id: wp__sw_component_fmea
@@ -61,10 +61,10 @@ Safety Analysis Work Products
    :tags: doc_lifecycle_model_2
    :complies: std_wp__iso26262__analysis_751, std_wp__iso26262__software_753, std_wp__isopas8926__4524, std_wp__iso26262__software_752
 
-   Dependent Failure Analysis on component/module level.
+   Dependent Failure Analysis on component level.
 
    Detections, preventions, mitigations linked to Software Component Requirements or Assumptions of Use.
 
    Perform analysis of safety related and non-safety related sub-elements or sub-elements with different ASIL.
 
-   Perform analysis on interactions between safety related and non-safety related sub-components or sub-components with different ASIL of one component. Including potential influences from the other components in the component's module.
+   Perform analysis on interactions between safety related and non-safety related lower level components or lower level components with different ASIL of one (higher level) component.

process/process_areas/verification/guidance/verification_templates.rst

@@ -25,7 +25,7 @@ Verification Templates
               std_req__iso26262__support_9421, std_req__iso26262__support_9422
 
    The sections below are seen as typical ways when writing tests and their specification.
-   Their usage differs based on the selected testing framework and the implementation language of the module(s).
+   Their usage differs based on the selected testing framework and the implementation language of the component(s).
 
 C++
 ---