Google Answers Logo
View Question
 
Q: software engineering ( Answered 5 out of 5 stars,   0 Comments )
Question  
Subject: software engineering
Category: Computers > Software
Asked by: jplhix-ga
List Price: $5.00
Posted: 17 Jan 2003 07:02 PST
Expires: 16 Feb 2003 07:02 PST
Question ID: 144681
You have been testing a module for 9 days and have found two faults. 
What does this tell you about the existence of other faults?
Answer  
Subject: Re: software engineering
Answered By: tutuzdad-ga on 17 Jan 2003 08:03 PST
Rated:5 out of 5 stars
 
Dear jplhix-ga;

Thank you for allowing me an opportunity to answer your interesting
question.

I assume you are looking for a means of averaging the number of
potential faults in a module in order to shorten the test period.
Speaking from a mathematical viewpoint, this discovery tells you
nothing about the possibility of other existing faults.

In order to mathematically predict fault incidence (without actually
discovering them) you would have to have the entire equation. There
would have to be a predetermined testing period and an established
(finite) number of possibilities to consider. Once this is determined,
each potential fault would have to be assigned a known likelihood of
being faulty. For example, potential #1 is 47% likely to be faulty,
potential #2 is 38% likely to be faulty, etc. These percentages would
then have to be averaged in order to come up with a number that is
representative of the collective. Until you can determine these parts
of the equation, it is impossible to mathematically ascertain the
likelihood of additional faults unless a precedent has already been
established from which you can make a reasonable comparison and derive
a “possible” conclusion. Even then this would only give you an
estimate of potential faults and would provide no measure of
accountability for the actual faults themselves.

On the other hand, finding just two faults in any period of time
indicates that your module is faulty. This is like being “a little
pregnant” or “somewhat dead”. You either ARE or you ARE NOT. It can be
assumed, I suppose, that after a “lengthy” period of use following
these corrective measure, if no additional faults are found that the
module can reasonable considered fault-free. Your corrective measures
themselves could, theoretically, prompt other previously undiscovered
faults, especially if it concerns an area of fault tolerance (as you
already know, some “faults” do not necessarily lead to “failure”, but
by the same token fault tolerance does not necessarily “protect” you
against failure). So even after correcting the first faults and
finding no others in a “reasonable” amount of time thereafter does not
necessarily guarantee that no other faults exist. This of course would
also dramatically change your average potential equation mentioned
above should you choose to return to that method.

Your goal is to determine if the module is faulty. If it is, you must
identify the faults and take appropriate corrective measures. This of
course must be done regardless of whether there was a true means of
determining whether other faults exist or not without actually finding
them first. Unfortunately, there is no quick fix or magical arithmetic
that will provide you with the conclusion you are hoping to find. If
there were, people would be churning out successful modules by the
thousands and moving on to the next project without ever looking back.

One question to ask is “What will be gained by knowing if faults exist
if I cannot determine where and what they are?”. Keep in mind that
some faults cause to perceivable problem, or may lead to other faults
that also cause no perceivable problem. Including these in your
results using the “magical math” method that you are hoping to find
would serve no real purpose unless your ultimate goal is absolute
perfection rather than functionality. The best method for replacing a
failed component is by “hot swapping” (allowing components to be
replaced while the system is still up and running). This way you can
fix a problem and test for additional faults at the same time. It may
also allow you to find an existing fault whose presence is irrelevant
and doesn’t warrant any real manipulation.

Below you will find that I have carefully defined my search strategy
for you in the event that you need to search for more information. By
following the same type of searches that I did you may be able to
enhance the research I have provided even further. I hope you find
that that my research exceeds your expectations. If you have any
questions about my research please post a clarification request prior
to rating the answer. Otherwise, I welcome your rating and your final
comments and I look forward to working with you again in the near
future. Thank you for bringing your question to us.

Best regards;
Tutuzdad-ga


INFORMATION SOURCES

IT MODULE
http://it.tech.kent.edu/modules/iedge/Module_LAN-FaultTolerance.asp



SEARCH STRATEGY


SEARCH ENGINE USED:

Google ://www.google.com


SEARCH TERMS USED:

Determining module faults

Predicting fault incidence
jplhix-ga rated this answer:5 out of 5 stars

Comments  
There are no comments at this time.

Important Disclaimer: Answers and comments provided on Google Answers are general information, and are not intended to substitute for informed professional medical, psychiatric, psychological, tax, legal, investment, accounting, or other professional advice. Google does not endorse, and expressly disclaims liability for any product, manufacturer, distributor, service or service provider mentioned or any opinion expressed in answers or comments. Please read carefully the Google Answers Terms of Service.

If you feel that you have found inappropriate content, please let us know by emailing us at answers-support@google.com with the question ID listed above. Thank you.
Search Google Answers for
Google Answers  


Google Home - Answers FAQ - Terms of Service - Privacy Policy