【软件工程知识】{5} 软件项目管理——软件的度量

一、度量的目的

1、引例

引用Lord Kelvin曾说过一句话： ①当你能够测量你所说的并将其用数字表达出来，你就对它有了一些了解；②但当你不能测量，不能用数字表达它时，你对它的了解就很贫乏、很不令人满意;③它可能是知识的开始，但你在思想上还远没有进入科学的境地。

这句话说明，想要得到一个可量化的结果，需要先去测量它，有了测量结果后，才会有度量；也就是说，测量是度量的基础。

2、度量的目的

进行度量工作，是为了了解产品开发的技术过程和产品本身。

• 度量开发过程的目的是为了改进过程；

• 度量产品的目的是为了提高产品的质量。

3、度量的作用

• 度量的作用是为了有效地定量地进行管理。

二、测量、度量和指标区别

1、引例

假设有A和B两个人，我们都知道A比B高。但不知道A比B高多少？

这个时候是不是就得经过测量身高才能知道具体值。

所以，A和B的身高值即为测量值。

经过测量，A的身高为189cm，B的身高为170cm。

得出结论，A比B高19cm。

所以，A比B高19cm是度量值。

2、测量、度量和指标的区别

（1）测量(measure) —— 对一个产品或过程的某个属性的范围、数量、维数、容量或大小提供了一个定量的指示。

（2）度量(metrics) —— 对一个系统、部件或过程具有的某个给定属性的度的一个定量测量。

（3）指标(indicator) —— 软件工程师收集测量并开发度量，这样就可以获得“指标(indicator)”；指标是一个度量或度量的组合，它对软件过程、软件项目或产品本身提供了更深入的理解。

3、思考题

Q：指出下面这段话中哪些是测量，哪些是度量，哪些是指标？

有四个软件小组共同完成一个大型项目，但是每个小组必须进行技术评审，

经过检查每人每小时所发现的错误数，管理者发现采用更加正式评审方法的两个小组比起另外两个小组，每人每小时所发现的错误数要高40%，

假设其它参数相同，这就给管理者提供一个指标：正式的评审方法比起其他评审方法在时间投资上能得到更大的回报，他可能会建议所有小组都采用正式的评审方法。

A：从上面这段话中可以得出，每人每小时所发现的错误数为测量值，更加正式的评审方法为指标，每人每小时所发现的错误数要高40%为度量值。

得出结论，测量是度量的基础，度量是为了得到指标，它们的关系为：测量->度量->指标。

三、过程度量和项目度量

软件过程度量主要用于战略的目的，软件项目度量则是战术的。

1、过程

（1）过程度量

• 在软件发布之前的错误数的测量；
• 交付给最终用户并由最终用户报告的缺陷的测量；
• 交付的工作产品（生产率）的测量；
• 花费的工作量的测量;
• 花费的时间的测量；
• 与进度是否一致的测量。

（2）过程指标

• 使得软件工程组织能够洞悉一个已有过程的功效（如范型、软件工程任务、工作产品及里程碑）；

• 使得管理者和开发者能够评估哪些部分可以起作用，哪些部分不行；

• 过程度量(Metrics)的收集跨越所有的项目，并经历很长的时间，目的是获得改善软件过程的指标。

2、项目

（1）项目度量

• 大多数软件项目度量的第一个应用是在估算时发生的；
• 从过去的项目中收集的度量可用来作为估算现在软件项目的工作量及时间的基础；
• 所花费的工作量及时间的测量可以和预估算值进行比较，项目管理者使用这些数据来监督和控制项目的进展。

（2）项目度量的目的

• 能指导进行一些进度上的必要调整，以避免延迟、减少问题及风险，从而使得开发时间减到最少；

• 项目度量可在项目进行的基础上评估质量，在必要时修改技术方法以改进质量。

（3）项目指标

• 评估正在进行的项目的状态；
• 跟踪潜在的风险；
• 在问题造成不良影响之前发现它们；
• 调整工作流程或任务；
• 评估项目组在控制软件工程工作产品的质量的能力。

四、度量的方式

1、物理世界中的测量

（1）直接测量 —— 例如，测量一个螺栓的长度；

（2）间接测量 —— 例如，用次品率来测量生产出的螺栓质量。

2、软件测量

软件测量与物理测量一样，也同样分为两类。

（1）直接测量

过程 —— 软件工程过程的直接测量包括所投入的成本和工作量；

产品 —— 软件产品的直接测量包括产生的代码行数(LOC)、执行速度、存储量大小、在某种时间周期中所报告的差错数。

（2）间接测量

产品 —— 软件产品的间接测量包括功能性、复杂性、效率、可靠性、可维护性和许多其它的质量特性。

五、面向规模的度量

1、定义

（1）面向规模的度量是对软件和软件开发过程的直接度量；

（2）可以建立一个面向规模的数据表格来记录项目的某些信息。

2、有用度量的计算——举例阐述

项目	LOC	工作量	成本	文档页数	错误	缺陷	人员
Alpha	12100	24	168	365	134	29	3
Beta	27200	62	440	1224	321	86	5
Gamma	20200	43	314	1050	256	64	6
…	…	…	…	…	…	…	…

