CMMI on line

这两个东西稍难理解和区分，中文翻译是验证和确认，比较绕口。

验证：验证检查某样东西是否符合之前已定好的标准，如：文档评审，要检查的东西是文档，检查标准就是文档的评审标准，又如：测试软件，要检查的东西就是软件，检查的标准就是软件的规格说明，包括功能说明，性能要求等。

确认：检查软件在最终的运行环境上是否达到预期的目标。一般来说，就是调试、验收测试等，这些工作都是在真正的软件需要运行的环境上进行的，在最终环境上运行软件，确保软件符合使用要求。

CMMI中专门有验证(Verification)与确认(Validation)两个PA来描述这两方面的要求。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

真是多谢楼主，正搞不清楚这2个东东，现在明白了！

如果将验证理解为同行评审+集成测试+系统测试，将确认理解为验收测试是否正确？

完全正确！而且很精辟、易懂！

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

其实Valiadation更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想要的一致。而Verification更多的是从开发方的角度来做评审、测试来验证产品的需求、架构设计等方面是否和用户要求的一致

oric:

其实Valiadation更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想要的一致。而Verification更多的是从开发方的角度来做评审、测试来验证产品的需求、架构设计等方面是否和用户要求的一致

我觉得从这个角度理解要更好一些，限定在某些特定的方法上可能会导致理解上的混乱。

Verfication

    Are you build the product right

Validation

   Are you build the right product

这个就是英文的原文，我想我们每个人看了都会傻掉，确实很难懂，而且仁者见仁

我的非常简单的理解就是Ver可以是我们认为的评审，Val可以认为我们做的测试，从SP来看也好像也可以这么理解。

比较赞同这个说法：

Valiadation更多是从用户的角度或者可以是模拟用户角度来验证产品是否和自己想要的一致。从SP来看可能更容易理解这个；

Verification更多的是从开发方的角度来做评审、测试来验证产品的需求、架构设计等方面是否和用户要求的一致；

有个小问题：我们的代码走读算什么活动呢？

 

代码评审是属于同行评审，属于Verification，见VER的SG2：
SG2 Peer reviews are performed on selected work work products.
对指定的工作产品进行同行评审。

VER参见：
http://cmmionline.net/forums/thread/234.aspx

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

我个人认为： 

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

这里有个疑问，

“计划评审、设计评审、代码评审等是属于“验证”的，这些工作是检查产品是否正确的，而不是检查我们的制作过程是否正确，检查制作过程是否正确是QA的职责。”

这些评审不是应该用来检查制作过程是否正确的么？还是说评审这个活动本身是SEG做的，而SQA是检查这些活动的？比如说计划也是活动，评审计划也算是检查这个活动的，或者说SQA做的是检查这个计划制订过程，而SEG做的是评审这个计划的结果？这里该如何理解呢？

按照SQA，SPEG和SEG三者独立的说法，测试的工作应该是属于SEG的，我的理解测试是项目组的一部分，而SQA则是检查所有项目组的过程的。

这些问题似乎越说越复杂了。

VER和VAL是针对SEG来说的，QA只检查是否按过程做了，工作产品是否按模板来做等内容。

评审计划时，有很多角色来参与，SEG参与，目的是检查内容是否合适，做的工作就是VER的工作，而QA参与，目的是检查有没有按过程要求来进行评审，不评价工作产品的具体内容，这是QA做的工作就是QA的工作。

测试的工作是应该属于SEG的。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

谢谢张总，我想得太多了，您讲得很清晰

如果接受了一个外包项目，任务是根据客户提供的测试用例和功能模块完成模块测试，并提交测试结果报告给客户。

请问在这个项目中，哪些活动可以被认为是确认，哪些活动可以被认为是验证？

这确实是一个问题，在我的实际工作中没有碰到过。

确认的过程，可能是由客户在自己环境中进行的，这样可能取不到确认的一些证据。

有以下的建议：
1.客户自己确认工作，可能也会留下一下证据，如你们跟客户沟通的邮件、系统验收的证据等。
2.重新定义你们的确认和验证到底是什么，有可能你们“根据客户提供的测试用例和功能模块完成模块测试，并提交测试结果报告给客户”就可以认为是确认。
3.这个项目可能太简单了，没有代表性，不能拿来做评估项目。

和你们的咨询师和主任评估师商量一下，他们经验很丰富，应该遇到过这样的情况，看看他们的意见。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

谢谢版主的建议。作为外包公司，我们很多项目都和这个类似，项目过程过于简单，试行CMMI有一定的困难，我们也正在摸索的过程中。

 请问：和客户一同进行需求文档的评审，属于Verification还是Validation呢？

这种情况一般既不是VER也不是VAL，是属于RD的：
SP 3.5: Validate requirements to ensure the resulting product will perform as intended in the user's environment using multiple techniques as appropriate.

一般来说和客户确认需求的时候，会用各种办法，让客户在“模拟的目标环境”中 确认这些需求，用到的办法可能有原型、画图、讲故事等等。
从这点看，很象VAL。不过我们进行评估的时候，主任评估师说这部分内容一般不对应到VAL，因为RD的SP3.5就是这些内容，而VAL一般是只最终产品的确认，当然在两个地方都体现这点是没有问题的，但没有必要。

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx

虽然验证(VER)和确认(VAL)都是指对于某个过程(process或subprocess)的工作产品(work product)的审查(review)。但是其时间点和目的都不同。对工作产品的质量而言，两者都不可或缺。

验证是看是否按照需求把工作产品做好，其审查应该在工作产品交付之前完成；
确认是看工作产品是否符合使用者的期望，做出对的工作产品，其审查在工作产品交付之后才进行。

试着从两个连续过程的互动观点来做进一步说明：
所谓两个连续的过程是指前一个过程所产生的工作产品(输出)会成为后续过程的工作产品(输入)。前一个过程的当事人是该工作产品生产者；后一个过程的当事人是该工作产品使用者。
例如分析和设计就是两个连续的过程，分析过程的输出会成为设计过程的输入。分析师是分析过程之工作产品的生产者；设计师则是分析过程之工作产品的使用者。

验证是在分析过程结束之前，分析师委请同侪对工作产品的审查(peer review)；
确认是结束分析过程之后，分析师将工作产品交付给设计过程，由设计师做验收确认审查。

 

精辟的讲解，让我认识更多更深了，谢谢！

---

CMMIonline 版权所有
欢迎转载，但请给出指向本网站的链接：
http://www.cmmionline.net
版权声明见：
http://cmmionline.net/forums/thread/1340.aspx