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

1、软件开发质量和风险的定量监理软件质量是指与软件产品满足规定和隐含的需求的能力和有关的特征 的全体，即所有描述计算机软件优秀程度的特性的组合。应用软件的质量依赖于问题需求的描 述、解决方案的建模设计、可执 行程序的编码的产生以及为发现错误而运行软件的测试。 一个优秀的监理工 程师应该能够使用定量的方法来评估软件开发过程中产生的分析及设计模 型、源代码和测试用例 (use case) 的质量。软件开发质量的定量监理为了实现这种实时的质量评估， 监理工程师们必须采用技术度量来客观 地评估质量，而不能仅仅采用主观的方法进行评估。在评估中，首先要明确的一点是，软件需求是度量软件质量的基础。不 符合需求的

2、软件就不具备质量而在定量监理实践中，通常需要使用一种被称为尺度度量的方法，这种 定量度量适用于一些能够直接度量的特性，比如，出错率定义为错误数 KL0C7单位时间等。因而，对质量控制所应该建立的一些定量数据是：（1）明确性 （无二义性 ） 、完全性、正确性、可理解性、可验证性、内 部和外部一致性、可完成性、简洁性、可追踪性、可修改性、精确性和可复 用性的数据。这些数据可以用来评价分析模型和相应的需求规约质量的特 征。公开的可能缺陷数与报告总缺陷数的对比则可以用来评价测试精确度 和测试覆盖度，同时也可以预测项目发布时间。（2）产品发布前清除的缺陷数在总缺陷数中所占的百分比，有助于评 估产品的质量

3、。3）按严重缺陷、子系统缺陷来划分，分类统计出平均修复时间，这样将有助于规划纠正缺陷的工作。（4）利用测试的统计数据，估算可维护性、可靠性、可用性和原有故 障总数等数据。 这些数据将有助于评估应用软件的稳定程度和可能产生的失 败。在上述定量数据的基础上，就可以开始进行估算。1、基本的定量估算基本定量估算示例：设F为用功能点描述的软件规模;D1为在开发过程（提交之前）中发现的所有缺陷数;D2为提交后发现的缺陷数;D 为发现的总缺陷数。因此， D=D1+D2对于一个应用软件项目，则有如下计算方程式（可以从不同的角度估算 软件的质量）：质量二D2/F;缺陷注入率 =D/F;整体缺陷清除率 =D1/D

4、;同样以上期中的CAD软件为例，根据上期计算所得结果，功能点F为366, 而在开发过程中发现了 15 个错误，提交后又发现了 4个错误，则：D1=15, D2=4D=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%。众所周知，清除软件缺陷的难易程度是不同的。需求错误、规格说明、

5、设计问题及错误修改是最难清除的。表 1给出了美国平均缺陷的情况：裏h平沟缺陷表潜崔缺16清除 *(%)隸交忖吿1 00770.2 |设计1 ,35851 ,76950.09丈档0.60800,12耕図修改0 + 4070會计5,00B50. 75表2反映的是CMh五个等级是如何影响软件质量的，其数据来源于美国 空军1994年委托SPR（美国一家著名的调查公司）进行的一项研究。褰二SEI CMM级别湖在缺陷与滴除SEt CMM溜在效爭（陽）被交时的扯甜p.oo0 Z!i24.00JJ90,443i 3.0G0,27N42.00'930/t4N * n51.00P50.05n sN= (5

6、/4 ) X 2=15 个软件开发风险的定量监理很多应用软件项目之所以陷入混乱状态而使项目组人员经常感到疲于奔命，就是因为对风险管理的不重视。在监理过程中也常常如此，很多情况 下都是问题发生时才意识到问题的存在。而资源和项目周期的压力，使得项 目的相关方不得不在没有很充分准备的情况下仓促应战，而在这种情况下产生的结果往往是不理想的。软件风险监理就是在风险成为影响软件项目成功的威胁之前，识别、着 手处理并消除风险的源头。风险关注未来将要发生的事情。那么，什么样的风险会导致软件项目彻 底失败呢？改变也是我们所关心的一用户需求、开发技术、目标计算机以及 所有其他与项目相关的因素的改变， 将会对按时交

