ROBUST DESIGN FOR SOFTWARE DEVELOPMENT - Software Design for Six-Sigma: A Roadmap for Excellence - page 472

effectiveness), nominal-the-best (keeping the software on a single performance ob-
jective is the main concern, (e.g., produce correct results for a test case), and dynamic
(energy-related functional performance across a prescribed dynamic range of usage
is the perspective, (e.g., produce correct results for a range of inputs).
When robustness cannot be assured by parameter design, we resort to the tolerance
design phase. Tolerance design is the last phase of robust design. The practice is to
upgrade or tighten tolerances of some design parameters so that quality loss can be
reduced. However, lightening tolerance practice usually will add cost to the process of
controlling tolerance. El-Haik (2005) formulated the problem of finding the optimum
tolerance of the design parameters that minimizes both quality loss and tolerance
control costs (Chapter 16).
The important contribution of robust design is the systematic inclusion of the
experimental design of noise variables, that is, the variables over which the designer
has little or no control. Robust design's objective is to suppress, as much as possible,
the effect of noise by exploring the levels of the factors to determine their potential
for making the software insensitive to these sources of variation.

18.4 ROBUST DESIGN CONCEPT #2: QUALITY LOSS FUNCTION

Traditional inspection schemes represent the heart of online quality control. Inspec-
tion schemes depend on the binary characterization of design parameters (i.e., being
within or outside the specification limits). A process is conforming if all its inspected
design parameters are within their respective specification limits; otherwise, it is
nonconforming. This binary representation of the acceptance criteria per design pa-
rameter, for example, is not realistic because it characterizes, equally, entities that are
marginally off these specification limits and entities that are marginally within these
limits. In addition, this characterization also does not discriminate the marginally off
entities with those that are significantly off. The point here is that it is not realistic
to assume that, as we move away from the nominal specification in software, the
quality loss is zero as long as you stay within the set tolerance limits. Rather, if
the software functional requirement is not exactly “on target,” then loss will result,
for example, in terms of customer satisfaction. Moreover, this loss is probably not
a linear function of the deviation from nominal specifications but rather a quadratic
function similar to what you see in Figure 18.4. Taguchi and Wu (1980) proposed
a continuous and better representation than this dichotomous characterization—the
quality loss function. The loss function provides a better estimate of the monetary
loss incurred by production and customers as an output response, y , deviating from
its targeted performance value, T y . The determination of the target T y implies the
nominal-the-best and dynamic classifications.
A quality loss function can be interpreted as a means to translate variation and
target adjustment to a monetary value. It allows the design teams to perform a
detailed optimization of cost by relating technical terminology to economical mea-
sures. In its quadratic form (Figure 18.6), quality loss is determined by first finding