Information Technology Reference
In-Depth Information
TABLE 16.5
Software Detection Rating
Rating
1-5
Rating
1-10
Detection Rating Criteria
Description
Very remote detection
Detectable only once “online”
5
9-10
Remote detection
Installation and start-up
4
7-8
Moderate detection
System integration and test
3
5-6
High detection
Code walkthroughs/unit testing
2
3-4
Very high detection
Requirements/design reviews
1
1-2
RPN numbers are used to prioritize the potential failures. The severity,
occurrence, and detection ratings are industry specific, and the belt should use
his/her own company adopted rating system. A summary of the software ratings
is provided in Table 16.6.
After the potential failure modes are identified, they are analyzed further
by potential causes and potential effects of the failure mode (causes and ef-
fects analysis). For each failure mode, the RPN is assigned based on Tables
20.3-20.5. For all potential failures identified with an RPN score greater than
a threshold (to be set by the DFSS team or accepted as a tribal knowledge),
the FMEA team will propose recommended actions to be completed within
the phase the failure was found (Step 10 below). A resulting RPN score must
be recomputed after each recommended action to show that the risk has been
mitigated significantly.
12. Actions recommended: The software DFSS team should select and manage
recommended subsequent actions. That is, where the risk of potential failures
is high, an immediate control plan should be crafted to control the situation.
Here is a list of recommended actions:
Transferring the risk of failure to other systems outside the project scope
Preventing failure all together (e.g., software poka-yoke, such as protection
shells)
Mitigating risk of failure by:
a. Reducing “severity” (most difficult)
b. Reducing “occurrence” (redundancy and mistake-proofing)
c. Increasing the “detection” capability (e.g., brainstorming sessions, con-
currently or use top-down failure analysis like FTA 11 )
Throughout the course of the DFSS project, the team should ob-
serve, learn, and update the SFMEA as a dynamic living document.
SFMEA is not retrospective but a rich source of information for corporate
11 See Chapter 15.
 
Search WWH ::




Custom Search