删除的前一发布中的模块数是1个，则：
SMI=（32－8－2－1）/32=0.656，
从结果可以看出，目前的情况离产品稳定还有相当的距离。
5、软件可用性的计算
软件可用性是指在某个给定时间点上程序能够按照需求执行的概率。其定义为：
可用性=MTTF/（MTTF+MTTR）×100％
其中，MTTF是“平均失败时间”，MTTR是“平均修复时间”。
在CAD软件的例子中，若软件在6个月内失败一次，每次恢复平均需要20分钟（恢复时间为排除故障或系统重新启动所用的时间），那么，它的可用性是：
6个月/（6个月+20分钟）X100=99.92%
通常，提高系统的可用性基本上有两种方法：即增加MTTF或减少MTTR。而增加MTTF还要求增加系统的可靠性。
6、利用植入故障法估算程序中原有故障总数ET
通常可以采用捕获－再捕获抽样法来估算程序中原有故障总数。
设Ns是在测试前人为地向程序中植入的故障数(称播种故障)，ns 是经过一段时间测试后发现的播种故障的数目，n是在测试中又发现的程序原有故障数。
假设测试用例发现植入故障和原有故障的能力相同，则程序中原有故障总数 N(=ET) 估算值为：
例如，在CAD软件的测试过程中，人为播入的故障数是5个，经过一段时间的测试后发现的播种故障数是4个，在测试中又发现原有的故障数是2个，则程序中原有的故障数是：
N=（5/4）× 2=15个
软件开发风险的定量监理
很多应用软件项目之所以陷入混乱状态而使项目组人员经常感到疲于奔命，就是因为对风险管理的不重视。在监理过程中也常常如此，很多情况下都是问题发生时才意识到问题的存在。而资源和项目周期的压力，使得项目的相关方不得不在没有很充分准备的情况下仓促应战，而在这种情况下产生的结果往往是不理想的。
软件风险监理就是在风险成为影响软件项目成功的威胁之前，识别、着手处理并消除风险的源头。
风险关注未来将要发生的事情。那么，什么样的风险会导致软件项目彻底失败呢？改变也是我们所关心的—用户需求、开发技术、目标计算机以及所有其他与项目相关的因素的改变，将会对按时交付和总体成功产生什么影响呢？最后，我们必须抓住选择机会—我们应该采用什么方法和工具？需要多少人员来参与工作？对质量的要求要达到什么程度才是“足够的”？……诸如此类的问题还有很多，这些问题是风险监理最关键的部分。
对风险进行定量监理的第一步，就是要识别那些可能将风险带到项目计划中的因素，也就是对风险进行分类。
1、项目风险威胁到项目计划。也就是说，如果项目风险变成现实，有可能会拖延项目的进度，且增加项目的成本。
项目风险是指潜在的预算、进度、人力(工作人员及组织)、资源、客户、及需求等方面的问题以及它们对软件项目的影响。项目复杂性、规模以及结构不确定性也被定义为项目风险因素。
2、技术风险威胁到要开发软件的质量及交付时间。如果技术风险变成现实，则开发工作可能变得很困难或根本不可能。
技术风险是指潜在的设计、实现、接口、验证、和维护等方面的问题。此外，规约的二义性、技术的不确定性、陈旧的技术及“先进的”技术也是风险因素。
3、组织风险。常见的组织风险是组织内部对目标未达成一致、高层对项目不重视、资金不足或与其他项目有资源冲突等都是潜在的组织风险。
4、外部风险。比如法律法规变化、项目相关接口方的情况发生变化，这些事件往往是不可控制的。但要注意的是，一般将不可控制的“不可抗力”不