同行评审课件

Part1Chapter3 同行评审同行评审1Part11同行评审同行评审本章重点：本章重点：v软件缺陷与软件评审软件缺陷与软件评审v同行评审及其在同行评审及其在CMM中的地位中的地位v同行评审的方法同行评审的方法v试一试试一试v同行评审的基础设施同行评审的基础设施v同行评审的组织管理同行评审的组织管理v小测验小测验2同行评审本章重点：2同行评审概述同行评审概述(Overview to Peer Reviews）同行评审概述(Overview to Peer Revie今日要点今日要点v软件缺陷与软件评审软件缺陷与软件评审v同行评审及其在同行评审及其在CMM中的地位中的地位v同行评审的方法同行评审的方法v试一试试一试v同行评审的基础设施同行评审的基础设施v同行评审的组织管理同行评审的组织管理v小测验小测验4今日要点软件缺陷与软件评审4软件的缺陷软件的缺陷v许多缺陷是在早期阶段引入的许多缺陷是在早期阶段引入的v资料来源：AppliedSoftwareMeasurement,CapersJones5软件的缺陷许多缺陷是在早期阶段引入的5尽早消除软件缺陷的价值尽早消除软件缺陷的价值来自上个步骤的缺陷放大了的缺陷，1:X本步骤新产生的缺陷缺陷检测有效性百分比传给下个步骤的缺陷来自上个步骤的缺陷缺陷数量的放大缺陷数量的放大每个进入下个步骤每个进入下个步骤的缺陷都可能引起的缺陷都可能引起下个步骤中的多个下个步骤中的多个缺陷，导致消缺成缺陷，导致消缺成本的剧增。本的剧增。缺陷发现越晚，纠缺陷发现越晚，纠正费用越高正费用越高资料来源：Boehm,IBM,1981100010010消除一个缺陷的相对成本需求分析实际运行401000倍系统测试3070倍设计36倍编码10倍开发测试1540倍11倍6尽早消除软件缺陷的价值来自上个步骤的缺陷放大了的缺陷，1:X测试是昂贵的测试是昂贵的v传统的测试只能在生存周期的后半部分进行传统的测试只能在生存周期的后半部分进行在需求、设计等阶段进行测试是不可能的在需求、设计等阶段进行测试是不可能的v测试消耗大量的时间测试消耗大量的时间测试计划、测试数据、测试脚本、测试执行和报告、测试计划、测试数据、测试脚本、测试执行和报告、调试、修正、重新测试调试、修正、重新测试v通常测试不能发现一些特定类型的缺陷通常测试不能发现一些特定类型的缺陷（例如违背编码标准）（例如违背编码标准）7测试是昂贵的传统的测试只能在生存周期的后半部分进行7因此因此评审！评审！v评审是检查某些软件工作产品的唯一方式！评审是检查某些软件工作产品的唯一方式！v评审的正式程度、着眼点和过程都有所不同。评审的正式程度、着眼点和过程都有所不同。越早消除缺陷越早消除缺陷就越经济就越经济8因此评审！评审是检查某些软件工作产品的唯一方式！越早消除评审的理想效果评审的理想效果v在保证一定质量目标的前提下，加快研发进度：在保证一定质量目标的前提下，加快研发进度：减少修改减少修改/返工工作量返工工作量发现测试工作不能发现的缺陷发现测试工作不能发现的缺陷v内部培训与沟通内部培训与沟通新技术、标准、管理手段新技术、标准、管理手段v促进开发过程的持续改进促进开发过程的持续改进无评审无评审有评审有评审需求需求设计设计编码编码测试测试RRR9评审的理想效果在保证一定质量目标的前提下，加快研发进度：无评某公司软件评审主要形式某公司软件评审主要形式v外部评审外部评审v内部评审内部评审讨论讨论设计评审设计评审代码走查代码走查 10某公司软件评审主要形式外部评审10评审的目的评审的目的v对于项目或产品：对于项目或产品：评估阶段产品质量和开发进展情况（考核）评估阶段产品质量和开发进展情况（考核）早期发现缺陷（质量保证）早期发现缺陷（质量保证）考核与质量保证之间是存在矛盾的考核与质量保证之间是存在矛盾的v对于开发流程改进：对于开发流程改进：评估流程效果评估流程效果发现流程缺陷发现流程缺陷11评审的目的对于项目或产品：11外部评审概况外部评审概况v在项目计划中规定的时间、按照设计评审规定的在项目计划中规定的时间、按照设计评审规定的流程进行。流程进行。v常常在系统评审中进行，不单独针对软件。常常在系统评审中进行，不单独针对软件。v目前起到的主要作用：目前起到的主要作用：对项目进展情况进行考核评估对项目进展情况进行考核评估专家意见对项目的促进专家意见对项目的促进技术交流与沟通技术交流与沟通12外部评审概况在项目计划中规定的时间、按照设计评审规定的流内部评审概况内部评审概况v软件开发工作中最经常最有效的质量保证手段。软件开发工作中最经常最有效的质量保证手段。v不同部门、项目组根据各自情况自行组织。不同部门、项目组根据各自情况自行组织。v一般参考设计评审规定的流程，规范化程度降低。一般参考设计评审规定的流程，规范化程度降低。v少数部门、项目组建立了内部制度。少数部门、项目组建立了内部制度。v必要时会邀请相关外部专家。必要时会邀请相关外部专家。v效果：效果：明确设计思路，发现设计缺陷明确设计思路，发现设计缺陷加强内部技术交流，有效地促进新员工成长加强内部技术交流，有效地促进新员工成长迫于项目压力常常缺少充分的时间，难以规范化和迫于项目压力常常缺少充分的时间，难以规范化和数据化，削弱评审效果。数据化，削弱评审效果。13内部评审概况软件开发工作中最经常最有效的质量保证手段。13内部评审的一般过程内部评审的一般过程非正式走查非正式走查v非正式过程非正式过程v由作者或组长决定由作者或组长决定v用于工作产品的各个阶段用于工作产品的各个阶段v一次评审大量文档或代码一次评审大量文档或代码v确定大方向比发现缺陷更重要确定大方向比发现缺陷更重要v可能讨论替代方案和建议可能讨论替代方案和建议v不需要处理所有的评审发现不需要处理所有的评审发现v缺少正规的数据收集和后继跟踪缺少正规的数据收集和后继跟踪分析分析选择评审组举行会议收尾工作14内部评审的一般过程非正式走查非正式过程选择评审组举行会议一个小实验一个小实验v“”TestvF规则：规则：屏幕上不允许出现任何形式的屏幕上不允许出现任何形式的“F”。v统计下页屏幕上所有违背统计下页屏幕上所有违背“F规则规则”的缺陷数量。的缺陷数量。提示：注意查找所有变形。提示：注意查找所有变形。v时间：时间：30秒。秒。v不可相互交流。不可相互交流。Dr.Juran，Quality Control Handbook 15一个小实验“”Test15Jurans“F”TestHow many letter Fs can you find on this page?Write the number down in this boxFEDERAL FUSES ARE THE RESULTS OF YEARS OFSCIENTIFIC STUDY COMBINED WITH THEEXPERIENCE OF YEARS.16Jurans“F”TestHow many lette支持支持“F”规则的检查单规则的检查单vF规则：屏幕上不允许出现任何形式的规则：屏幕上不允许出现任何形式的“F”。你有没有发现含有你有没有发现含有“f”的单词，如的单词，如“of”？你有没有发现与你有没有发现与“F”形状相似的图案？形状相似的图案？你有没有检查图案边界外的屏幕？你有没有检查图案边界外的屏幕？你有没有将图案反过来或者转动角度来看？你有没有将图案反过来或者转动角度来看？你有没有检查其它符号中的你有没有检查其它符号中的“F”形状？例如字母形状？例如字母“E”？你有没有找到所有发你有没有找到所有发“F”音的数字、单词和形状？例如音的数字、单词和形状？例如14、75和和“frames”?你有没有检查屏幕后面？你有没有检查屏幕后面？你有没有检查屏幕边框和包装？你有没有检查屏幕边框和包装？你有没有检查缩略语中的你有没有检查缩略语中的“f”发音？发音？你有没有将字母你有没有将字母“t”上下颠倒再反过来看？上下颠倒再反过来看？(“t”=“f”)?问题：如何界定问题：如何界定“变形变形”？例如，？例如，“P”算不算？算不算？17支持“F”规则的检查单F规则：屏幕上不允许出现任何形式的“F实验收获实验收获v寻找缺陷是困难的寻找缺陷是困难的即使基于一个非常简单清晰的规则即使基于一个非常简单清晰的规则v检查单有助于理解规则检查单有助于理解规则有必要使用它来作为工具有必要使用它来作为工具v检查单支持但不改变规则检查单支持但不改变规则检查项依然可能有歧义检查项依然可能有歧义v使用工具（例如检查单）是要花费时间的使用工具（例如检查单）是要花费时间的返回返回18实验收获寻找缺陷是困难的返回18今日要点今日要点v软件缺陷与软件评审软件缺陷与软件评审v同行评审及其在同行评审及其在CMM中的地位中的地位v同行评审的方法同行评审的方法v试一试试一试v同行评审的基础设施同行评审的基础设施v同行评审的组织管理同行评审的组织管理v小测验小测验19今日要点软件缺陷与软件评审19CMM的成熟度等级的成熟度等级v同行评审同行评审(1)初始级初始级(Initial)不可预测，控制很差(2)可重复级可重复级(Repeatable)能够重复以前掌握的任务(3)已定义级已定义级(Defined)过程得到描述和相当充分的理解(4)已管理级已管理级(Managed)过程的度量与控制(5)优化级优化级(Optimizing)注重于过程改进20CMM的成熟度等级同行评审(1)初始级(Initial)(同行评审同行评审v目的目的尽早有效地消除软件工作产品中的缺陷尽早有效地消除软件工作产品中的缺陷v“同行评审同行评审”被定义为被定义为由生产者的同行按照预定的规程对软件工作产品进由生产者的同行按照预定的规程对软件工作产品进行的评审，目的在于发现缺陷和需要改进之处。行的评审，目的在于发现缺陷和需要改进之处。Key Practices of the Capability Maturity ModelSM,Version 1.1“同行同行”的含义是什么？的含义是什么？不具有直接上下级关系的一组相关人员不具有直接上下级关系的一组相关人员21同行评审目的21同行评审同行评审v一个第一个第3级的级的KPAv纳入该纳入该KPA的原因是的原因是实践表明同行评审能够有效地阻实践表明同行评审能够有效地阻止缺陷从一个阶段进入到下一个阶段止缺陷从一个阶段进入到下一个阶段v在第在第3级，同行评审应该是完全有效的和日常性的级，同行评审应该是完全有效的和日常性的缺陷被早期发现，而且成本较低缺陷被早期发现，而且成本较低收集了有关数据，因而有助于改进缺陷消除的过程收集了有关数据，因而有助于改进缺陷消除的过程v在更高的级别，同行评审被用于预防缺陷在更高的级别，同行评审被用于预防缺陷同行评审有效的原因在于参加者是平等的（没有同行评审有效的原因在于参加者是平等的（没有直接上级参加）直接上级参加）22同行评审一个第3级的KPA同行评审有效的原因在于参加者是平等同行评审的类型同行评审的类型v非正式评审非正式评审单人检查单人检查(“Buddy”Checks)脑力风暴脑力风暴非正式走查非正式走查v正式评审正式评审审查审查结构化走查结构化走查单人复审单人复审23同行评审的类型非正式评审23正式评审与非正式评审正式评审与非正式评审v简要对比：简要对比：24正式评审与非正式评审简要对比：24评审带来的好处评审带来的好处v生存周期各阶段的质量控制生存周期各阶段的质量控制v缺陷的早期发现缺陷的早期发现v费用节约，因为降低了费用节约，因为降低了测试工作量测试工作量失效失效维护工作量维护工作量v更好的质量计划与跟踪更好的质量计划与跟踪v更高的团队热情更高的团队热情v更低的培训费用更低的培训费用v更高的一致性更高的一致性25评审带来的好处生存周期各阶段的质量控制25CMM要求的同行评审活动要求的同行评审活动v计划同行评审并编制计划文档计划同行评审并编制计划文档确定需经同行评审的工作产品确定需经同行评审的工作产品详细说明同行评审的进度计划详细说明同行评审的进度计划v依据书面规程实施同行评审依据书面规程实施同行评审由经过培训的同行评审负责人计划和领导由经过培训的同行评审负责人计划和领导事先将评审材料分给评审人员，使他们可进行充分准备事先将评审材料分给评审人员，使他们可进行充分准备赋予评审人员在同行评审中所承担的任务赋予评审人员在同行评审中所承担的任务规定和执行同行评审准备就绪和完成的准测规定和执行同行评审准备就绪和完成的准测使用检查表识别工作产品评审的符合性原则使用检查表识别工作产品评审的符合性原则v记录同行评审的实施和结果数据记录同行评审的实施和结果数据26CMM要求的同行评审活动计划同行评审并编制计划文档26CMM明确要求同行评审的工作产品明确要求同行评审的工作产品v软件过程开发和改进计划（软件过程开发和改进计划（OPF，AC2）v组织的标准软件过程（组织的标准软件过程（OPD，AC1）v软件生存期模型（软件生存期模型（OPD，AC3）v软件风险管理计划（软件风险管理计划（ISM，AC10）v软件需求（软件需求（SPE，AC2）v设计文件（设计文件（SPE，AC3）v软件代码（软件代码（SPE，AC4）v测试计划、测试规程和测试用例（测试计划、测试规程和测试用例（SPE，AC5）v用于操作维护软件的文档（用于操作维护软件的文档（SPE，AC8）v量化过程管理计划（量化过程管理计划（QPM，AC1）v软件质量计划（软件质量计划（SQM，AC1）v缺陷预防计划（缺陷预防计划（DP，AC1）v技术更新计划（技术更新计划（TCM，AC1）v过程改进计划（过程改进计划（PCM，AC3）返回返回27CMM明确要求同行评审的工作产品软件过程开发和改进计划（OP今日要点今日要点v软件缺陷与软件评审软件缺陷与软件评审v同行评审及其在同行评审及其在CMM中的地位中的地位v同行评审的方法同行评审的方法v试一试试一试v同行评审的基础设施同行评审的基础设施v同行评审的组织管理同行评审的组织管理v小测验小测验28今日要点软件缺陷与软件评审28同行评审的若干方法同行评审的若干方法v审查审查v走查走查v单人复审单人复审29同行评审的若干方法审查296.2审查审查软件界的最佳实践之一软件界的最佳实践之一a.一种正式的评定技术。由一种正式的评定技术。由除作者之外除作者之外的某人或某一小的某人或某一小组仔细检查软件需求、设计或代码，以找出故障、违组仔细检查软件需求、设计或代码，以找出故障、违反开发标准之处和其它一些问题。反开发标准之处和其它一些问题。b.质量管理的一个阶段。在此阶段借助检查、观察或测质量管理的一个阶段。在此阶段借助检查、观察或测量来确定材料、必须品、零部件、附属品、系统、过量来确定材料、必须品、零部件、附属品、系统、过程或结构是否符合预定的质量要求。程或结构是否符合预定的质量要求。vGB/T 11457-1995 软件工程术语软件工程术语v一种正式的评价技术，由不同于作者的一组人员详细检查软件需求、设计或代码，以发现错误、与开发标准的偏离和其它问题。vIEEE Std 729-1983306.2审查软件界的最佳实践之一a.一种正式的评定技术。审查的发展审查的发展v历史：历史：1972年，年，Michael Fagan开始在开始在IBM，Kingston使用使用论文于论文于1976年在年在IEEE发表发表IBM的的Carole Jones和和Robert Mays在审查过程中加在审查过程中加入了缺陷预防方面的内容入了缺陷预防方面的内容v特点：特点：明确定义了不同的步骤明确定义了不同的步骤明确定义了角色明确定义了角色审查员经过培训审查员经过培训正式的记录正式的记录v演变：演变：Fagan审查、审查、Gilb软件审查、正式技术评审、软件审查、正式技术评审、IEEE/NASA标准标准31审查的发展历史：31审查审查v目的：目的：独立的验证独立的验证验证规格说明是否得到满足验证规格说明是否得到满足验证与标准的一致性验证与标准的一致性为后继改进收集数据为后继改进收集数据集中于发现缺陷（而不是形式或备选方案）集中于发现缺陷（而不是形式或备选方案）32审查目的：32审查的对象审查的对象v最初起源于代码审查最初起源于代码审查v实践证明可以用于对所有软件工作产品的检查实践证明可以用于对所有软件工作产品的检查软件需求说明软件需求说明软件设计说明软件设计说明源代码源代码软件测试文档软件测试文档用户手册用户手册安装规程安装规程版本发布说明版本发布说明计划等管理文档计划等管理文档33审查的对象最初起源于代码审查33正式审查正式审查(Formal Inspection)v完整定义的审查方法完整定义的审查方法定义良好的过程定义良好的过程阶段阶段规程（检查单等）规程（检查单等）定义良好的角色定义良好的角色主持人、审查员、作者、讲解员、记录员，等主持人、审查员、作者、讲解员、记录员，等定义良好的目标定义良好的目标缺陷消除、需求提取，等缺陷消除、需求提取，等定义良好的度量定义良好的度量工作表、数据收集与处理等工作表、数据收集与处理等v实例：实例：NASA的正式审查的正式审查NASA-Std-2202-93 Software Formal Inspection StandardNASA-GB-A302 Software Formal Inspection Guidebookv国内也译作国内也译作“正规检视正规检视”，如国军标。，如国军标。34正式审查(Formal Inspection)完整定义的审查业界的相关经验业界的相关经验vIBM Federal Systems Division（FSD）以以30个采用正式审查的项目和个采用正式审查的项目和30个其它项目相比较个其它项目相比较生产率（生产率（LOC/人月）人月）有审查的为有审查的为300无审查的为无审查的为144vICI，Fine Chemical Manufacturing，UK400个程序经过审查，个程序经过审查，400个未经审查个未经审查未经审查的代码的维护工作量高未经审查的代码的维护工作量高10倍倍vStandard Bank88000行代码未经审查，行代码未经审查，90000行代码经过审查行代码经过审查未经审查的代码的维护工作量高未经审查的代码的维护工作量高28倍倍v来源：TomGilb&DorothyGraham，SoftwareInspections，AddisonWesley35业界的相关经验IBM Federal Systems Div业界的相关经验业界的相关经验v一次受控的试验一次受控的试验v来源：SoftwareProductivityResearch,Inc.v发现：评审降低了总的工作量和交付后缺陷数目发现：评审降低了总的工作量和交付后缺陷数目36业界的相关经验一次受控的试验36业界的相关经验业界的相关经验v印度一家软件出口商，从事通信软件项目印度一家软件出口商，从事通信软件项目v发现：审查可以达成更高的生产率和更低的缺陷密度！发现：审查可以达成更高的生产率和更低的缺陷密度！37业界的相关经验印度一家软件出口商，从事通信软件项目37审查审查(Inspection)v一种正规的同行评审一种正规的同行评审管理人员不参加、不用于对个人的考核管理人员不参加、不用于对个人的考核相关开发人员最大程度地畅所欲言相关开发人员最大程度地畅所欲言完整定义的过程与角色完整定义的过程与角色便于计划组织与实施便于计划组织与实施经过培训的组织者经过培训的组织者/主持人主持人适当控制审查的组织和会议的进程适当控制审查的组织和会议的进程不断优化的检查单不断优化的检查单积累经验、指导审查工作积累经验、指导审查工作完整的记录和报告完整的记录和报告数据积累和过程改进数据积累和过程改进38审查(Inspection)一种正规的同行评审38审查流程审查流程准备预审审查会议第三小时修改概要介绍跟踪会议介绍复查并记录普遍异常复查并记录特定异常复查异常记录作出决议诸葛亮会延续会议两两小小时时以以内内39审查流程准备预审审查会议第三小时修改概要介审查流程审查流程v上图描述了组成审查过程的七个阶段。v此外，如果审查过程中发现了大量错误或修改已有错误的过程极其复杂，需要进行再次审查，部分阶段可能需要重复。是否需要再次审查的决定由审查组在审查会结束时做出。准备准备阶段的主要任务是决定将被审查的产品是否满足进入准则，计划审查、选择组员、安排角色、安排审查会议时间及准备并分发审查表格材料等。此外，还应该确定是否需要进行一次概要介绍。40审查流程上图描述了组成审查过程的七个阶段。40审查流程审查流程概要介绍这个阶段是可选的，在这个阶段审查组成员可以得到当前审查的相关背景资料。如果审查组成员已经对要审查的产品比较熟悉，这个阶段就可以省略。预审该阶段是审查的关键阶段，在此阶段，审查组成员单独准备审查，对要审查的产品进行复查并寻找其中的潜在异常。各成员发现的潜在异常将在本次审查会上进行讨论。41审查流程概要介绍这个阶段是可选的，在这个阶段审查组成员可以审查流程审查流程审查会议审查组集体对文档进行复查的会议，寻找、分类并记录，但是不解决异常。第三小时与审查会议分开的一段可选的附加时间，可用于对审查会上提出的问题进行讨论，讨论问题的可能解决办法或关闭悬而未决的问题。修改作者对审查中发现的异常进行修正的阶段。跟踪该阶段是主持人和作者间的一次短会，确定审查会议中发现的异常是否已经得到纠正，并检查是否引入了新的异常。42审查流程审查会议审查组集体对文档进行复查的会议，寻找、分类准备准备准备阶段的工作主要由主持人完成，他确保产品已经可以提交审查，选择审查组成员并分配角色，安排会议的地点和时间，并保证审查材料的发布。审查材料包括被审查产品，审查通知，预审记录，背景材料和检查单等。进入准则用来筛选还不能接受审查的产品。例如，代码审查的进入准则要求代码已经能够无错地通过编译。进入准则还应该规定在向审查组分发审查材料前已经执行了可用的自动工具的检查。主持人应该根据同行评审规程中规定的前提条件的要求，结合项目组实际情况确定具体的进入准则。43准备准备阶段的工作主要由主持人完成，他确保产品已经可以提交审准备准备作者将被审查产品和相关资料交给主持人后，主持人决定是否可以进行审查。主持人应该确定被审查产品的规模合理，使得审查能在一次会议上完成，如果不行，主持人应将产品分成若干可管理的部分。审查可以与其它同行评审方式混合进行以减少评审工作量，加快速度。例如，较为复杂的代码应该采用审查，较为简单的代码可以采用走查或者单人复审。44准备作者将被审查产品和相关资料交给主持人后，主持人决定是否可准备准备主持人接下来的工作是选择审查组成员并给他们安排适当角色（参见第4章）。应该使整个审查组包含了审查被审产品所需要的不同观点，并明确要求审查员是全面还是仅从某个侧面对产品进行检查。审查员可能只需要检查被审产品的某个侧面或者某些部分，这类信息应填入“同行评审计划”等工作表中的“负责的主要内容”栏。主持人应确保所有审查员理解审查过程并明确各自在预审期间的职责。通常，主持人可以参照以往类似工作产品预审记录的情况来确定检查和判断预审充足与否的准则，例如用了多少预审时间、预审期间发现多少潜在异常等。主持人应该将预审退出准则通知各位审查员，例如填写在“同行评审计划”中，或者在概要会议上说明。45准备主持人接下来的工作是选择审查组成员并给他们安排适当角色（准备准备主持人还需要选择或编制本次审查所需要的检查单等评审规则材料。本指导书附录中的检查单只是一个起点，主持人应该根据各自项目的实际情况决定直接选用还是修改编制审查所需要的检查单。作为准备过程的一部分，审查组（主要是主持人和作者）必须确定是否要在审查会议上讨论备选方案。备选方案可以在审查会议上讨论，或者在审查会后的一次独立的会议（第三小时）上讨论，也可以留给软件产品的作者去解决。一般情况下，不建议在审查会上讨论备选方案。46准备主持人还需要选择或编制本次审查所需要的检查单等评审规则材准备准备主持人还必须确定审查组成员是否对要审查的材料足够熟悉，或决定是否必须进行概要介绍。审查组应该知道产品生成的背景资料（例如，对于源代码来说就是设计和需求）。审查组还应知道材料与整个开发中的系统的关系。在大部分情况下，审查组成员根据自己在项目中从事的工作会足够熟悉审查材料，如果不是这样就应该安排作者进行概要介绍。47准备主持人还必须确定审查组成员是否对要审查的材料足够熟悉，或准备准备主持人还必须完成各项会议安排工作，包括时间安排、场地预定、设备预定等。这些工作都完成后，主持人可以完成审查计划。在该计划获得项目经理或者其指定的代表批准后，主持人将该计划发给所有审查组成员。应该将被审查产品、检查单、引用的上级文档和/或相关的同级文档，以及空白的预审记录等一同分发给所有审查组成员。由于本阶段的主要工作是编制本次审查的计划，因此，在很多关于审查方法的介绍资料中将这个阶段称为“计划”阶段。注意这里的计划仅针对本次审查活动，与软件开发计划中对整个软件生存周期内的审查的计划不同。48准备主持人还必须完成各项会议安排工作，包括时间安排、场地预定概要介绍概要介绍概要介绍（Overview）是在审查组对被审查材料及其背景不够熟悉时安排的一个可选的阶段。在概要介绍时，作者向审查组介绍产品的原理，产品与项目中其他开发中产品的关系，产品的功能及其预期的用处，以及开发该产品所用的方法。这些信息对审查组来说是必需的，这样他们才能进行成功的审查。可以邀请审查组以外感兴趣的人员参加概要介绍，但审查组成员必须全部参加。49概要介绍概要介绍（Overview）是在审查组对被审查材料及概要介绍概要介绍审查主持人必须说明角色分配。审查主持人必须回答关于检查单和角色分配的问题，并应该展示以往的审查数据，例如最短的准备时间和以往类似产品中发现异常的典型数目等。审查主持人应该根据审查组人员的被审产品的熟悉程度和工作安排决定采用会议方式还是书面文件传阅方式进行概要介绍，或者不需要进行概要介绍（例如对于再次审查）。应尽量采用会议方式，同时在会上向审查组公布角色分配等审查组织事项，回答审查员的其它问题。50概要介绍审查主持人必须说明角色分配。审查主持人必须回答关于检预审预审预审阶段是审查过程的关键阶段，在此期间，审查组成员分别根据自己在审查会中的角色做准备工作。每个审查员都要逐行审阅产品，在产品中寻找一般的问题和与自己的专业领域相关的特殊问题。审查员可以首先对照更高层的工作产品、标准和接口文档检查被审产品，根据自己的经验和理解指出潜在的异常和自己的疑问与改进建议，最后应该利用主持人指定的检查单再次核对被审产品与自己的发现，继续寻找被审产品中的异常。如果对检查单中所列的检查项得出了对被审产品不利的结论，那么应该有至少一个异常可以支持该结论。审查员同时还应该根据实际情况提出对检查单的改进意见。51预审预审阶段是审查过程的关键阶段，在此期间，审查组成员分别根预审预审审查员应在预审记录表中记录预审中发现的异常和预审花费的时间。应在审查会前将完成的预审记录提交给审查主持人，并由主持人将预审记录表转交作者，以便作者为解释审查员的问题、解决提出的异常等作准备。预审记录应采用同行评审预审记录表。表中记录的异常分类应该按照该标准进行严重性分类，同时，应该记录审查员在预审提出的所有问题和改进建议。讲解员还应该确定在审查会议上讲解被审产品的方式。52预审审查员应在预审记录表中记录预审中发现的异常和预审花费的时预审预审审查会前，主持人检查每位审查员提交的记录以确定审查组是否进行了充分的准备。主持人还应检查出审查会议时需要特别注意的地方、可以快速归类的普通异常和需要重点关注的部分。如果预审记录表明审查组尚未做好充分准备，主持人应当重新安排审查会议时间，因为准备不足的审查组将浪费时间，并且不能有效发现异常。预审记录表将在审查会上发还给审查员供他们用于指出异常。本阶段的时间至少需要两天。另外，预审的速度不宜太快。按照业界经验，代码的预审速度应为每小时100行左右，文档的预审速度应为每小时150行左右。53预审审查会前，主持人检查每位审查员提交的记录以确定审查组是否审查会议审查会议审查会议阶段也常称为检查或者检查会议，在此期间，审查员一起复查产品。发现异常依然是审查会议的焦点。简要地说，审查会上的主要活动有：讲解员对文档进行合理的宣读和阐述，必要时作者提供解释信息，审查组识别异常并进行分类和记录。审查会议的速度也应该控制在合理的范围内。按照业界经验，代码的会议审查速度为每小时125行左右，文档的会议审查速度应为每小时150行左右。54审查会议审查会议阶段也常称为检查或者检查会议，在此期间，审查会议介绍会议介绍审查主持人必须介绍参加者并说明他们的角色。审查主持人必须重申审查的目的并应提醒审查员集中精力于异常发现而非解决。审查主持人应当提醒审查员直接将他们的意见告知记录员，并且仅对软件产品作评论，不对其作者作评论。审查员可以向作者提出关于软件产品的问题。审查主持人必须解决审查员提出的任何特殊的程序性问题。主持人将预审记录发还给各审查员，开始复查并记录异常。55会议介绍审查主持人必须介绍参加者并说明他们的角色。审查主持人复查并记录普遍异常复查并记录普遍异常 普遍异常是指在审查对象中普遍存在，而不能定位于某个特定位置的异常或者问题、建议等。概念理解错误、术语使用不规范、图形符号应用不当等都是常见的普遍异常。每位审查员分别向审查组说明他发现的普遍异常，审查组讨论并达成关于该事项的异常严重性等级、引入阶段、类型等一致意见后，由记录员根据主持人示意记录在异常记录表中。56复查并记录普遍异常 普遍异常是指在审查对象中普遍存在，而不能复查并记录特定异常复查并记录特定异常 然后讲解员开始按合理的顺序解读产品。讲解员对文档各组成部分（段落，代码块）的功能、结构及他们与更高一级文档的关系进行阐述。审查员可以在觉得可能包含异常的地方打断宣读过程，如果需要对可能的异常进行短时间讨论，宣读可以临时停止。在异常被提出和归类并由记录员记录到异常列表后讲解继续进行。主持人必须将这一阶段的会议集中在创建异常清单。应对讨论进行时间限制以防止浪费过多的时间。如果问题在有限的时间里不能得到解决，主持人应宣布该问题暂且搁置，讲解继续进行。遗留问题处于打开状态并在第三小时阶段进行讨论。57复查并记录特定异常 然后讲解员开始按合理的顺序解读产品。讲解复查并记录特定异常复查并记录特定异常 记录员必须根据主持人的示意在异常清单中记录每个异常及其位置、描述和严重性等级、引入阶段和分类。审查组对每一个提出的异常是否是实际异常都要达成共识，有时实际是审查员的错误，或者是通过作者的解释而弄明白的误解。作者必须根据他对软件产品的特殊理解回答细节问题并参与查找异常。如果不能达成共识，该问题应该搁置并处于打开状态而在第三小时阶段重新讨论。因此，在会议检查期间（包括第三小时）得出的异常记录中，最终不应该存在“疑问”或者“改进意见”，而应该将所有问题都归结为是否异常、严重性等级如何。注意改进意见也应该归结为异常。58复查并记录特定异常 记录员必须根据主持人的示意在异常清单中记复查并记录特定异常复查并记录特定异常 可以通过参考上级文档确定提出的问题是不是一个实际的异常，如果确定上级文档存存在潜在错误，应将问题记录为打开状态并继续审查。问题的解决（确定问题究竟是该文档的还是上级文档的）可以放到第三小时阶段。如果本次审查未能确定该问题，则应将这些问题也记录于审查报告中（可记录在备注栏）。59复查并记录特定异常 可以通过参考上级文档确定提出的问题是不是复查并记录特定异常复查并记录特定异常 为确定修正产品异常的优先顺序，审查组或主持人应区分异常的严重性（重要的或次要的）。例如：导致系统不能满足需求的异常应定为重要的；所有其它异常都分类为中等或次要的（诸如排版问题、较小的与标准不一致等问题）。审查期间还要收集的数据是异常的类型，诸如数据错误，需求符合性、标准符合性、逻辑、接口，数据，性能及可靠性等。应依据同行评审异常分类指导书进行异常分类。为了确定异常记录的完整清晰，记录员每次完成一项异常记录后应将记录宣读一遍，以获得审查组的认可。此后讲解员才能继续讲解。60复查并记录特定异常 为确定修正产品异常的优先顺序，审查组或主复查异常清单复查异常清单 在审查会议最后，审查主持人应当与审查组一起复查异常清单以保证其完整性和精确性，并汇总各类异常数目。记录员宣读他记录的异常清单，所有审查员表示是否还有异议。审查主持人应当留出时间来讨论每个存在不同意见的异常。审查主持人不应允许讨论注重于该异常的解决，而应澄清该异常的构成。61复查异常清单 在审查会议最后，审查主持人应当与审查组一起复查作出决议作出决议作出决议的目的是明确地结束审查会议。决议必须确定是否需要其它会议，判断该软件产品经过必要的修改后是否满足审查的退出准则，并必须规定所有必要的修改工作及验证。特别是，审查组必须确定软件产品的处理方式为以下三种之一：l不修改或作少量修改，不再需要进一步验证。l需要修改并由主持人或其指定的作者以外的审查员验证。l需要再次审查以验证修改工作。再次审查至少必须检查为解决本次审查发现的异常而修改了的软件产品部分以及这些修改的副作用。再次审查是对已经审查过的产品全部或局部地重复审查过程，应当另行计划组织和实施，产生独立的审查报告。62作出决议作出决议的目的是明确地结束审查会议。决议必须确定是否作出决议作出决议主持人可以根据作者的意见和审查会议遗留的问题情况决定是否需要进行审查的第三小时阶段，如果需要，这时要对每一个审查员安排后继的相关工作。审查会后，主持人和作者简短会面，估计修改工作时间并安排跟踪会议。作者得到一份异常清单的拷贝作为修改参考。注意并不针对被审文档或代码中发现的异常编制变更请求，因为这时的被审查产品尚未纳入配置管理控制。然而应针对在较高层文档中发现的任何异常编制变更请求，纳入公司的缺陷管理和变更控制。63作出决议主持人可以根据作者的意见和审查会议遗留的问题情况决定作出决议作出决议主持人应将审查发现的同一软件生存周期中与被评审产品有接口关系的软件产品中的异常通报给该产品的作者及其上级管理人员，由他们决定后继处理方式。如果该产品已经形成基线，则应纳入变更控制流程进行处理。64作出决议主持人应将审查发现的同一软件生存周期中与被评审产品有延续会议延续会议 为避免疲劳以及因此带来的遗漏异常，审查会议时间应该控制在两小时内。如果主持人预计会议将超过2小时，就应该提前中止记录异常的工作，复查已经记录的异常，并安排延续会议。延续会议应由审查会议参加者按照原来的角色参加。会议期间继续未完成的异常记录工作，并复查所有的异常记录，作出决议。65延续会议 为避免疲劳以及因此带来的遗漏异常，审查会议时间应该诸葛亮会诸葛亮会 诸葛亮会是一次可选的非正式的附加会议，目的是为软件过程改进积累素材。诸葛亮会应与审查会议一同进行（合计时间不超过2小时或者超过时间不多），诸葛亮会采取“脑力风暴“的形式，时间应控制在15至30分钟，由主持人选择审查期间发现的5个到10个重要异常，逐个提出，由审查员分别提出导致这些异常的根本原因及其预防措施。每个异常的讨论时间不得超过3分钟。诸葛亮会的目的是为软件过程改进积累素材。不需要在诸葛亮会期间进行深入讨论，只需要进行完整的记录（包括相互矛盾的意见）并将记录纳入审查报告。66诸葛亮会 诸葛亮会是一次可选的非正式的附加会议，目的是为软件诸葛亮会诸葛亮会 主持人根据项目组情况和审查中发现的异常情况决定是否需要进行诸葛亮会，向审查组介绍诸葛亮会的目的和形式，提出需要讨论的异常，严格控制时间。审查员首先要尽快根据主持人提出的异常确定自己是否在准备阶段发现了该缺陷，然后用几个关键词语来说明自己对异常发生原因和预防措施的看法。记录员记录各位审查员的看法，包括相互矛盾的内容。67诸葛亮会 主持人根据项目组情况和审查中发现的异常情况决定是否第三小时第三小时 第三小时是一次可选的非正式的附加会议或活动，应当与审查会议分别进行。第三小时期间，可以得出关于审查会议中记录的未解决事项的决定，也可以讨论审查中发现的缺陷的解决方案。第三小时阶段是对未关闭的问题进行讨论和关闭的阶段。如果作者希望对异常的修改进行讨论，或在上级（高层的参考）文档中有潜在的重大异常等未关闭的问题需要处置时，应安排第三小时阶段。第三小时可以采用另行组织一次会议的形式，也可以是组员们执行某些任务并做报告。第三小时阶段不必在审查会后立即进行，也不必限制在一小时。如果确定处于配置管理下的上级文档或者同级的相关文档中存在异常，应该在第三小时阶段编写变更申请。68第三小时 第三小时是一次可选的非正式的附加会议或活动，应当与第三小时第三小时 如果以会议形式进行第三小时阶段，就有了讨论解决问题和处理不一致意见的机会。参与者可以包括审查组部分或全体成员，也可包括项目经理（只有在技术原因需要时）、外部技术专家以及在修改错误和解决问题过程中可能涉及到的其他人员。多数情况下只有那些有特殊兴趣的审查员需要参加。在第三小时阶段，作者可以得到解决问题的更为有效的方法，上级文档的缺陷被报告，所有处于打开状态的问题得到解决。第三小时既可能讨论异常的定性，也可以讨论异常的解决方案。为了统计完整易于分析，这两部分时间应该分别记录在“同行评审报告”中，用于得到更为准确的异常发现数据。69第三小时 如果以会议形式进行第三小时阶段，就有了讨论解决问题修改修改修改阶段的目的是改正审查中发现的异常。作者负责更正异常记录表中记录的应修改的所有异常。主持人应保证异常记录表已经传递给了作者并得到了作者的处理。70修改修改阶段的目的是改正审查中发现的异常。作者负责更正异常记再次审查再次审查 如果产品中存在大量异常，或者一个或多个异常需要大范围的或复杂的改正工作时，应当进行再次审查。再次审查时，由整个审查组而不仅仅是主持人来复查产品中的修改。主持人和审查组在审查会结束时应决定是否需要进行再次审查。71再次审查 如果产品中存在大量异常，或者一个或多个异常需要大范跟踪跟踪主持人和作者应进行简短的交流，确定所有的重要问题都得到了正确的解决且没有因修改而产生新的问题。作者向主持人介绍修改每个重要问题所采取的方法。主持人保证所有的重要问题都得到解决。对次要异常的修正也应该复查，但是不是重点。如果有技术需要，主持人也可邀请其他的技术专家参加跟踪工作。如果所有的重要异常都已改正，异常记录表中所有的处理建议都得到了实施，产品满足了退出准则，主持人就可以在审查报告上记录完成情况以“通过”该产品。否则，作者就需要回到修改阶段继续进行必要的修改。72跟踪主持人和作者应进行简短的交流，确定所有的重要问题都得到了审查的角色审查的角色v37人人v主持人（主持人（Moderator）v讲解员（讲解员（Reader）v记录员（记录员（Recorder）v作者（作者（Author）v审查员（审查员（Inspector）73审查的角色37人73主持人主持人v需要领导技巧需要领导技巧v管理审查过程，保证效果：管理审查过程，保证效果：保持公正无私保持公正无私确保满足进入和退出准则确保满足进入和退出准则确保审查员准备充分确保审查员准备充分进行收尾工作进行收尾工作不一定来自同一项目不一定来自同一项目v主持人是关键！主持人是关键！v不仅要控制进程，还要控制气不仅要控制进程，还要控制气氛氛74主持人需要领导技巧74记录员记录员v按照主持人的示意记录异常按照主持人的示意记录异常v记录的同时记录异常分类记录的同时记录异常分类v大声朗读记录下来的缺陷大声朗读记录下来的缺陷在每次记录之后在每次记录之后最后朗读整个记录表最后朗读整个记录表v笔迹清晰，文字简明笔迹清晰，文字简明75记录员按照主持人的示意记录异常75讲解员讲解员v充分理解审查材料充分理解审查材料v讲解时加以解释讲解时加以解释v合理把握讲解的速度合理把握讲解的速度v等待记录员完成记录后继等待记录员完成记录后继续讲解续讲解v讲解员不能由作者担当讲解员不能由作者担当76讲解员充分理解审查材料76作者作者v收集与分发材料收集与分发材料v提供概要介绍提供概要介绍v能够参加审查以作出必要澄清能够参加审查以作出必要澄清v同时作为审查员同时作为审查员v不要有自我防卫心理不要有自我防卫心理77作者收集与分发材料77审查员审查员v所有人（主持人、讲解员、所有人（主持人、讲解员、记录员、作者）都是审查员记录员、作者）都是审查员v理解被审材料理解被审材料v进行个人检查进行个人检查v做好准备并参加会议做好准备并参加会议v寻找产品中的异常，而不是寻找产品中的异常，而不是针对作者针对作者v坦诚友善，言简意赅坦诚友善，言简意赅78审查员所有人（主持人、讲解员、记录员、作者）都是审查员78不同观点不同观点v不仅要分配审查角色，还需要不同的立场与观点不仅要分配审查角色，还需要不同的立场与观点v具体的需要取决于被审查项的类型具体的需要取决于被审查项的类型v下表给出了推荐的组合：下表给出了推荐的组合：79不同观点不仅要分配审查角色，还需要不同的立场与观点79有效评审的若干原则有效评审的若干原则v预审期间使用检查单预审期间使用检查单v避免过度依赖检查单避免过度依赖检查单v审查会议限制在审查会议限制在2小时内小时内v审查产品而非生产者审查产品而非生产者v避免长时间讨论避免长时间讨论在一个问在一个问题上的讨论不要超过题上的讨论不要超过5分钟分钟v对评审员提供足够的预审时间对评审员提供足够的预审时间（至少提前两天）（至少提前两天）v如果有人未准备好，则将会议如果有人未准备好，则将会议延期延期v如果实在没有时间如果实在没有时间取消！取消！80有效评审的若干原则预审期间使用检查单80NAH综合症的对策综合症的对策vNot Applicable Here？v组织对比实验，让事实说话：组织对比实验，让事实说话：随机选择项目中若干变更请求随机选择项目中若干变更请求一组人员，两种分工一组人员，两种分工单元测试单元测试审查（先经过必要培训）审查（先经过必要培训）对于同一变更，不能相互交流对于同一变更，不能相互交流数据记录与对比分析数据记录与对比分析81NAH综合症的对策Not Applicable Here？8NAH综合症的对策综合症的对策vNot Applicable Here？Infosys的试验结果：的试验结果：代码行968432856675040826102610工时8.05.04.06.512.52.527.527.5缺陷数88426355454工时2.01.51.51.51.52.510.510.5缺陷数4317052020增强123456合计合计审 查单元测试还可以继续对比缺陷分布等情况还可以继续对比缺陷分布等情况82NAH综合症的对策Not Applicable Here？NAH综合症的对策综合症的对策vNot Applicable Here？Infosys的试验结果（二）：的试验结果（二）：审查34141211555454单元测试121150012020重合缺陷00740011212缺陷类型数据功能接口逻辑可维护性可移植性其它合计合计结论：审查可以弥补测试的不足，并节省大量的后继时间。结论：审查可以弥补测试的不足，并节省大量的后继时间。83NAH综合症的对策Not Applicable Here？实施审查的要点与难点实施审查的要点与难点v良好的计划和会议控制良好的计划和会议控制v合理的审查速度控制合理的审查速度控制v长期积累的量化数据及其控制意义（审查速度、异常长期积累的量化数据及其控制意义（审查速度、异常密度等）密度等）v不断改进的检查单不断改进的检查单v诸葛亮会及其对过程改进的作用诸葛亮会及其对过程改进的作用v技术领导如何参加审查？技术领导如何参加审查？v审查是否可以代替基线评审和测试？审查是否可以代替基线评审和测试？84实施审查的要点与难点良好的计划和会议控制846.3走查（走查（Walkthrough）v比审查简单易行的一种同行评审比审查简单易行的一种同行评审v决不仅限于决不仅限于“代码走查代码走查”v走查由一组评审员经过一系列步骤或阶段完成的评审走查由一组评审员经过一系列步骤或阶段完成的评审活动。走查的过程比审查简单，走查组的角色构成也活动。走查的过程比审查简单，走查组的角色构成也相对简单，包括主持人、记录员、作者和评审员，没相对简单，包括主持人、记录员、作者和评审员，没有讲解员的角色。有讲解员的角色。856.3走查（Walkthrough）比审查简单易行的一种同行走查过程走查过程准备预审走查会议修改跟踪会议介绍概要介绍产品复查并记录普遍异常走查并记录特定异常小结86走查过程准备预审走查会议修改跟踪会议介绍走查过程的五个阶段走查过程的五个阶段v准备 准备阶段的主要任务是决定将被走查的产品是否满足进入准则，计划走查、选择评审员、安排角色、安排走查会议时间及准备并分发走查表格材料等。v预审 该阶段是走查的关键阶段，在此阶段，走查组成员单独对要走查的产品进行复查并寻找其中的潜在异常。各成员发现的潜在异常将在本次走查会上进行讨论。v走查会议走查组集体对文档进行复查的会议，寻找、分类并记录，有时也讨论异常的解决方案。v修改 作者对走查中发现的异常进行修正的阶段。v跟踪 该阶段是主持人和作者间的一次短会，确定走查会议中发现的异常是否已经得到纠正，并确保没有引入新的异常。87走查过程的五个阶段87走查与审查的主要区别走查与审查的主要区别v虽然走查的主要目的也是发现异常，但是走查会议期间通常可以讨论异常的解决方案以帮助作者改进产品。（审查过程中，这类活动应当在第三小时进行。）v走查会议时间要求不严格，虽然经验表明，超过两个小时后的会议效率会明显降低。v不需要独立的概要介绍阶段来为预审提供坚实的基础。作者应该在走查会议初期对产品进行概要介绍并回答问题。88走查与审查的主要区别虽然走查的主要目的也是发现异常，但是走查走查与审查的主要区别走查与审查的主要区别v不设专门的讲解员，由作者讲解v作者可以担任主持人或记录员（不宜同时担任）v记录员不需要在每条异常记录下来后进行复述以供走查组认可。但是在会议小结期间宣读所有的异常记录供走查组认可还是必要的。v通常不需要再次走查。如果发现的异常过多而且涉及面广，可以考虑对修改后的产品进行审查。v不设诸葛亮会、第三小时等可选环节89走查与审查的主要区别不设专门的讲解员，由作者讲解896.4单人复审单人复审v正规化的正规化的“Buddy Check”，简化的走查，简化的走查预审预审检查会议检查会议修改与跟踪修改与跟踪v同样应产生书面记录同样应产生书面记录906.4单人复审正规化的“Buddy Check”，简化的走查单人复审单人复审v单人复审可以视为两人进行的走查，但是由于人数少，准备和计划工作要简单很多，更接近于文档会签过程中的审核。v按照与审查、走查类似的思路引入检查单、异常记录表和评审报告等形式化的活动，可以有效地提高评审员和作者对单人复审的重视程度，提高评审效果，并且积累后继工作方式改进的数据。v单人复审由作者和评审员两人进行。作者应向有关领导提出复审申请，并建议担任评审员的人员。作者的上级领导应该根据实际情况确定是否进行单人复审并指定评审员。91单人复审单人复审可以视为两人进行的走查，但是由于人数少，准备单人复审单人复审v随后，评审员从作者处获得被评审产品和相关资料，选择适用的检查单，对产品进行预审并填写异常记录表。为了简化操作，这时不需要填写“同行评审预审表”，而是直接填写“同行评审异常记录表”。v预审完成后，评审员与作者进行一次简短的非正式会议，逐条讨论预审期间发现的异常，确定其分类情况和后继处理要求。在此期间，作者和评审员都应该注意发现新的异常，而不应只局限于预审结果，并将新的异常及其处理意见也记录下来。v作者同样要根据异常记录表对产品进行必要的修改。评审员应该验证修改情况，并最终完成同行评审报告。92单人复审随后，评审员从作者处获得被评审产品和相关资料，选择适今日要点今日要点v软件缺陷与软件评审软件缺陷与软件评