14.4 模式应用案例
应用案例：使用DFMEA（Design Failure Mode and Effects Analysis，设计失效模式及后果分析）进行风险规划
在软件设计和开发当中，常常存在的问题是，只考虑了正常的场景而忽略了异常的情况。
1999年，美国航空航天局（NASA）发射的火星探测者号在发射之后失去联系。随后的调查发现，失败的原因是：在设计火星探测者号软件时，一个NASA开发小组错误地使用了英制单位，而不是预定的国际单位。这一个“小小的”错误，就造成了超过3.27亿美元的巨大损失。
2003年北美大停电，超过5500万人受到影响。而事后调查的原因也非常简单：控制中心报警系统软件对“竞态”（Race Condition）处理不当，从而导致报警系统停止工作而错过了预警大停电的最好时机。
在这两个例子中可以看到，如果在软件开发的设计阶段忽略了对异常场景的规划和处理，看似微小的问题，有时都会带来巨大的损失。因此，如何能够用结构化的方式组织软件设计和开发中对异常情况的分析、规划和处理，便成为一个重要的课题。DFEMA（Design Failure Mode and Effects Analysis，设计失效模式及后果分析）就是充分利用本章所介绍的“结构化思维”的工具，在软件开发中结构化的分析和规划异常情况的实践。
DFEMA源于产品设计和制造时的FMA（Fault Mode Analysis，故障模式分析）和FEA（Fault Effect Analysis，故障影响分析）的组合。DFEMA对各种可能的风险和异常情况进行发掘、评价和分析，同时在现有技术的基础之上减轻或者消除这些风险。在软件开发中，我们可以将DFEMA进行简化，从而达到在投入时间和产出上的最佳。具体来说，我们推荐在软件设计和开发中将DFEMA简化为“P”和“F”两个阶段：即P-diagram分析和Follow-up后续跟进。
1. P-diagram分析
按照“结构化思维”的分类思考和分层分析的原则，对于软件开发和设计这个目标，可以使用“正常场景/异常场景”这个分类标准。在正常场景分类中，可以利用著名的“4+1视图”方式进行表11所示的二级思考和分析；而在异常场景分类中，就可以使用DFEMA工具进一步的分析和规划。
表11
如图22所示，在DFEMA工具中，可以进一步对下列几个方面进行分析和规划：
图22 P-diagram
输入（Input）
在软件设计中，输入意味着使用什么样的平台（例如网页或者iOS APP），以什么样的方式（例如加密或者非加密），输入什么样的数据。
噪声（Noise）
噪声实际上是对软件设计、开发和使用中可能会出现的风险和异常情况的隐喻。例如登录模块在使用中遇到的黑客攻击、iOS APP在使用过程中遇到的网络连接中断，等等。
控制因素（Control Factor）
控制因素指的是可以控制和调整、从而对可能出现的风险和异常情况进行减轻或者规避的那些可控量。例如，软件的日志系统，超时重连机制，备份数据库连接，等等。
理想情况处理（Ideal State）
理想情况是在正常的场景下软件的期望行为和输出。也就是软件的规格说明书中描述的软件的正常行为。
异常情况处理（Error State）
异常情况处理是DFEMA的精华部分，指的是当出现了噪声之后，如何利用控制性因素对异常情况进行减轻或者规避。例如，软件登录模块在遇到黑客对密码的攻击时，可以利用“超过若干次错误的密码尝试锁住账户”这个“控制性因素”来对风险进行减轻和规避。
通常，软件设计和开发团队会按照“输入→噪声→控制性因素→正常情况处理→异常情况处理”的顺序进行讨论。
2. Follow-up后续跟进
在P-diagram分析中，对于“异常情况处理”中的每一个条目，都必须指定专人负责对具体处理方法的规划和执行。在P-diagram讨论之后，还需要定期对讨论中制定的任务进行后续跟进，只有当所有“异常情况处理”中的条目都被处理完毕之后，一个完整的软件开发设计DFEMA才算正式结束。