The best way to interpret paragraph 6.4.4.2.b of the DO-178B is by using an "AND" logic.
Just to be clear what I am talking about, I quote the document: "The structural coverage analysis may be performed on the Source Code, unless the software level is A and the compiler generates object code that is not directly traceable to Source Code statements."
My interpretation:
The following 3 conditions apply:
(A) Structural Coverage analysis has to be performed on Object Code,
(B) The software level is A, and
(C) Object Code cannot be directly traceable to the Source Code
A == B AND C
Meaning,
We have to provide 100% Structural Coverage on the Object Code
If
The Software Level is A
AND
The Object Code does not have a direct correspondence to the Source Code
Thus,
If the Software Level is B, C, D or E, we can do Unit Level using any Qualified Testing Tool available in the market, since the condition (B) is False. Please note that (i) most OTS tools instrument the source code, and (ii) you have to qualify the tool for the environment you are testing in.
If the Software Level is A, but we can prove that Object Code has a one to one correspondence with the Source Code, then condition (C) is False. This happens when you have an interpreter which trranslates each line of your source code to a set of object code. (Proprietary languages have this feasture). In this case again, go ahead and use OTS tools without any problem.
However, since compiler use is more wide-spread, condition (C) is never False. It is therefore easier to just go ahead and carry out an Object Code Verification whenever the software level is A.
A word of caution: it is fine to take credit from a previous project, as long as the the environment is identical AND the constructs of the language being used is identical.
Object Code Verification is applicable even when someone claims that s/he has set the compiler option to no-optimisation. After all the idea of verification is to doubt every claim.
Recent Comments