度量分析
问题：
1.度量的目的是什么？
2.谁来做这个度量？
3.什么时候做这个度量？
4.如何做这个度量？
5.怎样记录度量的数据？记录到哪里？
6.谁会使用这些数据？
7.如何分析这些数据？
8.谁来分析这些数据？
9.分析的结果如何使用？
SG1: Measurement objectives and activities are aligned with identified information needs and objectives. 这个SG主要讲述的是，组织级要明确实际的需要，定出度量的目标，并根据此目标，定义合适的度量方法、过程等。
SP1.1: 建立和维护度量目标，这些度量目标是源自特定的需要的
Establish and maintain measurement objectives that are derived from indentified information needs and objectives.
如：质量、进度、成本是项目管理的三大要素，为了更好地管理这三个方面，可能需要分别对这些方面采取度量手段。也就是说，采取任何度量手段之前，要考虑清楚为什么要进行这个度量。
SP1.2: 制定度量办法满足度量目标的要求
Specify measures to address the measurement objectives.
明确了为什么要进行度量后，要把度量目标转化成可以实际操作的具体的度量办法。如：度量的目的是，要保证软件的质量，为了实现这么目标，定义出对缺陷进行度量、对评审发现的问题进行度量等度量办法。
SP1.3: 制定度量数据的收集及存储办法
Specify how measurement data will be obtained and stored.
SP1.4: 制定度量数据的分析和报告方法
Specify how measurement data will be analyed and reported.
SG2: Mesurement results the adreess identified information needs and objectives are provided. 这个SG主要讲述的是：根据组织级定义的要求，进行度量工作，收集、分析、存储、报告度量信息等。
SP2.1: Obtain specified measurement data.
收集指定的度量数据。
要根据SP1.3指定的收集办法来收集度量数据。
SP2.2: Analyze and interpret measurement data.
分析和说明度量数据。
根据SP1.4指定的办法，对度量数据进行分析，并说明这些数据的意义。
SP2.3: Manage and store measurement data,measurement specifications,and analysis results.
管理和存储度量数据、度量规范及度量结果。
根据SP1.3指定的存储办法，对度量数据及相关文档进行存储和管理。
SP2.4: Report results of measurement and analysis activities to all relevant stakeholders.
向相关人员报告度量结果及分析度量活动情况。
度量的数据、情况，需要让该知道的人知道。
SG1主要从组织级的角度定义度量的做法，SG2就是按照已定义的做法，在实际工作中开展度量的工作。
量化管理
初级量化管理-感知级，以数据“感知”项目的状况，相当于CMMI2级。
中级量化管理-经验级，通过经验值来管理项目，相当于CMMI3级。
高级量化管理-可预测级，用PCB进行项目管理，相当于CMMI4级。
超级量化管理-持续优化级，持续优化的量化管理，相当于CMMI5级。
“感知级”通过软件度量，大概了解项目的状况，并作为工作调整的依据。
“经验级”通过软件度量，对比项目的历史经验数据，把握项目的状况，并进行相应的工作调整。同时，项目的历史经验数据，可供估算等工作进行参考。
“可预测级”，把“经验级”推向一个更高的高度，对影响问题的因素进行详细的分析，排除和削弱影响项目性能的各种因素，对历史经验数据进行合理分组，统计出性能基线，并用于项目管理。用基线来管理的过程都是稳定的过程，这些过程从统计角度来说都可以准确地预测出将来的结果。
“持续优化级”是“数据管理过程”的最高级别，达到这个级别意味着企业能根据商业目标持续的优化SPC管理，使企业形成别的企业难以模仿并难以超越的核心竞争力。
如果你无法度量它，就无法管理它
CMMI级别中和BUG率相关的信息
| CMMI级别 | BUG率 |
|---|---|
| CMM1级 | 11.95‰ |
| CMM2级 | 5.52‰ |
| CMM3级 | 2.39‰ |
| CMM4级 | 0.92‰ |
| CMM5级 | 0.32‰ |
考核千行代码Bug率的问题
从考核标准上来说，Bug率数值越小就说明越好，基于这个结果，会引导团队成员做出一些对长远和整体效率无益的行为，例如：
增大基数，增加无意义代码
把定长循环分开写，写成顺序方法
把可配置信息写死到代码中
大量的复制、粘贴代码
重新发明各种轮子
统计“千行代码Bug率”和“每日生产代码行数”一样，都是没经过大脑思考，而直接打算把优秀员工踢出团队的懒人式管理方式。特别是对从事智力型工作工程师来说，是很不合适的考量指标。
优秀的程序员是通过减少代码行数来增加功能的。
千行代码Bug率，虽然没有明确鼓励增加代码行数，但是这个计算结果对于优秀的员工来说是相当的不公平。它隐含的推广了“尽量增大代码行数”这个意思。
其次，从考核阶段看，Bug率的数据主要产出在研发阶段的后期，及提交测试后产出bug数。从项目的研发阶段和效率价值金字塔来看，其对项目的整体质量方面更多的聚焦在微观层面问题，整体的质量的影响范围会较小。而前面几个阶段的缺陷，会影响整个项目的进度，甚至导致项目失败，管理者和团队更应该将风险控制和度量指标向前移。
研发阶段和效率价值金字塔
需求调研和评审>技术方案设计和评审>研发>测试
如何更合理的度量质量
如果考核千行代码Bug率不能很好的解决质量核心问题，那我们还有那些方法和方案来提高项目的整体质量呢？
个人觉得，我们还是从项目的研发阶段和效率价值金字塔出发，重整体上去把控质量，上下游一体，从源头开始：
需求的评审
架构设计方案评审
代码模块设计，包的依赖的规划，接口的设计的review
代码的review的机制
测试用例评审
使用代码检测工具，自动发现问题
过程评审是最有效也是成本最低的质量和效率保证和提升的手段。另外，过程评审还是迅速提高新人能力及其成果物的规范性的一个有效手段。
但是过程评审，也存在一些问题：
前期过度依赖于团队的人员素质
规则的定义也比较难，产出不好量化
评审耗时多
团队的意识不一致
过程评审的实施核心在用统一团队意识
团队意识不一致时，效果一定不好。 意识不一致，在资源的投入上就会缩手缩脚；只有把过程评审做到位，才能体会到评审活动的高效，避免那种走马观花式的“评审”，是浪费时间，不是真正的评审。过程中辅以严密的变更管理和风险控制手段，系统质量出大问题可行性会很小或者近乎为零。
系统质量是要靠上游工程做出来的
上游的工作质量会更为重要，上游的问题的影响范围将更广，对效率和价值的影响更大，应该是我们重点关注的地方。仅仅依赖下游工程(种种测试)来把质量关，是十分低效，而且代价是非常昂贵的。
总结
有效的管理很难绕开度量问题。在选择度量指标上，大部分管理者总是倾向于关注容易度量的指标，而忽略难以度量的指标。但是容易度量的指标不一定是重要的，难以度量的反而可能是重要的。
定性、定量的区别比较，定性是用文字说话，定量是用数字说话，两者侧重点不同，但各有各的好处。虽然已经量化了，但数据有时也可以骗人，量化是一种方法和手段，但并不是最终的目的。
代码行数<>价值。
考核不合理导致出现大量的复制，不合理的设计，大量的冗余，不但难以理解和维护，甚至没有实际运行起来。这样就造成大量的时间浪费，同时也造成质量的严重腐化。
而基于全过程的评审机制和持续改进方法，可以很好的改善质量。但持续改进需要一个过程，需全团队从认知达成一致，并共享问题，统一步调和规范，持续的执行和改进。
千行代码Bug率比较适用工程师自身自我评估和改进
1.进度方面
实际进度的计划进度的偏差情况，Gantt图和Pert图。
返工时间占项目总时间的比例情况
项目能够容忍的最大的处理变更的时间
三级强调了偏差的范围，四级强调严格的上下限控制(控制图)
2.工作量
实际工作量和计划工作量的偏差
三级增加对好质量成本和坏质量成本相关工作量的度量(COGQ,COPQ)
对项目返工，评审，测试和处理变更工作量的分别度量
3.成本
计划成本和实际成本的偏差
三级强调了成本和进度的性能指示器(挣值分析)
三级强调了偏差的范围，四级强调严格的上下限控制(控制图)
五级强调了会提供可选择的过程改进和缺陷预防策略供选择，而这个是在对项目的成本和效益做了比较和平衡后得出的。
4.软件质量保证
不合格项的信息
SQA具体的审核信息
5.Review的结果
Review的活动项的状态
6.问题报告
问题项的具体状态(打开,处理,关闭)
问题的原因的分析，对问题的分类的统计
问题的平均处理周期度量
7.同行评审和缺陷
同行评审的缺陷的打开和关闭的情况统计
缺陷密度
缺陷移除率和缺陷泄漏率
同行评审的效率，评审速率的度量
同行评审的覆盖率
四级强调对缺陷分类后的帕累托分析
四级强调对同行评审的关键特征项的控制图分析
8.需求的度量
需求的规模的情况
需求的稳定度或需求的变更率
需求变更的不同类型的分布情况
需求变更处理的效率和周期度量
9.培训
实际安排课程和计划课程的对比
实际参与人员和计划参与人员的对比
对培训的成本和花费的度量
对培训取得的效果的度量
10.测试过程
测试的生产率的度量
测试规模的度量
对测试BUG的分类后的帕累托分析
生命周期不同阶段发现缺陷的数量分布，泄漏情况
测试BUG的密度
基础度量：
• 工作产品规模大小的估计及实际度量*(例如：页数)*
• 人力与成本的估计及实际度量*(例如：人时)*
• 质量度量*(例如：缺陷数、依严重程度区分的缺陷数)*
衍生度量：
• 挣值*(Earned Value)*
• 进度绩效指标*(SPI)*
• 缺陷密度
• 同行评审涵盖度
• 测试或验证涵盖度
• 可靠度度量*(例如:平均失败时间)*
• 质量度量*(例如：依严重程度区分的缺陷数/总缺陷数)*