VV确认和验证过程指导书Word文档格式.docx

VV确认和验证过程指导书Word文档格式.docx

《VV确认和验证过程指导书Word文档格式.docx》由会员分享，可在线阅读，更多相关《VV确认和验证过程指导书Word文档格式.docx（23页珍藏版）》请在冰豆网上搜索。

按照修改后的评审方式，修改《评审计划》

2007-10-24

增加1.3.5对代码的评审发现的问题的处理方法。

2007-11-7

目录

一、概述6

二、确认6

1需求确认6

1.1概述6

1.2开始基准6

1.3实施过程6

1.4输出工作产品7

1.5结束基准7

2验收测试和Beta测试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召开评审会议12

1.3.1.3.3评审结果13

1.3.1.3.4消除问题13

1.3.1.3.5问题跟踪14

1.3.1.3.6评审结束14

1.3.1.4输出工作产品14

1.3.1.5结束基准14

1.3.2小组评审15

1.3.2.1概述15

1.3.2.2开始基准15

1.3.2.3实施过程15

1.3.2.4输出工作产品15

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测试17

2.1概述17

2.2开始基准18

2.3实施过程18

2.3.1实施测试18

2.3.2缺陷的记录、分析、解决和跟踪18

2.4输出工作产品18

2.5结束基准19

四、附录A瀑布模型生命周期中的评审计划19

五、附录B其它生命周期中的评审计划22

一、

概述

软件“确认”与“验证”是贯穿于软件开发过程中十分细致的软件检验活动。

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

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

二、确认

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测试看作是对产品的验收测试。

2.2开始基准

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

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

3、搭建好了测试环境。

2.3实施过程

2.3.1实施测试

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

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

2.3.2缺陷的记录、分析、解决和跟踪

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

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

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

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

缺陷原因分类：

设计错误，代码错误，功能遗漏，式样理解错误，共通错误，其他等。

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

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

2.4输出工作产品

1、《缺陷列表》或客户的不具合一览表。

2.5结束基准

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召开评审会议

10、召开会议：

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

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

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

11、展示工作产品：

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

12、提出问题：

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

13、解答问题：

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

14、记录问题：

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

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

1.3.1.3.3评审结果

15、确定产品评审结果：

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

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

评审结果如下表所示：

评审结果

含义

完全接受

可能需要做某些修改，但修改不需要审核。

有条件的接受

必须修改缺陷，所做的修改必须由指定的人审核。

需进行二次评审

工作产品的很大部分都需要修改或需要做很多变更。

作者完成修改工作后需要二次评审。

项目停止

由于项目存在重大缺陷或其它的原因，项目停止。

评审未完成

评审内容的重要部分没有评审或评审因某些原因中断。

16、签署评审结果：

所有评审参与者都要在阶段/工作产品评审会议纪要上签字，说明他们同意评审结果。

1.3.1.3.4消除问题

1、作者改正问题和小错误，解决提出的问题，并相应地修改工作产品。

在阶段/工作产品评审会议纪要的问题列表中标注已经处理过的问题。

2、作者基于工作产品评审发现的问题，修改其他相关文档。

3、作者向项目经理报告消除的问题数量，以及工作量。

1.3.1.3.5问题跟踪

1、由项目经理或指定的人员来确认作者已经对应了相应阶段/工作产品评审会议纪要中的问题。

确定作者是否正确的判断了哪些问题不必改正，那些改进建议不必实现。

2、项目经理检查修改后的工作产品，对问题的修正工作进行确认，将结果告之作者。

3、项目经理统计问题数及相关工作量。

4、项目经理检查是否满足评审的结束基准。

如果满足，则评审结束。

5、配置经理将工作产品基线化到项目配置管理系统中。

1.3.1.3.6评审结束

1、项目经理简单总结此次评审活动，将问题记录在相应阶段/工作产品评审会议纪要的问题列表中，提出建议和解决的方法。

2、评审活动结束。

1.3.1.4输出工作产品

1、基线化的工作产品。

2、完成的阶段/工作产品评审会议纪要（包括阶段/工作产品评审会议纪要的问题列表）。

1.3.1.5结束基准

1、所有评审目标都已达成。

2、评审中提出的确定必须消除的问题被跟踪直至关闭。

3、修改的工作产品已基线化到项目配置管理系统中。

4、如果修改了以前的工作产品，则已经正确地修改了这些工作产品，保存到了项目配置管理系统中。

5、项目经理记录了问题数和消除问题的工作量。

1.3.2小组评审

1.3.2.1概述

小组评审是非正式评审的方式，通常采用会议形式，有3-5人参与评审。

在进行实现、测试的阶段评审建议采用小组评审方式。

另外在下列情况下也使用小组评审的方式：

1、工作产品的初期评审。

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

3、当非关键工作产品发生大变更时。

1.3.2.2开始基准

1、项目经理为需要评审的工作产品选择了小组评审的评审方式。

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

1.3.2.3实施过程

1、作者在会议之前分发工作产品给评审参与人员。

2、在会议期间，作者以适当的方式向评审参与人员描述工作产品。

针对评审参与人员关心的议题组织讨论。

