昨天发了基于CMMI的软件测试以后，有人提出说法：
（1）验证对应需求规格说明，确认对应软件任务书，是不是可以这么理解？
（2）用户参与验证过程还是确认过程？
先说第一个问题，这种说法是不正确的，而且很片面。
昨天在文章中我说过，验证，是为了确认某一开发阶段的产品是否满足在阶段初期提出的要求而进行评估的过程；确认，是在开发过程中或结束时，对软件产品进行评估以确定其是否满足软件需求规格的要求。简单地讲，验证就是证明是否正确地构造了产品；确认则是证明构造的产品是否正确。
需要明确的是，无论验证还是确认，都是过程域，每个过程域都包含很多活动，不能简单地认为就是以某个文档来约束，为某个文档负责，这样考虑就太片面了。
以验证过程为例。在这个过程中，主要体现在评审活动上。例如需求阶段，最重要的产品就是两份文档，一份开发计划，一份需求规格说明。那么对这两份文档的评审就是验证过程。例如，软件概要设计阶段，最重要的产品就是概要设计和产品集成计划，那么这个阶段的主要验证活动就是评审这两份文档。到了编码阶段，还要对代码进行审查，甚至走查，也是验证活动。
而确认过程，是对软件产品的认可，主要体现在测试活动上。例如单元测试，这是对软件模块进行确认的过程，通过了测试，证明做出了正确的软件模块，ok，得到认可，确定版本，入受控库。同理，集成测试，是确认是否做出了正确的集成产品；配置项测试，是确认是否做出了正确的软件配置项。
所以，简单地说“验证对应需求规格说明，确认对应软件任务书”是非常不正确的。在实施CMMI的过程中，我们不能简单地从字面去理解内涵，否则很容易走错路。
接着，我们来讨论“用户应该参与验证还是确认过程”的问题。
在CMMI的每个过程域中，用户作为重要的利益相关方，原则上都可以参加。但是通常情况下，用户并不在意你的生长过程，更在乎最终产品。在实施CMMI的软件项目中，一般都会在软件声明周期中设置里程碑节点，并要求相关利益方参与里程碑会议，以通告本阶段工作进展，偏差如何控制，下一步如何开展。例如需求结束阶段，配置项测试阶段，通常都会设置里程碑节点。在未交付软件之前，比较忙的用户只需要参加里程碑节点即可。当然，如果用户不忙，不仅在乎结果，还在乎过程，那么全程都可以参与。
OK，That's all today。有问题欢迎来问，我们再讨论。
