本文介绍利用桌面检查、同行评审、走读、检查等方式来识别缺陷。
ISO/IEC/IEEE 2010定义评审为 "向项目人员、管理人员、用户、客户或其他相关方介绍工作产品或一组工作产品以征求意见或批准的过程或会议。" 审查可以作为软件开发、维护和获取活动的一部分进行。
IEEE软件审查和审计标准（IEEE 2008）将管理审查定义为："由管理层或代表管理层对软件产品或过程进行的系统性评估，以监测进度，确定计划和时间表的状态，确认需求及其系统分配，或评估用于实现目的的管理方法的有效性。"
管理评审用来：
通常，管理评审评估验证和确认(V&V)活动的结果，但不直接用于V&V目的。然而，其他三种主要的审查类型直接用于V&V目的包括。
V&V评审的主要目的是在软件生命周期的早期识别并消除软件工作产品的缺陷。作者要在自己的工作产品中发现缺陷是非常困难的。大多数软件从业人员都经历过这样的情况：他们不停地寻找那难以捉摸的缺陷，但就是找不到它。当他们请别人帮忙时，别人几乎立刻就发现了缺陷。这就是评审的力量。
V&V评审的另一个目的是为工作产品满足需求和利益相关者的需要提供信心。评审可以用来验证需求是否恰当地抓住了利益相关者的需求。评审也可以用来验证所有的功能需求和质量属性已经在设计、代码和其他软件产品中充分实现，并被测试有效评估。
V&V评审也被用来检查工作产品是否符合标准。例如，可以对设计进行同行评审，以验证它是否符合建模标准和符号，或者对源代码模块进行评审，以验证它是否符合编码标准和命名规则。
最后，V&V审查可以被用来识别需要改进的地方。这并不意味着 "风格 "问题--如果是风格问题，作者就赢了。然而，评审员可以识别出提高软件质量的机会。比如说审查员可能会发现一个更有效的排序程序，或者一个去除冗余代码的方法，甚至发现可以重复使用现有代码的地方。
在审查过程中，测试人员可能会发现需求或设计的可行性或可测试性的问题。评审员可能会发现可维护性问题。例如，在代码审查中，不充分的注释，硬编码的变量值，或混乱的代码缩进可能被确定为需要改进的地方。
在软件开发过程中创建的每个工作产品都可以作为V&V活动的一部分进行审查。然而，并不是每个工作产品都应该被审查。在进行评审之前，从业人员应该问这样一个问题："执行这个评审的成本是否比举行这个评审的收益要高？" 评审，就像任何其他过程活动一样，应该始终是增值的，否则就不应该进行。
每一个交付给客户、用户或其他外部利益相关者的工作产品都应被视为审查的对象。工作产品的交付物包括对招标书的回应、合同、用户手册、需求规格，当然还有软件及其子组件。每个交付物都可以给组织的外部利益相关者留下积极或消极的质量印象。此外，任何对这些交付物的创建有投入或有重大影响的工作产品也是审查的对象。例如，架构和组件设计、接口规范或测试用例可能不会直接交付，但这些工作产品的缺陷会对交付的软件质量产生重大影响。
那么，什么是不被审查的呢？实际上，在开发、获取和维护软件的过程中创建的许多工作产品，可能不适合审查。例如，许多质量记录，如会议记录、状态/进度报告、测试日志和缺陷报告等，通常不属于审查的对象。
IEEE软件审查和审计标准（IEEE 2008）指出，"技术审查的目的是由合格人员组成的团队对软件产品进行评估，以确定其是否适合于预期用途，并确定与规范和标准的差异。" 技术审查也可用于评估技术解决方案的替代方案，提供工程分析，并做出工程权衡决定。一般来说，技术审查与具体的同行审查之间的主要区别之一是，管理人员可以积极参加技术审查，而只有作者的同行参加同行审查。
IEEE软件审查和审计标准（IEEE 2008）定义了技术审查过程中的以下主要步骤。
这些评价的结果要记录下来，包括行动项目的清单。组长确定任何已确定的缺陷和/或不符合项的数量或关键性是否需要安排额外的审查以评估其解决方案。
结对编程涉及两个人，其中一个不断地审查另一人正在开发的东西。结对编程提供了软件如何工作的持续的思想交流。如果一人遇到了心理障碍，另一人可以跳进去尝试一些东西。结对编程是一种帮助人们保持敏捷方法所倡导的稳定步伐的技术，通过充分参与工作和保持彼此的 "诚实"（坚持遵守项目的实践、标准等）。Martin（2003）指出，结对编程的互动可能是 "激烈的"。他主张 "在迭代过程中，团队中的每个成员都应该与团队中的其他成员一起工作，他们应该对迭代中发生的所有事情进行工作"。通过这样做，团队中的每个人都会理解和欣赏其他人的工作，并对整个软件产生深刻的理解。结对编程是避免多余文件的一种方法，因为每个人都分享项目的需求和设计知识。
同行对工作产品进行评估，以识别缺陷，获得产品满足其要求和预期用途的信心水平，和/或识别改进该工作产品的机会。工作产品的作者是最初制作该工作产品的人或目前负责维护该工作产品的人。
开发的能力成熟度模型集成（CMMI）（SEI 2010）指出，"同行评审是验证的一个重要部分，是有效消除缺陷的一个成熟机制。" 同行评审的好处，特别是正式检查，在行业中得到了充分的证明。例如，与其他V&V方法相比，使用同行评审通常能发现更多缺陷。Capers Jones (2008)报告说："正式检查的缺陷消除效率水平可高达85%，是任何形式的测试的两倍"。由经验丰富的检查员进行的良好检查可以获得90%的缺陷消除效率（Wiegers 2002）。"检查可望将现场使用中发现的缺陷减少一到两个数量级"（Gilb 1993）。
一般来说，在同行评审中识别缺陷的时间比使用其他缺陷检测技术的时间要少得多。例如，Kaplan报告说，在IBM的Santa Teresa实验室，使用代码检查发现一个主要缺陷平均需要3.5个工时，而在测试中发现一个主要缺陷需要15到25个工时（Wiegers 2002）。修复缺陷的时间也通常要短得多，因为缺陷是在工作产品中直接发现的，这就不需要进行潜在的耗时的调试活动了。同行评审可以在生命周期的早期用于工作产品，如需求和设计规范，在这些缺陷传播到其他工作产品并变得更昂贵之前消除缺陷。
同行评审也提供了交叉培训的机会。经验不足的从业人员在帮助同行评审经验丰富的从业人员的工作时，可以看到高质量的工作产品是什么样子的，从而受益。经验更丰富的从业人员在审查经验不足的从业人员的工作时，可以提供工程分析和改进建议，这有助于知识的转换。同行评审还有助于在组织内传播产品、项目和技术知识。例如，在同行评审之后，不止一个从业人员熟悉被评审的工作产品，并且在其作者无法工作的情况下，有可能为其提供支持。对需求和设计文件的同行评审有助于沟通，并有助于促进共同的理解，有利于未来的开发活动。例如，这些同行评审可以帮助识别和澄清被评审的工作产品中的假设或模糊之处。
同行评审可以帮助建立共同的工艺标准和期望。他们可以建立协同的心态，因为工作产品随着同行评审从个人所有权过渡到团队所有权。
最后，同行评审提供数据，帮助团队评估工作产品的质量和可靠性。同行评审的数据也可以用来推动未来的缺陷预防和流程改进工作。
同行评审员是根据被评审的工作产品的类型和性质来选择的。评审员应该是作者的同行，拥有足够的技术和/或领域知识，以便对工作成果进行全面的评估。为了使同行评审有效，评审员也必须能够投入必要的时间和精力来进行评审。有各种原因导致个人无法参与，包括时间限制、需要专注于更优先的任务，或认为他们没有足够的领域/技术知识。如果一个 "无法参与 "的人被认为对同行评议的成功至关重要，那么在指派他们参与同行评议之前，需要处理好这些问题，使其满意。
同行是指在组织中与工作产品的作者处于同一级别的人。同行评审的一般规则是，管理人员不参与同行评审，他们不是同行。如果管理者参与评审，那么作者更不愿意让他们的工作产品接受同行评审，因为发现的缺陷可能会在管理者眼中对作者产生不好的影响。
评审员更不愿意在管理人员面前报告缺陷，使他们的同事看起来很糟糕，因为他们知道下一次可能就会轮到自己。然而，事情并不那么简单。这在很大程度上取决于组织的文化。在一线经理是工作经理（团队的积极成员）的组织中，或者在参与式管理风格盛行的组织中，让直接主管参与同行评审可能是一个真正的好处。他们可能拥有知识和技能，是同行评审小组和作者的财富。在组织层次上比作者高一级或低一级的人，可以考虑作为评审员，但前提是作者对这种选择感到满意。换句话说，问问作者。如果作者对自己的上司参与审稿感到满意，其他审稿人也可能会感到满意。
当谈及同行评审中的 "同行 "时，并不意味着 "克隆"。例如，在需求同行评审中，作者是一个系统分析员，同行评审小组不应该只限于其他系统分析员。拥有不同视角的评审员可以增加同行评审小组的多样性。这种多样性带来了不同的视角，可以增加发现额外缺陷和不同类型缺陷的概率。评审员的选择应该通过选择不同的参与者来使这种好处最大化，包括。
被评审的工作产品的前身的工作产品的作者。"前身的观点很重要，因为一个......目标是验证工作产品是否满足其规格"（Wiegers 2002）。
从属（后继）工作产品的作者，以及界面工作产品的作者，他们对工作产品的质量有着强烈的既得利益。例如，考虑邀请一位设计师和一位测试员参加需求的同行评审。他们不仅会帮助发现缺陷，而且是考察可理解性、可行性和可测试性等问题的优秀人选。
专家，当特殊的专业知识可以增加同行评审的有效性时，也可以召集他们（例如，安全专家、安全专家和人为因素专家）。
这并不意味着与作者有相同工作的其他人被排除在审查之外。他们掌握着特定产品的工艺标准和最佳实践。他们也最熟悉该类型工作产品的常见缺陷。这也增加了团队的多样性。
对于大多数同行评审，同行通常是同一项目组的其他成员。然而，对于小型项目或只有一个人拥有专业技能的项目，可能需要请其他项目的人参与同行评审。
如上所述，同行评审是绝佳的培训场所，可以教给新人编程技术、产品和领域知识、流程和其他有价值的信息。然而，太多的受训者也会影响同行评审的效率和效果。也可能有几个原因，个人可能想观察同行评审。例如，审核员可能通过观察来验证同行评审是否按照文件规定的流程进行，或者检查主持人学员可能观察经验丰富的主持人的行动。观察者可能会分散团队成员的注意力，即使他们没有参与实际审查。建议将同行评审会议中的受训人员和观察员人数限制在每次会议不超过一到两名。
管理层对同行评审过程的主要责任是通过强调其价值和保持组织对该过程的承诺来支持该过程。要做到这一点，管理层必须明白，虽然在项目早期需要对同行评审进行投资，但其真正的好处（投资回报）要到生命周期的后期，甚至是产品发布后才能看到。管理层可以通过以下方式支持同行评审。
同行评审的正式程度差别很大。在同行评审的最非正式的一端，软件从业者可以要求同事，"请帮我看看这个"。这些类型的非正式同行评审一直都在进行。当从业者遇到问题，需要第二种意见，或者想验证他们的工作时，让第二双眼睛看一下工作成果，这只是一个好的做法。这些非正式的审查是临时进行的，没有正式的过程，没有准备，没有质量记录或指标。缺陷通常是口头报告或在工作产品的草稿上以红线标注的方式报告。从这些非正式的同行评审中产生的任何返工，都由作者自己决定。
在正式的同行评审中。
同行评审有不同的类型，在软件行业中有许多不同的名称。同行评审的名称有：团队评审、技术评审、走读、检查、配对评审、变通、临时评审、桌面检查等。然而，笔者发现，大多数都可以归入三个主要的同行评审类型之一。
虽然检查都是非常正式的同行评审，但桌面检查和走读的正式程度有很大不同，这取决于项目的需要、评审的时间和参与人员。
应该选择哪种类型的同行评审取决于几个因素。
在选择哪种类型的同行评审时，风险是最后要考虑的因素。下面将讨论基于风险的同行评审。
基于风险的同行评审只是基于风险的V&V活动的一种类型。应该对考虑进行同行评审的每个工作产品进行风险分析，以确定该工作产品中存在尚未发现的重要缺陷的概率，以及如果这些缺陷逃过同行评审的潜在影响。如果未被发现的缺陷的概率和影响都很低，那么由一个同行进行非正式的桌面检查可能是合适的。随着概率和影响的增加，最合适的同行评审类型会转向更正式的桌面检查、非正式的走访、更正式的走访，然后是正式检查。对于一个非常高风险的工作产品，进行多次同行评审可能是合适的。例如，对于像需求这样的高风险工作产品，每一套或每一节需求都可以在开发过程中进行桌面检查或走过场，然后在开发的后期，在过渡之前，对整个需求规范进行检查。
执行同行评审的人数也可以根据风险而变化。对于非常低风险的工作产品，由一个人进行桌面检查可能就足够了。对于风险稍高的工作产品，由多人进行案头检查可能是合适的。对于值得投资检查的产品，风险较小的工作产品可以分配一个由2至4人组成的小型检查小组，而风险较高的产品可以分配一个由5至7人组成的检查小组。
基于风险的同行评审也接受了收益递减的规律。当一个软件工作产品第一次被同行评审时，产品中存在的许多缺陷就会被发现，而且是以较少的精力发现。随着更多的同行评审的进行，发现更多缺陷的概率就会降低。在某些时候，发现最后几个缺陷的投资回报超过了额外同行评审的成本。
作者在同行评审中面临的挑战之一是在评审过程中（尤其是在会议中）保持 "无自我"，不要变成防御性或争论性。无自我的方法使作者能够退后一步，接受改进建议，承认已发现的缺陷，而不把它们视为对其专业能力或个人价值的人身攻击。这样做的一个方法是，作者要把工作产品从他们个人的责任过渡到提交审查时成为团队的产品。其他同行评审员也应该采取无自我的方法，不要试图通过贬低作者的工作、其他评审员的评论或工作成果本身来证明自己有多聪明。在同行评审中，每个人都应该尊重工作成果、其他评审成员，特别是作者。
在整个同行评审过程中，重点应该放在产品上，而不是放在人身上。实现这一目标的方法之一是使用 "我 "和 "它 "的信息，在讨论中避免使用 "你 "这个词。例如，一个评审员可能会说，"我不理解这个逻辑 "或 "工作产品的这一部分的逻辑有缺陷"，而不是说 "你在这个逻辑中犯了一个错误"。另一种方法是把评论写成中性的事实、积极的批评或问题，而不是批评。
在同行评审会议期间，团队成员不应打断对方。他们应该积极听取其他团队成员的意见，并在其他评审员的意见基础上，发现更多的缺陷。在同行评审会议上，作者不应该被迫承认每一个缺陷。这真的会把作者打倒。假设作者的沉默表明他们同意缺陷的存在。
桌面检查是指工作产品作者的一个或多个同行单独审查该工作产品的过程。桌面检查可以用来检测工作成果中的缺陷和/或提供工程分析。桌面检查过程中使用的形式可能有所不同。桌面检查可以是最非正式的同行评审过程，也可以采用更正式的同行评审技术。桌面检查本身可以是一个完整的同行评审过程，也可以作为穿行或检查的准备步骤的一部分。桌面检查过程的有效性在很大程度上取决于个别审查员的技能和他们在审查中投入的关心和努力。
非正式的桌面检查开始于工作产品的作者要求他们的一个或多个同行来评估该工作产品。然后，这些同行评审员独立地对工作成果进行案头检查，并将他们的意见口头反馈给作者，或提供一份已注有他们意见的工作成果（红线）。这通常是在文件的第一稿或源代码模块的清洁编译后进行。然而，桌面检查可以在工作产品的生命周期中的任何时候进行。
桌面检查也可以以更正式的方式进行。例如，当桌面检查作为审查和批准周期的一部分时，可以遵循一个确定的流程，并指定具体的角色（例如，软件质量工程师、安全专家或测试人员）和正式记录缺陷。这些比较正式的桌面检查可能会导致质量记录的保存，包括正式的同行评审缺陷记录和/或正式的书面报告。正式的案头检查甚至可以包括审查员的跟进，重新审查更新的工作产品，以验证缺陷是否得到了适当的纠正，工程建议是否被采纳。
在桌面检查中，审查员不应该试图在一次过的工作产品中找到所有的东西。这样做会削弱他们的注意力，而被发现的重要缺陷和问题也会减少。相反，每个评审员应该对工作产品进行第一遍检查，以获得一个总体的概述和理解，而不是寻找缺陷。这为进一步的、更详细的审查提供了一个背景。然后，每个评审员对工作成果进行第二次详细检查，记录任何已发现的缺陷。然后，每个评审员应该从共同的缺陷检查表中选择一个项目，或一个重点领域，对工作成果进行第三次检查，只集中审查这一个项目/领域。如果有时间，每个审查员可以选择另一个检查表项目或重点领域，进行第四遍审查，以此类推。例如，在需求规格审查中，审查员可以集中精力确保所有的需求是有限的，并在另一次审查中重点评估每个需求的可行性。对工作产品进行多次检查不被认为是返工（重复已经完成的工作），因为每次检查都是从不同的焦点或重点领域来观察工作产品。
评审员在对工作产品进行第二遍检查时，可以使用的桌面检查技术之一是心理执行。使用心理执行技术，审查员遵循工作成果的每条路径或线索的流程，而不是按照逐行的顺序来写。例如，在设计审查中，审查员可能会按照每个逻辑控制流程来进行设计。在审查一套安装说明时，审查员可以按照安装步骤的流程进行审查。一个代码审查的例子可能是选择一组输入数据并跟随数据流通过源代码模块。
在测试用例审查技术中，审查员设计一组测试用例，并使用这些测试用例来审查工作成果。这种技术与心理执行技术密切相关，因为审查者通常没有可执行的软件，所以他们必须在心理上执行他们的测试用例。尝试写测试用例的行为本身可以帮助识别工作产品中的歧义和产品的可测试性问题。通过从 "产品如何工作 "的心态转变为测试人员 "我怎样才能打破它 "的心态，审查员也可以发现工作产品中 "缺失 "的地方（例如，没有解决的需求，没有实现的过程替代方案或例外，缺失的错误处理代码，或代码中没有正确释放资源的地方）。测试用例审查技术可以用于许多不同类型的工作产品。例如，评审员可以对需求规范、架构或组件设计元素、源代码模块、安装说明、用户手册，甚至对测试案例本身编写测试案例。
让第二个人看工作产品的真正好处之一是这个人可以看到作者没有考虑到的东西。然而，审查工作产品中缺少的东西要比审查工作产品中的东西难得多。核对表和头脑风暴是两种技术，可以帮助识别工作产品中缺少的东西。核对表只是提醒审查员根据类似工作产品中的历史常见问题来寻找特定的项目。如果没有核对表，评审员可以根据所评审的工作产品类型，集思广益，列出可能缺失的东西。例如，对于一个需求规范，这个清单可能包括以下项目。
任何同行评审的目标是在现有的时间和资源限制下尽可能多地发现重要缺陷。通常，发现小的、不重要的缺陷，如错别字和语法问题，比发现工作成果中的主要问题要容易。事实上，如果评审员开始发现许多小缺陷，就很容易被它们分散注意力。评审员应该专注于发现重要的缺陷。如果他们注意到小的缺陷或错别字，他们应该记录下来，但随后将他们的注意力恢复到寻找 "大东西 "上。如果评审员实在忍不住了，他们应该对工作产品进行一次检查，只是为了寻找小东西，然后就完事了。这就是为什么许多组织坚持所有的工作产品都要经过拼写/语法检查和/或通过代码分析工具（例如，编译器）来确保它们尽可能的干净，这样评审员就可以避免浪费时间去寻找那些可以用工具更有效地发现的缺陷。
现在是计算机时代，审查员可以利用计算机提供的工具。在桌面检查中可以使用的工具之一是搜索功能。如果审查员能得到工作成果的电子版，他们可以搜索关键词。例如，需求说明中的 "所有"、"通常"、"有时 "或 "每一个 "等词可能表明需要进一步调查的领域的有限性。在确定了一个缺陷之后，搜索功能也可以用来帮助确定同一缺陷的其他发生情况。例如，在编写本章时，一位评审员指出，有些地方使用 "记录员 "一词，有些地方使用 "抄写员 "一词，指的是同一个检查角色。由于这可能会造成一定程度的混乱，因此使用了搜索功能来查找所有出现的 "抄写员 "一词，并将其改为 "记录员"。这里的寓意是，不要手动搜索那些计算机可以更快、更准确地找到的东西。
在桌面检查过程中，应将工作成果与其前身进行比较，以保证其完整性和一致性。一个工作产品的前身是以前的工作产品，它是创建被同行评审的工作产品的基础。
走读是指工作产品作者的一个或多个同行与该作者会面，作为一个团队审查工作产品的过程。通过走读，可以发现工作产品的缺陷和/或提供工程分析。与检查相比，会议前的准备工作不那么重要。走过场过程的有效性不仅取决于个别审查员的技能和他们在审查中投入的关心和努力，还取决于审查小组的协同作用。
在走访过程中使用的形式可以有所不同。一个非常非正式的走读的例子可能是作者对一个算法或其他设计元素进行一个即兴的 "白板 "走过场。在一个非正式的演练中，可能很少或没有准备。
在更正式的走读中，准备工作是在团队会议之前完成的，通常是通过使用桌面检查。准备工作通常由审查员个人决定，范围从很少或没有准备到对被审查的工作产品进行深入研究。在走访会议上，作者每次都会向审查员介绍工作成果的一个部分并解释每个部分。评审员提出问题，提出建议（工程分析），或报告发现的缺陷。作者回答有关工作成果的问题。记录员对讨论情况和任何建议、公开的问题或发现的缺陷进行记录。走过场会议结束后，记录员制作会议记录，作者对工作产品进行任何必要的修改，以纳入建议、解决问题和纠正缺陷。
虽然走读和检查都是以团队为导向的同行评审过程，但两者之间有很大的区别，许多将在检查部分讨论的工具和技术也可以应用于走读，这取决于为走读选择的正式程度。
检查是一种非常正式的同行评审方法，包括作者在内的同行团队进行详细的准备，然后开会检查工作成果。当作者认为工作产品已经完成并准备好进入下一阶段或活动时，就会进行检查。检查的唯一重点是识别缺陷。强调使用检查表和指定角色的个人准备。衡量标准被收集起来，用于确定是否符合检查会议的准入标准，以及用于对产品或过程改进工作的投入
在检查中，团队成员被赋予特定的角色。
工作产品的原始创造者或负责其维护的个人。作者负责启动检查，并在整个检查过程中与主持人紧密合作。在检查会议期间，作者充当检查员的角色，另外负责回答有关工作产品的问题。检查会议结束后，作者与其他团队成员和/或利益相关者合作，结束所有未解决的问题。作者负责根据检查结果，对工作产品进行所有必要的返工。
也被称为检查负责人，是检查的协调者和领导者，在检查期间被认为是流程的 "所有者"。主持人使检查小组专注于产品并确保检查保持 "无自我"。主持人必须拥有强大的促进、协调和会议管理技能。主持人应接受培训，了解如何履行其职责，以及检查过程的细节。主持人的最终责任是确保检查指标被收集并记录在检查指标数据库中。主持人负责处理检查会议的后勤工作，如预订会议室和处理任何特殊安排，例如，如果需要投影仪来展示工作产品的部分内容，或者如果记录员需要使用计算机来将会议信息直接记录到检查数据库。
在检查会议期间，阅读者，也称为介绍者，每次向其他检查小组成员描述工作成果的一个部分或部分，然后将该部分开放供讨论。这种逐节转述的方式还有一个好处，就是让作者听到别人对他/她的工作的解释。很多时候，当读者的解释与作者的原意不同时，这种解释会导致作者在会议期间发现额外的缺陷。读者的 "解释往往会揭示出模棱两可、隐藏的假设、不充分的文件、或妨碍沟通的风格问题，或者是彻头彻尾的错误"（Wiegers 2002）。读者必须具备良好的表达能力、对产品技术的熟悉和强大的组织能力的适当组合。
也叫抄写员，负责充当团队的正式记录员。这包括记录准备工作和会议指标，以及检查会议期间发现的所有缺陷和公开问题。由于记录员同时也是会议上的检查员，这个人必须能够 "多管齐下 "他们的时间，并且应该有扎实的写作技巧。
观察者的角色在检查中是可选的。观察者在检查中不发挥积极作用，而是作为检查活动的被动观察者。这样做可能是为了了解工作产品或检查过程的情况。它也可以作为审计或其他评估的一部分进行。
当作者完成一个工作产品并确定它可以被检查时，作者通过确定一个检查的主持人来启动检查过程。通常每个项目都有一组训练有素的主持人，作者可以从中选择。主持人与作者合作，计划检查工作。
在计划步骤中，主持人核实在检查正式开始前，检查过程中定义的检查进入标准是否得到满足，并核实工作产品是否准备好接受检查。这可能包括对工作产品的样本做案头检查，以验证其质量是否合适，以便继续进行。在检查过程开始之前，任何基本的缺陷都应从工作产品中去除。
检查会议的时间不超过两小时。如果工作产品太大，无法在两小时的会议中进行检查，作者和主持人将产品分割成两个或更多的子产品，并为每个分割部分安排单独检查。这些会议中的每一个都应该使用同一个检查小组，一次启动会议可能是合适的。
主持人和作者选择适当的人参与检查，然后分配角色。检查小组应尽可能的小，并且仍然满足检查目标，包括拥有发现不同类型缺陷所需的多样性。一般的经验法则是每次会议的检查人员不超过7人。
作者和主持人确定是否需要召开启动会议。如果检查员需要有关工作产品的重要特征、假设、背景和/或背景的信息，以有效地准备检查，或者如果他们需要检查过程的培训，则应在准备步骤之前举行启动会议。举行启动会议的另一种方法是将产品概述信息作为检查包的一部分。
在决定何时何地举行启动会议和检查会议时，应考虑到与会者的时间和地点。对于同一个检查员来说，每天安排的检查会议不应超过两次，这两次会议之间要有很长的休息时间。检查公告应在会议前足够长的时间内与检查包一起交付给所有检查小组成员，以便他们有足够的准备时间（通常在启动会议前至少一天，在检查会议前两到三天）。
检查计划的主要交付品是检查包，它与检查公告一起发送。这个包可以是硬拷贝或电子版，包括检查小组成员为检查做充分准备所需的所有材料，其中包括
启动会议（也称为概述会议）的主要目的是教育。检查小组的一些成员可能不熟悉被检查的工作产品，也不知道它如何与整个软件产品或客户要求相适应。首先，作者对被检查的工作产品进行简要概述，并回答其他团队成员的任何问题。启动会议的这个产品简介部分是用来让团队成员了解被检查工作产品的范围、目的、重要功能、背景、假设和背景。
除了从他们自己的角度对工作产品进行总体评价外，要求个别检查员关注工作产品的特殊领域或特点可能是有价值的。例如，如果安全是工作产品的一个重要方面，可以指派一名检查员专门调查产品的这一特点。指定特殊重点领域的好处是，确保有人覆盖该领域，同时消除准备过程中的潜在冗余。作者通常是确定特殊重点领域是否适合被检查的工作产品的最佳人选。检查员也可以被分配到特定的检查表项目作为重点领域。这样做是为了确保至少有一名检查员查看检查表上的每个项目。这些重点领域和检查表项目，以及阅读者和记录者的角色，都在启动会议上分配。
最后，如果检查小组中有不熟悉检查过程的成员，启动会议也可以用来为这些人提供补救性的检查过程培训，以确保所有小组成员了解对他们的期望。在这种情况下，主持人会在启动会议上进行检查过程的介绍，以确认所有检查小组成员对检查过程、角色和任务有相同的理解。
在工作产品中发现缺陷和问题的真正工作始于准备步骤。利用检查包中提供的信息，每个检查员使用桌面检查技术独立评估工作产品，目的是识别和记录尽可能多的缺陷、问题和疑问。检查表在准备过程中被使用，以确保重要的项目被调查。然而，检查员也应该在检查表之外寻找其他缺陷。如果检查员被分配到一个或多个特定的重点领域或检查表项目，他们除了做一般的检查准备外，还应该从这个角度评估工作成果。如果检查员有足够重要的问题，影响到该检查员准备检查的能力，应该与作者联系。否则，问题应该被记录下来并带到检查会议上。
读者的准备工作也是至关重要的，他必须计划并制定出进行会议的时间表，包括如何将工作成果分成单独的、小的部分进行介绍和讨论。读者必须确定如何转述工作成果的每个部分，做笔记以促进会议期间的转述，然后练习他们的转述，以便在检查会议期间能够顺利和迅速地完成。由于这种准备工作很耗费时间，所以不给读者分配任何额外的重点领域。
准备时间的一个经验法则是，检查员为检查会议做准备的时间应该是检查会议预期时间的1到1.5倍。例如，如果会议计划持续两个小时，检查员应该花两到三个小时准备该会议。
检查会议的目标是在分配的时间内发现尽可能多的重要缺陷并进行分类。检查会议开始时，主持人要求每个检查员提供准备时间、按严重程度统计的缺陷数量以及问题/议题的数量，记录员记录这些项目。主持人利用这些信息来确定检查小组的所有成员是否已经准备好进行检查。如果一个或多个检查员没有为会议做好准备，主持人会重新安排会议的时间或日期，检查过程会回到准备步骤。
主持人也使用这些信息来决定如何进行检查会议。如果有大量的主要缺陷、问题和议题需要涉及，主持人可以决定在第一轮讨论中只提出这些主要项目。如果有时间，可以对工作成果进行第二轮讨论，讨论小缺陷。记住，我们的目标是在规定的时间内找到尽可能多的重要缺陷。如果有许多重大问题，那么无论如何，工作产品都可能需要重新检查。
在主持人审查了任何相关的会议程序后，会议就交给了读者。然后，主持人承担起检查员的角色，但要注意主持会议，确保检查过程得到遵守，并确保检查的重点是工作产品而不是人。读者首先呼吁对工作产品的全球问题进行检查。在前任工作产品、标准或检查表中发现的任何问题也可以在这个时候报告。记录员应记录这些问题。会议结束后，作者应将前任工作产品、标准或检查单中发现的任何缺陷告知相关负责人，以便对其进行纠正。然而，这些缺陷并没有记录在检查日志中，也没有被计入检查缺陷计数指标中。
然后，读者每次对工作产品的一个小部分进行解析，并要求对该部分的工作产品提出具体问题。检查员提出问题，并报告问题和潜在缺陷。作者回答关于工作产品的问题。团队对每个问题、议题或潜在缺陷的讨论应限于回答问题、讨论议题和确定实际缺陷，不包括讨论可能的解决方案。讨论的目的是让团队就每个问题、议题或潜在缺陷的分类（非问题、主要或次要缺陷、或开放性问题）达成共识。如果在合理的时间内（少于两分钟）无法就分类达成共识，则将其归类为一个开放性问题。记录员将所有开放的问题和已确定的缺陷及其严重程度和类型记录下来。
在讨论完工作成果的最后一节后，主持人恢复对会议的控制。如果会议时间已过，但工作产品的所有部分都没有涉及，检查小组就会安排第二次会议来完成检查。如果需要召开第二次续会，主持人要协调该会议的后勤工作。然后，记录员审查所有的缺陷和未决问题。这是一个验证步骤，以确认所有的东西都被记录下来了，而且每个项目的描述都被充分地记录下来了。
然后，检查小组就工作成果的处置达成共识。工作产品的处置包括。
现在会议的缺陷记录部分已经完成。记录员记下检查会议的结束时间和花费的总精力（会议持续时间x检查员人数）。作为检查会议过程的最后一步，团队用会议的最后几分钟来讨论改进检查过程的建议。这个步骤可以提供有用的信息，帮助持续改进检查过程。经验教训的例子可能包括。
有三个检查后会议步骤。
会议结束后，记录员记录并分发检查会议记录。
跟踪步骤的目的是验证缺陷的解决，并确认在纠正过程中没有引入其他缺陷。后续行动也是一个最后的检查，以确保所有未解决的问题都得到适当的解决。根据检查小组决定的工作产品处置情况，主持人可以执行后续步骤，也可能需要重新检查。
页面更新：2024-05-19
本站资料均由网友自行发布提供，仅用于学习交流。如有版权问题，请与我联系，QQ：4156828
© CopyRight 2020-2024 All Rights Reserved. Powered By 71396.com 闽ICP备11008920号-4
闽公网安备35020302034903号
