Timeline for Estimating the probability that a software change fixed a problem
Current License: CC BY-SA 2.5
22 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 3, 2017 at 13:50 | history | edited | mdewey |
Removed tag failure as deprecated
|
|
| Nov 5, 2010 at 9:11 | history | edited | csgillespie |
edited tags
|
|
| Nov 4, 2010 at 21:22 | vote | accept | SiegeX | ||
| Nov 4, 2010 at 21:17 | history | edited | SiegeX | CC BY-SA 2.5 |
deleted 8 characters in body
|
| Nov 4, 2010 at 21:07 | history | edited | SiegeX | CC BY-SA 2.5 |
added Tex markup
|
| Nov 4, 2010 at 16:45 | comment | added | James | @SiegeX OK, that does make more sense, seems like your data could be drawn from an overdispersed poisson process | |
| Nov 4, 2010 at 2:22 | history | edited | whuber♦ |
edited tags
|
|
| Nov 4, 2010 at 1:55 | history | edited | SiegeX | CC BY-SA 2.5 |
changed the title to be more reflective of the problem at hand.; edited title; added 9 characters in body; deleted 8 characters in body
|
| Nov 4, 2010 at 1:47 | history | edited | SiegeX | CC BY-SA 2.5 |
added 1025 characters in body
|
| Nov 3, 2010 at 19:35 | comment | added | whuber♦ | @SiegeX Your last approach has the right flavor, but please don't use the formulae on the Wikipedia page: they are only for normally distributed data. It is rare for failure time data to be normal. They typically are positively skewed. This implies the normal theory upper prediction limits can be (way) too low. BTW, a lower prediction limit is irrelevant here--although the fact that it is hugely negative is a clear indicator of how bad the normal theory methods are for these data. To adjust the equation, see the reference I provided in my answer. | |
| Nov 3, 2010 at 18:57 | history | edited | SiegeX | CC BY-SA 2.5 |
added 853 characters in body
|
| Nov 3, 2010 at 18:48 | answer | added | mcdowella | timeline score: 1 | |
| Nov 3, 2010 at 18:16 | history | edited | SiegeX | CC BY-SA 2.5 |
added 123 characters in body
|
| Nov 3, 2010 at 18:01 | comment | added | SiegeX | @Srikant: Yes, your interpretation is spot on. To James' question, I think it would be fair to say that with this given device and software test bench, the device fails on average at the 55th iteration. Does that not sit will with you? | |
| Nov 3, 2010 at 17:53 | history | edited | SiegeX | CC BY-SA 2.5 |
added 1131 characters in body
|
| Nov 3, 2010 at 16:57 | comment | added | James | I take your point, but I'm still a little unsure of the value of the mean of these numbers. | |
| Nov 3, 2010 at 16:37 | answer | added | whuber♦ | timeline score: 7 | |
| Nov 3, 2010 at 16:26 | comment | added | user28 | @James I could be wrong but if the iterations are simply identifiers then most people will naturally report them in an increasing order like so: 22 24 36 44 ... The fact that the numbers are reported in an apparently random sequence suggests that each number represents the failed iteration number of 7 separate tests. | |
| Nov 3, 2010 at 16:11 | comment | added | James | The iteration numbers are surely just identifiers, and should not be used as numbers in computations. How many iterations did you do in total in your original trial? | |
| Nov 3, 2010 at 15:49 | answer | added | Owe Jessen | timeline score: 2 | |
| Nov 3, 2010 at 15:16 | answer | added | csgillespie | timeline score: 4 | |
| Nov 3, 2010 at 14:52 | history | asked | SiegeX | CC BY-SA 2.5 |