7、付和总体成功产生什么影 响呢？最后，我们必须抓住选择机会一我们应该采用什么方法和工具？需要 多少人员来参与工作？对质量的要求要达到什么程度才是“足够 的”？诸如此类的问题还有很多，这些问题是风险监理最关键的部 分。对风险进行定量监理的第一步，就是要识别那些可能将风险带到项目计 划中的因素，也就是对风险进行分类。1、项目风险威胁到项目计划。也就是说，如果项目风险变成现实，有 可能会拖延项目的进度，且增加项目的成本。项目风险是指潜在的预算、 进度、人力（工作人员及组织 ） 、资源、客户、 及需求等方面的问题以及它们对软件项目的影响。项目复杂性、规模以及结 构不确定性也被定义为项目风险因素。2、技术

8、风险威胁到要开发软件的质量及交付时间。如果技术风险变成 现实，则开发工作可能变得很困难或根本不可能。技术风险是指潜在的设计、实现、接口、验证、和维护等方面的问题。 此外，规约的二义性、技术的不确定性、陈旧的技术及“先进的”技术也是 风险因素。3、组织风险。常见的组织风险是组织内部对目标未达成一致、高层对 项目不重视、资金不足或与其他项目有资源冲突等都是潜在的组织风险。4、外部风险。比如法律法规变化、项目相关接口方的情况发生变化， 这些事件往往是不可控制的。但要注意的是，一般将不可控制的“不可抗 力”不作为风险，而是将它们当作灾难进行防御。风险预测，又称为风险估算，试图从两个方面评估每一个风险风

9、险发 生的可能性或概率，以及如果风险发生后所产生的后果。项目计划者以及其他管理人员和技术人员需要一起执行四个风险预测 活动：（1）建立一个尺度， 以反映风险发生的可能性； （2）描述风险的后果； （3）估算风险对项目及产品的影响； （4）标注风险预测的整体精确度，以 免产生误解。风险表可以给项目管理者、监督者提供一种简单的风险预测技术。风险 表的样本如表 3 所示。在这里，PS指产品/项目规模风险，BU指商业风险，CU是指客户特性风 险，TE是指建造技术风险，DE是指开发环境风险，ST是指人员经验与经验 风险，像这样风险可以有许多，在这里就不一一举例了。项目组一开始要在表中的第一列列出所有风险

10、 （不管多么细微）。每一个 风险在第二列上加以分类。每个风险发生的概率则输入到第三列中。每个风 险的概率值可以由项目组成员个别估算，然后将这些单个值求平均，得到一 个有代表性的概率值。下一步是评估每个风险所产生的影响。使用表3所述的特性评估每个风险因素，并确定其影响的类别。对四个风险因素-性能、支持、成本及进度 的影响类别求平均可得到一个整体的影响值 （如果其中一个风险因素对项目 特别重要，也可以使用加权求平均值）。JK.L加瞠負*可峙m 乂 丁卄昭1峡件产嵩氓憫叫静flip 賂樂就疏诜慢焉甩+0% 'i'0%1拖車已f译1币吧记風庄11備噪找七JCfSttt（：*：.¥：旳毗-iao%JH人凸婷帕h焙甘尽碎1七間坏枪行恺任凤檜r r-X2在表三中，影响类别取值如下:1-灾难的，2-严重的，3-轻微的，4-可忽略的完成了风险表的前四列内容之后，就要根据概率及影响来进行排序。高 发生概率、高影响的风险放在表的上方，而低概率风险则移到表的下方。这 样就完成了第一次风险排序。项目监理者研究已排序的表，并定义一条中止线。该中止线 （ 表中某一 点上的一条水平线 ） 表示：只有那些在线之上的风险才会得到进一步的关注。 而在线之下