带你读《SAS数据分析开发之道 软件质量的维度》第一章概览1.1引言（七）

风险登记表

风险登记表旨在记录被识别的风险的相关信息。风险是所有软件应用程序内在的    属性，因此，风险登记表（有时也称为缺陷数据库）记录整个 SDLC 中的风险、威胁、漏洞及其他相关信息。开发人员和其他利益相关者应该确定在软件中添加哪些性能要    求，但不能在所有的软件中包含全部的性能要求。由于软件中会存在漏洞，因此，漏    洞的识别、检测和记录是非常重要的，这能帮助我们查明它们对软件操作造成的特定    风险。

风险登记表能定性和定量地记录已知的漏洞及软件功能或性能的相关威胁和风险，主要包括以下内容 ：

■     漏洞描述 ；

■    漏洞位置 ；

■     漏洞的威胁 ；

■     漏洞被利用的风险 ；

■    风险级别 ；

■     风险发生的概率 ；

■     风险被发现的概率 ；

■     消除或降低风险的成本 ；

■    建议的解决方案。

有些风险登记表是按照漏洞等级组织的，而另外一些则是按照威胁或风险等级组织的。漏洞等级风险登记表在软件开发领域比较常见，因为尽管有许多威胁超出了开发人员的可控范围，但可以利用编程解决方案来消除或弥补特定的漏洞。而且，在一个软件产品内，类似“大数据”这种常见的威胁可以利用无数个不相关的漏洞。

表1-1是一个简化的风险登记表，记录了代码中的两个错误。风险的级别、风险发生的概率、风险被发现的可能性及实施解决方案所需要的成本的数值范围（1～5），5表示风险比较严重、发生的概率比较大、被发现的可能性比较小、修复的成本较高。

表 1-1风险登记表范例

顺序	漏洞	位置	风险	风险级别	风险发生的概率	风险被发现的概率	风险成本
1	%SYSEVALF应该 用在评估中	小于运算符	科技符号未正确解读	5
2	没有格式指令	PROCSQL 的 SELECT指令

第一个和第二个风险描述的是两个不同的漏洞，每一个都被含有1亿个以上观测数据的数据集威胁所利用。尽管遇到威胁时，5 表示最严重，但其发生的概率比较小， 数值是 1，因为在该开发环境中，从未遇到过这么大的文件。

如果仅考虑上述两个因素，开发团队可能会鉴于漏洞发生的概率比较小，接受风险并发布含有漏洞的软件。但由于被发现的概率比较小（5）——如果遇到威胁，不    会出现警告或“运行时错误”——而且因为实施补救措施（修改其中一行代码）的成       本较低（1），开发团队可能转而会修改代码，消除风险，而不是接受风险。

建议的解决方案描述的是管理风险所选定的路径——通常有避开、转移、接受或降低，但表1-1中没有提到，我们会在后续部分进行讲述。建议的解决方案可能包括一个技术说明，说明如何管理风险。例如，如果要消除风险，那么解决方案可能会从编程方面描述如何消除或控制相关威胁，如何消除相关漏洞以避免被威胁利用。

风险管理

风险管理指的是指导和管理企业风险的协调活动。ISO     进一步定义了风险管理架构     ：一系列提供理论依据和组织安排的组件，帮助企业设计、实施、监测、审查及提 升风险管理能力。本书所提到的操作软件风险指的是软件故障——与功能或性能相关   的故障，风险管理接受故障，将其看作是一个不可避免的事实，并努力去消除风险，    向利益相关者交付一个可接受的风险。故障并不能表示一定出现了运行错误，但能表    示软件不能再满足功能或性能要求。

风险登记表不仅包括理论上的、未被利用的软件漏洞，还包括实际的软件故障中    出现的漏洞。如果有故障日志，那么后一种故障便会出现在故障日志中（第   4章会讲到这一点）。风险解决方案并不表示风险被消除，在许多情况下，漏洞一旦被识别， 开发人员就决定接受风险，保持源代码不变。常见的风险解决方案模式如下。

风险规避   ：不参与或撤回某项活动以避免特定风险的知情决策。例如，如果软件发生故障，则停止使用。

风险共享     ：根据商定的风险分配协议与他人共担风险的处理模式。例如，有些服务等级协议规定，如果出现电源故障（引起生产软件故障），则事故责任转移到公司，而不是由    O&M    团队、开发人员或用户承担。PMBOK    和其他系统使用另外一个术语“风险转移”。

风险保留   ：接受某个风险的潜在利润或损失的责任。利益相关人员在进行综合评价之后，认为解决风险是不合算的，他们就会保留或接受风险。PMBOK    和其他系统使用的是“风险接受“这个术语。

风险消减“降低风险发生的概率及风险潜在损失所采取的措施。”例如，使用程序化解决方案来减少或消除软件的漏洞，如删除某个错误。

风险登记表对生产软件至关重要，因为它为内部利益相关人员提供了一个通用的架构来测定软件的优点或缺点。在某些情况下，一个注册簿中会创建一个独立的量化优先级，因此，开发人员可能会优先校正代码的一个元素，而客户可能会优先校正其他的元素，而利益相关者需要做的是投票选出如何有效地调整软件。通过评估软件的总风险，所有的利益相关者能清楚地掌握软件的质量。而且，由于风险登记表是一个不断变化、灵活的文件，因此，如果软件总风险随着时间推移越来越高，那么之前可被接受的风险之后可能需要被消除或减弱，使风险回到一个可接受的水平。