CMMI3同行评审详细过程定义
CMMI3全过程域翻译讲解
1CMMI GG2制度化已管理的过程institutionalize a managed process: The Process is institutionalized as a managed process.制度化已管理的过程：将过程制度化为一个已管理的过程。
GP2.1建立组织纺方针Establish and maintain an organizational policy for planning and performing the project planning process.建立和维护一个组织级方针来规划和执行项目策划过程。
GP2.2规划过程Establish and maintain the plan for performing the project planning process.建立和维护执行项目策划过程的计划。
GP2.3提供资源Provide adequate resources for performing the project planning process, developing the work products, and providing the services of the process.提供充足的资源来执行项目策划过程，开发工作产品和提供过程服务。
GP2.4分配职责Assign responsibility for performing the process, developing the work products, and providing the services of the project planning process.分配项目策划过程的职责和权力来执行过程、开发工作产品和提供过程服务。
GP2.5培训人员Train the people performing or supporting the project planning process as needed.按照需要培训人员来执行或支持项目策划过程。
CMMI3级18个过程域
CMMI3级过程域一共有18个PA，分别是：过程管理1、OPD：（Organizational Process Definition）组织级过程定义。
建立和维护有用的组织过程资产。
2、OPF：（Organizational Process Focus）组织级过程焦点。
在理解现有过程强项和弱项的基础上计划和实施组织过程改善。
3、OT：（Organizational Training）组织培训管理。
增加开发人员的技能和知识，使他们能有效地执行他们的任务。
项目管理：4、PP：（Project Plan）项目计划。
保证在正确的时间有正确的资源可用。
为每个人员分配任务。
协调人员。
根据实际情况，调整项目。
5、PMC：（Project Monitoring and Control）项目监督与控制。
通过项目的跟踪与监控活动，及时反映项目的进度、费用、风险、规模、关键计算机资源及工作量等情况，通过对跟踪结果的分析，依据跟踪与监控策略采取有效的行动，使项目组能在既定的时间、费用、质量要求等情况下完成项目。
6、SAM：（Supplier Agreement Management）供应商协议管理。
旨在对以正式协定的形式从项目之外的供方采办的产品和服务实施管理。
7、IPM：（Integrated Project Management）集成项目管理。
根据从组织标准过程剪裁而来的集成的、定义的过程对项目和利益相关者的介入进行管理。
8、RSKM：（Risk Management）风险管理。
识别潜在的问题，以便策划应对风险的活动和必要时在整个项目生存周期中实施这些活动，缓解不利的影响，实现目标。
工程管理：9、REQM：（Requirements Management）需求管理。
需求管理的目的是在客户和软件项目之间就需要满足的需求建立和维护一致的约定。
10、RD：（Requirement Development）需求开发。
需求开发的目的在于定义系统的边界和功能、非功能需求，以便涉众（客户、最终用户）和项目组对所开发的内容达成一致。
CMMI3_介绍
导言
课程目标：使公司人员初步了解CMMI3级 课程主要内容：CMMI3级基础知识及练习题 课程适用人群：全体员工 培训达标的标准： 课后练习题能够解答正确； 通过最终考核；
课程大纲
CMMI介绍 CMMI的意义 公司实施CMMI3级的计划
CMMI介绍
CMMI介绍
CMMI分为5个等级
量化管理级 分析对软件过程和产品质量的详细度量数据，对软件过程 和产品都有定量的理解与控制。管理有一个作出结论的客 观依据，管理能够在定量的范围内预测性能。 优化级
过程的量化反馈和先进的新思想、新技术促使过程持续不 断改进。
CMMI介绍
CMMI介绍
CMMI介绍
CMMI介绍
能力等级介绍
2：Managed（管理级） 已管理的过程除了得到执行外，还需要得到计划，并且按 照组织方针来进行实施，相关的人员得到与执行有关的培 训，为了过程的执行，分配了相关的资源，生成的工作产 品受到控制。 利益相关的方面都参与了过程的执行，并且进行了相关的 评审以及过程符合度的验证。 管理层关心过程的制度化状况以及过程的其他目标，例如 成本、进度和质量目标。
CMMI介绍
过程改进的价值
4.improved quality (as measured by defects) （质量） 5.increased customer satisfaction （客户满意度） 6.improved employee morale （士气） 7.increased return on investment （投资回报率）
1.过程评估的检查单 2.过程改进的指导书，行业最佳实践 3.过程审计的依据 4.方法论 CMMI不是过程，是检查单，是方法论。
CMMI3级过程培训讲义
二、角色和职责
EPG – 负责组织建立和维护OSSP（Organization’s Set of Standard Processes)。 项目经理 – 参加《生命周期模型描述》、《组织标准过程裁减指南》的评审和改进活动，并 在所负责的项目中按照《组织标准过程裁减指南》选择该项目的过程。 过程数据库使用人员 – 参与过程数据库系统需求的收集和《过程数据库使用管理规范》评审工作。 过程财富库使用人员 – 使用过程财富库，实践标准过程，提出改进建议并推动所实施过程的改进。 财富数据库管理人员： 财富数据库管理人员： – 负责管理财富数据库，定期提交配置报告。 PPQA – 负责评审和审核组织过程定义活动的规范性。
36
参考： 参考：过程管理类基本过程关系图
37
谢 谢！
38
实现通用目标2：制度化为受管理过程 ： • • • • • • • • • • 2.1 为策划和执行“组织标准定义”过程制订并维护组织方针 2.2 为执行“组织标准定义”过程建立并维护需求、目标和计划 2.3 提供足够的资源 2.4 分配责任和权限 2.5 必要时，对执行或支持“组织标准定义”过程的人员进行培训 2.6 管理配置项 2.7 按计划确定“组织标准定义”过程的相关共利益者并使之介入 2.8 对照计划跟踪和控制本过程，采取适当的纠正措施 2.9 客观地评价过程遵循情况，处理不符合问题 2.10 高级管理者审查过程活动、状态和结果，并解决问题 7
通用目标
– 实现特定目标。
– 制度化为受管理过程（2级） – 制度化为已定义过程（3级） – 制度化为定量管理过程（4级） – 制度化为持续优化过程（5级）
5
CMM&CMMI对该过程描述（2） 对该过程描述（ ） 对该过程描述
cmmi3级认证条件
cmmi3级认证条件
CMMI（Capability Maturity Model Integration）是一种过程改进方法，用于评估和改进组织的软件和系统工程过程。
CMMI 3级认证是指组织在CMMI评估中达到的第3级成熟度。
CMMI 3级认证的条件包括以下几个方面：
1. 了解和执行过程定义：组织需要有明确定义的软件和系统工程过程，并确保员工了解并按照这些过程执行工作。
2. 量化过程绩效：组织需要采集和量化过程绩效的数据，以便评估工作的进展和效果。
3. 快速纠正不良趋势：组织需要能够及时发现和纠正不良趋势，以确保过程及时调整和改进。
4. 风险管理：组织需要具备有效的风险管理机制，能够识别和管理项目和过程中的风险。
5. 强调过程改进：组织需要持续关注过程改进，通过不断改进和优化过程来提高工作效率和质量。
6. 组织学习和知识管理：组织需要建立知识库和学习机制，以便员工能够共享和应用组织内部的经验和知识。
以上是一些CMMI 3级认证的条件，但具体要求还需要根据CMMI 评估模型的要求进行具体确定。
cmmi3管理体系
cmmi3管理体系CMMI Level 3：提升组织管理体系效能的关键步骤CMMI（Capability Maturity Model Integration）是一个用于评估和改进组织开发和管理过程的标准模型。
CMMI Level 3是CMMI评估中的一个重要里程碑，表示组织已经实现了一定程度的过程标准化和持续改进。
本文将探讨CMMI Level 3管理体系的关键步骤。
首先，实施CMMI Level 3的关键是建立一个可追溯性的过程框架。
这个过程框架包括开发、交付、维护和支持等一系列共享的最佳实践。
通过明确定义和记录这些过程，组织可以确保各个部门和团队在开展工作时能够按照统一的标准进行操作，从而提高工作的一致性和质量。
其次，关键的步骤是启动跨部门的沟通与合作。
实施CMMI Level 3需要各个部门之间的密切协调和合作。
通过定期召开沟通和协调会议，促进信息共享和经验交流，可以帮助不同团队之间建立良好的合作关系，并确保整个组织能够形成一个高效的工作团队。
第三，持续改进是实施CMMI Level 3的核心原则。
持续改进是一个迭代的过程，通过不断评估和审查已有的工作过程，并根据评估结果提出改进方案，组织可以逐步提高其管理体系的效能。
在这个过程中，组织应该鼓励员工提供反馈意见，并对提出的意见进行积极回应，以便不断推动管理体系的进一步改进。
最后，成功的CMMI Level 3实施需要领导层的坚定支持。
领导层应该给予足够的资源和重视，同时树立榜样，引领组织朝着卓越的管理体系目标迈进。
此外，领导层还应该促进并培养组织文化，强调质量和持续改进的重要性。
总之，实施CMMI Level 3需要建立一个可追溯性的过程框架，促进跨部门的沟通与合作，持续改进，并获得领导层的坚定支持。
这些关键步骤的合理执行将有助于组织提高管理体系的效能，实现持续的质量改进和在市场竞争中的优势地位。
CMMI3级18个过程域
CMMI3级18个过程域CMMI（Capability Maturity Model Integration）是一种用于评价和改进组织的软件工程能力的模型。
CMMI模型将软件工程能力分为不同的级别，目前最高级别是CMMI级别5、在CMMI模型中，共有18个过程域，每个过程域都包含一组过程目标和过程实践。
下面将介绍CMMI级别3中的18个过程域，并对每个过程域进行详细解析。
1. 要求开发（Requirements Development）：该过程域涉及确定、分析和记录系统和软件需求的活动。
它包括需求的获取、管理、分析和验证。
2. 要求管理（Requirements Management）：该过程域涉及组织和控制项目的需求。
它包括需求的识别、跟踪、控制和变更管理。
3. 项目计划和监控（Project Planning and Monitoring）：该过程域涉及制定和维护项目计划，并监控项目活动的执行。
它包括识别和规划项目活动、建立项目计划、监控项目进展和基于此进行调整。
4. 项目监控和控制（Project Monitoring and Control）：该过程域涉及监控和控制项目执行过程中的工作和活动。
它包括收集和分析项目绩效数据、对比实际和计划绩效，对项目进展进行控制。
5. 供应商协议管理（Supplier Agreement Management）：该过程域涉及与供应商达成协议，并管理和监控供应商的活动。
它包括选择供应商、与供应商协商、管理和控制供应商的交付和绩效。
6. 产品集成（Product Integration）：该过程域涉及对各个组成部分进行整合，形成最终产品。
它包括定义和实施产品集成策略、执行产品集成和验证集成后的产品。
7. 风险管理（Risk Management）：该过程域涉及识别、评估和控制项目和产品的风险。
它包括制定风险管理计划、识别和评估风险、并采取相应的风险缓解措施。
8. 决策分析和解决方案评估（Decision Analysis and Resolution）：该过程域涉及通过分析和评估不同的解决方案，制定决策。
cmmi3
CMMI3简介CMMI三级，称为定义级。
在定义级水平上，企业不仅能够对项目的实施有一整套的管理措施，并保障项目的完成；而且，企业能够根据自身的特殊情况以及自己的标准流程，将这套管理体系与流程予以制度化这样，企业不仅能够在同类的项目上生到成功的实施，在不同类的项目上一样能够得到成功的实施。
科学的管理成为企业的一种文化，企业的组织财富。
CMMI3级区别CMMI2级对软件工程活动的指导很弱，如：需求开发、设计、编码、测试等。
在CMMI3级，你会发现：1)有指导需求开发的需求开发(Requirements Development)这个PA；2)有指导设计、编码工作的技术解决方案(Technical Solution)这个PA；3)有指导如何保证工作产品满足要求的验证(Verification)；4)有指导如何保证软件产品满足真实使用环境要求的(Validation)；5)还有指导如何把软件产品各组件集成在一起并保证能在相应的硬件载体运行正常的产品集成(Product Integration)；CMMI2级的PP与PMC是直接与项目管理有关的两个PA，在CMMI3级，对项目管理的要求进一步提高：6)集成项目管理(Integrated Project Management)：3级的项目管理，要求利用组织级的财富库进行项目估算，并且利用财富库裁剪出项目自己的过程，并用这个过程来管理项目。
7)风险管理(Risk Management)：2级只有PP的SP2.2中提到要识别风险，而在3级专门有一个PA对风险管理提出更高的要求。
大家不知道有没有发现，2级的PA都是直接针对项目提出要求的。
3级的IPM和RSKM，除了对项目级提出要求，另外也对组织级提出了要求，IPM要求有组织级的资产库，RSKM 要求要有组织级的风险管理策略等。
另外，3级有几个“O”开头的PA，这几个PA都是直接对组织级的提出要求。
8)组织过程焦点(Organizational Process Focus)：这个PA要求组织成立SEPG来推动过程改进的工作，要求识别、计划、实施改进过程，保证组织过程能持续改进。
CMMI3级18个过程域
CMMI3级过程域一共有18个PA，分别是：过程管理1、OPD：（Organizational Process Definition）组织级过程定义。
建立和维护有用的组织过程资产。
2、OPF：（Organizational Process Focus）组织级过程焦点。
在理解现有过程强项和弱项的基础上计划和实施组织过程改善。
3、OT：（Organizational Training）组织培训管理。
增加开发人员的技能和知识，使他们能有效地执行他们的任务。
项目管理：4、PP：（Project Plan）项目计划。
保证在正确的时间有正确的资源可用。
为每个人员分配任务。
协调人员。
根据实际情况，调整项目。
5、PMC：（Project Monitoring and Control）项目监督与控制。
通过项目的跟踪与监控活动，及时反映项目的进度、费用、风险、规模、关键计算机资源及工作量等情况，通过对跟踪结果的分析，依据跟踪与监控策略采取有效的行动，使项目组能在既定的时间、费用、质量要求等情况下完成项目。
6、SAM：（Supplier Agreement Management）供应商协议管理。
旨在对以正式协定的形式从项目之外的供方采办的产品和服务实施管理。
7、IPM：（Integrated Project Management）集成项目管理。
根据从组织标准过程剪裁而来的集成的、定义的过程对项目和利益相关者的介入进行管理。
8、RSKM：（Risk Management）风险管理。
识别潜在的问题，以便策划应对风险的活动和必要时在整个项目生存周期中实施这些活动，缓解不利的影响，实现目标。
工程管理：9、REQM：（Requirements Management）需求管理。
需求管理的目的是在客户和软件项目之间就需要满足的需求建立和维护一致的约定。
10、RD：（Requirement Development）需求开发。
需求开发的目的在于定义系统的边界和功能、非功能需求，以便涉众（客户、最终用户）和项目组对所开发的内容达成一致。
cmmi 3级标准要求
cmmi 3级标准要求
CMMI 3级标准要求是指CMMI（能力成熟度模型集成）框架的第三级
要求。
CMMI是一种用于评估和改进组织的过程的方法论，它定义了一组最
佳实践，用于提高组织的绩效和效率。
CMMI模型有5个不同的成熟度级别，分别是初始级、被管理级、定义级、定量管理级和优化级。
CMMI 3级标准
要求位于定义级，是一个相对高级的阶段。
CMMI 3级标准要求涉及组织建设、过程管理和绩效改进等方面。
在组
织建设方面，组织应当详细描述和文档化其标准化的工作流程和活动，包括
项目计划、配置管理、风险管理等。
组织还需要建立起有效的人员协作机制，确保团队成员之间的沟通和协调。
在过程管理方面，组织应当制定并执行一套适当的过程和方法，用于规
范化项目的开发和实施。
这些过程和方法需要能够提供明确的工作指导和质
量监督，以确保项目按时、按预算、按质量完成。
组织还需要有效地进行项
目管理，包括项目计划、需求管理、质量控制等。
在绩效改进方面，组织应当设立适当的绩效指标和度量方法，对项目和
过程进行评估和监控，并根据评估结果进行相应的改进。
组织还需要建立经
验资料库，以便从以往的项目中获取宝贵的经验教训和最佳实践。
总的来说，遵循CMMI 3级标准要求可以帮助组织建立起稳定和可靠的
工作流程，提高项目的管理水平和绩效表现。
这将有助于组织改进和优化，
达到更高的成熟度级别。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
同行评审4.1同行评审与测试的关系发现缺陷的手段为什么要引入同行评审而不是继续完全使用测试呢？有些工作产品在早期阶段就可以进行同行评审去发现缺陷，但无法对其进行测试；即使到了编码阶段，测试活动也不能发现某些特定类型的缺陷（例如违反编程规范）。
从图4-1（开发各阶段缺陷放大图）可以看出，随着开发的不断开展，缺陷不断泄漏和放大，最终形成的产品是一个灰色的距离用户真正需求很远的一个"东西"。
这就需要在开发的过程中不断进行同行评审，减少泄漏到下一个阶段的缺陷。
成功的同行评审是提高质量和生产率的重要因素，不管人们喜欢与否，审查过程会迫使每个人在一种开放式的环境中工作。
一旦人们懂得了他们的工作都要接受同行评审，他们就会越早地将他们的工作公之于众，以待监督。
在同级评审上的投入把组织的一些质量成本从昂贵的测试以及后期的大规模返工转变为早期的缺陷发现。
更重要的是，工作产品的作者学到了如何将工作做得更好，从而避免了缺陷。
固然同行评审的准备、活动和跟踪需要花费一定的时间和工作量，但这些可以在测试中节省更多。
从经济角度考虑，许多缺陷是在早期阶段注入的，越早消除缺陷就越能降低开发成本。
据统计，对于保存精确记录的大系统，一套完整的同行评审体系能够使项目在每个测试阶段出现的错误减少了90%。
这样一来，即使在综合考虑了同行评审活动成本的情况下，同行评审活动也会使测试成本下降50%～80%。
同时，通过同行评审，开发人员能够及时地得到专家的帮助和指导，加深对工作成果的理解，更好地预防缺陷，在一定程度上提高了开发生产率。
再者，消除工作成果的缺陷，可以提高产品质量，提高客户满意度。
（点击查看大图）图4-1 开发各阶段缺陷放大图总之，同行评审有助于"提高质量、提高生产率、降低成本"。
但是要注意，同行评审不可能代替测试，正如测试不可能替代同行评审一样。
那么，工作产品通过了什么样的评审才算合格呢？同行评审本身的要求有没有在质量目标里？评审的工作量和参加人员的资格、评审时间是否有要求呢?4.2 同行评审的种类和对象同行评审活动的关注点应该是工作产品中的缺陷，而不应该是工作产品的作者或者生产者，管理者也不应使用同行评审的结果去评价个人的行为。
同行评审的分类有很多种，自从IBM的Fagan发明了同行评审之后，软件行业提出了很多同行评审模型，比较著名的有IEEE 1028评审、微软的技术评审、Gill Graham 审查、Van Emden审查、Yourdon结构化走查等。
4.2.1 同行评审的种类本书中按照CMMI模型的提法，将同行评审分为3类。
（1）正式评审（Inspection），通常是由经过同行评审培训的项目经理或PPQA主持，规模在3～7人之间为宜，一般在完成了一个工作产品后对其进行的评审。
正式评审的目的在于定位并除去工作产品中的缺陷。
（2）技术审查（Technical Reviews），或称内部评审，通常由技术负责人或项目经理召集，三人以上参加。
技术审查一般是在工作产品的中期进行或完成了某部分独立的工作产品时进行，也可在书写草案遇到问题时就其中专门的一两项问题讨论和审查。
也可以是检查工作产品与规程、模板、计划、标准的符合性或者变更是否被正确地执行。
技术审查的目的在于通过对开发人员的工作产品的技术审查，提出改进意见。
（3）走查（Walkthrough），又叫代码走查或代码走读，审查的范围根据需求的优先级通常由管理人员来确定，主要是静态质量分析和编程规则检查。
通常是小型讨论会，一般是在工作产品形成的早期进行，作者有一定的想法时，希望从中获得一些帮助或补充一些想法。
当然也可以在编制工作产品的任何阶段进行，两三个人参加，由作者主持，主要是评估和提高工作产品的质量或教育参加者。
其中，"正式评审"是正式的，"技术审查"和"走查"是常用的非正式同行评审方法。
4.2.2 同行评审的对象同行评审的对象包括所有软件开发的中间和最终工作产品，例如包括：（1）产品需求规格说明书；（2）用户界面规范及设计；（3）架构设计、概要设计、详细设计及模型；（4）源代码；（5）测试计划、设计、用例及步骤；（6）项目计划，包括开发计划、配置管理计划和质量保证计划等。
所有这些会涉及的评审内容，应该在编制的项目计划或者小的开发计划中体现，不应该也不能是临时性的安排。
4.3 同行评审过程根据同行评审的重要程度，正式评审、技术审查和走查三种形式的流程和成果物的使用力度不尽相同，但其主要的步骤和内容大体一致，参见如图4-2所示的同行评审流程图。
（点击查看大图）图4-2 同行评审流程图4.3.1 正式评审流程正式评审包括下述6个基本步骤。
（1）预备：为保证评审的质量，可以先进行一个预备会议。
会议上，由作者花几分钟的时间向评审组概要介绍评审材料，例如讲解一下本工作产品的目标是什么，其他相关的实现细节、开发标准等。
应该允许甚至鼓励评审组成员动手查看工作产品，或者查看开发过程中所用到的检查单等。
这个讲解的过程从某种角度上来说，也保证了作者提交工作产品的质量。
会议结束时把文档分发给每位与会者，下发的材料应该控制在2小时之内审核完成为宜。
这些文档可以包括：要审查的工作产品；参考文档；工作产品评审检查表；工作产品审阅情况记录表。
评审主持人负责根据具体情况确定什么时间开始真正的评审会议。
（2）审查：在预备会和正式评审会之间，评审小组成员会对工作产品进行彻底检查，并依据相关标准和准则评审工作产品，记录发现的缺陷、问题种类与严重程度、所用的时间等。
（3）评审：在预定的正式评审时间内（会议时间建议控制在2小时），评审小组成员以会议形式聚在一起，依次对产品进行检查。
每个评审员花一定的时间（一般为十几分钟）指出问题，并和作者确定问题和定义问题的严重程度。
注意，评审过程中是发现错误，而不是现场改正它们。
会议中，记录员详细记录每一个已达成共识的缺陷，包括缺陷的位置、简短描述缺陷、缺陷类别、该缺陷的发现者等。
未达成共识的缺陷也将记录下来，加入"待处理"或者TBD标识，评审主持人将指派作者和评审员在会后处理评审会议中未能解决的问题。
（4）书写评审报告：评审主持人根据记录员的记录和自己的总结，在一天内写出评审报告，内容包括：根据评审专家个人的输入创建总的问题清单；加入会议中发现的问题；剔除经确认属于重复或者无效的问题；共同确定需要修改的问题及修改的程度。
（5）返工：作者根据评审报告的决议，负责解决确定的所有缺陷和问题。
（6）跟踪：评审组长必须确保所提出的每个问题都得到了圆满解决。
必须仔细检查对文档的每个修正，以确保没有注入新的错误。
4.3.2 技术审查流程技术审查通常包括下述3个基本步骤。
（1）准备：评审组长（通常是项目经理）要求项目组成员提供需要考虑的特定问题并分发评审材料。
评审组长确定评审重点：需要注意的特定问题；需要满足的特殊标准或规格说明；需要审查的接口或依赖关系。
（2）评审：评审人各自审查评审材料，目的是发现错误，而不是改正它们（通常每次评审会不超过1小时）。
评审组组长应在一天内写出评审报告。
评审会议内容包括：汇总个人发现的问题；加入会议中发现的问题。
（3）跟踪：作者负责解决评审报告中的所有错误及问题。
评审组长检查所提出的每个问题都得到了解决。
组长起草评审发现报告：问题或弱项清单；小组对如何解决这些问题或弱项清单的建议；行动事项。
4.3.3 走查流程走查对形式的要求更为简单，主要有下述两种方式。
（1）参与者驱动法：参与者按照事先准备好的列表，提出他们不理解的术语和认为不正确的术语。
作者必须回答每个质疑，要么承认确实有错误，要么对质疑做出解释。
（2）文档驱动法：作者向评审人仔细解释文档（或代码）。
在此过程中，可以将评审的内容（如关键代码、架构图、业务逻辑图等）用投影仪投射到屏幕上，作者对工作产品进行讲解，评审人不时针对事先准备好的问题或解释过程中发现的问题提出质疑。
它比参与者驱动法可能更有效，往往能检查出更多错误。
经验表明，使用文档驱动法时许多错误是由文档讲解者自己发现的。
在走查过程中，每个评审人都要记录错误或建议，会后要整理会议记录，作为走查报告。
工作产品的作者可以根据自己的思路对走查报告质疑。
注：对代码的同行评审其实就是代码走查，可以使用投影仪打出关键代码位置与参与人员一起读，也可以几个开发人员一起进行交叉走查。
选定的进行代码走查的范围根据需求的优先级来具体确定。
4.4 同行评审方式的选择对于同一个工作产品，根据所处于的阶段可以使用不同的评审方式。
如对于工作产品刚刚勾画、起草时，可以采用走查方式；对于完成了某一个单独的章节，可以采用技术审查方式；待整个产品完成，使用正式评审全面考察。
4.4.1 三种同行评审方式的比较对不同的工作产品，可以根据表4-1建议结合项目情况进行调整和裁剪。
表4-1 三种同行评审方式的比较种类正式评审、技术审查、走查，目的以比较详细的粒度，定位并去除工作产品中的缺陷表明工作产品与规约、计划、标准的符合性或者变更被正确地执行了评估、提高工作产品，教育参加者入口准则工作产品符合已建立的准备准则发布了评审目的，工作产品就绪，作者准备好工作产品计划中标识时机工作产品全部完成完成独立的章节架构、蓝图、草稿规模3～8人3～5人2～3人评审材料相对较少中等或较多，需要根据评审的目的确定中等准备时间3～5天准备2天准备主持人专职主持人小组长/组长作者变更验证主持人验证返工组长验证，作为评审报告的一部分由其他的项目控制手段执行成果物缺陷清单和度量元总结技术评审报告，包括缺陷清单以及行动计划走查报告，缺陷记录以及改进建议4.4.2 同行评审的结果同行评审的结果通常有3种：（1）正常：评审专家做好了评审准备，会议正常，结果明确，不需要再次评审；（2）延期：30%以上评审专家没有做好准备，会议无法正常进行，需要确定再次评审时间；（3）取消：在初审阶段就发现很多问题，需要作者进行修正，然后再进行第二次同行评审。
4.4.3 正式评审的特征相对于走查和技术评审，正式评审具有一些明显的特征。
（1）评审以一种正式的形式进行，如有正式的、事先定义好的有关职责的各种角色，并遵循组织规定的标准流程。
（2）对于任何工作产品的评审，都会组建与之对应的专门评审组，包括作者、主持人、记录员以及评审员若干。
评审组成员也可以包括项目经理、PPQA，但是不能有作者的直接领导或者管理者。
（3）评审小组先召开一个预备会议，作者会针对工作产品向大家做一个总体的介绍，例如讲解一下本工作产品的目标是什么，其他相关的实现细节、开发标准等。
应该允许甚至鼓励评审组成员动手查看工作产品，或者查看开发过程中所用到的检查单等。