评审规程V10.docx

评审规程V10.docx

《评审规程V10.docx》由会员分享，可在线阅读，更多相关《评审规程V10.docx（18页珍藏版）》请在冰豆网上搜索。

评审规程V10

评审过程

文档编号：

VER_PRS

文档信息：

公司级别过程文件

文档名称：

评审过程

文档类别：

工程过程类

密级：

内部

版本信息：

1.0

建立日期：

创建人：

审核者：

批准人：

批准日期：

保管人：

存放位置：

文档修订记录

版本编号或者更改记录编号

*变化

状态

简要说明（变更内容和变更范围）

日期

变更人

批准日期

批准人

0.5

A

新建

2014-1-15

*变化状态：

A——增加，M——修改，D——删除

文档审批信息

序号

审批人

角色

审批日期

签字

备注

图索引：

1

简介

1.1目的

本文的目的是为在开发软件项目上成功地执行各种评审活动所提供的评审过程框架。

1.2适用范围

本文档适用于组织內的各软件项目的评审活动。

1.3背景描述

无

1.4引用文件

●《质量保证过程》文件编号：

NFS-CHINA-QM_QA_PRS

●《度量分析过程》文件编号：

NFS-CHINA-QM_MA_PRS

●《软件测试过程》文件编号：

NFS-CHINA-QM_VV_TEST_PRS

1.5术语表

●作者或产品责任人：

创建或维护被评审的工作产品的个体。

●初始交付产品：

由作者交付的等待评审的工作产品。

●评审产品描述者：

评审会议的一个参与者，他需要在评审会议上向其他评审者描述所评审的产品。

●评审会议记录者：

评审会议的一个参与者，他需要在评审会议上记录评审中发现的所有问题和缺陷，并记录在《评审会议记录》中。

●因果分析：

评审的一个阶段，评审者追查每一个所发现的缺陷的产生原因，并确定阻止该类缺陷再出现的办法。

●缺陷检查表：

在一类指定的工作产品中所发现的缺陷种类的列表。

●可交付产品：

在工程项目的执行过程中产生的临时的或最后的文档、程序、文件或其他工件，在本过程中同“工作产品”。

●评审材料包：

由工作产品的作者和评审组长评审会之前分发给评审人员的一组材料，包括被评审的工作产品及定义其规格说明的文档、标准、必要的表单、检查表和规则集，以及测试文档等。

●评审组长：

领导评审活动，也称为评审领导。

他负责同作者一起计划评审活动，制定进度，布置会议，从其领导的评审活动中收集和报告测量数据，并可能参与验证作者的返工结果。

评审组长通常由质量保证人员兼任，产品作者不应充当该角色。

●规则：

指导作者以特定的方式完成任务和产品文档的语句或标准。

●工作产品：

在开发过程中所产生的文档、程序或其他成品，可能是项目中间产品或最终发布的产品，以及一些支持项目成功开发的支持性文档。

例如项目计划、需求规格说明、设计文档、用户接口设计、源代码、测试文档、用户及系统文档、培训材料，以及过程文档等。

1.6参考资料

●Paulk,MarkC.,etal.CapabilityMaturityModelforSoftware,Version1.1CMU/SEI-93-TR-24

●Paulk,MarkC.,etal.KeyPracticesoftheCapabilityMaturityModel,Version1.1,CMU/SEI-93-TR-25

●NationalAeronauticsandSpaceAdministration.SoftwareFormalInspectionsGuideBook,NASA-GB-A302

●Wiegers,KarlE.PeerReviewsinSoftware:

APracticalGuide.Addison-Wesley,2002.

●InstructionalHandbookforFormalInspections.Downloadedfromweb

●Wiegers,KarlE.SevenTruthsAboutPeerReviews.

2过程/规程总体描述

2.1过程/规程概述

评审的目的是由一组有资格的人员对软件设计和开发的输出进行评价，以判断确定设计和开发的输出能否实现软件产品预先定义的规格，同时通过评审标识出与规格和标准的偏差。

它向管理部门提供充足的证据以证明：

1）设计和开发的输出符合了其规格要求；

2）设计和开发的输出是否满足相关法律、法规以及企业标准的要求；

3）软件产品的更改得到了恰当地实施；

4）软件产品的更改只对那些规格发生了更改的系统区域有影响，没有引入新的问题。

评审应该遵守几项基本的原则：

1）保持公正客观的态度；

2）评审针对工作产品，而不是个人；

3）评审的目的是发现问题，从而解决问题；

4）尽量保持小型的评审小组；

5）评审会议时间不宜过长；

6）评审前必须先做准备。

2.2过程/规程结构描述

