What Is Robust Software?

A general but descriptive definition of robustness in product and process design is given in Taguchi's Quality Engineering Handbook: "Robust design (including product and process design) generally means designing a product or process that can function properly under various conditions of use or operation."^[4] This definition can be extended to make it more prescriptive, which is the purpose of this book, at least for business enterprise applications software. Our contention is that robust software is trustworthy software, because it performs as specified, expected, and desired in spite of adverse circumstances, termed noise by Taguchi. The essence of the Taguchi method lies in measurements made in the product's functional space to calculate a signal's nearness to an ideal output function. Thus, its use in quality engineering or robust design involves a procedure for improving functionality to meet user needs (voice of the customer) and improved accuracy in prediction of outcomes by using measurement methods in both the functional space and multidimensional space. Each design feature or improvement is an individual engineering task. As long as the multidimensional data has sufficient accuracy, the signal-to-noise ratio may be calculated as the Mahalanobis distance from objects or phenomena that do not belong in the homogenous design space.^[5] This distance measure was introduced by P. C. Mahalanobis in 1936 as a measure of similarity in a sample set based on the correlations between the samples. Robust software design classifies a signal into two types: the quality of an active signal for software that the user interacts with, and the quality of the Mahalanobis-Taguchi System (MTS) for a passive signal resulting from largely exogenous performance limiting factors that arise in complex systems, whether they be organic or automaton.^[6] The Taguchi method assumes that all conditions of software use belong to either a signal (proper function) or noise (faulty operation, error, or bug), independent of whether the user depends on the software application actively or passively. At the design stage of the development process, the intended software functionality is considered the user's active signal factor. However, in the downstream stages of development, the inspection, testing, diagnostic, and prediction data is regarded as representing passive signal factors. Thus, robustness in software can be quantified at the earliest design stages in such a way that it can be analyzed, predicted, and even enhanced before the application detailed design is complete and coding has begun. The stages in the DFTS process (see Figure 2.6 in Chapter 2) allow continuous prediction and improvement during consequent development.