如何提升(软件)交付质量 大家可先看看下面 Xerox 公司的缺陷统计数据

缺陷修复成本是越后越高，而且以倍数递增， 所以 软件工程有个重要原则，尽量第一次就把工作做好 (do it right the first time)，减少返工。

所以从软件质量管理，我们要：

尽力避免在整个开发过程中产生缺陷

如果有缺陷产生，要尽早排除。例如：瀑布性开发过程 - 要做需求评审，设计评审，代码走查 ， 单元测试

在过程中收集不同阶段发现的缺陷数，两个目标：a)把总的缺陷降低；b)把缺陷的高峰尽量往前推

下面首先会先介绍 CMMI V2.0 PR 与 VV 的 Practice 如何一一对应 以前 V1.3。

接着用一些实例解答如何从1级升到2级再升到3级，量化管理等的常见问题：

从1级升到2级：我们做好测试，有系统测试，有QA保证不就可以了吗，为什么要花精力做评审，尤其现在讲究敏捷、简单，评审是否已经过时？

为什么要把在评审中发现的问题记录下来并跟踪，让成员自发完善不是更省事吗？

为什么要有固定的测试环境？为什么重要？

为什么极少公司能做好量化管理？收集哪些数据？成功要素是什么？

量化管理、度量，为什么要统计？自己依据发现的问题改好是否也可以？统计出来的数据应该如何有效利用才对整个团队的提升有帮助？

例如：有效的量化管理必须依据有效的公司目标驱动,后面的金融产品开发组的量化管理例子告诉我们 - 除了要度量公司关心的结果外，也需要度量一些可控因素，才能更好帮我们改善。

最后以 ‘质量之旅’总结，让大家了解质量改进的路径图，与不同成熟度的差异。

整个讨论也对应CMMI V2.0 模型 的 ‘同行评审 PR’与 ‘验证确认(V&V)’各实践

目录  

PA介绍

PR 1.1对工作产品进行评审并记录问题

VV 1.1执行验证来确保需求得到实现并记录和沟通结果

从1级升到2级：同行评审案例分享

PR 2.1开发并持续更新用于准备和执行同行评审的程序与支持材料

PR 2.2选择要进行同行评审的工作产品

VV2.1 选择用于验证和确认的组件和方法

Agile Tips 敏捷又如何

PR 2.3使用既定程序准备和执行选定工作产品的同行评审

PR 2.4解决同行评审中发现的问题

VV 2.2开发,使用并保持更新支持验证和确认所需的环境

VV 2.3制定、保持更新并遵循验证和确认程序

3级：从定性提升到度量与分析

与一金融产品开发组长对话

度量可控因素

PR 3.1分析从同行评审得到的结果和数据

VV 3.2分析和沟通验证和确认结果

VV 3.1制定、使用并保持更新验证和确认标准

质量之旅

附件1：敏捷团队如何有效利用度量数据分析

附件2：Inspection审查

反馈

References

PR (V2.0)

VV (V2.0)

VAL (V1.3)

VER (V1.3)

CMMI V2.0从V1.3特别抽出“验证”(VER) 中的第二目标“同行评审”作为一个单独的PA。 可见CMMI也认同同行评审确实可以帮助项目预早找出缺陷和问题，减少后面的返工。

在V2.0， 同行评审的大部分实践属于CMMI 2级 (分析部分属于3级)。以前在V1.3，“验证”(VER)，包括同行评审，和 “确认”(VAL) 都属于 3级，工程部分。

2.0版本和1.3版本的对应：

V2.0 对应 V1.3

什么属于 验证(VER) 或 确认(VAL) ， 一直有很多争议 (我确实见过 一些开发公司 V V 的 定义 与 CMMI 的定义刚刚相反)

V1.3 的 VER 与 VAL 本来就很相近： 如果把VER 的 中间第二部分抽出来， V 与 V 的内容基本一致：

PR 2.1 2.2