3、扩展的功能点度量 —— 特征点

（1）基础知识

①扩展的功能点也叫特征点度量法，是另外一种功能点度量；

②功能点度量最初主要是用于商业信息系统应用中；

③强调数据维而排除了功能维及行为(控制)维；

④因此，功能点度量不适合用于很多工程及嵌入式系统（它们强调功能及控制）。

（2）特征点

功能点测量的超集(superset)，适用于算法复杂性较高的应用，主要应用于系统和工程软件的应用，例如，实时系统、过程控制软件及嵌入式软件应用。

（3）特征点的计算

由上图可以发现：

①在FP信息域值计算的基础上增加了一个新的软件特性，即算法——特定计算机程序中所包含的一个界定的计算问题；

②在特征点的计算中，权值是固定的，而原来功能点的度量计算中，权值有简单、平均、复杂三种取值。

PS：权值即加权因子

4、调和不同的度量方法

Q：如果我知道LOC的数量，有没有可能估算功能点(FP)的数量？

A：代码行数和功能点之间的关系依赖于用来实现软件的程序设计语言和设计质量。

那么不同程序语言建造一个功能点所需的平均代码行数是多少呢？

如下图所示：

看到这里，小伙伴们对功能点是否有一定了解了呢？

不妨试问下自己，如果开发一个信息系统需要用到56000行VB代码，3000行SQL代码，那么该系统的功能点(FP)是多少？

56000LOC47LOC/FP+3000LOC40LOC/FP≈1192+75=1267个\frac{56000 LOC}{47 LOC/FP}+\frac{3000 LOC}{40 LOC/FP} ≈ 1192+75 = 1267个47LOC/FP56000LOC+40LOC/FP3000LOC≈1192+75=1267个

七、软件质量度量

1、软件质量的度量

质量度量贯穿于软件工程的全过程以及软件交付给用户使用之后。

（1）交付前度量

• 在软件交付之前得到的度量可作为判断设计和测试质量好坏的依据；
• 这一类度量包括程序复杂性、有效的模块性和总的程序规模。

（2）交付后度量

• 在软件交付之后的度量则把注意力集中于还未发现的缺陷数和系统的可维护性方面；

2、软件质量的度量指标

为了实现实时的质量评估，工程师们必须采用技术测量客观地评估质量，而不能采用主观的方法。以下列出4种客观的度量指标：

（1）正确性（最重要）

• 一个程序必须正确地运行，并为它的用户提供某些输出；
• 正确性要求软件执行所要求的功能；
• 关于正确性的最常用的测量是每KLOC的缺陷数(Defects/KLOC)，这里的缺陷数定义为“验证结果与需求不符的地方”。

思考：

Q：缺陷数越高越好还是越少越好？

A：缺陷数越高，软件质量越低；所以缺陷数应该尽可能少。

（2）可维护性

• 可维护性是指遇到错误时程序能被修改的容易程度，维护所占的工作量比其他活动都大，它无法直接测量；
  
• 面向时间：
  有一种简单的面向时间的度量，称MTTC（平均变更时间），可以作为可维护性的度量；
  这个时间包括分析变更要求、设计适当的修改、实现变更并测试、及把变更发送给所有的用户。
  
• 面向成本：
  还有一种面向成本的可维护性度量，称损坏度，指的是软件发布给最终用户后修改遇到缺陷的成本。
  

思考：

Q1：MTTC越低，可维护性越好还是越差呢？

A1：MTTC即平均变更时间，变更时间越少，说明软件质量越好；所以，MTTC越低，可维护性越好。

Q2：当每千代码行的缺陷数降低的同时，损坏度有可能提高吗？

A2：损坏度即遇到缺陷的成本。

举个例子：

假设在一个软件中，遇到50个缺陷，这50个缺陷都是些很小很细微的问题，很快就能修复完，那么所花费的成本也就不会很高；

再或者在另一个软件中，遇到5个缺陷，这5个缺陷刚好是5个非常重大的漏洞问题，需要很多时日才能修复完，那么所花费的成本就会很高，即损坏度提高；

所以，缺陷数低并不代表成本就会低，这也就意味着，当每千代码行的缺陷数降低的同时，损坏度有可能提高。

（3）完整性

• 完整性是度量一个系统在安全方面的抗攻击的能力；
• 软件的三个成分，程序、数据和文档都会遭到攻击；
• 度量完整性，需要定义两个附加的属性：危险性和安全性；
• 危险性是特定类型的攻击将在一个给定时间内发生的概率；
• 安全性是排除特定类型攻击的概率；
• 一个系统的完整性可定义为 完整性＝∑［1－危险性×( 1－安全性) ］ 其中，对每一个攻击的危险性和安全性都进行累加。

思考：

Q：某个攻击的危险性是70%,安全性是40%，那它的完整性等于多少？

A：完整性 = ∑ [1－危险性×( 1－安全性) ] = 1 - 0.7(1 - 0.4) = 1 - 0.7x0.6 = 1 - 0.42 = 0.58

试想下，一个完整性为0.58的系统，它合格吗？

答案自然是不合格的。一个软件，连最基础的60%的合格率都达不到，又怎么能合格呢。

（4）可用性

如果一个程序不具有“用户友好性”，即使它所执行的功能很有价值，也常常会失败。可使用性量化“用户友好性”，并依据以下四个特征进行度量：

• 为学习系统所需要的体力上的和智力上的技能；
• 为达到适度有效使用系统所需要的时间；
• 当软件被某些人适度有效地使用时所度量的在生产率方面的净增值；
• 用户角度对系统的主观评价 （可以通过问题调查表得到）。

八、DRE

1、DRE的全称

DRE，即Defect Removal Efficiency，表示缺陷排除效率。

2、衡量DRE的两种角度

（1）DRE=E/(E+D)

• DRE是对质量保证及控制活动中滤除缺陷能力的一个测量；
• E是软件交付给最终用户之前所发现的错误数，D是软件交付之后所发现的缺陷数。

（2）DREi=Ei/(Ei+Ei+1)DRE_i =E_i/(E_i+E_{i+1} )DREi=Ei/(Ei+Ei+1)

• DRE也能够用于在项目中评估一个小组在错误传递到下一个活动或任务之前发现这些错误的能力。在这种情况下，我们定义DRE为：

即,DREi=Ei/(Ei+Ei+1)即,DRE_i =E_i/(E_i+E_{i+1} )即,DREi=Ei/(Ei+Ei+1)

• EiE_iEi是在软件工程活动i中所发现的错误数， Ei+1E_{i+1}Ei+1是在软件工程活动i+1中所发现的错误数，这些错误起源于软件工程活动i中未能发现的错误。
• 可以把EiE_iEi理解为前一个活动，Ei+1E_{i+1}Ei+1理解为后一个活动。

3、思考题 —— think more

软件团队将软件交付给了最终用户。在使用的第一个月中，用户发现了8个缺陷。在交付之前，软件团队在正式的评审和所有的测试任务中发现了72个错误。那么，项目总的缺陷排除效率公式是DRE=E/ (  +  )，最后的结果是____（写成小数点的形式）。

解析：

• 项目总的缺陷排除效率公式是 DRE=E/(E+D)；
  
• 最后的结果是 DRE = 72 / (72 + 8) = 0.9。
  

九、结束语

关于软件项目管理中软件的度量就讲到这里啦！