Aerospace Software

Effective Thread Audits

DO-178B does not explicitly mention this but I am not aware of any better auditing technique. I am, of course, talking of Thread Audits.

Just to explain the concept of thread audits to those who are probably unaware of the term: you need to take a few critical requirements at the system level and follow the trail down the Software Development Life Cycle processes to determine if the requirements are correctly and completely designed, coded and verified.

This seems to be a no-brainer. But consider the associated problems:

1) Thread Audits are generally carried out towards the end of the project, and any error discovered at the fag end of a project means escalating costs and slipped milestones.

On the other hand,

2) Following a thread from the beginning of the project might mean that the development team focuses too much on the threads being audited with a consequent low(ish) quality on rest of the product. The purpose of audit is lost when randomness is sacrificed.

So the best auditing strategy is a mix of randomly picked requirements and thread audits and here's is how to do it.

Let's assume you pick some 10 system requirements for audit. The list needs to contain critical requirements too.

SO,

a) Follow the thread of critical requirements as the project moves from one phase to another to the very end.

b) Do not reveal rest of the requirements that are in the list to the development team. Carry out a sort of truncated thread audits for these requirements at different phases.

Your thread audit chart should look something like this ...

Requirements                Requirements Phase      Design Phase         Verification Phase

Critical Req#1                            X                             X                               X

Critical Req#2                            X                             X                               X

Non-Critical Req#1 & 2               X                                    

Non-Critical Req#3 & 4               X                             X

Non-Critical Req#5 & 6               X                              X                              X

Here, the non-critical requirements #5 and #6 are done when all the phases are complete - equivalent to an acceptance audit. Critical Requirements are audited as part of phase transition checks - continuously. And the other requirements are audited randomly (or even abandoned after the first phase).

Root Cause Analysis is Flawed

I know this is going to ruffle some feathers. Rather get criticised than bottle up thoughts. So here goes ...

The first step to conducting a Root Cause Analysis (RCA) is defining the problem. And from there one goes backwards analysing all possible causes by asking series of why's and eventually homing on to the root cause, taking corrective action against which will result in elimination of the problem initially defined. Frequently, Fish Bone Diagrams are used to depict the causal relationship between the cause and the effect.

So where is the flaw?

Here is the list:

1) It assumes that addressing one or a few causes will result in mitigation of the problem. Thus, RCA ignores the interdependency of the contributing factors. It assumes that real life is linear. In real life there are no

2) The emphasis of causality results in too much focus on already established template. Thus one gets local solution instead of a global one.

3) It assumes a problem is typical. So, by definition fixing this problem is a guarantee of solving all such problems in the future. In real life all problems are contextual.

4) It ignores that human are complex beings. It also ignores that an average human would present a fact in the way that best suits it.

5) The biggest flaw. Too much focus on the problem. Elimination of a problem does not always result in the desired behaviour of a system. The focus, instead, should be on what we wish to achieve rather than on what we do not wish to. This shift of focus alone can eliminate many of the above mentioned issues.

RCA has its use. But we need to keep in mind its limitation. It is one of the many tools that needs to be used to improve quality. As a tool for continuous improvement, it might be useful. But is continuous improvement such a good thing? I would prefer a hop-step-and-jump.