diff --git a/process/process_areas/implementation/guidance/implementation_checklist.rst b/process/process_areas/implementation/guidance/implementation_checklist.rst index 250a0bba96..93edb10b35 100644 --- a/process/process_areas/implementation/guidance/implementation_checklist.rst +++ b/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. diff --git a/process/process_areas/implementation/guidance/implementation_process_reqs.rst b/process/process_areas/implementation/guidance/implementation_process_reqs.rst index be1a03e96d..3d7e5f5528 100644 --- a/process/process_areas/implementation/guidance/implementation_process_reqs.rst +++ b/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 diff --git a/process/process_areas/implementation/implementation_concept.rst b/process/process_areas/implementation/implementation_concept.rst index d790048a78..fc485378d9 100644 --- a/process/process_areas/implementation/implementation_concept.rst +++ b/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__ - * :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 .... diff --git a/process/process_areas/verification/verification_concept.rst b/process/process_areas/verification/verification_concept.rst index 15d7ed3414..51de21b42c 100644 --- a/process/process_areas/verification/verification_concept.rst +++ b/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: