Information Technology Reference
In-Depth Information
debugging. It is difficult to determine how long it will take to find and fix an error, not to
mention whether the fix actually will be effective. To remove bugs from the software,
the team first must discover that a problem exists, then classify the error, locate
where the problem actually lies in the code, and finally, create a solution that will
remedy the situation (without introducing other problems!). Software professionals
constantly are searching for ways to improve and streamline the debugging process.
At the same time, they have been attempting to automate techniques used in error
detection.
Where bugs are found by users after shipment, not only the software per se but also
the company's reputation will be damaged. However, thanks to the widely spreading
Internet technology, even if software contain bugs, it is now easy to distribute bug-
fix software to users. Possibly because of this trend, the issue of whether there
are bugs seems to become of less interest. However, it is still difficult to correct
bugs after shipping in computerized applications (e.g., automation). This case study
establishes a method of removing bugs within a limited period before shipping, using
an orthogonal array.
This case study is based on the work of Dr. G. Taguchi in (Taguchi, 1999a)
and (Taguchi, 1999b). The method was conducted by Takada et al. (2000). They
allocated items selected by users (signal factors) to L 36 or L 18 orthogonal arrays,
ran software in accordance to the combination in each row, and judged using binary
output (0 or 1) whether an output was normal. Subsequently, and using the output
obtained, the authors calculated the variance of interaction to identify bugging root
cause factors in the experiment. Through this process, the authors found almost
all bugs caused by combinations of factors on the beta version (contains numerous
recognized bugs) of their company software. Therefore, the effectiveness of this
experiment easily can be confirmed. However, because bugs detected cannot be
corrected, they cannot check whether the trend in regard to the number of bugs is
decreasing. As signal factors, they selected eight items that frequently can be set up
by users, allocating them to an L 18 orthogonal array. When a signal factor has four or
more levels, for example, continuous values ranging from 0 to 100, they selected 0, 50,
and 100.
When dealing with a factor that can be selected, such as patterns 1 to 5, three of
the levels that are used most commonly by users were selected. Once they assigned
these factors to an orthogonal array, they noticed that there were quite a few two-level
factors. In this case, they allocated a dummy level to level 3. For the output, they
used a rule of normal
1, based on whether the result was what
they wanted. In some cases, “no output” was the right output. Therefore, normal or
abnormal was determined by referring to the specifications. Signal factors and levels
are shown in Table 18.4.
From the results of Table 18.5, they created approximate two-way tables for all
combinations. The upper left part of Table 18.6 shows the number of each com-
bination of A and B: A 1 B 1 ,A 1 B 2 ,A 1 B 3 ,A 2 B 1 ,A 2 B 2 , and A 2 B 3 . Similarly, they
created a table for all combinations.
Where many bugs occur on one side of this table was regarded as a location
with bugs. Looking at the overall result, they can see that bugs occur at H 3 .After
=
0 and abnormal
=
Search WWH ::




Custom Search