实践证明：阶段性评审在项目的全面质量管理中占据了非常重要的作用，它就像信息化项目过程中的“过滤器”，被用于项目实施过程中的每一个重要环节点(特别是针对具有里程碑意义的阶段成果)上。技术评审的目的既是为了发现被评审项的缺陷，也是对阶段成果的质量验证。评审结果是否通过标志着项目是否能够进入下一个开发或建设阶段。

之所以要组织阶段评审，我考虑基于下面两方面的考虑：

第一，对于有多家企业共同承建的大型信息化工程，例如我曾经组织实施的城市运行指挥平台项目，有六家企业分别承担一些专项子系统的开发建设任务。如果仅根据建设任务的分工，完全由各承担任务的人员自行控制所负责部分的质量，将会是项目承担很大的风险。因为我们每一个人的知识和能力都会有局限性，具体承担设计实施某项任务的技术人员，无论他来自哪一个企业，都可能在对项目目标或需求的认识方面，技术设计方面、以及实施经验方面存在一定的偏差和弱项。如果不加以控制，对整体项目的质量将会产生短板效应。

在项目的关键环节，我们组织参与项目建设的各个企业的技术骨干共同针对每个子系统进行阶段评审工作(也可说是交叉评审)，就可将大家的智慧和经验得到共享，纠偏补漏，互相切磋和借鉴，补充当事人在经验、知识、信息方面的不足。组织多人进行阶段评审，就是借助不同人员在对问题的认识、技术水平和经验等方面可能存在的差异性，来达到质量控制把关的目的。通过交叉评审，还可以发现各企业分别承担建设的子系统之间接口不一致的问题，以确保项目的实施质量。对于关键环节或关键技术，可以组织专家评审。

对于一个产品开发或工程实施为主的企业或较大型的开发团队，内部的质量管理来说也是如此。因为技术人员可能分散在并行开发实施的多个项目中，我们不希望具体项目的质量仅是因从事该项目当事人水平的局限性而受到制约。为此，建议在项目的立项，制定项目计划的时候，就明确要在实施过程的一些关键环节，组织跨项目的交叉评审，特别是对一些重点项目的设计方案评审，应有针对性组织主要的技术骨干，包括聘请外部的专家参与评审，以达到提高质量的作用。我们多年的项目管理实践证明，其效果还是很明显的。

第二，项目实施的每一个过程产生的差错在后续的阶段都可能会逐步的积累和放大，开发前期的微小疏忽和差错，会对后期设计实施产生严重的影响。而且不同阶段引入变更和纠错所付出的代价是不同的，错误和偏差发现的越早就越容易调整与纠正，为此所花费的时间、人力和经费的投入也越少。甚至有些错误如在项目的后期才暴露出来会对项目产生无法弥补的损失。

当然对于大型项目，组织来自不同企业的整个项目团队集中进行正规的评审会议方式是需要一定的成本与时间代价的。从实效性角度考虑，参与一次评审会的关键人员不要超过8名。项目规模如果很大，应根据阶段和被评审内容的不同采用不同的范围和方式组织技术评审。技术评审也可通过电子邮件、文件汇签，甚至是网络聊天或私下进行专题讨论等多种形式进行非正式的评审。两种不同的评审形式各有利弊，在有些情况下可能非正式的评审比正式的评审效率更高，更容易发现问题。因此在评审时，应该更灵活地利用不同方式。

例如我们在开发电子政务信息化应用系统的过程中，主要都是针对项目的需求分析、概要设计、测试计划与测试用例等阶段成果，组织参与项目的各企业的骨干人员(包括项目经理、客户方代表、与其相关的子项目经理、技术骨干、项目监理等)举行正式的技术评审会议，而其他环节的技术评审就由各承建企业自行组织或采用非正式的评审方式。由于紧紧把住影响项目建设质量的关键点开展工作，尽可能将缺陷发现在下一个实施环节之前，取得了明显的效果。

