CMMI2.0：验证和确认VV&同行评审PR

验证和确认（VV)

在CMMI1.3版本中验证（VER）和确认（VAL）是两个过程域，2.0版本中对两者进行了合并形成了新的实践域VV（验证和确认），同时将之前验证过程域中的同行评审活动单独形成了一个实践域PR。虽然将之前的验证和确认两个实践域进行了合并，但不代表验证和确认的工作也合并了，它们各自要做的事情，一个都不能少。

很多企业都会把这个实践域搞混，理解上容易产生错乱，今天我们就说一说验证与确认。

在软件开发过程中，持续地关注并有效地执行验证与确认是基本的原则。验证和确认是互补的，也是缺一不可的。

验证更多偏重中间过程的正确性，其目的是确保所选择的工作产品满足指定的需求，例如：验证设计时需要对照需求，验证代码时需要对照设计等。

确认则更多偏重客户的原始需求，也就是我们常说的用户需求，其目的是确保最终结果的正确性。例如：在最后的客户验收阶段，客户需要对照的早期需求报告，需求承诺等等。

通过上述描述，我们会发现验证和确认在实施目的、关注重点、检验参照物上均有所不同。另外，在采用的检验方法上也有所区别，验证的方法可以包括：需求梳理，需求评审，设计评审，代码评审，单元测试，集成测试，系统测试等。确认的方法包括：原型、模拟、验收测试、用户反馈、试运营等，以上几点就是验证和确认的重要区别所在。

什么是验证？验证是提供客观证据对比之前确定的标准，相关活动主要偏内部，最终目的是获得满意的结果。“验证”处理的是工作产品是否适当地体现了规定的需求。对于软件开发来讲，就是要用数据证明我们是不是在正确地开发产品，强调的是过程的正确性，如：测试软件，要检查的东西就是软件本身，检查的标准就是软件需求规格说明，包含功能说明，性能要求，接口等，用检验的方法来检验某个结论是否正确。

“验证”包括按照所有约定的需求，对最终产物和过程工作产物进行的验证，例如：约定的需求包括客户需求、接口需求、产品需求。验证本身是一个增量式的迭代过程，因为它贯穿产品与工作产品开发的整个过程，始于对需求的验证，终于对完整产品的验证。实践是检验真理的唯一标准，验证的目的就是执行检验和证明的过程，最终目的是用实践来检验理论，证明之前既定的假设、确定的要求是否成立。

什么是确认？确认是通过提供客观证据对比预期用途，相关实践主要偏外部，最终目的也是获得满意的结果。

“确认”证实产品在被提供时能满足其预期的用途，软件开发来讲就是要用数据证明我们是不是开发了正确的产品，强调的是结果的正确性。确认软件产品在客户环境上是否达到预期的目标，正常活动包括调试、客户的验收测试等，这些工作都是要求软件产品必须能够在客户真实执行环境上进行的，最终的目的是确保软件符合使用要求，是从最终用户的角度或者能模拟最终用户角度来验证产品是否和需求一致。

确认的真实意图不是用来检验理论的正确性，而是通过检验判断目前的执行结果是否达到预期，需求是否被有效的实现，是对执行力的检查，简单理解就是“眼见为实“。

验证与确认都是确定软件产品是否满足其预期要求和条件的检查。验证可适用于分析、设计、编码、测试等众多的过程，而确认通常用于最后的验收过程。通常我们选择验证和确认的产品包括需求、设计、代码、测试等文档，2.0模型中还特别强调了接口、培训材料、供应商货品等也都是需要验证和确认的内容。

总而言之，验证是确保“正确地做了事”，而确认是确保“做了正确的事”。验证确认有助于确保采用系统化的方法来选择将要测试的工作产品、将要搭建环境、将要管理的接口，有助于确保尽早识别并处理各类缺陷。项目规模越大，复杂度越高，越需要使用系统化水平高的方法来确保需求与解决方案之间的相容性，以确保项目最终满足最终用户的使用需求。

同行评审（PR)

同行评审是2.0版本新增的实践域，是从V1.3版本验证（VER）中剥离出来的，强调了评审可以发现几类问题：与工作产品相关的缺陷；绩效或功能问题；与过程相关的问题；成本、风险、进度问题。

