软件开发质量和风险的定量监理

软件开发质量和风险的定量监理 

作者：中国软件评测中心 陈兵
发表：2003.12.31 
来源：中国计算机用户

软件质量是指与软件产品满足规定和隐含的需求的能力和有关的特征的全体，即所有描述计算机软件优秀程度的特性的组合。 

　　应用软件的质量依赖于问题需求的描述、解决方案的建模设计、可执行程序的编码的产生以及为发现错误而运行软件的测试。一个优秀的监理工程师应该能够使用定量的方法来评估软件开发过程中产生的分析及设计模型、源代码和测试用例(use case)的质量。 

　　软件开发质量的定量监理 

　　为了实现这种实时的质量评估，监理工程师们必须采用技术度量来客观地评估质量，而不能仅仅采用主观的方法进行评估。 

　　在评估中，首先要明确的一点是，软件需求是度量软件质量的基础。不符合需求的软件就不具备质量。 

　　而在定量监理实践中，通常需要使用一种被称为尺度度量的方法，这种定量度量适用于一些能够直接度量的特性，比如，出错率定义为错误数／KLOC／单位时间等。 

　　因而，对质量控制所应该建立的一些定量数据是： 

　　（1）明确性(无二义性)、完全性、正确性、可理解性、可验证性、内部和外部一致性、可完成性、简洁性、可追踪性、可修改性、精确性和可复用性的数据。这些数据可以用来评价分析模型和相应的需求规约质量的特征。 

　　公开的可能缺陷数与报告总缺陷数的对比则可以用来评价测试精确度和测试覆盖度，同时也可以预测项目发布时间。 

　　（2）产品发布前清除的缺陷数在总缺陷数中所占的百分比，有助于评估产品的质量。 

　　（3）按严重缺陷、子系统缺陷来划分，分类统计出平均修复时间，这样将有助于规划纠正缺陷的工作。 

　　（4）利用测试的统计数据，估算可维护性、可靠性、可用性和原有故障总数等数据。这些数据将有助于评估应用软件的稳定程度和可能产生的失败。 

　　在上述定量数据的基础上，就可以开始进行估算。 

　　1、基本的定量估算 

　　基本定量估算示例： 

　　设 F为用功能点描述的软件规模； 

　　D1为在开发过程（提交之前）中发现的所有缺陷数； 

　　D2为提交后发现的缺陷数； 

　　D为发现的总缺陷数。 

　　因此，　D=D1+D2 

　　对于一个应用软件项目，则有如下计算方程式（可以从不同的角度估算软件的质量）： 

　　质量=D2/F； 

　　缺陷注入率=D/F； 

　　整体缺陷清除率=D1/D； 

　　同样以上期中的CAD软件为例，根据上期计算所得结果，功能点F为366，而在开发过程中发现了15个错误，提交后又发现了4个错误，则： 

　　D1=15，D2=4 

　　D=D1 +D2=15+4=19 

　　质量(每功能点的缺陷数)=D2/F=4/366=0.0109 

　　缺陷注入率=D/F=19/366=0.05191 

　　整体缺陷清除率=D1/D=15/19=0.7895 

　　有资料报告，美国的平均整体缺陷清除率目前只达到大约85%。而像AT&T、IBM、摩托罗拉和惠普这样一些大公司的顶级项目，通过实施最佳实践，其缺陷清除率可以超过99%。 

　　众所周知，清除软件缺陷的难易程度是不同的。需求错误、规格说明、设计问题及错误修改是最难清除的。表1给出了美国平均缺陷的情况： 

　　 

　　表2反映的是CMM五个等级是如何影响软件质量的，其数据来源于美国空军1994年委托SPR（美国一家著名的调查公司）进行的一项研究。 

　　

　　从表中可以看出，CMM级别越高，缺陷清除率也越高。 

　　在监理过程中，可以将这这些标准或指标结合起来使用，用以辨明可能存在的质量问题。 

　　2、对软件需求的估算 

　　假设在一个规约中有nr个需求，所以 

　　nr=nf+nnf 

　　其中，nf是功能需求的数目，nnf是非功能需求数目(例如性能)。 

　　为了确定需求的确定性(无二义性)，一种基于复审者对每个需求解释的一致性的度量方法为： 

　　Q1＝nui/nr 

　　其中，Q1表示需求的确定性，nui是所有复审者都有相同解释的需求数目。当需求的模糊性越低时，Q1的值越接近1。 

　　在CAD软件的例子中，假设计算机图形显示功能模块的功能性需求是10个，非功能性需求（响应速度和分辨率）是2个，所有复审者都有相同解释的需求数目是11个，则： 

　　Q1=11/12=0.916667 

　　而功能需求的完整性Q2则可以通过计算以下比率获得： 

　　Q2＝nu/(ni×ns) 

　　其中，nu是唯一功能需求的数目，ni是由规约定义或包含的输入(刺激)的个数，ns是被表示的状态的个数。 

　　Q2只是测度了一个系统所表示的必需的功能百分比，但是它并没有考虑非功能需求。为了把这些非功能需求结合到整体度量中以求完整，必须考虑已有需求已经被确认的程度。这可以用Q3来表示： 

　　Q3＝nc/(nc＋nnv) 