为了提高阶段评审会的效率和实际效果，我们通过实践总结出以下一些经验：

一、充分做好评审前的准备

评审质量的好坏很大程度上取决于在评审会议前的准备活动。

1. 要检查参与评审的内容是否真正完成，是否达到评审的条件。在评审的对象中如果存在大量的低级错误，文档中存在许多方向性的偏差，或缺少大量的关键性内容，就可能导致评审无法进行下去，不得不等待下次补充、修正后再举行复审。所以应事先明确要求按照规范文档模版编写技术文档。在评审过程中其中很重要的内容之一也是审查技术文档的内容是否符合文档模版的要求，是否有遗漏项。另外也需要根据评审内容事先准备出一些背景资料和参考素材。

2. 精心挑选评审人员。根据评审内容及评审目的的不同来确定关键人员的范围，除了客户方的管理人员、用户方的业务人员、IT主管、承建方的分析设计人员、质量保证人员、实施人员、项目经理之外，需求分析评审时应考虑请关键用户代表参与，设计评审时也可邀请一些第三方的行业专家参加。在这些人员中由于大家所处的立场不同，对同一个问题的看法是不相同的，有些观点是和系统的目标有关系的，不同的观点可能形成互补的关系。为了保证评审的质量和效率，需要精心挑选评审员。首先尽可能邀请到所有不同类型的关键人员参加，否则很可能会漏掉了很重要的需求或出现技术偏差。在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则很可能使评审的效率降低或者最终不切实际的修改了系统的范围。

3. 一般欲评审的技术文档内容都会比较多，如果相关文档在评审会议前并没有提前下发给参与评审会议的人员，没有留出充分的时间让参与评审的人员在会前有时间仔细阅读和理解，就会出现评审会上花了大量的时间念文档，还使很多参会者不知所云的现象，无法达到评审的目的。所以最好在评审会召开前三天前，就将技术文档发给所有的评审者。如果要求大家先在会议之前认真阅读，并进行预审，则评审会的效果会更好

4. 评审检查单是非常好的评审工具，在评审举行之前，应根据其内容和特点事先准备好评审检查单，发给所有参与评审的人员，帮助评审人员思考，以便全面系统地发现评审对象中存在的问题。评审单的内容会随着项目经验的积累逐渐丰富和优化的。

5. 由于多数评审员是领域专家而不是进行评审活动的专家，他们可能没有掌握进行评审的方法、技巧、过程等，因此需要会前对评审员进行简单的培训，明确评审会议的人员职责分配，评审的具体步骤，评审通过的条件等等。以便于参与评审的人员能够紧紧围绕评审的目标来进行，能够控制评审活动的节奏，提高评审效率。并指导评审人员充分利用好评审检查单。

二、确定评审的关键点

评审的关键点一般需要事先整理在评审检查单上，供参与评审的人员了解，并以此作为评审过程的主要依据。这些内容需要认真分析项目的特点，针对评审对象的质量要点进行整理。下面是针对需求分析、系统设计及测试方案几方面进行评审建议的关键点，但不局限于此。仅供参考：

1.对用户需求分析进行评审

• 需求文档是否按照项目规定的文档模板进行编写?
• 是否已经清晰的描述了系统的业务背景、目标?
• 是否已按照用户特点对目标用户进行分类，而且定义是唯一的?
• 系统用户和系统的间接用户是否已经识别?
• 是否识别定义了在将来可能会变化的需求?
• 是否已考虑了项目特定技术的限制，如接口，数据库，并行操作，通讯协议，设计约定，编程规范等。
• 本项目与其他项目间的依赖关系是否已明确描述?
• 本软件同其他软件之间的公共接口、数据通信协议等要求是否明确?
• 对于用户的业务流程是否清晰描述，并对关键业务流程绘制了标准的、易于理解的流程图?
• 用户对界面的要求描述是否清晰，易于理解?
• 是否说明了如何进行系统输入的合法性检查?
• 业务功能的描述符合假设、约束的要求吗?
• 各个需求之间是否一致?是否有冲突和矛盾?
• 用户对软件、硬件、网络环境的要求是否已清晰描述?
• 用户对系统质量的要求是否已清晰描述，并给出了详细的指标参数;
• 需求定义是否足够清楚和明确，以满足能够作为开发设计规约和功能性测试数据基础?

