Making Sense Out of SOUP (Software of Unknown Pedigree)

Software test tools have been traditionally designed with the expectation that the code has been (or is being) designed and developed following a best practice development process. Legacy code turns the ideal process on its head. Although such code is a valuable asset, it is likely to have been developed on an experimental, ad hoc basis by a series of “gurus” — experts who prided themselves on getting things done and in knowing the application itself, but not necessarily expert at complying with modern development thinking and bored with providing complete documentation. That doesn’t sit well with the requirements of standards such as DO-178B.

Frequently, this legacy software — software of unknown pedigree (SOUP) — forms the basis of new developments to meet modern coding standards and may deploy updated target hardware and development tool chains. The need to leverage the value of SOUP presents its own set of unique challenges.

The Dangers of SOUP

Many SOUP projects will have initially been subjected only to functional system testing, leaving many code paths unexercised and leading to costly in-service corrections. Even in the field, it is highly likely that the circumstances required to exercise much of the code have never occurred, and such applications have therefore sustained little more than an extension of functional system testing by their in-field use.

When there is a requirement for ongoing development of legacy code, previously unexercised code paths are likely to be called into use by combinations of data never previously encountered (Figure 1). Given that commercial pressures often rule out a rewrite, what options are available?

Static and Dynamic Analysis

Some static analysis tools use mathematical techniques to try to verify all possible execution paths through a program. It is true that some problems in simpler code sections can be readily isolated and corrected in this way, giving some level of warm, fuzzy feelings that the software is reasonably robust. However, where source code is complex, such tools rely ever more heavily on data approximations and hence, raise many warnings. These warnings require the user to confirm or deny the existence of each problem in the most complex parts of the application and represent considerable overhead.

Even if overhead weren’t an issue, these tools provide no evidence that the code is functionally correct! A better alternative involves the use of static and dynamic formal test tools, traditionally modified. Even where all source code remains identical, a new compiler or target hardware can introduce unintentional functionality changes with potentially disastrous results. The challenge is to identify the building blocks within the test tools which can be used in an appropriate sequence to aid the efficient enhancement of SOUP.