VV-确认和验证过程指导书

编号：cStyleCN-PG18-VV 北京利众得应用技术有限公司软件过程改进之确认与验证过程指导书V1.6.0修订记录目录一、概述 (6)二、确认 (6)1需求确认 (6)1.1概述 (6)1.2开始基准 (6)1.3实施过程 (6)1.4输出工作产品 (7)1.5结束基准 (7)2验收测试和B ETA测试 (7)2.1概述 (7)2.2开始基准 (8)2.3实施过程 (8)2.3.1实施测试 (8)2.3.2缺陷的记录、分析、解决和跟踪 (8)2.4输出工作产品 (8)2.5结束基准 (9)三、验证 (9)1评审 (9)1.1评审分类 (9)1.1.1专家评审 (9)1.1.2同级互查 (9)1.2角色 (10)1.3评审方式 (11)1.3.1审查 (11)1.3.1.1概述 (11)1.3.1.2开始基准 (11)1.3.1.3实施过程 (12)1.3.1.3.1评审准备 (12)1.3.1.3.2召开评审会议 (13)1.3.1.3.3评审结果 (13)1.3.1.3.4消除问题 (14)1.3.1.3.5问题跟踪 (14)1.3.1.3.6评审结束 (14)1.3.1.4输出工作产品 (14)1.3.1.5结束基准 (15)1.3.2小组评审 (15)1.3.2.1概述 (15)1.3.2.2开始基准 (15)1.3.2.3实施过程 (15)1.3.2.4输出工作产品 (16)1.3.2.5结束基准 (16)1.3.3个体检查 (16)1.3.3.1概述 (16)1.3.3.2开始基准 (16)1.3.3.3实施过程 (16)1.3.3.4输出工作产品 (17)1.3.3.5结束基准 (17)1.3.4评审检查表 (17)1.3.5对代码的评审 (17)2测试 (18)2.1概述 (18)2.2开始基准 (18)2.3实施过程 (18)2.3.1实施测试 (18)2.3.2缺陷的记录、分析、解决和跟踪 (18)2.4输出工作产品 (19)2.5结束基准 (19)四、附录A 瀑布模型生命周期中的评审计划 (19)五、附录B 其它生命周期中的评审计划 (23)软件“确认”与“验证”是贯穿于软件开发过程中十分细致的软件检验活动。

“确认”是从用户的角度，检验当前的开发成果符合用户的真正需求，即“做了正确的事”。

“验证”是在软件开发的各个阶段，从软件技术人员的角度，测试当前的开发成果（文档，代码等）符合设计的规范，保证按照设计流程和要求进行开发，即“正确地做了事”。

1需求确认1.1概述从根本上说，需求来源于用户的“需要”和“要求”，这些“需要”和“要求”被分析、整理、确认后形成完整的文档，该文档详细地说明了产品“应当”实现的功能。

需求确认是指项目经理和客户经过充分的沟通和交流，对项目的开发要求达成共识并做出承诺。

1.2开始基准1、对需求的必要性和可行性进行分析，确定需求文档。

2、已识别了被确认的工作的产品和产品组件。

1.3实施过程1、将客户的“需要”和“要求”记录在《要求记录表》中，内容主要包括：功能性要求、非功能性要求、关于组件的重用和开发的要求以及业务流程图。

客户需要在《要求记录表》上签字。

2、项目经理与客户代表双方经过充分的沟通和交流，对项目的开发需求已经达成共识，将已确认的需求记录在《要求记录表》中，作为进行项目开发的依据。

客户需要在《需求记录表》上签字。

3、如果要对《要求记录表》或《需求记录表》中的内容进行变更，必须由双方协商确认。

4、在项目过程中，客户无法签字的情况，可采用Q&A的方式确认。

当对业务的理解有疑问，需要就需求文档，设计文档等工作产品与客户进行确认时，可使用《Q&A》和客户进行沟通，在《Q&A》中项目经理向客户提供主要的确认点(可从技术评审检查表中提出主要的检查项)，请客户确认；对技术有疑问而内部不能达成一致的或得到解决时，通过《Q&A》和客户沟通，在《Q&A》中记录疑问，请客户回答。

1.4输出工作产品1、《要求记录表》。

2、《需求记录表》。

3、《Q&A》或客户返回的确认邮件。

1.5结束基准1、客户在《要求记录表》和《需求记录表》上签字。

2、客户针对《Q&A》确认点或疑问，进行了确认或回答。

3、项目经理记录了《Q&A》的问题数和确认工作的工作量。

2验收测试和Beta测试2.1概述验收测试和Beta测试是检验软件的功能和性能及其它特性是否与用户的要求一致。

对软件的品质从功能、性能、可靠性、易用性等方面作全面的质量检测，帮助项目组找出产品存在的问题。

验收测试主要针对项目来实施，Beta测试主要针对产品实施，可以把Beta 测试看作是对产品的验收测试。

1、制定了《验收测试计划》和《Beta测试计划》。

2、准备了相关的《测试式样书》、测试脚本、测试工具和测试所用数据。

3、搭建好了测试环境。

2.3实施过程2.3.1实施测试1、需要测试的所有测试项均已准备就绪，测试经理会按照《项目开发进度表》中的测试进度来安排测试人员进行测试。

2、测试人员将装载所有软件和测试数据文件，并利用《测试式样书》中的测试用例、测试脚本和预期测试结果来进行测试。

2.3.2缺陷的记录、分析、解决和跟踪1、在测试过程中，记录测试结果，对于预期结果和实际结果不符的，需要将预期结果与实际结果之间的差异一起记录下来。

可以记录在《缺陷列表》或Bugzilla 或客户的不具合一览表中。

所有的缺陷都要进行记录。

