7.4.3 数据的有效性
需要制定过程度量以监视不断演进的系统，其中包括设计过程中的改动、在不同的回顾或测试阶段发现的错误等。使用严格定义的度量元来指定对软件质量和性能的要求，以便使这些要求可测试。例如系统必须“可靠”，可用如下更具体的文字加以描述“平均错误时间必须大于15个CPU时间片”。
最起码的要求，要能够证明用于描述一个属性的值真实地反映了该属性。例如，项目的估计起始/结束日期为2007/3/12—2007/4/30，而实际的起始/结束日期为2007/3/12—2007/5/8。项目确实是2007/5/8结束的，延迟了1天。如果没考虑五一放假7天，就以为项目延迟了8天。
7.4.4 数据的一致性
一致性难于确定。因为这意味着检查者要能够判定一致性，就必须充分了解以前记录的数据。不过要避免错误地分析，重要的时间差是否有异常或不可能的数据元素，并验证其正确性。如果定义或采集度量的方式不一致，则会导致分析无效。比如：按照日历月份报告的工作费用含有不同的工作天数。
因此，如果数据不一致，在数据收集的过程中会发现收集的数据前后对不上。
度量定义阶段追求完美，大量增加度量元，结果无法收集数据。这是一个非常常见的现象。在度量定义的过程中，总觉得这也要收集，那也要收集。有的公司，收集的项目多达300余项。实在搞不懂这些数据真正能起到多大的作用。因此，我们不仅要关注度量的理论性，更要关注度量的可收集性，“少而精”永远是我们的追求目标，宁缺毋滥。
从日常应用的体会来看，最难统计的是Effort（工时）。因为时间进度比较清楚，哪个开发阶段从哪一天开始，哪一天结束，通过Project工具可以一目了然；代码量可以通过SLOC工具统计出来总共多少行，多少注释行等；缺陷数，应用缺陷管理工具，也不难完成缺陷的统计。但是工时就难了：
一天工作8个小时，但是实际只做了4个小时。算一天，还是半天？
一天工作8个小时，结果加班到了晚上10点多，算12小时？
项目中有系统设计师、资深工程师、一般工程师，还有实习的学生，工时标准是否一律平等？
半夜两点钟在家里和到美国出差的上司通过Skype开了一个会，又给老美来回几封E-mail，是否算2点上班？
从以上实际例子可以看出，Effort的统计是不容易的。没有好的管理手段和统计机制，极容易得到虚假数据。当只有两三个项目时，可能还监管得过来，当同时有十几个以上的项目时，各种奇怪的问题和现象都会挑战度量的定义。
相关阅读：
版权声明：51Testing软件测试网获电子工业出版社授权连载《软件质量管理实践》部分章节，其他个人或单位未经许可，不得对本内容复制、转载或进行镜像。51Testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。
