In practice, how to harmonize/synchronize the detailed design and code implementation? From what I observed, programmers would prefer writing comments in the code, instead of writing a separate document. Is commented source code acceptable from ASPICE point of view as the detailed design document?
@陳韋任 Thank you for your question! No, this is not acceptable. The expectation is to write your thoughts regarding the design of the code. If you make comments, you define the design which you implement. All assessors typically downrate such an approach, and the OEMs do not accept that. Remember, that the unit test and the code review should be performed against the detailed design and not against the code. So, depending on the potential ASIL-criticality, you should be able to derive an appropriate code coverage. For MCDC- or C1-coverage, typically diagrams are very helpful to ensure that you can identify branches and conditions. We hope this helps you further!
@Lev Tunik Yes, SWE.3.BP8 deals with the actual code (.c-files, .h-files, C++ classes, any other code like Pearl, Java, Python, Assembler…) based on the detailed design. It is expected that this code fulfils any non-functional requirements. Typically, compliance with MISRA-rules is expected and in cybersecurity-sensitive code other standards like e.g. CertC. We hope this answers your question! :)
The only thing I miss in this video is the traceability. Especially if we use statis functions or variables that are not visible in architecture, but they exists in detailed design and those functions are used by many SW elements from architecture. Could you please put some light on it? E.g. we have some function which convert from one unit to the other and it is called by several function describer in architecture or we have some statis variable to memorize variable between function calls. How to ensure the traceability to architecture in such cases?
Hi there, thanks for your feedback! We do not cover the complete process but in each the three major points. All engineering processes on system- and SW-level require traceabilities. So, even these kind of “global” functions should be traceable to SW architecture and SW detailed design. As these functions are required in several high level components, you may use a combination of references and traces. How you do that depends on your tooling and the set-up of your processes. We hope this helps you further!
In practice, how to harmonize/synchronize the detailed design and code implementation? From what I observed, programmers would prefer writing comments in the code, instead of writing a separate document. Is commented source code acceptable from ASPICE point of view as the detailed design document?
@陳韋任 Thank you for your question! No, this is not acceptable. The expectation is to write your thoughts regarding the design of the code. If you make comments, you define the design which you implement. All assessors typically downrate such an approach, and the OEMs do not accept that.
Remember, that the unit test and the code review should be performed against the detailed design and not against the code. So, depending on the potential ASIL-criticality, you should be able to derive an appropriate code coverage. For MCDC- or C1-coverage, typically diagrams are very helpful to ensure that you can identify branches and conditions. We hope this helps you further!
About the unit construction (BP 8, OUTCOME 6, FORMAT 11-05)- is this actually the code files? e.g. .cpp+.h files if the project is in c++?
@Lev Tunik Yes, SWE.3.BP8 deals with the actual code (.c-files, .h-files, C++ classes, any other code like Pearl, Java, Python, Assembler…) based on the detailed design. It is expected that this code fulfils any non-functional requirements. Typically, compliance with MISRA-rules is expected and in cybersecurity-sensitive code other standards like e.g. CertC. We hope this answers your question! :)
The only thing I miss in this video is the traceability. Especially if we use statis functions or variables that are not visible in architecture, but they exists in detailed design and those functions are used by many SW elements from architecture. Could you please put some light on it? E.g. we have some function which convert from one unit to the other and it is called by several function describer in architecture or we have some statis variable to memorize variable between function calls. How to ensure the traceability to architecture in such cases?
Hi there, thanks for your feedback! We do not cover the complete process but in each the three major points. All engineering processes on system- and SW-level require traceabilities. So, even these kind of “global” functions should be traceable to SW architecture and SW detailed design. As these functions are required in several high level components, you may use a combination of references and traces. How you do that depends on your tooling and the set-up of your processes. We hope this helps you further!
Your sharing very very professional, clear and easy to understanding. Hope you will create more video for SWE4, SWE5 and some Audit Tips.
Hi there, we're very glad to hear that. We will definitely publish further videos - stay tuned! :)
To raise the stage curtain a little: next release will be SWE 4, SW Unit Verification. ;)
Well explained...👍👍
We're happy that you like it! :)
Good. Thank you
@Subramonian Mohan you're very welcome! :)