1.1.名称

本规范是贯穿整个项目的软件生命周期的 评审过程规范（以下简称 本规范）。

1.2.缩写词

本规范详细描述了本公司进行的评审活动。

本规范适用于本公司所有项目的评审过程。在客户要求使用客户提供的评审过程规范的项目中本规范不适用。

1.4.准入条件

1.4.1.评审策划

PM或PL确认作者已完成了待评审的工作品。

1.4.2.评审准备

分发给小组评审有关的文档，明确评审小组成员，确认评审时间。

1.4.3.评审会议

评审组负责人（RTL）保证会议的准备就绪。                                                       

1.4.4.评审闭合

只要评审结果中存在一个问题或者缺陷，就必须进行返工和问题的闭合工作。

1.5.准出条件

1.5.1.评审策划

评审人员最终确立下来，并认可评审会议的日程安排。确认进入准则已经实现，并且小组评审材料准备就绪可以进行分发。

1.5.2.评审准备

所有评审人员向评审负责人（RTL）递交个人评审中发现的问题清单。

1.5.3.评审会议

完成小组评审报告表，事先准备工作中所有提出的问题都得到了讨论和初步的处理意见。

1.5.4.评审闭合

所有提出的缺陷和问题都闭合，并且总结报告已经向所有相关的PM/PM/SM以及SEPG提交了。

1.6.过程产物

1.6.1.评审策划

小组评审进度表，小组评审的邀请函。

1.6.2.评审准备

个人评审中发现的问题。

1.6.3.评审会议

评审报告。

1.6.4.评审闭合

经过了检查的工作产品，闭合了的评审报告表。

1.7.用户

本规范的用户为公司全体软件技术人员。

1.8.评审概要

评审的目的是在缺陷泄漏到开发的下一阶段之前将其探查和标识出来，这有助于在问题扩大化、变得复杂难以处理之前将其纠正。 

正式评审是实现生产力提升和过程改进的有效途径。软件评审就是通过对软件工作产品进行技术评审来减少缺陷和提高质量。评审可以通过以下两种方式进行：

评审的基本目的是：

在开发的较早阶段将缺陷探查出来 。

验证工作产品符合预先设定的准则。

提供产品和评审过程的相关数据，包括对评审中能发现的缺陷数的预测能力。

评审须遵循以下的基本原则：

评审是一个结构化的正式过程，有系统化的一系列检查单来帮助工作，并且参与者分别有不同的角色。

评审人员事先要经过准备工作，并在小组评审进行之前要明确他们自己工作的重点，和个人已经发现的问题。

评审的工作重点是发现问题，而不是解决问题。

技术人员进行小组评审，项目负责人通常不参与软件工作产品的小组评审，但对评审结果要了解。但是对于项目管理文档，有经验的项目负责人要参与小组评审。

小组评审数据要记录下来，以供监控小组评审过程是否有效。

1.9.总体过程

1.10.评审策划

1.10.1.过程流图

1.10.2.过程描述

在评审会议开始之前，评审人员要接到待评审的材料，并进行的个人评审。

评审策划阶段的主要活动

●验证进入准则

⏹作者必须保证工作产品准备就绪，等待小组评审，并且符合所有适用的标准和相关免责条款都已明确。

⏹PM保证工作产品准备就绪，等待接受评审。

●组建评审小组

⏹PM征求作者的意见，选择RL，然后再经过RL的同意，确立其他参与人员。SQA可在RL的选择上提供帮助，而且只要可能，就应作为观察者参与评审。

●准备小组评审资料清单以备分发

⏹作者要列出所有要分发给评审小组的资料。

●为小组评审安排进度，召开小组评审会议

⏹PM，RL和作者安排评审会议的日程，并征求相关人员同意。

⏹如果某个评审组员不能来参加，应当确定替换人员。

评审策划的指南

●在组建小组的时候，不能有以监控者身份出现的上级在场，因为这样会使得评审组员不敢勇于指出问题。