评审活动的过程结构图如下所示。

3过程/规程元素描述

3.1制定项目评审计划

概述

项目策划期间，项目组长和QA人员需要制定项目评审计划，包括整个项目周期内的哪些工作产品需要被评审及评审的大致时间，记录在项目计划书中。

参与人员及职责

●项目组长：

确定整个项目周期内的评审点及评审时间。

●QA人员：

与项目组长讨论确定评审计划。

入口准则

●项目已经立项；

●项目目标和项目范围已经确定；

●项目过程定义已经完成；

●工作拆分WBS已经完成；

●项目里程碑已经确定。

输入

●项目定义的软件过程

●工作拆分WBS

●里程碑安排

任务/步骤

1.确定评审点

根据项目定义的软件过程，确定在哪些节点需要进行评审，一般情况，在项目的各阶段性节点或里程碑点需要对工作产品进行正式评审，如：

项目策划结束、需求分析结束、详细设计结束等。

2.确定评审项

确定各评审的工作产品。

一般情况，在项目策划时尚不能确定每次评审准确的工作产品名称，但应在评审计划中说明待评审产品的主要内容，如：

项目计划、需求文档、架构设计文档、测试用例等。

3、确定评审类型

确定各评审的类型，包括：

会议评审、单人评审。

4、估计评审工作量

估计各评审的工作量，包括评审计划、预审、评审会议等活动的总工作量。

5、估计评审日期

估计各评审进行的日期，可以某一天，也可以是某个较小的时间段。

6、估计缺陷数

估计各评审可能发现的缺陷数，可以依据经验、历史项目数据、过程性能基线等。

7、确定评审方

确定参加评审的人员组成，如：

项目组人员、相关组、高层等。

8、编写评审计划

编写项目计划书中的评审计划部分。

9、在甘特图上拆分评审任务

在的甘特图上拆分评审任务，指定评审者及计划评审日期。

出口准则

●项目评审计划已制定

输出（工作产品）

●项目计划书中的评审计划

资源和能力要求

●项目组长和QA人员接受过项目策划、评审方面的培训。

度量

度量元

采集点

制定项目评审计划过程中所花费的工作量

项目组长和QA人员的工作周报

裁剪指南

裁剪内容

裁剪准则

不可裁剪

无

3.2制定评审任务计划

概述

本节描述了制定单个评审计划的相关活动。

参与人员及职责

●项目组长：

任命评审组长，并赋予他相应的权利。

●产品责任人：

提交产品和相应材料，并提出评审目标。

●评审组长：

与项目组长和产品责任人一起准备评审材料，确定参加评审的人员组成等。

入口准则

●产品已经完成，准备进行评审；

●文本文档已经经过拼写检查和校对；

●初始可交付产品有一个唯一的版本标识；

●行号已经被打印在文件和源代码清单上了；

●所有未解决的问题都必须用特定的标记标识出来；

●对于重复审查，所有上次审查发现的问题都必须得到解决。

输入

●初始可交付产品

任务/步骤

1.确定评审组长

在准备评审前，项目组长应根据评审的产品和具体情况指定一个人员来负责主持评审，称为评审组长。

项目组长可担任评审组长，也可任命项目的质量保证负责人作为评审组长。

2.确定被评审对象

在计划制定阶段，产品责任人和评审组长要决定是审查整个可交付产品还是只审查其中的一部分。

对于不能进行整体检查的大件产品和评审时间不够时，可以选择其中一些样本进行审查。

对于每个部分复杂度和技术风险不同的产品，着重审查那些最复杂，风险最高的部分。

然后根据可交付产品的代表性样本的审查结果，可以有效的决定是否应该评审整个可交付产品。

3.选择参加评审的人员组成

评审组长应该与产品责任人和项目组长一起确定参加评审的人员组成。

评审的成功很大程度上依赖于参与者，所以应该谨慎的选择评审参与人员。

4.准备评审材料包

典型的评审材料包应包括以下各项：

●被评审的初始可交付产品，其中明确指明需评审的部分；

●定义了可交付产品的规格说明的所有前期的文档；

●相关标准，缺陷检测表，规则集或其他参考文档；

●参与评审者需要的所有表格，如评审意见表等；

●有助于评审者发现缺陷的帮助文档，如该类工作产品的常见缺陷检查表和产品要求遵循的规则等；

●用于验证初始可交付产品的测试文档；

●其他可帮助评审的材料等。

对于代码的评审，还包括静态代码分析器生成的报告和与被评审源代码相关的其他文件的副本，如头文件，make文件，或协作对象类的代码或设计描述等。

评审组长和产品负责人在这一阶段要负责选择或自行编写相关产品的缺陷检测表等帮助评审人员对产品进行评审的材料。

