SWE.3 Software Detailed Design and Unit Construction#
The purpose is to establish a software detailed design, comprising static and dynamic aspects, consistent with the software architecture, and to construct software units consistent with the software detailed design.
Process outcomes#
A detailed design is specified including static and dynamic aspects.
Software units as specified in the software detailed design are produced.
Consistency and bidirectional traceability are established between software detailed design and software architecture; and consistency and bidirectional traceability are established between source code and software detailed design; and consistency and bidirectional traceability are established between the software detailed design and the software requirements.
The source code and the agreed software detailed design are communicated to all affected parties.
Base practices#
SWE.3.BP1: Specify the static aspects of the detailed design
|
status: valid
|
||||
For each software component specify the behavior of its software units, their static structure and relationships, their interfaces including
Note The boundary of a software unit is independent from the software unit’s representation in the source code, code file structure, or model-based implementation, respectively. It is rather driven by the semantics of the application domain perspective. Therefore, a software unit may be, at the code level, represented by a single subroutine or a set of subroutines. Note Examples of valid data value ranges with applicable physical units from the application domain perspective are ‘0..200 [m/s]’, ‘0..3.8 [A]’ or ‘1..100 [N]’. For mapping such application domain value ranges to programming language-level data types (such as unsigned Integer with a value range of 0..65535) refer to {need}`std_bp_aspice-40__SWE-3-BP2`. Note Examples of a measurement unit are ‘%’ or ‘‰’ Note A counter is an example of a parameter, or a return value, to which neither a physical nor a surement unit is applicable. Note The hardware-software-interface (HSI) definition puts in context the hardware design and refore is an aspect of system design (SYS.3). |
|||||
SWE.3.BP2: Specify dynamic aspects of the detailed design
|
status: valid
|
||||
Specify and document the dynamic aspects of the detailed design with respect to the software architecture, including the interactions between relevant software units to fulfill the component’s dynamic behavior. Note Examples for behavioral descriptions are natural language or semi-formal notation (e.g, SysML, UML). |
|||||
SWE.3.BP3: Develop software units
|
status: valid
|
||||
Develop and document the software units consistent with the detailed design, and according to coding principles. Note Examples for coding principles at capability level 1 are not to use implicit type conversions, only one entry and one exit point in subroutines, and range checks (design-by-contract, defensive programming). Further examples see e.g, ISO 26262-6 clause 8.4.5 together with table 6. |
|||||
SWE.3.BP4: Ensure consistency and establish bidirectional traceability
|
status: valid
|
||||
Ensure consistency and establish bidirectional traceability between the software detailed design and the software architecture. Ensure consistency and establish bidirectional traceability between the developed software units and the software detailed design. Ensure consistency and establish traceability between the software detailed design and the software requirements. Note Redundancy should be avoided by establishing a combination of these approaches. Note Examples for tracing a software unit in the detailed design to a software requirement directly are communication matrices or basis software aspects such as a list of diagnosis identifiers inherent in an Autosar configuration. Note Bidirectional traceability supports consistency, and facilitates impact analysis of change requests, and demonstration of verification coverage. Traceability alone, e.g., the existence of links, does not necessarily mean that the information is consistent with each other. |
|||||
SWE.3.BP5: Communicate agreed software detailed design and developed software units
|
status: valid
|
||||
Communicate the agreed software detailed design and developed software units to all affected parties. |
|||||