Not sure if there are books specific on that.
Not sure if there are books specific on that. I picked it up as part of Six Sigma training. The concept is you list all the possible failure modes in one column, then score the severity (1-10, 10 most severe), occurrence probability (1-10, 10 highest probability), and detection probability (1-10, 10=lowest probability) in other columns. Multiply those to rank the risks and then list out ways to improve or fix the risk, etc. A software angle would be listing ways your application would fail, or go down to lower level components inside the app. A tricky concept with the scoring is the detection piece. If you don't have a good way to detect the failure then it ends up being really high ranking. I typically used 1,5,10 for the scores since ending up in a debate about is it a 6 or 7 or 8 is a waste of time. Once you work on improvements for a failure mode, like additional logging for an NullPointerException, then adjust the scores. If you are doing TDD, this would be a good way to identify areas to build testing coverage.
Posted by mattbrewsbytes on Jul 10, 2015, 1:26 PM
Tags
Related issues
- Many devs love to shit on the guy from the 'I just want the exe.
- Now imagine how poor people stress if their smartphone bricks or gets damaged or lost.
- Resuming an extended-thinking session fails permanently with 400 "thinking blocks cannot be modified" (transcript stores thinking text as empty but keeps signat
- I'll preface this with a statement that as a European I want European alternatives to succeed, and MS-owned GitHub to shrivel and disappear.
- Yeah, but there’s a world of difference between “not perfect” and “we rounded a few sliders, and now the modal is a nightmare to use”.
- I used to write a lot of native Windows corporate software in the 90's and 2000's and my standard login window was a floating draggable o...
Raise real-world problems, find people facing the same issue, and discuss solutions.5,500 issues0 comments
reliability (SaaS)
Many devs love to shit on the guy from the 'I just want the exe.
Now imagine how poor people stress if their smartphone bricks or gets damaged or lost.
Resuming an extended-thinking session fails permanently with 400 "thinking blocks cannot be modified" (transcript stores thinking text as empty but keeps signat
I'll preface this with a statement that as a European I want European alternatives to succeed, and MS-owned GitHub to shrivel and disappear.
Yeah, but there’s a world of difference between “not perfect” and “we rounded a few sliders, and now the modal is a nightmare to use”.
I used to write a lot of native Windows corporate software in the 90's and 2000's and my standard login window was a floating draggable o...
App broken with Mosquitto broker 7.0.0
[BUG] Remote Control: automatic reconnection doesn't work -- connection drops silently with no recovery
Not sure if there are books specific on that.
Not sure if there are books specific on that. I picked it up as part of Six Sigma training. The concept is you list all the possible failure modes in one column, then score the severity (1-10, 10 most severe), occurrence probability (1-10, 10 highest probability), and detection probability (1-10, 10=lowest probability) in other columns. Multiply those to rank the risks and then list out ways to improve or fix the risk, etc. A software angle would be listing ways your application would fail, or go down to lower level components inside the app. A tricky concept with the scoring is the detection piece. If you don't have a good way to detect the failure then it ends up being really high ranking. I typically used 1,5,10 for the scores since ending up in a debate about is it a 6 or 7 or 8 is a waste of time. Once you work on improvements for a failure mode, like additional logging for an NullPointerException, then adjust the scores. If you are doing TDD, this would be a good way to identify areas to build testing coverage.
Comments (0)
No comments yet. Start the discussion.