Introduction
The Software Detailed Design and Unit Construction process in Automotive SPICE® (also known as SWE.3) can help your organization provide an evaluated detailed design for the software components and specify and produce the software units.
There are two aspects you should manage in the software detailed design process:
Level of detail
Often, organizations struggle how specific the detailed design should be. A good way to approach this is to remember what the purpose of the detailed design is. It is the basis for the implementation of the code and the unit test. Especially the unit verification requires a detailed description. Here, the level of coverage must be considered.
For safety-critical software, ISO 26262 provides guidance. In non-safety software, customers typically require at least C0 or statement coverage; some customers require C1 or branch coverage. The higher the coverage goal, the more detail is required by the detailed design. If you have an ASIL-B classified module, C1 coverage is expected. That means that your detailed design should identify the different branches of your software.
Interfaces
A pitfall often encountered in assessments is the lack of a detailed description of the external and internal interfaces.
Expected content of interface documentation:
- Names
- Types
- Units
- Resolutions
- Ranges
- Default values
Without this information, a proper testing of the interfaces in the unit test is impossible.
It is okay if the external interfaces are described on the architectural level and tested in the software integration test.
When the detailed design should be documented?
Describe the detailed design before you implement the code.
Often, the detailed design is described after the code has been written. Why is that a problem? The unit test should check whether the code fulfills the detailed design.
If you write the detailed design after documenting your code, the point of the unit test is lost. You could argue that you may not need the unit test. The point is that you should derive your detailed design from your architecture and not from the code. If the chain is broken, then suddenly the content of documentation, and the tests do not make sense anymore.
So, the detailed design must be written before you start writing your code. There is nothing wrong with iteratively developing detailed design and code step by step.
What is the benefit of Software Detailed Design and Unit Construction?
The software detailed design is the link between the software requirements, software architecture and the implementation. This is done in iterative steps:
- The software architecture describes how the software is organized into components and how they interact.
- The software detailed design fully details each component and describes the structure and behavior of the software units.
- The software units are created according to the detailed design specifications.
The detailed design provides a complete specification for the software developer to construct the required software unit so that only high-quality and traceable tested software units are being developed.
What is the content of the Software Detailed Design and Unit Construction process?
- Based on the software architecture, the detailed design for each software component is created and documented. It describes the required logic and algorithms, internal and external interfaces, dynamic behaviors, and error conditions (BP1, BP2, BP3).
- It is evaluated and verified that they detailed design supports the software architecture (BP4).
The traceability between the software requirements and software units, software architecture and the software detailed design, and the detailed design and software units are demonstrated and checked for consistency (BP5, BP6).
Methods of unit verification
- The detailed design and any changes to it are agreed upon and communicated to the relevant parties (BP7).
- The source code of a software unit is created according to the detailed design specifications. In model-based development, it will be generated from the model (BP8).
Experiences, problems and hints
- Determining how the software architecture and the detailed design are structured: The architecture consists of elements which can be broken down into lower-level elements. The elements on the lowest level are called “components.” The detailed design starts with components and breaks them down into units, which have atomic character.
- Units must be often clearly defined and consistently used. For example, is a unit a C file, a method or function, or an atomic element in a model? Make it clear.
- A detailed design specification for software component usually includes the algorithms used, defined interactions and interface specifications with input and output variables as well as description of the program structure. Often, we see flow and state diagrams, message sequence charts, UML diagrams and natural language descriptions used to help describe portions of the detailed design.
- Source code comments are an essential part of the unit.
- Development must be carried out considering the coding guidelines and standards. Compliance is confirmed by static code analysis and code reviews.
- Historically, detailed design is often over-simplified or skipped entirely. Teams have tried to document the design through the use of markup languages in the source code. This may have the problem of not properly considering and reviewing the design ahead of implementation.
- The traceability between detailed design and software units is often established through naming conventions.
- Redundancy in the traceability is not required. However, if the links run from requirements to architecture to detailed design to the single unit, care must be taken that no information gets lost in between.
Deepen your knowledge of Automotive SPICE®
Participate in one of our Automotive SPICE® trainings.
About the author
Bhaskar Vanamali has been working on process improvement for nearly 20 years and served as secretary of Working Group 13 of the VDA QMC.
He is Principal Assessor and Trainer for Automotive SPICE® and has performed more than 140 assessments and trained more than 250 assessors.
To access the rest of this engaging content, please fill out the form below:
Please wait…