SWE.3 SW Detailed Design and Unit Construction
Involved in the challenges of Automotive SPICE, particularly the detailed design of your software and the unit construction? Read on for a quick overview of key information on SWE.3, a key process from VDA Scope, including a video and our free white paper.
back to Automotive SPICEAutomotive SPICE® is a trademark of VDA QMC.
The Software Detailed Design and Unit Construction process in Automotive SPICE® (also known as SWE.3) helps your organization to provide an evaluated detailed design for the software components and to specify and to produce the software units.
What is the goal of the Software detailed design? A lot of organizations and projects have problems understanding how to document the detailed design. So, what are the three aspects you should manage in this process?
The following are the most important aspects of Change Request Management in Automotive SPICE®.
Image
The SWE.3 process under VDA Scope
Interested in finding out more about SW Detailed Design and Unit Construction (SWE.3), the Automotive SPICE® process from VDA Scope? Our free white paper provides you with a summary of all key information, including an extract from our book on Automotive SPICE® Essentials – ideal reading for anyone new to the topic of process improvements.
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.
In safety-critical software ISO 26262 provides guidance. In non-safety software typically at least C0- or statement coverage, by some customers C1- or branch coverage is required. The higher the coverage goal the more detail is required by the detailed design. If you have an ASIL-B classified module a C1-coverage is expected. That means that your detailed design should identify the different branches of your software.
Need support with a key project? We’re your first port of call when it comes to management consulting and improvement programmes in electronics development.
Steffen Herrmann and the sales team
A pitfall I often encounter in assessments is the lack of detailed description of the external and internal interfaces.
Expected content of interface documentation are
- 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 architectural level and tested in the software integration test (SWE.5).
Over 100 corporate customers on four continents bank on our experience.
Automotive SPICE®? We’re the experts!
We currently have 48 intacs™-certified assessors. These include ten instructors on Provisional and Competent Level.
Automotive SPICE®? We’re the experts!
As a peer reviewer, we have been continually involved in the process of designing standards since 2005. We also co-authored plug-ins for mechanical engineering and hardware engineering with intacs™.
Automotive SPICE®? We’re the experts!
We have written multiple editions of »Automotive SPICE® in Practice«, already an industry classic.
Automotive SPICE®? We’re the experts!
Benefit from over 200 people-years of cumulative project experience, often involving improvement programmes lasting several years.
Automotive SPICE®? We’re the experts!
We have now trained more than 1000 assessors according to intacs™ guidelines.
Automotive SPICE®? We’re the experts!
We have conducted over 200 assessments since 2007, on both a project and an organisational level. That is equivalent to 10,000 assessment-hours.
Automotive SPICE®? We’re the experts!
Describe the detailed design b e f o r e your implement the code. Often, the detailed design is described after the fact, meaning after the code has been written.
Why is that a problem? The unit test should check whether the code fulfils the detailed design. If you write the detailed design after documenting your code, the point of the unit test is lost.
Now, you could argue that you may not need the unit test. The point is that you should derive your detailed design form your architecture and not from the code. If the chain is broken, then suddenly the content of documentation and all the tests do not make sense anymore. So, the detailed design must be written before you start writing your code.
There is nothing wrong to iteratively develop detailed design and code step by step.
As part of our strategy to systematically improve development processes in the automotive electronics sector, we are also an official licensee of Automotive SPICE® – a trademark of the Association of the German Automotive Industry (VDA QMC).
- Using Automotive SPICE® to achieve the required maturity levels within your key processes in development
- Systematically improving existing workflows and methods
- Evaluating the status of your process improvements through formal assessments and gap analysis
- Fulfilling the requirements of Automotive SPICE® in harmony with SECURITY,FUNCTIONAL SAFETY and AGILE METHODS
- Training your staff and assessors
