CMMI5文档之评审规程

评审规程文档编号：FHI_CMMI_VER_PRD_SYN文档信息：评审规程文档名称：评审规程文档类别：CMMI规程密级：内部秘密版本信息：1.2建立日期：2016-1-5创建人：EPG批准人：李庆林批准日期：2016-2-25存放位置：集成公司组织资产库/组织标准过程编辑软件：Microsoft Office 2003 中文版文档修订记录目录s1.简述 (4)1.1.目的 (4)1.2.适用范围 (4)1.3.术语表 (4)2.概述 (4)3.同行评审过程说明 (6)3.1.正式评审 (6)3.2.技术评审 (9)3.3.走查 (10)3.4.审批 (11)3.5.审阅 (11)3.6.邮件评审 (11)4.分析评审结果 (11)5.同行评审验证准则 (11)5.1.同行评审严重程度定义 (11)5.2.同行评审不通过的准则 (11)6.QA评审/审计 (12)7.CM审计 (12)1. 简述1.1. 目的本规程的目的是为了定义在软件生命周期内不同的评审类型，确定评审的时机和评审的一般流程，并规定各项评审的主要内容、入口、出口和评审人员等。

1.2. 适用范围本规程适用于本公司的所有软件项目。

1.3. 术语表无2. 概述软件生命周期内的评审分为三类：同行评审、QA 评审和审计、CM 审计，如下图所示：(经验人员或客户代表CM 人员QA 人员相关人员:图表 1 评审分类正式评审活动评审的一般是比较重要的或具有里程碑意义的工作产品。

正式评审的目的既是为了发现被评审项的缺陷，也是对重要工作产品的质量验证。

评审的结果(通过或不通过)标志着项目是否进入下一个开发阶段。

因此，项目评审具备一定意义上承诺的意味。

同行评审是在软件开发过程中按照明确定义的过程对工作产品进行系统检测的方式之一，同行评审分为技术评审、走查两种方式。

技术评审、走查由一组与软件工作产品的作者处于同一级别的、具有类似工作（技术）经验的技术人员来进行。

技术评审和走查是作业过程中不可缺少的部分，使得缺陷能及早排除，产生较高的生产率和高质量产品。

技术评审和走查关注的是被评审的软件工作产品本身，而不是软件工作产品的作者。

与软件工作产品的作者相关的管理人员不应参加技术评审和走查，因为相关的管理人员参加技术评审和走查可能会妨碍评审人提出问题或发现缺陷。

技术评审和走查的结果也不应作为管理人员评价个人工作业绩的依据。

●正式评审的特点：高层经理通常被邀请参加。

评审对象可是技术工作产品也可是管理工作产品。

重点在于识别问题，不是解决问题。

要给评审做出结论。

●正式评审和技术评审及走查的区别：正式评审中，软件工作产品或软件工作产品集要交给管理人员、客户、最终用户或其他相关人员，以征得他们的认可或同意。

正式评审一般在任务完成后进行。

技术评审及走查中，软件工作产品或软件工作产品集提交给软件开发单位的同行，以发现其中存在的缺陷。

管理人员、客户和最终用户一般不参与技术评审及走查，技术评审及走查是不可缺少的任务。

有些软件工作产品需要经过正式评审，有些则需要经过技术评审及走查，而还有一些两者都需要。

根据评审对象的性质及项目的重要程度，可选择正式评审、技术评审、走查、审批、审阅、非正式评审六种方式进行评审活动。

五者的区别如下：3.同行评审过程说明3.1.正式评审3.1.1.概述正式评审由项目组或质量管理部的人员进行组织，由遵守明确定义过程的一组人员对软件工作产品以召开评审会的方式进行的评审。

其特点是：●评审人事先进行准备，并在评审会议开始前确定其关注的内容和问题。

●记录评审数据，并用于监督评审过程的效果。

●整个过程是为参与者定义好角色的结构化过程。

3.1.2.优缺点●优点以经济的方式发现缺陷。

在软件生命周期早期产生的产品中注入的缺陷，可以尽早发现，而不会导致以后发现缺陷所需的高额成本。

有效利用人力资源，即使有些人没有安排在项目中。

有助于建设团队精神，培养参与感和认同感。

评审人和作者通过该过程，对缺陷及其类型有了更多的认识，可以有效减少以后对该类产品的缺陷注入率。

若某工作产品的负责人中途退出，其它人员由于较早了解了该产品和退出人的思想，可以最大化地减少由于人员变动带来的损失。

●缺点需要许多人花费时间来准备和参加评审会议。

安排评审会议也需要相关开销。

3.1.3.适用范围重要的或非常复杂的工作产品需要进行公司正式评审，如：《软件需求规格说明书》、《用户需求说明书》、《项目计划》、《概要设计》或需要提交给用户的工作产品。

3.1.4.参与人员●作者：不能作为主持人，尽量不要充当宣读人。

评审前准备工作产品和相关资料。

保持客观，避免防御。

快速确定是否是问题。

根据评审结果，积极修改原先的工作产品。

●主持人：尽量不要充当宣读者。

安排、组织评审会议。

评审前与评审人积极沟通，发放材料。

评审开始时，检查评审人的《评审准备表》。

确保会议一直关注的是识别缺陷这个任务。

完成《评审报告》。

●评审人：评审前，认真准备。

评审中不要关注解决方案。

解决方案可以在评审结束后与作者交流。

积极参与问题的讨论和提出问题的解决建议，可以随时打断会议。

●宣读者：逐行宣读产品，以便评审人更好的理解产品。

控制评审的速度。

●记录员：在评审中，在《评审报告》中记录确认的问题。

●跟踪人：由评审会议最后指定，负责跟踪问题的解决情况。

跟踪人不能是作者。

●软件工程组：进行项目评审。

●其他评审人员：必要时，请高层经理、客户代表参加。

3.1.5.入口准则●待评审的工作产品已完成。

3.1.6.输入●完成的工作产品3.1.7.流程评审准备为了确保评审的成功和顺利，评审组织者和产品负责人（项目负责人）应做好充分协调，做好评审前的准备工作。

1.确定评审的参加人员，指定主持人、记录员等，并准备好相关的材料。

在选择评审人时应考虑以下情况：评审人尽量选择受评审结果影响的组的负责人。

评审人必须具备相关的经验。

考虑参加评审人的连续性。

（注：评审人员如果参加过项目以前的评审，那么他对项目问题的理解会比较深刻，更能保证评审的效果。

）2.确定评审的时间、地点和内容在评审前，主持人与参加评审的人员进行沟通(沟通方式可以是召开会议、发送电子邮件或电话通知等)。

确定评审的时间、地点和内容，填写《评审计划》。

3.主持人和产品负责人或者作者开发评审项的检查单和标准，填写《评审检查表》，可以采用公司模板进行补充。

4.主持人将《评审计划》、《评审检查表》和与评审有关的材料发给评审人，评审人应该在评审会前认真阅读这些材料，将发现的问题记录在《评审检查表》上。

注意：评审通知和材料发放，应尽量提前以便给评审人预留充足的准备时间。

执行评审1.主持人应先检查是否所有的评审人都作了充足的准备（检查《评审检查表》），并和项目经理协商确定本次准备是否充足，当准备不充足时，暂时取消本次评审。

2.主持人协调地点、投影仪等必备环境准备情况，会议期间应掌握和控制评审时间，一次会议的时间一般不超过4小时，对特殊事件可以做特殊处理。

当评审有了明确的结论后，主持人做出总结，确保没有歧义后可以结束本次评审。

如果本次评审没有通过，必须安排再次评审并决定再次评审的时间。

3.在评审过程中，记录员记录发现的问题和做出的决定，记录在《评审报告》中。

4.评审结束时，指定问题的跟踪人。

跟踪人按照评审记录跟踪问题情况，确认问题已经得到澄清（确定是否是问题）。

5.评审结束后，与会人员要在《评审报告》上签字，并认同评审的结果。

评审只针对评审项不对人。

评审过程中只是确定问题，不要涉及问题如何解决或如何解决更好的讨论。

如果确定的问题很少，或只需要做很少的修改，那么这次评审结果就是通过。

如果问题太严重，则要决定作者修改完毕后要进行再次评审。

按照同行评审严重程度、不通过的准则定义填写评审问题，参见本文第4章。

7.将《评审计划》、《评审检查表》、《评审报告》纳入配置库。

跟踪返工作者必须根据评审的《评审报告》进行修改。

若不需要再度评审，则在这个阶段，作者和跟踪人一起检查所做的更改，最终跟踪人记录修改结果和数据，并签字表示通过。

3.1.8.出口准则通过跟踪人的检查，并签字。

3.1.9.输出●《评审计划》●《评审检查表》●《评审报告》3.1.10.资源与能力要求●评审的参与人员（包括作者）接受过关于项目评审的培训。

●评审主持人接受过填写《评审报告》的培训。

3.2.技术评审组内正式评审由项目组组织，评审主要集中在项目内部，有条件的可以邀请项目外专家参与。

3.2.1.适用范围应进行技术评审的工作产品包括：●公司级的过程定义文件。

例如：过程开发和维护活动计划、标准软件过程文件、软件生命周期模型描述文件等。

●软件项目管理过程中的工作产品。

例如：风险管理计划、软件规模估算等。

●软件开发过程中的下列工作产品。

各种说明书（例如，软件需求规格说明书、概要设计说明书、详细设计说明书、数据编码说明书等），各种计划书（例如，系统测试计划、集成测试计划等），其它文档（例如，系统测试用例，集成测试用例等）。

技术评审与公司正式评审不同之处在于，技术评审中没有管理人员的参加，技术评审关注的是软件工作产品本身，而不是软件工作产品的作者。

其他内容与正式评审相同，参考正式评审的过程说明。

3.3.走查3.3.1.概述走查是对软件产品进行的同行评审，通常用于尽早快速发现工作产品中可能存在的设计缺陷和不符合标准、规范的问题。

3.3.2.适用范围适用于实现阶段和详细设计阶段的工作产品。

例如：程序源代码文件、数据源代码文件、详细设计说明书、数据编码说明书等。

当评审的首要目的是使别人了解产品时，走查很适合：●需求开发计划（需求调研计划）●设计方案●测试文档●用户界面设计3.3.3.参与人员●作者：将工作产品向一组同事介绍，并希望他们给出意见。

●评审人：指出其工作产品中可能存在的缺陷，以及与标准、规范的不符合项。

3.3.4.入口准则作者已准备工作产品。

3.3.5.输入●要评审的软件工作产品及其源头文件。

3.3.6.流程1.由产品的作者将该产品向一组同事介绍，并希望他们给出意见。

2.产品作者起主导作用，而其他评审角色则通常没有定义。

通常不需要进行计划，不制订详细的准出条件，也不需要管理报告，且不进行缺陷度量。

3.走查人员根据检查表的要求和自身的经验，随时指出其工作产品中存在的缺陷，以及与标准、规范的不符合之处，交流工作中的经验。

作者应记录下存在的缺陷和不符合项，以便在走查结束之后做必要的修改。

3.3.7.出口准则●已记录缺陷。

记录在评审检查表的问题记录中。

对评审的工作量进行度量。

3.3.8.输出●《评审报告》3.3.9.资源与能力要求走查参与者了解走查的流程3.4.审批审批主要是由有权力批准的人员对工作产品的批准方式，有权力批准的人员通常比软件工作产品的作者高一级别。