同行评审精品PPT课件.ppt

1、 1 Part1Chapter3 同行评审同行评审 2 同行评审同行评审本章重点：本章重点：v软件缺陷与软件评审软件缺陷与软件评审v同行评审及其在同行评审及其在CMM中的地位中的地位v同行评审的方法同行评审的方法v试一试试一试v同行评审的基础设施同行评审的基础设施v同行评审的组织管理同行评审的组织管理v小测验小测验同行评审概述同行评审概述(Overview to Peer Reviews） 4 今日要点今日要点v软件缺陷与软件评审软件缺陷与软件评审v同行评审及其在同行评审及其在CMM中的地位中的地位v同行评审的方法同行评审的方法v试一试试一试v同行评审的基础设施同行评审的基础设施v同行评审的组

2、织管理同行评审的组织管理v小测验小测验 5 软件的缺陷软件的缺陷交付后的缺陷分布交付后的缺陷分布需求15%设计40%编码30%文档5%改错10%v 许多缺陷是在早期阶段引入的许多缺陷是在早期阶段引入的v资料来源： Applied Software Measurement, Capers Jones 6 尽早消除软件缺陷的价值尽早消除软件缺陷的价值来自上个步骤的缺陷放大了的缺陷，1:X本步骤新产生的缺陷缺陷检测有效性百分比传给下个步骤的缺陷来自上个步骤的缺陷缺陷数量的放大缺陷数量的放大每个进入下个步骤每个进入下个步骤的缺陷都可能引起的缺陷都可能引起下个步骤中的多个下个步骤中的多个缺陷，导致消缺成

3、缺陷，导致消缺成本的剧增。本的剧增。缺陷发现越晚，纠缺陷发现越晚，纠正费用越高正费用越高资料来源：Boehm, IBM, 1981100010010消除一个缺陷的相对成本需求分析实际运行401000倍系统测试3070倍设计36倍编码10倍开发测试1540倍11倍 7 测试是昂贵的测试是昂贵的v 传统的测试只能在生存周期的后半部分进行传统的测试只能在生存周期的后半部分进行在需求、设计等阶段进行测试是不可能的在需求、设计等阶段进行测试是不可能的v 测试消耗大量的时间测试消耗大量的时间测试计划、测试数据、测试脚本、测试执行和报告、测试计划、测试数据、测试脚本、测试执行和报告、调试、修正、重新测试调试

4、、修正、重新测试v 通常测试不能发现一些特定类型的缺陷通常测试不能发现一些特定类型的缺陷（例如违背编码标准）（例如违背编码标准） 8 因此因此评审！评审！v评审是检查某些软件工作产品的唯一方式！评审是检查某些软件工作产品的唯一方式！v评审的正式程度、着眼点和过程都有所不同。评审的正式程度、着眼点和过程都有所不同。越早消除缺陷越早消除缺陷就越经济就越经济 9 评审的理想效果评审的理想效果v 在保证一定质量目标的前提下，加快研发进度：在保证一定质量目标的前提下，加快研发进度：减少修改减少修改/返工工作量返工工作量发现测试工作不能发现的缺陷发现测试工作不能发现的缺陷v 内部培训与沟通内部培训与沟通新

5、技术、标准、管理手段新技术、标准、管理手段v 促进开发过程的持续改进促进开发过程的持续改进无评审无评审有评审有评审需求需求设计设计编码编码测试测试RRR 10 某公司软件评审主要形式某公司软件评审主要形式v 外部评审外部评审v 内部评审内部评审讨论讨论设计评审设计评审代码走查代码走查 11 评审的目的评审的目的v 对于项目或产品：对于项目或产品：评估阶段产品质量和开发进展情况（考核）评估阶段产品质量和开发进展情况（考核）早期发现缺陷（质量保证）早期发现缺陷（质量保证）考核与质量保证之间是存在矛盾的考核与质量保证之间是存在矛盾的v 对于开发流程改进：对于开发流程改进：评估流程效果评估流程效果发现

6、流程缺陷发现流程缺陷 12 外部评审概况外部评审概况v 在项目计划中规定的时间、按照在项目计划中规定的时间、按照设计评审规定设计评审规定的的流程进行。流程进行。v 常常在系统评审中进行，不单独针对软件。常常在系统评审中进行，不单独针对软件。v 目前起到的主要作用：目前起到的主要作用：对项目进展情况进行考核评估对项目进展情况进行考核评估专家意见对项目的促进专家意见对项目的促进技术交流与沟通技术交流与沟通 13 内部评审概况内部评审概况v 软件开发工作中最经常最有效的质量保证手段。软件开发工作中最经常最有效的质量保证手段。v 不同部门、项目组根据各自情况自行组织。不同部门、项目组根据各自情况自行组

7、织。v 一般参考一般参考设计评审规定设计评审规定的流程，规范化程度降低。的流程，规范化程度降低。v 少数部门、项目组建立了内部制度。少数部门、项目组建立了内部制度。v 必要时会邀请相关外部专家。必要时会邀请相关外部专家。v 效果：效果：明确设计思路，发现设计缺陷明确设计思路，发现设计缺陷加强内部技术交流，有效地促进新员工成长加强内部技术交流，有效地促进新员工成长迫于项目压力常常缺少充分的时间，难以规范化和迫于项目压力常常缺少充分的时间，难以规范化和数据化，削弱评审效果。数据化，削弱评审效果。 14 内部评审的一般过程内部评审的一般过程非正式走查非正式走查v 非正式过程非正式过程v 由作者或组长

8、决定由作者或组长决定v 用于工作产品的各个阶段用于工作产品的各个阶段v 一次评审大量文档或代码一次评审大量文档或代码v 确定大方向比发现缺陷更重要确定大方向比发现缺陷更重要v 可能讨论替代方案和建议可能讨论替代方案和建议v 不需要处理所有的评审发现不需要处理所有的评审发现v 缺少正规的数据收集和后继跟缺少正规的数据收集和后继跟踪分析踪分析选择评审组举行会议收尾工作 15 一个小实验一个小实验v “” Testv F规则：规则：屏幕上不允许出现任何形式的屏幕上不允许出现任何形式的“F”。v 统计下页屏幕上所有违背统计下页屏幕上所有违背“F规则规则”的缺陷数量。的缺陷数量。提示：注意查找所有变形。

9、提示：注意查找所有变形。v 时间：时间：30秒。秒。v 不可相互交流。不可相互交流。Dr. Juran，Quality Control Handbook 16 Jurans “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. 17 支持支持“F”规则的检查单规则的检查单v F规则：屏幕上

10、不允许出现任何形式的规则：屏幕上不允许出现任何形式的“F”。 你有没有发现含有你有没有发现含有“f”的单词，如的单词，如“of”？ 你有没有发现与你有没有发现与“F”形状相似的图案？形状相似的图案？ 你有没有检查图案边界外的屏幕？你有没有检查图案边界外的屏幕？ 你有没有将图案反过来或者转动角度来看？你有没有将图案反过来或者转动角度来看？ 你有没有检查其它符号中的你有没有检查其它符号中的“F”形状？例如字母形状？例如字母“E”？ 你有没有找到所有发你有没有找到所有发“F”音的数字、单词和形状？例如音的数字、单词和形状？例如14、75和和“frames”? 你有没有检查屏幕后面？你有没有检查屏幕后

11、面？ 你有没有检查屏幕边框和包装？你有没有检查屏幕边框和包装？ 你有没有检查缩略语中的你有没有检查缩略语中的“f”发音？发音？ 你有没有将字母你有没有将字母“t”上下颠倒再反过来看？上下颠倒再反过来看？ (“t”= “f”)? 问题：如何界定问题：如何界定“变形变形”？例如，？例如，“P”算不算？算不算？ 18 实验收获实验收获v 寻找缺陷是困难的寻找缺陷是困难的即使基于一个非常简单清晰的规则即使基于一个非常简单清晰的规则v 检查单有助于理解规则检查单有助于理解规则有必要使用它来作为工具有必要使用它来作为工具v 检查单支持但不改变规则检查单支持但不改变规则检查项依然可能有歧义检查项依然可能有歧

12、义v 使用工具（例如检查单）是要花费时间的使用工具（例如检查单）是要花费时间的 19 今日要点今日要点v软件缺陷与软件评审软件缺陷与软件评审v同行评审及其在同行评审及其在CMM中的地位中的地位v同行评审的方法同行评审的方法v试一试试一试v同行评审的基础设施同行评审的基础设施v同行评审的组织管理同行评审的组织管理v小测验小测验 20 CMM的成熟度等级的成熟度等级v 同行评审同行评审(1) 初始级初始级(Initial)不可预测，控制很差(2) 可重复级可重复级(Repeatable)能够重复以前掌握的任务(3) 已定义级已定义级(Defined)过程得到描述和相当充分的理解(4) 已管理级已管

13、理级(Managed)过程的度量与控制(5) 优化级优化级(Optimizing)注重于过程改进 21 同行评审同行评审v 目的目的尽早有效地消除软件工作产品中的缺陷尽早有效地消除软件工作产品中的缺陷v “同行评审同行评审”被定义为被定义为由生产者的同行按照预定的规程对软件工作产品进由生产者的同行按照预定的规程对软件工作产品进行的评审，目的在于发现缺陷和需要改进之处。行的评审，目的在于发现缺陷和需要改进之处。Key Practices of the Capability Maturity ModelSM , Version 1.1“同行同行”的含义是什么？的含义是什么？ 不具有直接上下级关系的

14、一组相关人员不具有直接上下级关系的一组相关人员 22 同行评审同行评审v 一个第一个第3级的级的KPAv 纳入该纳入该KPA的原因是的原因是实践表明同行评审能够有效地阻实践表明同行评审能够有效地阻止缺陷从一个阶段进入到下一个阶段止缺陷从一个阶段进入到下一个阶段v 在第在第3级，同行评审应该是完全有效的和日常性的级，同行评审应该是完全有效的和日常性的缺陷被早期发现，而且成本较低缺陷被早期发现，而且成本较低收集了有关数据，因而有助于改进缺陷消除的过程收集了有关数据，因而有助于改进缺陷消除的过程v 在更高的级别，同行评审被用于预防缺陷在更高的级别，同行评审被用于预防缺陷同行评审有效的原因在于参加者是

15、平等的（没有同行评审有效的原因在于参加者是平等的（没有直接上级参加）直接上级参加） 23 同行评审的类型同行评审的类型v 非正式评审非正式评审单人检查单人检查(“Buddy” Checks)脑力风暴脑力风暴非正式走查非正式走查v 正式评审正式评审审查审查结构化走查结构化走查单人复审单人复审 24 正式评审与非正式评审正式评审与非正式评审v 简要对比：简要对比： 25 评审带来的好处评审带来的好处v 生存周期各阶段的质量控制生存周期各阶段的质量控制v 缺陷的早期发现缺陷的早期发现v 费用节约，因为降低了费用节约，因为降低了测试工作量测试工作量失效失效维护工作量维护工作量v 更好的质量计划与跟踪更

16、好的质量计划与跟踪v 更高的团队热情更高的团队热情v 更低的培训费用更低的培训费用v 更高的一致性更高的一致性 26 CMM要求的同行评审活动要求的同行评审活动v 计划同行评审并编制计划文档计划同行评审并编制计划文档 确定需经同行评审的工作产品确定需经同行评审的工作产品 详细说明同行评审的进度计划详细说明同行评审的进度计划v 依据书面规程实施同行评审依据书面规程实施同行评审 由经过培训的同行评审负责人计划和领导由经过培训的同行评审负责人计划和领导 事先将评审材料分给评审人员，使他们可进行充分准备事先将评审材料分给评审人员，使他们可进行充分准备 赋予评审人员在同行评审中所承担的任务赋予评审人员在

17、同行评审中所承担的任务 规定和执行同行评审准备就绪和完成的准测规定和执行同行评审准备就绪和完成的准测 使用检查表识别工作产品评审的符合性原则使用检查表识别工作产品评审的符合性原则v 记录同行评审的实施和结果数据记录同行评审的实施和结果数据 27 CMM明确要求同行评审的工作产品明确要求同行评审的工作产品v 软件过程开发和改进计划（软件过程开发和改进计划（OPF，AC2）v 组织的标准软件过程（组织的标准软件过程（OPD，AC1）v 软件生存期模型（软件生存期模型（OPD，AC3）v 软件风险管理计划（软件风险管理计划（ISM，AC10）v 软件需求（软件需求（SPE，AC2）v 设计文件（设计

18、文件（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） 28 今日要点今日要点v软件缺陷与软件评审软件缺陷与软件评审v同行评审及其在同行评审及其在CMM中的地位中的地位v同行评审的方法同行评审的方法

19、v试一试试一试v同行评审的基础设施同行评审的基础设施v同行评审的组织管理同行评审的组织管理v小测验小测验 29 同行评审的若干方法同行评审的若干方法v 审查审查v 走查走查v 单人复审单人复审 30 6.2审查审查软件界的最佳实践之一软件界的最佳实践之一a. 一种正式的评定技术。由一种正式的评定技术。由除作者之外除作者之外的某人或某一小的某人或某一小组仔细检查软件需求、设计或代码，以找出故障、违组仔细检查软件需求、设计或代码，以找出故障、违反开发标准之处和其它一些问题。反开发标准之处和其它一些问题。b. 质量管理的一个阶段。在此阶段借助检查、观察或测质量管理的一个阶段。在此阶段借助检查、观察或

20、测量来确定材料、必须品、零部件、附属品、系统、过量来确定材料、必须品、零部件、附属品、系统、过程或结构是否符合预定的质量要求。程或结构是否符合预定的质量要求。vGB/T 11457-1995 软件工程术语软件工程术语v一种正式的评价技术，由不同于作者的一组人员详细检查软件需求、设计或代码，以发现错误、与开发标准的偏离和其它问题。vIEEE Std 729-1983 31 审查的发展审查的发展v 历史：历史：1972年，年，Michael Fagan开始在开始在IBM，Kingston使用使用论文于论文于1976年在年在IEEE发表发表IBM的的Carole Jones和和Robert Mays

21、在审查过程中加在审查过程中加入了缺陷预防方面的内容入了缺陷预防方面的内容v 特点：特点：明确定义了不同的步骤明确定义了不同的步骤明确定义了角色明确定义了角色审查员经过培训审查员经过培训正式的记录正式的记录v 演变：演变：Fagan审查、审查、Gilb软件审查、正式技术评审、软件审查、正式技术评审、IEEE/NASA标准标准 32 审查审查v 目的：目的：独立的验证独立的验证验证规格说明是否得到满足验证规格说明是否得到满足验证与标准的一致性验证与标准的一致性为后继改进收集数据为后继改进收集数据集中于发现缺陷（而不是形式或备选方案）集中于发现缺陷（而不是形式或备选方案） 33 审查的对象审查的对象

22、v 最初起源于代码审查最初起源于代码审查v 实践证明可以用于对所有软件工作产品的检查实践证明可以用于对所有软件工作产品的检查软件需求说明软件需求说明软件设计说明软件设计说明源代码源代码软件测试文档软件测试文档用户手册用户手册安装规程安装规程版本发布说明版本发布说明计划等管理文档计划等管理文档 34 正式审查正式审查(Formal Inspection)v 完整定义的审查方法完整定义的审查方法 定义良好的过程定义良好的过程 阶段阶段 规程（检查单等）规程（检查单等） 定义良好的角色定义良好的角色 主持人、审查员、作者、讲解员、记录员，等主持人、审查员、作者、讲解员、记录员，等 定义良好的目标定义

23、良好的目标 缺陷消除、需求提取，等缺陷消除、需求提取，等 定义良好的度量定义良好的度量 工作表、数据收集与处理等工作表、数据收集与处理等v 实例：实例：NASA的正式审查的正式审查 NASA-Std-2202-93 Software Formal Inspection Standard NASA-GB-A302 Software Formal Inspection Guidebookv 国内也译作国内也译作“正规检视正规检视”，如国军标。，如国军标。 35 业界的相关经验业界的相关经验v IBM Federal Systems Division（FSD） 以以30个采用正式审查的项目和个采用正

24、式审查的项目和30个其它项目相比较个其它项目相比较 生产率（生产率（LOC/人月）人月） 有审查的为有审查的为300 无审查的为无审查的为144v ICI，Fine Chemical Manufacturing，UK 400个程序经过审查，个程序经过审查，400个未经审查个未经审查 未经审查的代码的维护工作量高未经审查的代码的维护工作量高10倍倍v Standard Bank 88000行代码未经审查，行代码未经审查，90000行代码经过审查行代码经过审查 未经审查的代码的维护工作量高未经审查的代码的维护工作量高28倍倍v来源：Tom Gilb & Dorothy Graham，Softwar

25、e Inspections，AddisonWesley 36 业界的相关经验业界的相关经验v 一次受控的试验一次受控的试验v来源：Software Productivity Research, Inc.v 发现：评审降低了总的工作量和交付后缺陷数目发现：评审降低了总的工作量和交付后缺陷数目 37 业界的相关经验业界的相关经验v 印度一家软件出口商，从事通信软件项目印度一家软件出口商，从事通信软件项目v 发现：审查可以达成更高的生产率和更低的缺陷密度！发现：审查可以达成更高的生产率和更低的缺陷密度！ 38 审查审查(Inspection)v 一种正规的同行评审一种正规的同行评审管理人员不参加、不

26、用于对个人的考核管理人员不参加、不用于对个人的考核 相关开发人员最大程度地畅所欲言相关开发人员最大程度地畅所欲言完整定义的过程与角色完整定义的过程与角色 便于计划组织与实施便于计划组织与实施经过培训的组织者经过培训的组织者/主持人主持人 适当控制审查的组织和会议的进程适当控制审查的组织和会议的进程不断优化的检查单不断优化的检查单 积累经验、指导审查工作积累经验、指导审查工作完整的记录和报告完整的记录和报告 数据积累和过程改进数据积累和过程改进 39 审查流程审查流程准备预审审查会议第三小时修改概要介绍跟踪会议介绍复查并记录普遍异常复查并记录特定异常复查异常记录作出决议诸葛亮会延续会议两两小小时

27、时以以内内 40 审查流程审查流程v 上图描述了组成审查过程的七个阶段。v 此外，如果审查过程中发现了大量错误或修改已有错误的过程极其复杂，需要进行再次审查，部分阶段可能需要重复。是否需要再次审查的决定由审查组在审查会结束时做出。 准备准备阶段的主要任务是决定将被审查的产品是否满足进入准则，计划审查、选择组员、安排角色、安排审查会议时间及准备并分发审查表格材料等。此外，还应该确定是否需要进行一次概要介绍。 41 审查流程审查流程概要介绍这个阶段是可选的，在这个阶段审查组成员可以得到当前审查的相关背景资料。如果审查组成员已经对要审查的产品比较熟悉，这个阶段就可以省略。 预审该阶段是审查的关键阶段

28、，在此阶段，审查组成员单独准备审查，对要审查的产品进行复查并寻找其中的潜在异常。各成员发现的潜在异常将在本次审查会上进行讨论。 42 审查流程审查流程审查会议审查组集体对文档进行复查的会议，寻找、分类并记录，但是不解决异常。 第三小时与审查会议分开的一段可选的附加时间，可用于对审查会上提出的问题进行讨论，讨论问题的可能解决办法或关闭悬而未决的问题。 修改作者对审查中发现的异常进行修正的阶段。 跟踪该阶段是主持人和作者间的一次短会，确定审查会议中发现的异常是否已经得到纠正，并检查是否引入了新的异常。 43 准备准备v准备阶段的工作主要由主持人完成，他确保产品已经可以提交审查，选择审查组成员并分配

29、角色，安排会议的地点和时间，并保证审查材料的发布。审查材料包括被审查产品，审查通知，预审记录，背景材料和检查单等。v进入准则用来筛选还不能接受审查的产品。例如，代码审查的进入准则要求代码已经能够无错地通过编译。进入准则还应该规定在向审查组分发审查材料前已经执行了可用的自动工具的检查。主持人应该根据同行评审规程中规定的前提条件的要求，结合项目组实际情况确定具体的进入准则。 44 准备准备v作者将被审查产品和相关资料交给主持人后，主持人决定是否可以进行审查。主持人应该确定被审查产品的规模合理，使得审查能在一次会议上完成，如果不行，主持人应将产品分成若干可管理的部分。v审查可以与其它同行评审方式混合

30、进行以减少评审工作量，加快速度。例如，较为复杂的代码应该采用审查，较为简单的代码可以采用走查或者单人复审。 45 准备准备v主持人接下来的工作是选择审查组成员并给他们安排适当角色（参见第4章）。应该使整个审查组包含了审查被审产品所需要的不同观点，并明确要求审查员是全面还是仅从某个侧面对产品进行检查。审查员可能只需要检查被审产品的某个侧面或者某些部分，这类信息应填入“同行评审计划”等工作表中的“负责的主要内容”栏。主持人应确保所有审查员理解审查过程并明确各自在预审期间的职责。通常，主持人可以参照以往类似工作产品预审记录的情况来确定检查和判断预审充足与否的准则，例如用了多少预审时间、预审期间发现多

31、少潜在异常等。主持人应该将预审退出准则通知各位审查员，例如填写在“同行评审计划”中，或者在概要会议上说明。 46 准备准备v主持人还需要选择或编制本次审查所需要的检查单等评审规则材料。本指导书附录中的检查单只是一个起点，主持人应该根据各自项目的实际情况决定直接选用还是修改编制审查所需要的检查单。v作为准备过程的一部分，审查组（主要是主持人和作者）必须确定是否要在审查会议上讨论备选方案。备选方案可以在审查会议上讨论，或者在审查会后的一次独立的会议（第三小时）上讨论，也可以留给软件产品的作者去解决。一般情况下，不建议在审查会上讨论备选方案。 47 准备准备v主持人还必须确定审查组成员是否对要审查的

32、材料足够熟悉，或决定是否必须进行概要介绍。审查组应该知道产品生成的背景资料（例如，对于源代码来说就是设计和需求）。审查组还应知道材料与整个开发中的系统的关系。在大部分情况下，审查组成员根据自己在项目中从事的工作会足够熟悉审查材料，如果不是这样就应该安排作者进行概要介绍。 48 准备准备v主持人还必须完成各项会议安排工作，包括时间安排、场地预定、设备预定等。这些工作都完成后，主持人可以完成审查计划。在该计划获得项目经理或者其指定的代表批准后，主持人将该计划发给所有审查组成员。应该将被审查产品、检查单、引用的上级文档和/或相关的同级文档，以及空白的预审记录等一同分发给所有审查组成员。v由于本阶段的

33、主要工作是编制本次审查的计划，因此，在很多关于审查方法的介绍资料中将这个阶段称为“计划”阶段。注意这里的计划仅针对本次审查活动，与软件开发计划中对整个软件生存周期内的审查的计划不同。 49 概要介绍概要介绍v概要介绍（Overview）是在审查组对被审查材料及其背景不够熟悉时安排的一个可选的阶段。在概要介绍时，作者向审查组介绍产品的原理，产品与项目中其他开发中产品的关系，产品的功能及其预期的用处，以及开发该产品所用的方法。这些信息对审查组来说是必需的，这样他们才能进行成功的审查。可以邀请审查组以外感兴趣的人员参加概要介绍，但审查组成员必须全部参加。 50 概要介绍概要介绍v审查主持人必须说明角

34、色分配。审查主持人必须回答关于检查单和角色分配的问题，并应该展示以往的审查数据，例如最短的准备时间和以往类似产品中发现异常的典型数目等。v审查主持人应该根据审查组人员的被审产品的熟悉程度和工作安排决定采用会议方式还是书面文件传阅方式进行概要介绍，或者不需要进行概要介绍（例如对于再次审查）。应尽量采用会议方式，同时在会上向审查组公布角色分配等审查组织事项，回答审查员的其它问题。 51 预审预审v预审阶段是审查过程的关键阶段，在此期间，审查组成员分别根据自己在审查会中的角色做准备工作。v每个审查员都要逐行审阅产品，在产品中寻找一般的问题和与自己的专业领域相关的特殊问题。审查员可以首先对照更高层的工

35、作产品、标准和接口文档检查被审产品，根据自己的经验和理解指出潜在的异常和自己的疑问与改进建议，最后应该利用主持人指定的检查单再次核对被审产品与自己的发现，继续寻找被审产品中的异常。如果对检查单中所列的检查项得出了对被审产品不利的结论，那么应该有至少一个异常可以支持该结论。审查员同时还应该根据实际情况提出对检查单的改进意见。 52 预审预审v审查员应在预审记录表中记录预审中发现的异常和预审花费的时间。应在审查会前将完成的预审记录提交给审查主持人，并由主持人将预审记录表转交作者，以便作者为解释审查员的问题、解决提出的异常等作准备。v预审记录应采用同行评审预审记录表。表中记录的异常分类应该按照该标准

36、进行严重性分类，同时，应该记录审查员在预审提出的所有问题和改进建议。讲解员还应该确定在审查会议上讲解被审产品的方式。 53 预审预审v审查会前，主持人检查每位审查员提交的记录以确定审查组是否进行了充分的准备。主持人还应检查出审查会议时需要特别注意的地方、可以快速归类的普通异常和需要重点关注的部分。如果预审记录表明审查组尚未做好充分准备，主持人应当重新安排审查会议时间，因为准备不足的审查组将浪费时间，并且不能有效发现异常。预审记录表将在审查会上发还给审查员供他们用于指出异常。v本阶段的时间至少需要两天。另外，预审的速度不宜太快。按照业界经验，代码的预审速度应为每小时100行左右，文档的预审速度应

37、为每小时150行左右。 54 审查会议审查会议v审查会议阶段也常称为检查或者检查会议，在此期间，审查员一起复查产品。发现异常依然是审查会议的焦点。简要地说，审查会上的主要活动有：讲解员对文档进行合理的宣读和阐述，必要时作者提供解释信息，审查组识别异常并进行分类和记录。v审查会议的速度也应该控制在合理的范围内。按照业界经验，代码的会议审查速度为每小时125行左右，文档的会议审查速度应为每小时150行左右。 55 会议介绍会议介绍v审查主持人必须介绍参加者并说明他们的角色。审查主持人必须重申审查的目的并应提醒审查员集中精力于异常发现而非解决。审查主持人应当提醒审查员直接将他们的意见告知记录员，并且

38、仅对软件产品作评论，不对其作者作评论。审查员可以向作者提出关于软件产品的问题。审查主持人必须解决审查员提出的任何特殊的程序性问题。v主持人将预审记录发还给各审查员，开始复查并记录异常。 56 复查并记录普遍异常复查并记录普遍异常 v普遍异常是指在审查对象中普遍存在，而不能定位于某个特定位置的异常或者问题、建议等。概念理解错误、术语使用不规范、图形符号应用不当等都是常见的普遍异常。每位审查员分别向审查组说明他发现的普遍异常，审查组讨论并达成关于该事项的异常严重性等级、引入阶段、类型等一致意见后，由记录员根据主持人示意记录在异常记录表中 。 57 复查并记录特定异常复查并记录特定异常 v然后讲解员

39、开始按合理的顺序解读产品。讲解员对文档各组成部分（段落，代码块）的功能、结构及他们与更高一级文档的关系进行阐述。审查员可以在觉得可能包含异常的地方打断宣读过程，如果需要对可能的异常进行短时间讨论，宣读可以临时停止。在异常被提出和归类并由记录员记录到异常列表后讲解继续进行。v主持人必须将这一阶段的会议集中在创建异常清单。应对讨论进行时间限制以防止浪费过多的时间。如果问题在有限的时间里不能得到解决，主持人应宣布该问题暂且搁置，讲解继续进行。遗留问题处于打开状态并在第三小时阶段进行讨论。 58 复查并记录特定异常复查并记录特定异常 v记录员必须根据主持人的示意在异常清单中记录每个异常及其位置、描述和

40、严重性等级、引入阶段和分类。审查组对每一个提出的异常是否是实际异常都要达成共识，有时实际是审查员的错误，或者是通过作者的解释而弄明白的误解。作者必须根据他对软件产品的特殊理解回答细节问题并参与查找异常。如果不能达成共识，该问题应该搁置并处于打开状态而在第三小时阶段重新讨论。因此，在会议检查期间（包括第三小时）得出的异常记录中，最终不应该存在“疑问”或者“改进意见”，而应该将所有问题都归结为是否异常、严重性等级如何。注意改进意见也应该归结为异常。 59 复查并记录特定异常复查并记录特定异常 v可以通过参考上级文档确定提出的问题是不是一个实际的异常，如果确定上级文档存存在潜在错误，应将问题记录为打

41、开状态并继续审查。问题的解决（确定问题究竟是该文档的还是上级文档的）可以放到第三小时阶段。如果本次审查未能确定该问题，则应将这些问题也记录于审查报告中（可记录在备注栏）。 60 复查并记录特定异常复查并记录特定异常 v为确定修正产品异常的优先顺序，审查组或主持人应区分异常的严重性（重要的或次要的）。例如：导致系统不能满足需求的异常应定为重要的；所有其它异常都分类为中等或次要的（诸如排版问题、较小的与标准不一致等问题）。审查期间还要收集的数据是异常的类型，诸如数据错误，需求符合性、标准符合性、逻辑、接口，数据，性能及可靠性等。应依据同行评审异常分类指导书进行异常分类。v为了确定异常记录的完整清晰

42、，记录员每次完成一项异常记录后应将记录宣读一遍，以获得审查组的认可。此后讲解员才能继续讲解。 61 复查异常清单复查异常清单 v在审查会议最后，审查主持人应当与审查组一起复查异常清单以保证其完整性和精确性，并汇总各类异常数目。记录员宣读他记录的异常清单，所有审查员表示是否还有异议。审查主持人应当留出时间来讨论每个存在不同意见的异常。审查主持人不应允许讨论注重于该异常的解决，而应澄清该异常的构成。 62 作出决议作出决议v作出决议的目的是明确地结束审查会议。决议必须确定是否需要其它会议，判断该软件产品经过必要的修改后是否满足审查的退出准则，并必须规定所有必要的修改工作及验证。特别是，审查组必须确

43、定软件产品的处理方式为以下三种之一：l 不修改或作少量修改，不再需要进一步验证。l 需要修改并由主持人或其指定的作者以外的审查员验证。l需要再次审查以验证修改工作。再次审查至少必须检查为解决本次审查发现的异常而修改了的软件产品部分以及这些修改的副作用。再次审查是对已经审查过的产品全部或局部地重复审查过程，应当另行计划组织和实施，产生独立的审查报告。 63 作出决议作出决议v主持人可以根据作者的意见和审查会议遗留的问题情况决定是否需要进行审查的第三小时阶段，如果需要，这时要对每一个审查员安排后继的相关工作。v审查会后，主持人和作者简短会面，估计修改工作时间并安排跟踪会议。作者得到一份异常清单的拷

44、贝作为修改参考。注意并不针对被审文档或代码中发现的异常编制变更请求，因为这时的被审查产品尚未纳入配置管理控制。然而应针对在较高层文档中发现的任何异常编制变更请求，纳入公司的缺陷管理和变更控制。 64 作出决议作出决议v主持人应将审查发现的同一软件生存周期中与被评审产品有接口关系的软件产品中的异常通报给该产品的作者及其上级管理人员，由他们决定后继处理方式。如果该产品已经形成基线，则应纳入变更控制流程进行处理。 65 延续会议延续会议 v为避免疲劳以及因此带来的遗漏异常，审查会议时间应该控制在两小时内。如果主持人预计会议将超过2小时，就应该提前中止记录异常的工作，复查已经记录的异常，并安排延续会议

45、。v延续会议应由审查会议参加者按照原来的角色参加。会议期间继续未完成的异常记录工作，并复查所有的异常记录，作出决议。 66 诸葛亮会诸葛亮会 v诸葛亮会是一次可选的非正式的附加会议，目的是为软件过程改进积累素材。诸葛亮会应与审查会议一同进行（合计时间不超过2小时或者超过时间不多），诸葛亮会采取“脑力风暴“的形式，时间应控制在15至30分钟，由主持人选择审查期间发现的5个到10个重要异常，逐个提出，由审查员分别提出导致这些异常的根本原因及其预防措施。每个异常的讨论时间不得超过3分钟。v诸葛亮会的目的是为软件过程改进积累素材。不需要在诸葛亮会期间进行深入讨论，只需要进行完整的记录（包括相互矛盾的意

46、见）并将记录纳入审查报告。 67 诸葛亮会诸葛亮会 v主持人根据项目组情况和审查中发现的异常情况决定是否需要进行诸葛亮会，向审查组介绍诸葛亮会的目的和形式，提出需要讨论的异常，严格控制时间。v审查员首先要尽快根据主持人提出的异常确定自己是否在准备阶段发现了该缺陷，然后用几个关键词语来说明自己对异常发生原因和预防措施的看法。v记录员记录各位审查员的看法，包括相互矛盾的内容。 68 第三小时第三小时 v第三小时是一次可选的非正式的附加会议或活动，应当与审查会议分别进行。第三小时期间，可以得出关于审查会议中记录的未解决事项的决定，也可以讨论审查中发现的缺陷的解决方案。v第三小时阶段是对未关闭的问题进

47、行讨论和关闭的阶段。如果作者希望对异常的修改进行讨论，或在上级（高层的参考）文档中有潜在的重大异常等未关闭的问题需要处置时，应安排第三小时阶段。第三小时可以采用另行组织一次会议的形式，也可以是组员们执行某些任务并做报告。第三小时阶段不必在审查会后立即进行，也不必限制在一小时。 v如果确定处于配置管理下的上级文档或者同级的相关文档中存在异常，应该在第三小时阶段编写变更申请。 69 第三小时第三小时 v如果以会议形式进行第三小时阶段，就有了讨论解决问题和处理不一致意见的机会。参与者可以包括审查组部分或全体成员，也可包括项目经理（只有在技术原因需要时）、外部技术专家以及在修改错误和解决问题过程中可能

48、涉及到的其他人员。多数情况下只有那些有特殊兴趣的审查员需要参加。在第三小时阶段，作者可以得到解决问题的更为有效的方法，上级文档的缺陷被报告，所有处于打开状态的问题得到解决。v第三小时既可能讨论异常的定性，也可以讨论异常的解决方案。为了统计完整易于分析，这两部分时间应该分别记录在“同行评审报告”中，用于得到更为准确的异常发现数据。 70 修改修改v修改阶段的目的是改正审查中发现的异常。作者负责更正异常记录表中记录的应修改的所有异常。主持人应保证异常记录表已经传递给了作者并得到了作者的处理。 71 再次审查再次审查 v如果产品中存在大量异常，或者一个或多个异常需要大范围的或复杂的改正工作时，应当进

49、行再次审查。再次审查时，由整个审查组而不仅仅是主持人来复查产品中的修改。主持人和审查组在审查会结束时应决定是否需要进行再次审查。 72 跟踪跟踪v主持人和作者应进行简短的交流，确定所有的重要问题都得到了正确的解决且没有因修改而产生新的问题。作者向主持人介绍修改每个重要问题所采取的方法。主持人保证所有的重要问题都得到解决。对次要异常的修正也应该复查，但是不是重点。如果有技术需要，主持人也可邀请其他的技术专家参加跟踪工作。v如果所有的重要异常都已改正，异常记录表中所有的处理建议都得到了实施，产品满足了退出准则，主持人就可以在审查报告上记录完成情况以“通过”该产品。否则，作者就需要回到修改阶段继续进

50、行必要的修改。 73 审查的角色审查的角色v 37人人v 主持人（主持人（Moderator）v 讲解员（讲解员（Reader）v 记录员（记录员（Recorder）v 作者（作者（Author）v 审查员（审查员（Inspector） 74 主持人主持人v 需要领导技巧需要领导技巧v 管理审查过程，保证效果：管理审查过程，保证效果：保持公正无私保持公正无私确保满足进入和退出准则确保满足进入和退出准则确保审查员准备充分确保审查员准备充分进行收尾工作进行收尾工作不一定来自同一项目不一定来自同一项目v 主持人是关键！主持人是关键！v 不仅要控制进程，还要控制气不仅要控制进程，还要控制气氛氛 75