Merge pull request #399 from etas-contrib/add_links_to_pmp

Add links to pmp

Author: masc2023

process/process_areas/architecture_design/architecture_concept.rst

@@ -175,7 +175,7 @@ On the feature level only *logical interfaces* shall be displayed. This means th
 SW Module View
 ==============
 
-A SW Module in S-CORE represents a `Bazel Module <https://bazel.build/external/module>`_. 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 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.
 
 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.
 
@@ -196,7 +196,7 @@ Component View
 Static View
 -----------
 
-The second viewpoint is named as *component architecture* and describes the implementation of the functionalities in a white-box view of the platform. It describes the structural decomposition of the *SW components* into *lower level* SW components. In the S-CORE project this viewpoint provides more detailed information concerning the respective interfaces of a component. If a SW component interacts with a different component it is also included via a *use* relationship in the diagram. An example of the *component architecture* is displayed here:
+The second viewpoint is named as *component architecture* and describes the implementation of the functionalities in a white-box view of the platform. It describes the structural decomposition of the *SW components* into *lower level* SW components. In the projects this viewpoint provides more detailed information concerning the respective interfaces of a component. If a SW component interacts with a different component it is also included via a *use* relationship in the diagram. An example of the *component architecture* is displayed here:
 
 .. comp_arc_sta:: Component 2
    :id: comp_arc_sta__example_feature__archdes_component_2
@@ -280,7 +280,7 @@ The *static view* shows the *building blocks* of the architecture. It shall be c
      - comp_arc_sta
      - comp_arc_sta_t
 
-To represent the `Bazel Modules <https://bazel.build/external/module>`_ an additional container (or package) is introduced. It can only contain components:
+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:
 
 .. list-table:: Definition of the static module view
    :header-rows: 1

process/process_areas/architecture_design/guidance/architecture_guideline.rst

@@ -100,15 +100,8 @@ Create feature architecture (Concept)
 ----------------------------------------
 
 The feature architecture (= high level architecture) shall be created in the feature tree of the platform repository.
-As a starting point a :need:`template <gd_temp__arch_feature>` is available.
 
-Based on this template the feature architecture shall describe the concept of the feature including supporting figures and drawings.
-
-For this step following guidances are available:
-
-* `Branch Naming Conventions <REPLACE_doc__naming_conventions>`
-* `Git Guidelines <REPLACE_doc__git_coding_guidelines>`
-* :need:`[[title]] Feature Architecture <gd_temp__arch_feature>`
+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. 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>`.
 
 .. _model_feature_architecture:
 
@@ -176,11 +169,7 @@ 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.
 
-For this step following guidances are available:
-
-* `Branch Naming Conventions <REPLACE_doc__naming_conventions>`
-* `Git Guidelines <REPLACE_doc__git_coding_guidelines>`
-* :need:`[[title]] <gd_temp__arch_comp>`
+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>`.
 
 .. _allocate_component_requirements:
 

process/process_areas/architecture_design/guidance/architecture_inspection_checklist.rst

@@ -27,7 +27,7 @@ Purpose
 -------
 
 The purpose of the software architecture checklist is to ensure that the design meets the criteria and quality as
-defined per S-CORE processes and guidelines for feature and component architectural design elements.
+defined per project processes and guidelines for feature and component architectural design elements.
 It helps to check the compliance with requirements, identify errors or inconsistencies, and ensure adherence to best
 practices.
 The checklist guides evaluation of the architecture design, identifies potential problems, and aids in

process/process_areas/architecture_design/guidance/architecture_process_reqs.rst

@@ -51,11 +51,13 @@ Architectural Model
    Following architectural elements shall be defined on the respective hierarchical level:
 
    * Logical Level
+
      * Feature (feature_arc_sta)
      * Logical Interface (logic_arc_int)
      * Logical Interface Operation (logic_arc_int_op)
 
    * Component Level
+
      * Component (comp_arc_sta)
      * Interface (real_arc_int)
      * Interface Operation (real_arc_int_op)

process/process_areas/implementation/guidance/implementation_guideline.rst

@@ -28,13 +28,12 @@ Workflow for Implementation
 Detailed description which steps are need for implementation.
 
 #. Consult which programming languages, design/coding guidelines and tools are used for Software
-   development within the Software Development Plan `REPLACE_doc__software_development_plan`.
+   development according the rules given in the project specific :need:`SW development Plan <wp__sw_development_plan>`.
 #. Create a Detailed Design by using the template :need:`gd_temp__detailed_design`.
    In this step, the components are broken down into smaller, independent units that can be tested
    separately during the unit testing phase. The detailed design shall be so exact, that test and
    implementation can be run simultaneously.
-#. Implement the source code, by using the coding guidelines `REPLACE_doc__cpp_coding_guidelines` for C++,
-   or <TBD> for Rust.
+#. Implement the source code, by using the coding guidelines given within the project specific :need:`SW development Plan <wp__sw_development_plan>` for the programming languages in your project.
 #. Create a pull request for your change.
 #. Detail Design and Code Inspection is done to review the code of the software and detect errors in it.
 #. Check the results of the static and dynamic code analysis (this inlcludes compiler warnings).

process/process_areas/implementation/guidance/implementation_process_reqs.rst

@@ -55,9 +55,7 @@ Process Requirements
    :complies: std_req__iso26262__software_942
 
    For each component a dependency tree view shall be created to support design inspection and Safety Analysis.
-   It shall show the libraries used by the component (i.e. which libraries are linked to the component, defined as Bazel target) up to the leaves of the tree.
-
-   Note: This may be realized by using Bazel query mechanism.
+   It shall show the libraries used by the component (i.e. which libraries are linked to the component, defined as CI build tool target) up to the leaves of the tree.
 
 .. needextend:: docname is not None and "process_areas/implementation" in docname
    :+tags: implementation

process/process_areas/requirements_engineering/requirements_concept.rst

@@ -228,7 +228,7 @@ Requirements Versioning
 Individual Requirements
 =======================
 
-For the requirements the version management is basically provided by version managemnt tooling (e.g. git history). However it needs to be identified if the content of a requirement changed. So this concept aims only at identifying a change in the mandatory attributes of a requirement.
+For the requirements the version management is basically provided by version management tooling (e.g. git history). However it needs to be identified if the content of a requirement changed. So this concept aims only at identifying a change in the mandatory attributes of a requirement.
 
 Calculate hash for current requirements
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^