2.对系统设计进行评审

• 设计文档是否按照项目规定的文档模板进行编写?
• 所提出的技术方案在技术上是否可行?
• 技术方案实施的复杂程度是否可接受?
• 系统现有能力(包括功能、性能等)是否已不能满足业务需求?
• 对系统存在问题的分析是否清晰准确?
• 所提出的技术解决方案是否采用成熟技术，是否经济合理?
• 是否对方案实施后，系统的处理能力及可适应业务变化的情况进行了量化分析和预测?
• 是否对限定条件和假设条件进行了说明?
• 是否考虑了系统的易升级性、扩充性和可靠性
• 是否满足系统的安全性要求?
• 是否对与其它相关系统的接口进行了明确说明?
• 是否有其它可替代方案?是否进行了对比分析?
• 是否对实施风险进行了分析?
• 所提出的方案是否比其它方案在综合比较上具有优越性?
• 有关方案中的数据计算和推断是否合理?

3.对测试计划和测试用例进行评审

• 测试计划和测试用例是否按照项目规定的标准模板编写?
• 测试计划中是否清楚地描述了测试方法及测试环境要求?
• 测试用例结构是否清晰、组织是否合理?编号是否正确、唯一?
• 测试用例内容描述是否正确、清晰明确、易读性强?
• 是否每个需求(或需求条件分支)都有对应的测试用例?
• 是否在测试用例中列举了一些过去常存在的错误?
• 是否测试了典型的中间值、临界值进行了测试?
• 是否对复合临界值，即组合输入数据可能导致错误输出进行了测试?
• 测试用例是否检查误操作对系统的影响(健壮性)?
• 是否设计了系统数据初始状态时的测试用例
• 是否存在安装卸载测试用例?
• 是否存在非功能性测试用例?如易用性、兼容性?

三、评审会的操作规则

为了保证评审会组织的有效性，根据我们实际工作的经验总结出一些组织评审会时应把握的操作规则：

• 会场要保持有良好的协作气氛。要求各参加评审的人员跳出自己在建设中所处的角色，均站在用户的角度，站在为整个项目负责的角度考虑问题、分析问题;
• 关注评审产品，而不是评审具体的设计者或编写者(不能使当事人有任何压力);
• 指明问题范围，限制争论与反驳。因评审会的目的不是为了解决问题，而是尽可能多的发现问题;
• 采用投影和白板书写的方式清楚地展示论述的问题;
• 为每次技术评审尽可能安排充足的时间资源，以保证实际效果，但一次评审会的时间最好不要超过3个小时;
• 事先给参会者提供被评审内容的文档进行预评审，会上只梳理要点以提高效率;
• 评审会上要安排专人进行会议纪要的记录与整理，并在会后整理出文字供与会者签字确认。

四、做好评审后的跟踪工作

在评审会后，需要根据评审人员提出的问题进行评价与整理，必须明确所提出的问题哪些是致命的错误，哪些是一般性错误;哪些必须纠正，哪些可以不纠正，并给出充分的、客观的理由与证据，以形成书面的评审报告。确定了需要纠正的问题后，要责成责任人在规定的时间范围内进行修改并提交新一版的文档。对于错误不多的评审对象，可以仅安排参与评审的人员对修改后的内容简单的进行文档会签评审;而对于发现错误较多的关键的评审内容，在变更修改完成后，必须要安排时间再次开会进行复审。切忌评审完毕后，不再对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流。我们就曾为一个评审内容先后举行过两次复审会议。