Extension

Software is usually released in major numbered versions, such as 1.0, 2.0, 3.0. However, circumstances may require a minor extension, updating, or upgrading to meet the terms of a new union contract, a new tax law or other legal record-keeping requirement, a new Financial Accounting Standards Board (FASB) recommendation, an acquisition, a challenge to the vendor's competitive advantage, or for many other reasons. Such extensions or upgrades are usually called something like version 3.1 or even 3.4.2 in some rapidly changing business application areas. Upgrades and extensions of software functionality are a promising application area for Taguchi Methods, which are ideal for product improvement or redesign. Taguchi Methods excel when design data is already available. So naturally an enhancement allows the designer to evaluate the value of modifications with the quality loss function and thus see what the real value of an enhancement will be in the next release and later releases. New features can also be evaluated for their functional enhancement to the product by parameter analysis, which works best in a test-bed environment. What better test bed for any upgrade than the current product?

Case Study 19.1: Extending the Capability of an Electronic Warfare System^[1]

Electronic countermeasure (ECM) systems are multiplexed computer-controlled microwave (radar) transceivers that intercept an enemy's radar signal. They send back in real time a masking signal only slightly stronger than the expected reflection that tells the enemy radar operator the wrong signature, the wrong distance, and even the wrong number of potential targets. You cannot hide a carrier fleet group, but if you make all 28 destroyers appear to have the same signature as the carrier, the enemy cannot aim a missile accurately at the real carrier.

The software for such systems must be continually upgraded to be able to detect and counter new enemy radars, new radar frequencies, and new targeting and scanning techniques. This is a natural application for Taguchi Methods, because the software extensions are additions to a tested library of proven countermeasure software algorithms. Also, tactical ECM systems must work properly in the presence of uncontrollable noise factors. Robustness is critical in such systems, and trustworthy software is essential, because the alternative is assured destruction! For the system under analysis in this case study, software upgrades are made on a weekly basis, but checking them against all the recognized emitter types takes 16 hours. The goal of the Taguchi analysis was to enhance robustness while reducing weekly testing time. The noise factors in the study were variation in emitter characteristics over the range of recognized emitter types; variation in emitter position, including amplitude (nearness) and azimuth (direction of received signal arrival); variation in emitter mode; and actual background (electrical atmospheric) noise.

An L₁₈ orthogonal array was selected to model one two-level factor and up to seven three-level factors. The factors in the array are as follows:

Factor	Level 1	Level 2	Level 3
Overall mean
Frequency diversity	Single	Multiple
Frequency	Low	Medium	High
Emission type	Continuous wave (CW)	Stable	Agile
Scan type	Steady	Circular	Raster
Peak power	Nominal	Medium	Low
Arrival angle	Bore sight	Offset 1	Offset 2
Illumination	Short	Medium	100%
Background	None	Low density	High density

Next, 18 emitters or Taguchi experiments were selected to cover the parameters represented in the factors. The major characteristics were single radio frequency (RF), high RF, stable emission mode, circular scan, and short illumination time. For example, the first 2 of the 18 experiments went as follows:

Number	Mean	Diversity	Frequency	Emission	Scan	Power	Illumination
1	0	Single	High	CW	Steady	Nominal	100%
2	1	Single	High	Stable	Circular	Medium	Short

The developer's choice of experimental parameters was informed by extensive experience with the system and a history of weekly upgrades to the software. We will not try to explain the case study at this level of technical detail, because we are merely focusing on the methodology. You're encouraged to read the referenced article.^[1] The signal-to-noise (SN) ratio for this experiment was calculated as follows:

SN = 20 log {(total defects) / (n + 1)}

Because the problem type is "maximum is best," the SN for a perfect system is 0 dB. Any performance error will result in a negative SN ratio. The "defects plus 1" expression was used because log (0) is undefined and log (1) = 0. To compute the SN ratio for all 18 experiments in the array, the value of n would be 18. However, to compute the SN for RF diversity alone, n would be 9, because "multiple" appears in nine of the experiments and "single" in the other nine. The author calculates the SN ratio for multiple diversity as 10.6 dB and for single source as 7.8 dB, based on the errors detected in a particular testing session.

This case study confirmed that each week's upgraded software can be tested in only four hours for the 18 emitter types modeled. This was considered significant, because sensitivity to test results did not show any additional system weakness when the more-extensive monthly test was carried out later. The use of a Taguchi analysis to reduce testing time for the weekly software upgrades by a factor of 4 is quite remarkable. However, the most amazing result of this application of the method was that the careful choice of 18 emitter types by the designer, together with the operational noise factors, surpassed the performance results of testing for each radar type individually!