●在评审过程中，主要角色有：评审组长、作者、朗读者、记录者、评审人员等，其中作者不能兼任其它任何角色；读者、记录者不能是同一个人；评审组长不能是读者或记录者。

●不能在评审即将开始前替换人员，评审人员不能在同一天参加两次以上的评审。建议评审持续时间为2小时，如果工作产品太庞大，可以分成为几个部分进行。

1.11.评审准备

1.11.1.过程流图

1.11.2.过程描述

在评审会议开始之前，评审人员要接到待评审的材料，并进行的个人评审。

评审准备的主要活动

●召集开始会议描述小组评审的目的

⏹本活动的目的是介绍待审查的工作产品，可能的话，应尽可能的给予解释，以帮助评审组员更好的进行准备工作。

●如果有要求，对小组评审进行简要介绍

⏹RL首先简要的介绍审查对象，小组评审的目的，如果需要的话，再介绍一下小组评审的过程。作者就涉及的领域、一些存在特殊考虑的地方、以及一些难以理解的地方等等进行一个简短的介绍。

⏹这一步骤是可选的，如果待评审的材料很少，所有的评审人员对待评审的材料都很熟悉，本步骤可略去。RL向各位评审人员提供一份评审相关资料的拷贝。

●的评审工作产品

⏹在开始的介绍会议之后，评审人员的为小组评审进行准备。遇到问题，记录下来，并尽可能详细的加上注释，以便于作者理解。

⏹缺陷报告应尽可能早的递交到作者手中，以备作者研究和思考评审者发现的缺陷和问题。评审者应当在工作产品中所有涉及到正确性，或者是存在严重不足的地方作标记。

●记录缺陷、潜在的缺陷和标识出的问题，并向RL和作者提交

⏹在准备中，评审者记录他们耗费的时间，发现的错误，然后在小组评审会议之前或者开始的时候向RL提交。

●记录准备工作耗费的时间，向RL递交

⏹评审表应当有填写测量信息的地方，所有评审者都要填写。要记录下来被评审的工作产品的规模，个人进行评审的工作量。

⏹此表格要递交到RL。

●检查评审的准备情况

⏹RL通过检查个人评审报告表，    确认所有的评审人员都得到了工作产品及相关的资料，并进行了准备工作。 

⏹检查作者的准备情况。

⏹接下来RL检查作者是否进行了充分的准备工作。比如， 检查作者是否分析了评审人员的缺陷报告，是否进行了备份、整理，是否准备了讨论笔记。

●如果准备不充分，将评审会议延期

如果准备工作不充分，小组评审会议要延期直到所有参与人员都准备充分为止，发生这种情况，要向SQA和高级经理汇报。

评审准备工作指南

●至少在小组评审进行前一天，作者必须向所有评审人员分发被评审的工作产品及相关材料，或者指明存取该工作产品及相关材料的路径。

●在介绍概况时，标注出来本项目中比较特殊的地方，或者是关于程序/设计工作量方面比较特殊的地方。

●理想的情况下，评审的准备工作应当在一个持续的时间段内进行。

●在准备报告的时候，对缺陷/问题进行分类

⏹如根据影响程度来分类－会产生重大影响的，中等影响程度的，较低影响程度的。

⏹根据缺陷种类来分类－术语出现遗漏的错误，出现多余的错误，某些部分错误。

1.12.评审会议

1.12.1.过程流图

1.12.2.过程描述

当所有的评审者完成个人评审，就可以进行小组评审，在这里，缺陷被最终正式确立下来，小组评审会议完成后，会生成正式的缺陷列表。

评审会议的活动

●评审准备工作中发现的所有问题/缺陷

⏹朗读者按顺序朗读工作产品，当朗读者读到某个评审人员指出有问题存在的地方，评审人员打断朗读者的朗读。评审人员就发现的问题进行解释。

