曝光台 注意防骗
网曝天猫店富美金盛家居专营店坑蒙拐骗欺诈消费者
A second point is that our result does not mean that N-version programming does not work or should
never be used. It means that the reliability of an N-version system may not be as high as theory predicts
under the assumption of independence. If the implementation issues can be resolved for a particular Nversion
system, the required reliability might be achieved by using a larger value for N using the coincident
errors model [7] to predict reliability.
Based on a preliminary analysis of the faults in the programs, we have found that approximately one
half of the total software faults found involved two or more programs. This is surprisingly high and implies
that either programmers make a large number of similar faults or, alternatively, that the common faults are
more likely to remain after debugging and testing. Several alternative hypotheses are possible and need to
be further explored. One is that certain parts of any problem are just more difficult than others and will lead
to the same faults by different programmers. Thus the fault distribution is more an artifact of the problem
itself than the programmer, and thus is not random. Another possible hypothesis is that unique (random)
faults tend to be those most likely to be caught by a compiler or by testing. Common faults may reflect
inherently difficult semantic aspects of the problem or typical human misconceptions which are not easily
detected through standard verification and validation efforts.
A final possibility is that common faults may reflect flaws in the requirements specification
document. We do not think this is the case in this experiment since great care went into its preparation and
the requirements specification had been debugged through use in an earlier experiment. Furthermore, the
- 20 -
particular common faults made in this experiment are quite subtle. In our opinion, none involve ambiguity,
inconsistency, or deficiency in the specification.
Given that common faults (as shown by this and other experiments) are possible and perhaps even
likely in separately developed multiple versions of a software system, then relying on random chance to get
diversity in programs and eliminate design faults may not be effective. However, this does not mean that
diversity is not a possible solution to the software fault tolerance problem. What it does imply is that
further research on common faults may be useful. Hardware designers do not rely on simple redundancy or
independently generated diverse designs to get rid of common design faults. Instead, they use sophisticated
techniques to determine common failure modes and systematically alter their designs to attempt to
eliminate common failure modes or to minimize their probability. Perhaps we need equivalent techniques
for software. Unfortunately, this will not be simple but perhaps a simple solution just does not exist for
what is undoubtedly a very difficult problem.
9. ACKNOWLEDGEMENTS
It is a pleasure to acknowledge the students who wrote the versions that were tested in this
experiment; P. Ammann, C. Finch, N. Fitzgerald, M. Heiss, D. Irwin, L. Lauterbach, S. Samanta, J. Watts,
P. Wilson from UVA, and R. Bowles, D. Duong, P. Higgins, A. Milne, S. Musgrave, T. Nguyen, J. Peck, P.
Ritter, R. Sargent, R. Schmaltz, A. Schoonhoven, T. Shimeall, G. Stoermer, J. Stolzy, D. Taback, J.
Thomas, C. Thompson, L. Wong from UCI. We are also pleased to acknowledge the Academic Computer
Center at the University of Virginia, the AIRLAB facility and the Central Computer Complex at NASA
Langley Research Center for providing computer time to allow the programs to be tested. Much of the
design of the experiment is due to Lois St.Jean, and Susan Brilliant and Paul Ammann were responsible for
much of the testing activities. We are indebted to Janet Dunham and Earl Migneault for allowing us to
learn from the experience gained in an earlier version of this experiment, and to Jo Mahoney for comments
on our statistical analysis. This work was supported in part by NASA grant number NAG1-242, and in part
- 21 -
by a MICRO grant cofunded by the University of California and Hughes Aircraft Company. Finally, none
of this work would have been possible and this paper could not have been written without the excellent
facilities provided by the ARPA and CSNET computer networks.
- 22 -
APPENDIX
This is the requirements specification document used in this experiment. It is the version used at
UVA. Only minor changes to names and document references were made for the version used at UCI.
LAUNCH INTECEPTOR PROGRAM - REQUIREMENTS SPECIFICATION
INTRODUCTION
As part of a hypothetical anti-ballistic missile system, you will write a parameterless Pascal
procedure called DECIDE. It will generate a signal which determines whether an interceptor should be
中国航空网 www.aero.cn
航空翻译 www.aviation.cn
本文链接地址：
航空资料35(193)