同行评审是软件质量保证的重要手段，它几乎贯穿了整个软件生命周期。通过同行评审能够及早发现并纠正工作产品中的问题，降低成本和返工。其目的是为了及早和高效地从软件工作产品中识别并消除缺陷，让软件变得更健壮和更易维护，同时减少产品发布时的遗留缺陷，最终达到降低缺陷率。

在评审环节首要任务就是发现工作产品中的各种缺陷，例如代码的，文档的，数据的等。再通过对这些缺陷进行数据分析，发现缺陷产生的根源及主要原因，通过从开发过程中的反馈和错误中汲取教训，以便将来避免类似的缺陷和问题再次发生。

常规的同行评审包括：正式评审、技术审查和走查。"正式评审"是正式的，后两者是常用的非正式的同行评审方法。正式评审、技术审查和走查三种形式的同行评审的重要程度不同，目的、评审时间、准备、主持人、参与评审人员等不完全相同，应当严格遵循其流程、步骤和注意事项进行同行评审，以保证同行评审的有效性。要努力吸取经验教训，避免同行评审中的常见问题，如文化问题、准备问题、效率问题等。

成功的同行评审是提高质量和生产率的重要因素，审查过程会迫使每个人在一种开放式的环境中工作。慢慢员工懂得了同行评审的价值就会欣然接受同行评审，就会将他们的工作做得细致，以待监督。

有的人可能会有疑惑，准备一个同行评审也需要耗费大量的人工和时间成本，是否值得投入？根据数据统计，一套完整的同行评审体系能够使项目在每个测试阶段出现的错误减少了90%。整体来看，即使在综合考虑了同行评审活动成本的情况下，同行评审活动也会使测试成本下降50%～80%。

在同行评审上的投入可以将后期测试及变更的大量返工成本尽早的转变为早期发现的缺陷，大大降低实施成本，更重要的是使得项目开发过程中的每一个员工学到了如何将工作做得更好。

在软件类项目中，重要评审对象包括：项目计划书，需求规格书，概设/详设的设计书，测试用例，代码等等。这些在每个结点中重要的产出物我们势必都要纳入到正常评审的范围，同时在评审计划中我们需要定义清楚评审的时机和退出准则。例如对项目计划书的评审，首先需要项目经理完成计划书，再提出申请。退出准则可以是达到某一个准则，例如评审发现的缺陷控制在某一个阈值内，再者结果超过了阈值，需要定义二次评审等等。

最后，根据经验谈一谈怎么样会让评审做得更有效：

• 首先，需要管理者的足够重视，不要使得评审变成形式主义，这样反而得不偿失。

• 在评审开始之前评审者和参与者都要提前做好准备，例如提前发放材料，提前批注，提前准备问题，提前计划怎么阐述等，做到心中有数。

• 要控制会议的时间，有的评审会一搞就是半天，搞得参与人员精神疲惫，评审会议尽量控制在1-2小时之间为佳。

• 选择的参与人员要合适，是否有能力给出意见，不要太官僚，甚至因为某些领导的意见不敢发音，评审会议不能变成一言堂。

• 评审形式也需要根据评审内容进行合适的选择，什么时候正式评审，什么时候走查等等，所有的缺陷最终都应追溯到需求，务必从根源上进行解决。

• 软件开发人员应避免检查自己的程序，尽可能采用同行交叉评审，程序中的大部分错误往往是在一小部分模块中发现的，遵循普遍适用的"二八定理"。

• 缺陷的修复和完善工作中，要充分注意问题解决带来的关联问题的产生。

• 做好评审活动的度量工作，评审活动一般需要花费较多时间，所以评审活动的度量会变得尤为重要，我们可以通过度量数据和结果反向对评审的相关流程进行优化，一般在评审度量上我们需要关注以下方面：每类评审会议的工作量，每个人投入的工作量，评审会议发现的问题，每个人发现的问题数，个人和整体评审的效率，以及评审文档或代码的规模等等。

中国人常说：“人非圣贤，孰能无过。神仙打鼓，也会出错。”在项目和产品开发过程中出错不可怕，重要的是需要我们掌握正确的、行之有效的方法和措施进行妥善处理，最终定会以最小的成本和代价投入，获得最大的价值和收益！ 

——————————————————————————————

作者：赛希咨询 

https://www.bilibili.com/read/cv16912079/?from=search&spm_id_from=333.337.0.0 

出处：bilibili

声明：本文系转载，版权属于原文作者，如有疑问请联系删除。