⏹作者解释每一个关键的和严重的问题，要么解释为什么它不是一个缺陷，要么试着去理解评审者的想法，接受它为一个缺陷。

●记录缺陷

⏹记录员要作会议记录，要记录下所有未解决的问题和缺陷。在会议结束的时候，记录员向大家逐条念出仍处于开放状态的问题，确认有无遗漏，并进行最终修订。

●评审工作产品，检查是否有其它待考虑的方面

⏹对产品进行讨论，检查是否有其它值得考虑的问题。

●

决定是否需要再评审

⏹小组在报告中明确对工作产品要采取的措施，可以是以下任意一种：

∙完全接受产品。

∙工作产品需作改动后再接受。

∙或者需要再评审。

●标识记录应该在下一阶段接受小组评审/个人评审的部分：

⏹一旦产品被接受，并进入下一开发阶段，小组就可以在本次评审的基础上决定要对哪些工作产品进行评审。

⏹譬如概要设计的评审中就可以确定在详细设计中那些部分需要进行小组评审，哪些需要个人评审。同样的在详细设计评审结束时，可以就代码评审和集成测试计划给出些建议。

⏹以上工作都是为了保证有些无法马上解决的问题可以留到以后处理。

●总结采取的措施

⏹小组总结所有需采取措施的地方，并通报相关作者。

●会议结束

⏹会议结结束后，RL会跟踪作者确认纠正措施的实施和报告的闭合。

评审会议指南

如果修改很轻微，进行完返工后，小组评审状态就可标注为“已接受”。如果修改有可能会引起更多的问题，就要RL召开一个后续的会议，或者再次进行小组评审，来验证是否已正确无误的进行了变更。以上两种处理方式的选择取决于缺陷的多少和返工的工作量多少。如果缺陷密度超过可接受的限度，RL可以建议再次进行评审。

1.13.评审闭合

1.13.1.过程流图

1.13.2.过程描述

在评审会议结束后，作者要依据发现的缺陷对工作产品进行修改。评审人员和RL验证修改的正确性，RL在评审报告上签字闭合评审报告。

评审会议的主要活动

根据发现的缺陷进行返工

作者要进行返工以纠正所有评审中发现的缺陷。

评审人员进行调查，将报告提交给作者

评审人员应就在评审会议中分配给他们的问题进行跟踪，并将跟踪结果提交给RL。

一起评审其正确性，或者如果RL决定有必要进行再评审，就以小组形式检查其正确性。

将评审报告提交给所有评审组成员，同时提交给SQA和SEPG

记录员要保证小组评审报告和会议记录都得到了评审小组的认可，同时要将一份小组评审报告提交给SQA。

RL保证小组评审结果和数据得到记录，在所有缺陷和问题闭合后小组评审总结提交给了SEPG、PL/PM。

评审闭合指南

标识出来的未闭合的问题如果不对工作产品产生影响，可以被标注为闭合。

如果发现缺陷密度超过可接受的限度，RL 可以建议进行再评审。

RL 要保证评审报告中列出的所有缺陷都的到了纠正，可以接受工作产品，或者是进行再评审。

1.14.过程验证

评审活动的确认机制如下：

SM/MM要定期和SQA、SEPG一起评审工作产品评审活动和结果。此活动的频度要在每个项目的项目计划中明确。

SQA通过以观察者的身份参与评审会议和项目内部审计来审计评审活动。

PM定期的，或者通过项目状态会议和评审人员、SQA、SEPG一起评审工作产品的评审过程和评审结果。项目的评审活动要作为项目状态报告的一部分。

1.15.过程度量

以下测量数据通过评审过程和评审活动来采集

评审策划

●策划工作量。

评审准备

●准备工作量、缺陷数、问题数和缺陷严重性。

评审会议

●小组评审会议的总工作量、缺陷数、缺陷类型、缺陷成因。

评审闭合

●工作产品的缺陷数和规模、平均每一评审小时发现的缺陷数、平均每一个评审人员发现的缺陷数。下载本文