　　其中，nc是已经确认为正确的需求的个数，nnv是尚未被确认的需求的个数。 

　　在CAD软件的例子中，假设数据库管理功能模块的唯一功能需求是10个，由规约定义或包含的输入个数也是10个，表示的状态的个数是1个，已经被确认的需求是8个，未被确认的需求是2个，则： 

　　Q2＝10/（10×1）=1.0 

　　Q3＝8 /（8+2）=0.8 

　　3、估算验收测试阶段预期发现的缺陷数 

　　（1）如果使用类似项目的数据，那么可以估计当前项目在验收测试时发现缺陷数，它等于在类似项目的验收测试阶段发现的缺陷数和这个项目估计的工作量与类似的总工作量比率的乘积。用如下公式表示: 

　　验收测试缺陷的估计=验收测试缺陷数×工作量估计/实际工作量 

　　在CAD软件的例子中，若以前有一个相似的图形处理软件，在验收测试的时候发现了12个缺陷，本项目估算的工作量是66人/月，实际的工作量是82人/月，则CAD软件项目在验收测试时可能出现的缺陷是： 

　　验收测试缺陷的估计=12×66/82=10 

　　（2）使用过程能力基线中的数据，那么可以使用几种方法来计算这个值: 

　　a、估算每功能单元的缺陷数，那么功能点规模按前面讨论的方式进行估计，预期的缺陷数是质量数据和估计规模的乘积。 

　　b、估算过程缺陷清除率。在这种情形下，在验收测试阶段预期存在的缺陷数可以由缺陷注入率、过程中的清除率目标以及估计的规模一起来决定。 

　　4、针对维护活动设计的度量 

　　IEEE Std.982.1-1988[IEE94]建议了一个软件成熟度指标(SMI)，它提供了对软件产品的稳定性的指示(基于为每一个产品的发布而做的变动)，以下信息可以确定： 

　　MT=当前发布中的模块数； 

　　Fc=当前发布中已经变动的模块数； 

　　Fa=当前发布中已经增加的模块数； 

　　Fd=当前发布中已删除的前一发布中的模块数； 

　　那么，软件成熟度指标可以用下面的公式来计算： 

　　SMI=[MT-(Fa+Fc+Fd)]/MT 

　　当SMI接近1.0的时候，产品开始稳定。SMI也可以用作计划软件维护活动的度量。产生一个软件产品的发布的平均时间可以和SMI关联起来，并且也可以开发一个维护工作量的经验模型。 

　　在CAD软件的例子中，若目前的软件是2.0版，当前发布的模块数是32个，当前发布中已经变动的模块数是8个，当前发布中已经增加的模块数是2个，当前发布中已删除的前一发布中的模块数是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、外部风险。比如法律法规变化、项目相关接口方的情况发生变化，这些事件往往是不可控制的。但要注意的是，一般将不可控制的“不可抗力”不作为风险，而是将它们当作灾难进行防御。 

　　风险预测，又称为风险估算，试图从两个方面评估每一个风险—风险发生的可能性或概率，以及如果风险发生后所产生的后果。 

　　项目计划者以及其他管理人员和技术人员需要一起执行四个风险预测活动：（1）建立一个尺度，以反映风险发生的可能性；（2）描述风险的后果；（3）估算风险对项目及产品的影响；（4）标注风险预测的整体精确度，以免产生误解。 

　　风险表可以给项目管理者、监督者提供一种简单的风险预测技术。风险表的样本如表3所示。 

　　在这里，PS指产品/项目规模风险，BU指商业风险，CU是指客户特性风险，TE是指建造技术风险，DE是指开发环境风险，ST是指人员经验与经验风险，……像这样风险可以有许多，在这里就不一一举例了。 

　　项目组一开始要在表中的第一列列出所有风险(不管多么细微)。每一个风险在第二列上加以分类。每个风险发生的概率则输入到第三列中。每个风险的概率值可以由项目组成员个别估算，然后将这些单个值求平均，得到一个有代表性的概率值。 

　　下一步是评估每个风险所产生的影响。使用表3所述的特性评估每个风险因素，并确定其影响的类别。对四个风险因素--性能、支持、成本及进度的影响类别求平均可得到一个整体的影响值(如果其中一个风险因素对项目特别重要，也可以使用加权求平均值)。 

　　 

　　在表三中，影响类别取值如下： 

　　1-灾难的，2-严重的，3-轻微的，4-可忽略的 

　　完成了风险表的前四列内容之后，就要根据概率及影响来进行排序。高发生概率、高影响的风险放在表的上方，而低概率风险则移到表的下方。这样就完成了第一次风险排序。 

　　项目监理者研究已排序的表，并定义一条中止线。该中止线(表中某一点上的一条水平线)表示：只有那些在线之上的风险才会得到进一步的关注。而在线之下的风险则需要再评估以完成第二次排序。排序后找出需要关注的风险点，进行处理。可以依次类推完成第三次排序或更多的排序。 

　　从监理的角度来考虑，风险影响及概率是起着不同的作用的。一个具有高影响但发生概率很低的风险因素不应该花费太多的监理时间和精力。而高影响且发生概率为中到高的风险、以及低影响且高概率的风险，应该首先列入重点监理考虑之中。

原文转自：http://www.ltesting.net