3、评审参与人员提出可能的问题和改进建议，记录在阶段/工作产品评审会议纪要及阶段/工作产品评审会议纪要的问题列表中。

4、作者根据评审参与人员的评论，对工作产品执行必要的修改。

1.3.2.4输出工作产品

1、修改的工作产品。

1.3.2.5结束基准

作者已经对工作产品做了恰当的修改。

1.3.3个体检查

1.3.3.1概述

个体检查是非正式评审的形式，有2-n人参与评审。

通常由作者将工作产品及相关资料分发给评审参与人员，作者和评审参与人员之间进行讨论交流。

在下列情况下使用个体检查评审方式：

1、工作产品最初的设计和开发时。

3、当非关键工作产品发生小变更时。

1.3.3.2开始基准

1、项目经理选择了个体检查的评审方式。

2、作者对文档进行了拼写错误检查。

3、作者对代码进行了基本的检查。

1.3.3.3实施过程

1、作者将工作产品及相关文档发送或共享给每个评审参与人员。

2、作者通知评审参与人员工作产品已经准备好，指定评审的结束日期。

3、评审参与人员将发现的问题记入阶段/工作产品评审会议纪要的问题列表中，交给作者。

4、作者在评审结束后，从共享目录中移走工作产品。

5、作者根据评审参与人员填写的阶段/工作产品评审会议纪要的问题列表，对工作产品进行必要的修改。

1.3.3.4输出工作产品

1、修改后的工作产品。

1.3.3.5结束基准

作者已经对应了阶段/工作产品评审会议纪要的问题列表中的所有问题。

1.3.4评审检查表

评审检查表分为工作产品评审检查表（包含在《工作产品评审会议纪要》中）和阶段评审检查表（包含在《阶段评审会议纪要》中）。

开始时，检查表可以基于行业标准，但是不可以与组织的标准有冲突。

在个体检查中，评审人员在执行评审时，可以根据实际情况，对当前项目所使用的检查表进行更新，对本项目的检查对象不适用的项目可以删除，而未被计入的可以作为新项目添加到当前项目所使用的检查表模板中，但在对检查表进行修改时必须得到项目经理的认可。

组织将定期对检查表进行更新，确保其支持组织最新的开发模式，有些从来没有发现过问题的检查项也可以逐渐从检查表中被删除。

1.3.5对代码的评审

仔细的分析代码发现的问题对于减少后期测试的工作量有很大的帮助，便于项目经理掌控整个项目的缺陷信息，我们将代码评审时发现的问题，当作缺陷处理，记录在《缺陷列表》中。

其处理流程参见2.3.2缺陷的记录、分析、解决和跟踪。

2测试

软件测试是一个在可控的环境中执行软件的过程，其目的是为了验证软件是否按照预期运行。

这里所说的测试包括单体测试、结合测试和系统测试。

1、制定了《测试计划》，并在其中说明了测试策略。

单体测试一般由开发人员进行。

可以记录在《缺陷列表》或Bugzilla中。

2、项目经理对缺陷进行原因分析，缺陷原因等信息详见《缺陷列表》。

5、测试结束后，要对前一阶段的测试进行分析，将分析结果记录在《测试分析报告》中。

1、《缺陷列表》。

2、《测试分析报告》。

1、《缺陷列表》中的缺陷均得到了解决、验证并通过了测试。

四、附录A瀑布模型生命周期中的评审计划

时机

评审分类

评审方式

评审目的

评审工作产品

评审后的产物

评审检查表

参加评审人员

立项阶段

专家评审

审查

工作产品评审

《项目启动协议书》

已签字的《项目启动协议书》

《项目立项协议书检查表》

PMO、项目经理、项目支持人员、项目启动支持人员、QA

计划阶段

阶段评审

《执行计划书》

《项目开发计划》

《裁减过程记录》

《项目估计表》

《项目风险列表》

《项目进度表》

《测试计划》

《项目度量数据》

《计划评审会议纪要》（含签字）

《项目开发计划评审检查表》

PMO、项目经理、QA

需求开发阶段

小组评审/个体走查

《要求列表》

《需求列表》（需求规格式样书）

《需求评审会议纪要》

《需求文档评审检查表》

领域专家、客户代表、项目经理、QA

《问题列表》

《需求阶段评审会议纪要》

《阶段评审检查表》

设计阶段

《概要设计式样书》

《详细设计式样书》

Mockup

《软件设计对应表》

《画面设计书》

《画面迁移图》

《表定义书》

《消息定义书》

《系统架构设计书》

《采购需求定义书》

《软件架构设计书》

《帐票设计书》

《文件设计书》

《外部接口说明书》

《设计评审会议纪要》

《设计文档评审检查表》

架构师、设计师、项目经理、

《设计阶段评审会议纪要》

实现

同级互查

个体检查

代码

《代码走查检查表》

程序员

《单体测试式样书》

《单体测试式样书评审纪要》

《单体测试式样书评审检查表》

小组评审

《单体测试报告》

《缺陷列表》

《实现阶段评审会议纪要》

测试

《测试式样书》

《测试式样书评审纪要》

《测试式样书评审检查表》

测试经理、项目经理、测试人员

《测试分析报告》

《测试阶段评审检查表》

PMO、项