记录督促学习28

程序审查是“同行评审”团队成员合作来发现开发程序中的漏洞。审查可以作为软件检验和有效性验证过程的一部分，因为它们不要求执行程序，所以它们和测试互补。
这就表示能够验证系统不完整的版本，并且能够检查像统一建模语言模型这样的表示法。

一种使用审查最有效的方法，就是复查系统测试用例。审查能够发现测试的问题，并且提升这些测试检测程序错误的有效性。

程序审查设计来自不同背景的团队成员，他们对程序源代码进行精心的、一行一行的复查，他们寻找错误和问题，并且在审查会议中描述出来。
错误可能是逻辑错误，也可能是代码中的异常，这些异常可能表明了错误情况或者代码忽略的特征。

审查时，经常使用一份常见编程错误的检查表。
这个检查表基于的是来自书本的实力和个别应用领域的错误经验。

在审查过程中可能做出的检查，强调每个机构都应当根据部门标准和实践开发自己的检查表。由于不断发现新的错误类型，这些检查表经常更新。

大多引入审查的公司发现它们在发现漏洞方面是非常有效的。

很多软件开发公司还是不情愿使用审查或者同行评审，有程序测试经验的软件工程师有时会不情愿接受关于审查会比测试在发现错误方面更有效的观点。

敏捷过程很少使用形式化的审查和同行评审过程，但是，他们依赖于团队成员合作来检查每一个其他成员的代码，也信封非正式的实用准则，比如“提交前检查”这表明程序员应该检查他们自己的代码。

配对编程会使人员对程序有一个深入的了解，因为两个程序员必须理解它的工作细节才能继续开发。
相关人员不能跟外部检查团队那样客观，他们发现错误的能力很可能因为亲密工作关系减弱。

软件度量就是对软件组件、系统或过程的某种属性进行量化。在得到的数据之间以及数据和机构的通用标准之间进行比较，就可以得出有关软件质量或评估软件过程有效性、工具和方法有效性的结论。

软件度量的长期目标是利用度量代替复查来对软件质量进行评判。

软件度量是能够被客观度量的软件系统、系统文档或开发过程有关的特性。
软件量度要么是控制量度要么是预言者量度。

无论是控制量度还是预言者量度，都能影响管理决策的制定。使用预言者量度来估计软件变更所需要的成本。
软件产品量度的两种方法：
1给系统质量属性赋值。
2找出质量低于标准的系统组件。

内在属性的度量能否对外部的软件特性做出有益的预测取决于：

1内在属性必须被精确度量
2在能够度量的属性和我们感兴趣的外部质量属性之间必须有一定关系。
3内部属性和外部属性的关系必须是可理解的、可验证的、能用公式或模型表达出来。

软件的内在属性，比如组件的环路复杂度，使用分析软件源代码的软件工具来度量。

系统地度量比较困难主要是因为：

1引入一个机构量度程序在投资回报是无法量化计算的。
2现在还没有软件量度标准，或是没有标准化的度量和分析过程。
3软件过程是非标准的，没有很好定义也是很难控制的。
4许多关于软件度量和量度的研究主要侧重于基于代码的量度和计划驱动开发过程。。
5一如度量增加了额外的开销。这和敏捷开发目标违背。

软件度量和量度是经验软件工程的基础。

产品量度 续