评审组长在正式评审开始之前将这些评审材料包的副本分发给每位评审人员，让他们有足够的时间去准备。

在评审组长分发了评审材料包之后，产品责任人应该冻结工作产品，不要让它在评审会议开始之前再有任何改动。

5.编写评审活动计划

制定评审活动计划的一个重要部分是判断当材料都准备就绪时，评审小组能有效的评审多少材料，评审组长根据积累数据或参考其他项目提供的数据判断合适的准备和评审速率。

评审组长为每次评审制定计划，确定需要评审会议的次数，每次会议的内容和进度。

评审组长还有安排好合适的地点，并确保将活动、日期、次数和地点通知各位评审者。

项目组长在上拆分相关的评审任务，由评审组长制定评审计划，确定评审的内容和进度，确定评审的工作产品。

评审组长应提前２～３天将评审材料包发给评审者。

出口准则

●评审组长已经按本过程的要求确定

●评审活动计划已经完成

输出（工作产品）

《评审任务计划》

资源和能力要求

评审过程中的所有参与者都接受过培训，如果评审组长决定在小组中引入一个没有经过培训的新手，必须事先简单的向他介绍情况，使他至少对评审有所了解。

对于源代码的评审，要求：

●代码在特定的编译器设置环境中已经正确编译；

●静态代码分析器发现的错误已经被纠正了；

●将被审查的代码段已经被明确标识。

度量

度量元

采集点

制定评审计划花费的工作量

评审组长工作周报

裁剪指南

裁剪内容

裁剪准则

不可裁剪

无

3.3正式评审

正式评审的过程流图如下：

概述

正式评审的方法有两种，一种是评审会议法，另一种是直接法。

参与人员及职责

●评审组长：

主持评审会议，分析评审意见，记录评审问题。

●产品责任人：

参加评审会议，查看评审报告。

●评审产品说明者：

在评审会议上向其他评审者描述所评审的产品。

●评审者：

参加评审会议，确认产品缺陷，提供解决意见。

●评审会议记录者：

参加评审会议，并在会议上负责记录下所有的问题。

入口准则

●各参与评审者都已提交了《评审意见表》

输入

●初始可交付产品

●《评审意见表》

任务/步骤

1.直接法

评审组长根据各评审者提供的评审意见表，分析各评审者的评审意见，当各位评审者的意见基本一致，或问题比较明确并已得到解决时，可与项目组长协商采用直接法的方式，直接形成评审结论，填写《评审会议记录》。

否则，则采用会议评审方式。

2.评审会议

会议评审就是将所有参加评审的人员集中在一起召开评审会议，根据评审的内容和要求进行讨论、分析并就最终结果达成一致的评审方式。

评审会议可以采用以下三种形式：

1）如果评审组长通过统计各《评审意见表》，发现问题已经比较明显或集中，可以由评审组长口述工作产品中出现问题的部分，再通过各评审者的讨论得出一致的结论和建议解决措施。

2）由产品责任人分段描述自己的工作产品，再通过各评审者讨论找出缺陷或提出问题。

3）最慎重的方式是，由评审组长在制定评审计划时指定的产品描述者在评审会议上用自己的语言对工作产品进行分段描述，然后通过各评审者讨论确认产品中的缺陷或问题。

评审会议记录者要记录下评审会议中找出的工作产品中的缺陷和问题，以及在会议中达成的建议解决措施等，将这些信息记录在《评审会议记录》中。

出口准则

●初始工作产品已执行了评审，并形成了评审意见。

输出（工作产品）

●《评审会议记录》

资源和能力要求

评审组长在评审会议中起着重要的作用，他要做到：

●保证会议按计划进展；

●控制会议节奏；

●使各评审者积极有效的参与；

●领导评审小组对产品质量作出正确的评价。

度量

度量元

采集点

评审会议过程中所花费的工作量

《评审会议记录》

评审会议过程中发现的缺陷数

裁剪指南

裁剪内容

裁剪准则

评审会议

●当各位评审者的意见基本一致，或问题比较明确并已得到解决时，可以不举行评审会议

●当独立评审意见不一致，产品问题较多或产品对后续开发十分重要时，必须举行评审会议

3.4填写评审总结报告

概述

完成正式评审之后，还需要填写《评审总结报告》，用以确保对评审结果有正确的记录。

参与人员及职责

●项目组长：

审阅和批准评审报告。

●评审组长：

形成《评审总结报告》。

入口准则

●评审结束，已找出产品存在的缺陷和问题。

输入

●《评审会议记录》

任务/步骤

1.直接法

