WESTFORD, Mass., 21 Oct. 2010. The accommodation of modern software tools and technologies receives the most attention in press accounts of the upgrade to DO-178C, yet revisions to the body of the standard also are important. Although these revisions should not make the standard more or less difficult to follow, it should make the playing field "more level," stopping the exploitation of certain ambiguities, says George Romanski, chief executive officer of Verocel, a software verification company in Westford, Mass.
One such area involves modified condition and decision coverage (MC/DC) testing. DO-178B clearly requires MC/DC testing for Level A software with a requirement for several conditions, Romanski explains. The idea is to test every condition independently that has an effect on the outcome. The issue is whether requirements with several different conditions must undergo MC/DC testing at lower levels of criticality. The revised document will spell out where MC/DC testing is necessary in cases involving multiple conditions, regardless of the software level, he says.
Vance Hilderman, co-founder and advisor at HighRely in Phoenix, takes a different view. "MC/DC is definitely only required for Level A," he says. Nevertheless, for cases where low-level software requirements call out specific conditions and corresponding outputs, complete testing of such requirements "essentially emulates full MC/DC testing." He foresees "at least a subset of MC/DC testing at lower criticality levels."
Another issue involves traceability between software artifacts, Romanski says. The revised standard traceability not only from requirement to design to code to test, but in the reverse direction, from test to code to design to requirements. This revision seeks to eliminate practices such as embedding traceability information in the operational or test code, which makes the links hard to follow and traceability more difficult to verify.