Q：该表格列出了在过去几年完成的每一个软件开发项目和关于这些项目的相应的面向规模的数据。那么，①从该表中可以获得哪些有用信息？②三个项目哪个项目的软件质量最高？③哪个项目的生产率最高？④哪个项目的单位成本最高？

注：LOC即Line Of Code，表示代码行数；PM即Person Month，表示每人每月。

需要注意的是：在表格中记载的工作量和成本是整个软件工程的活动（分析、设计、编码和测试），而不仅仅是编码活动；

对于每一个项目，可以根据表格中列出的基本数据计算简单的面向规模的生产率和质量等的度量。

A：根据表格可以对所有的项目计算出以下有用度量：

生产率 ＝ KLOC／PM(人月)；（成正比）

质量 ＝ 错误数／KLOC；（成正比）

质量 = 缺陷数/KLOC；（成反比）

成本 ＝ 元／LOC；（成正比）

文档 ＝ 文档页数／KLOC。（成正比）

六、面向功能的度量

1、定义

（1）面向功能的软件度量是对软件和软件开发过程的间接度量；

（2）面向功能的度量主要考虑程序的“功能性”和“实用性”，而不是对LOC计数；

（3）该度量是一种叫做功能点方法的生产率度量法，利用软件信息域中的一些计数和软件复杂性估计的经验关系式而导出功能点FP。

2、功能点度量的计算

（1）图例

面向功能的度量图例

需了解以下公式：

①FP=总计数值х(0.65+0.01 х ΣFi)；

②Fi(i=1到14)：复杂度调整值。

注：

• FP即Function Points，表示功能点；

• 总计数值是所有加权计数项的和；与五个信息域有关，即输入，输出，查询，文件，接口，且需考虑加权因子；

• Fi为复杂度校正值，需回答14个问题，详情看第（3）点

（2）五个信息域

• 用户输入数：各个用户输入是面向不同应用的输入数据；
• 用户输出数：各个用户输出是面向应用的输出信息，包括报表，屏幕信息，错误信息等。在报表中的各个数据项不应该再分别计数；
• 用户查询数：查询是一种联机的交互操作，每一个不同的查询都要计算；
• 文件数：每一个逻辑主文件都应计数。逻辑主文件是指逻辑上的一组数据，可以是一个大数据库的一部分，也可以是一个单独的文件；
• 外部接口数：与系统中其他设备通过外部接口读写信息次数均应计数。

（3）关于复杂性校正值Fi

1. 系统是否需要可靠的备份和恢复？
2. 是否需要数据通信？
3. 是否有分布处理的功能？
4. 是否性能成为关键？
5. 系统是否运行在现存的高度实用化的操作环境中？
6. 系统是否需要联机数据项？
7. 联机数据项是否需要建立多重窗口显示和操作，以处理输入处理？
8. 主文件是否联机更新？
9. 输入、输出、文件、查询是否复杂？
10. 内部处理过程是否复杂？
11. 程序代码是否可复用？
12. 设计中是否包括了转移和安装？
13. 系统是否设计成可以重复安装在不同机构中?
14. 系统是否设计成易修改和易使用？

（4）关于计算

①一旦收集到上述数据，就可以计算出与每一个计数相关的复杂性值；

②一个信息域是简单的、平均（中等）的还是复杂的，由使用功能点方法的机构自行确定，从而计算出加权计数；

③计算功能点，使用如下的计算公式：

FP=总计数值×[0.65+0.01 × ∑(Fi)]，总计数值是所有加权计数项的和；

④Fi(i＝1..14)是复杂性校正值，它们应该通过逐一回答14个问题来确定，详情看第（3）点；

③④注意点：

Fi的取值0~5：0表示没有影响；1表示微小影响；2表示轻度；3表示中度；4表示显著；5表示重大；

∑(Fi)是求和函数

⑤一旦计算出功能点，就可仿照LOC的方式度量软件的生产率、质量和其它属性：

生产率＝FP／PM（人月）；（成正比）

质量＝错误数／FP；（成正比）

质量 = 缺陷数/FP；（成反比）

成本＝元／FP；（成正比）

文档＝文档页数／FP；（成正比）

（5）基于FP的软件度量

• 每个FP的错误数(Errors per FP) —— 质量

  每个FP的缺陷数(Defects per FP) —— 质量

• 每个FP的花费($ per FP) —— 成本

• 每个FP的文档页数(Pages of documentation per FP) —— 文档

• 每人月完成的FP数(FP per person-month) —— 生产率

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

（1）基础知识

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

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

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

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

（2）特征点

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

（3）特征点的计算

特征点的计算

由上图可以发现：

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

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

PS：权值即加权因子

4、调和不同的度量方法

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

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

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

如下图所示：

不同的语言中建造功能点所需LOC

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

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

七、软件质量度量

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的系统，它合格吗？

评论区留下你的答案~

（4）可用性

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

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

八、DRE

1、DRE的全称

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

2、衡量DRE的两种角度

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

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

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

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

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

如果这篇文章对你有帮助，记得留下star哦~