2、项目经理对缺陷进行分析，确定是客户原因的缺陷还是己方原因的缺陷，对于己方原因的缺陷，需要分析缺陷产生的原因。

缺陷原因分类：设计错误，代码错误，功能遗漏，式样理解错误，共通错误，其他等。

3、确定了缺陷改正的措施，并解决了缺陷。

4、解决了的缺陷得到了验证，并通过了测试。

2.4输出工作产品1、《缺陷列表》或客户的不具合一览表。

1、《缺陷列表》或客户的不具合一览表中己方原因的缺陷均得到了解决、验证并通过了测试。

2、项目经理记录了缺陷数和解决缺陷的工作量。

1评审评审分为：专家评审、同级互查两种类型，每种类型都可以采用三种评审方式（审查，小组评审，个体检查）之一进行评审，评审目的有两个：工作产品评审和阶段评审。

一般来讲，阶段评审在每个阶段结束前进行，工作产品评审一般安排在阶段评审之前或同时进行。

在制定计划的时候，项目经理识别出哪些工作产品将要进行同级互查，哪些工作产品将要进行专家评审，计划采用哪种评审方式，评审的目的是什么等。

并将评审的进度安排在项目进度表中并明确评审者。

1.1评审分类1.1.1专家评审专家的定义：与另一个人或其他人在等级、阶级上不一定具有同等地位，但在某些领域具有足够的经验和技能，能够在此领域对某些问题提出有见地的意见和建议。

专家评审的目的：在项目组成员内或外对工作产品进行专家级的检查，尽可能在生命周期的早期发现并除去问题。

1.1.2同级互查同级的定义：与其他人处于相同等级、阶级地位的人。

同级互查的概念：由作者的同级按照预定的规程对软件工作产品进行的评审，不得由作者本人对自己的工作产品进行评审。

同级互查的目的：在项目组成员内对工作产品进行相互检查，尽可能在生命周期的早期发现并除去问题。

1.2角色下表列出了在评审过程中所有可能涉及的角色及其责任。

每个参与者可以担任多个角色。

所有参与者除了自身担任的特定角色外，也都是评审参与人员。

一次评审需要至少三个参与者，包括作者。

作者一般不作讲解员或记录员。

1.3评审方式下面主要描述了三种评审方式的实施过程。

1.3.1审查1.3.1.1概述审查是正式评审方式，一般有3-5人参与评审，以评审会议或email的形式进行。

以email方式进行审查时，评审参与人员需使用检查表，对待评审的工作产品及相关资料进行审阅，将发现的问题记录在阶段/工作产品评审会议纪要的问题列表中，以email方式告知项目经理。

如果没有问题，也需回复email说明。

在进行立项、计划、需求、设计的阶段评审时间建议采用审查方式。

另外，评审下列工作产品时一般也采用审查方式。

1、关键的工作产品。

2、复杂或关键的代码。

3、问题较多的工作产品。

4、关键工作产品的最终评审。

1.3.1.2开始基准1、项目经理为待评审的工作产品选择了审查的评审方式。

2、作者准备好待评审的工作产品及相关文档。

3、作者陈述了评审目标。

4、配臵经理为待评审的文档分配了版本号。

所有页面都标明了页码。

文档经过了拼写错误检查。

5、配臵经理为待评审的源代码分配了版本号。

代码清单标明了行号和页码。

代码通过了基本检查。

6、对于二次评审，前一次评审中发现的所有问题都已经解决。

1.3.1.3实施过程1.3.1.3.1评审准备1、作者将待评审的工作产品和相关资料提交给项目经理。

2、项目经理确定工作产品是否满足评审入口准则。

3、项目经理根据工作产品的规模和复杂度确定需要多少次评审会议（评审工作产品的工作量最长不超过2-3小时，若工作量过大，要分成多次评审会议）。

4、项目经理和作者共同选择评审参与人员，为其分配角色。

5、在评审会议前，项目经理至少提前三个工作日向评审参与人员发布评审会议通知，待评审的工作产品、相关资料和检查表。

6、作者向评审参与人员陈述评审目标，描述工作产品的重要特征。

（可召开评审说明会议，或通过邮件说明）。

7、项目经理要求评审参与人员以特定的角度准备评审。

例如，检查交叉引用的一致性，检查接口错误，检查对以往的规范的可追溯性和一致性，检查对标准的符合性。

8、评审参与人员预评审工作产品，将发现的问题在阶段/工作产品评审会议纪要的问题列表中，在评审会议之前交给项目经理，由项目经理转交给作者。

9、项目经理确认准备情况：了解每个评审参与人员的准备时间，如果准备不充分，重新安排会议时间。

1.3.1.3.2召开评审会议1、召开会议：项目经理介绍评审会议参加者（可选），说明其角色（可选），陈述评审目标。

指导评审参与人员将精力集中于发现问题，而不是解决方法。

提醒参与人员要针对正在评审的工作产品，而不是作者。

2、展示工作产品：讲解员向评审参与人员描述工作产品的各个部分。

3、提出问题：每展示完工作产品的一部分，评审参与人员提出关心的问题，潜在的缺陷，疑问或改进建议。

4、解答问题：作者简短回答提出的问题，使评审参与人员进一步了解工作产品，从而帮助确认是否真的是问题。

5、记录问题：对确认存在的问题，记录员记录到阶段/工作产品评审会议纪要的问题列表中。

大声读出记录，以确认问题被正确地记录。

1.3.1.3.3评审结果1、确定产品评审结果：所有评审会议结束以后，评审小组确定工作产品的评审结果。

如果意见不一致，由项目经理协调，评审结果应确定为所有评审参与人员给出的评审结果中最保守的一个。