评审组长填写《评审会议记录》后，形成《评审总结报告》。

2.评审会议

评审会议结束后，由评审组长综合各评审者的《评审意见表》，和评审会议的达成的结论形成《评审总结报告》。

出口准则

●产品责任人已经根据评审意见对初始的可交付产品完成了返工。

输出（工作产品）

●评审组长形成《评审总结报告》

资源和能力要求

无

度量

度量元

采集点

形成评审结论和评审会议过程中所花费的工作量

评审总结报告

形成评审结论和评审会议过程中发现的缺陷数

裁剪指南

裁剪内容

裁剪准则

不可裁剪

无

3.5修改评审缺陷

概述

完成评审报告并不意味着审查结束了，还需要进行修正错误和其他对初始的可交付产品进行改进等工作。

参与人员及职责

●产品责任人：

根据评审结果，修改产品。

●项目组长：

协助产品责任人修改产品。

●评审组长：

协助产品责任人修改产品。

入口准则

●评审结束，已找出产品存在的缺陷和问题。

输入

●初始的可交付产品

●评审问题列表

任务/步骤

几乎每一次评审都会找出一些需要改正的缺陷和一些建议的改进要求，其中对于改进建议，产品责任人可以有选择的实施改进。

产品责任人应该迅速完成返工，以便他能够将改正后所发布的版本定为基线，并继续他下一个任务。

产品责任人应与项目组长协商，对于评审中发现的产品缺陷的修改方法，通常有以下的处理方法：

●根据评审意见修改产品，使产品符合标准。

●对于有些项目而言，可能对一些已知的缺陷不作修改，这或是迫于项目进度的压力，或是认为这些保留的缺陷只会对用户产生很小的影响。

对于决定不作修改的缺陷或问题，产品责任人应该在评审会议记录上将原因注明在该问题后面。

缺陷修改后，在中将问题状态改为“待验证”。

出口准则

●产品责任人已经根据评审意见对初始的可交付产品完成了评审缺陷的修改。

输出（工作产品）

●改正后的可交付产品

●《评审会议记录》

资源和能力要求

无

度量

度量元

采集点

产品责任人在返工过程中所花费的工作量

产品责任人的周报表

产品责任人在返工过程中清除的缺陷数

裁剪指南

裁剪内容

裁剪准则

修改

●可不进行修改

⏹评审没有发现问题；

⏹评审发现的问题属于次要问题，经与项目组长协商决定不进行修改。

●必须进行修改

⏹评审发现的问题属于主要缺陷，或会导致严重的后续问题

3.6跟踪评审缺陷

概述

跟踪是完成一个工作产品审查的一个重要阶段，验证评审中发现的工作产品的问题是否正确的进行了修改和处理。

只有经过跟踪验证的产品才能形成可基线化的产品，为后续的开发工作提供稳固的基础。

参与人员及职责

●项目组长：

审阅和批准修改后的产品；

●评审组长：

对产品的修改进行跟踪，对修改后的产品进行检查；

●产品责任人：

提交修改后的产品。

入口准则

●初始的可交付产品已经根据评审意见进行了修改，是形成基线前的待发布产品。

输入

●改正后的可交付产品

●《评审会议记录》

任务/步骤

评审组长根据《评审会议记录》来跟踪修改后的产品，跟踪的目的是：

●验证产品责任人是否恰当的解决了评审中发现的所有问题，以及是否合理的决策了某些缺陷可以不修改；

●确认对原来的缺陷所作的修改是正确的，并不会带来新的缺陷；

如果评审组长跟踪的结果不能确定修改后的产品是否满足要求或者本次评审结论要求修改后的产品必须再次评审，评审组长可以与项目组长协商，针对修改后的产品再进行一次评审，评审过程也同本规程。

缺陷被验证通过后，在中将问题状态置为“关闭”。

出口准则

●评审结束

输出（工作产品）

●可基线化的可交付产品

资源和能力要求

无

度量

度量元

采集点

进行跟踪活动所花费的工作量

评审组长的工作周报

裁剪指南

裁剪内容

裁剪准则

跟踪

●评审结果是接受产品目前的状态，可不进行跟踪；

●评审结果要求产品进行修改，必须进行跟踪。

附录

3.7附录A－相关过程

3.8附录B－相关规程

3.9附录C－相关指南

3.10附录D－相关模板列表

模板名称

使用人

使用时间

《评审活动计划模板》

评审组长

制定评审计划时使用

《评审会议记录模板》

评审组长，评审会议记录者，产品责任人

发现问题，解决问题和跟踪问题时使用

《评审意见表模板》

评审者

进行预审时使用

《评审总结报告模板》

评审组长

评审结束时使用