implementation process tooling team feedback fixes (#56)

Author: aschemmel-tech

process/process_areas/implementation/guidance/implementation_checklist.rst

@@ -52,30 +52,19 @@ Checklist
      -
      -
    * - IMPL_01_02
-     - Are the SOLID design principles applied?
-     - The Unit Design shall achieve the following principles:
-       Correct order of execution of the functions,
-       consistency of the interfaces between the units,
-       correctness of data flow and data control between the units,
-       simplicity, readability and comprehensibility, robustness,
-       suitability for modifications, verifiability
-     -
-     -
-     -
-   * - IMPL_01_03
      - Is the implementation according to specification?
      - Check if the linked component requirements are fulfilled
        and detailed design also matches architecture description.
      -
      -
      -
-   * - IMPL_01_04
+   * - IMPL_01_03
      - Are the design decisions and constraints documented?
      - Check also for plausibility of these.
      -
      -
      -
-   * - IMPL_01_05
+   * - IMPL_01_04
      - Are all external libraries used by the component specified in the detailed design?
      - Check the automated dependency analysis.
        Also make sure ASIL rated units also only use ASIL or FFI rated libraries.

process/process_areas/implementation/guidance/implementation_process_reqs.rst

@@ -19,19 +19,44 @@ Process Requirements
    :id: gd_req__static_diagram
    :status: valid
    :tags: mandatory
-   :satisfies: wp__sw_implementation
+   :satisfies: wf__sw_detailed_design
    :complies: std_req__iso26262__software_843
 
-   The static diagram represents the unit and their relationships using UML 2.0 notations by using PlantUML.
+   The static diagram shall represent the unit and their relationships using UML notations.
 
 .. gd_req:: Dynamic Diagram for Unit Interactions
    :id: gd_req__dynamic_diagram
    :status: valid
    :tags: mandatory
-   :satisfies: wp__sw_implementation
+   :satisfies: wf__sw_detailed_design
    :complies: std_req__iso26262__software_843
 
-   The dynamic diagram represents the unit and their relationships using UML 2.0 notations by using PlantUML.
+   The dynamic diagram shall represent the unit and their relationships using UML notations.
+
+.. gd_req:: Design to Code Linking
+   :id: gd_req__design_code_link
+   :status: valid
+   :tags: mandatory
+   :satisfies: wf__sw_detailed_design
+   :complies: std_req__iso26262__software_843
+
+   The detailed design (units and interfaces in DD document) shall be linked
+   to the source code which implements the units and interfaces in the DD.
+
+   Note: Not every code element must have such a link (i.e. is represented in the detailed design),
+   these elements are implementation detail.
+
+
+.. gd_req:: Dependency Analysis
+   :id: gd_req__dependency_analysis
+   :status: valid
+   :satisfies: wf__sw_verify_implementation
+   :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.
 
 .. needextend:: docname is not None and "process_areas/implementation" in docname
    :+tags: implementation

process/process_areas/implementation/implementation_concept.rst

@@ -89,6 +89,10 @@ This view focuses **only on units and their relationships**.
 Details such as **attributes and interfaces** are documented under the **Units within the Component section**
 (refer to the template for details).
 
+Note that the detailed design may not be complete in the way that it covers every class which is coded.
+These not covered parts may contain implementation detail and should not be needed to understand the
+the detailed design.
+
 Dynamic View
 ````````````
 The **dynamic view** illustrates how the **units** interact with each other to fulfill a specific
@@ -98,10 +102,11 @@ It is represented using **UML behavioral diagrams**, including:
 - **Sequence Diagrams** – Depict the interactions between objects in a **time-ordered sequence**,
   highlighting how methods are invoked and how control flows between objects over time.
 - **State Machine Diagrams** – Show how the **state of an object changes** in response to events,
-  allowing for the modeling of complex state transitions.
+  allowing for the modeling of complex state transitions (if there is stateful behaviour).
 
 These diagrams are essential for understanding the **dynamic behavior** of the component and how
-units collaborate to perform tasks.
+units collaborate to perform tasks. But this also means that if the dynamic behaviour is simple
+it does not require a dynamic diagram at all (similar to the rules depicted in :need:`gd_guidl__arch__design`).
 
 Units within the Component
 --------------------------
@@ -120,9 +125,6 @@ For cpp using doxygen style comments-
       * @rst
       * .. sw_unit:: cpp unit
       *    :id: sw_unit__<title>
-      *    :security:
-      *    :safety:
-      *    :status
       *
       *    This implements the ....
       * @endrst
@@ -134,9 +136,6 @@ for rust -
 
    //! .. sw_unit:: rust unit
    //!     :id: sw_unit__<title>
-   //!     :security:
-   //!     :safety:
-   //!     :status
    //!
    //!     This implements the ....
 
@@ -156,9 +155,6 @@ For cpp using doxygen comments-
       * @rst
       * .. sw_unit_int:: cpp unit
       *    :id: sw_unit_int__<title>
-      *    :security:
-      *    :safety:
-      *    :status
       *
       *    This implements the ....
       * @endrst
@@ -170,8 +166,5 @@ For rust -
 
    //! .. sw_unit_int:: rust unit
    //!     :id: sw_unit_int__<title>
-   //!     :security:
-   //!     :safety:
-   //!     :status
    //!
    //!     This implements the ....

process/process_areas/verification/verification_concept.rst

@@ -139,9 +139,12 @@ Following aspect should be considered when developing test cases:
 * **Comprehensive Coverage:** Test cases should cover all functional and tool requirements, including
   positive, negative, and boundary conditions. Specific attention should be given to corner cases and error handling.
 * **Requirements Testing:** Guarantees testing of Component, Feature, and Stakeholder requirements.
-* **Unit Testing:** Focus on isolating and testing individual units or components of the code.
+* **Unit Testing:** Focus on testing individual units or components of the code.
   Strive for high code coverage for branches and lines.
   Coverage goals are defined in the :need:`wp__verification__plan`.
+  Consider not mocking away libraries the unit uses, as long as you can obtain sufficient
+  structural coverage from the unit testing with included/integrated libraries,
+  as this reduces effort on integration testing.
 
   Use the following frameworks for unit testing: