VV确认和验证过程指导书Word文档下载推荐.docx
《VV确认和验证过程指导书Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《VV确认和验证过程指导书Word文档下载推荐.docx（36页珍藏版）》请在冰点文库上搜索。
实施过程........
1.4
输出工作产品
1.5
结束基准.......'
10...
2验收测试和beta测试
2.1
2.2
开始基准
2.3
实施过程
1.0.
2.3.1实施测试
2.3.2缺陷的记录、分析、解决和跟踪
1.0
2.4输出工作产品
2.5结束基准
.1.1
验证
11
1评审
1.1评审分类
专家评审
1.2角色
.12...
1.3评审方式
13...
1.3.1审查
14
1.3.1.1
.14,
1.3.1.2
1.3.1.3
1.5..
1.3.1.3.1
评审准备
1.3.1.3.4
1.3.1.3.5
1.3.1.3.6
1.3.1.4
1.3.1.5
召开评审会议
评审结果
消除问题
问题跟踪
评审结束
结束基准
1.3.2小组评审
1.3.2.1
1.3.2.2
开始基准.......
1.3.2.3
实施过程.......
1.3.2.4
1.3.2.5
结束基准.......
1.3.3个体检查
1.6.
1.6
1.7
1.7.
1.8
18..
1.8..
1.8...
.18...
1.9..
19.
20..
20...
四、
五、
1.3.3.2
1.3.3.3
1.3.3.4
1.3.3.5
1.3.4评审检查表
1.3.5对代码的评审
2测试
概述........
附录A瀑布模型生命周期中的评审计划
附录B其它生命周期中的评审计划
21..
21…
21...
22..
22....
22...
23
23...
24
28
、概述
软件“确认”与“验证”是贯穿于软件开发过程中十分细致的软件检验活动。
“确认”是从用户的角度，检验当前的开发成果符合用户的真正需求，即“做了正确的事”。
“验证”是在软件开发的各个阶段，从软件技术人员的角度，测试当前的开发成果（文档，代码等）符合设计的规范，保证按照设计流程和要求进行开发，即“正确地做了事”
、确认
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角色
F表列出了在评审过程中所有可能涉及的角色及其责任。
每个参与者可以担
任多个角色。
所有参与者除了自身担任的特定角色外，也都是评审参与人员。
一次评审需
要至少三个参与者，包括作者。
作者一般不作讲解员或记录员。
角色
责任
作者
•被评审的工作产品的创建者或维护者，与项目经理一起发起评审过程。
•陈述评审目标
•提交工作产品及相关文档给项目经理。
•与项目经理一起选择评审参与人员，并分配角色。
•与作者一起选择评审参与人员，并分配角色。
-提前评审会议至少三天，将待评审的工作产品及相关
文档发送给评审参与人员。
-确定会议准备是否充分。
如果不充分，重新安排会议
时间。
•保证评审会议进行。
纠正任何不适当的行为。
随着讲
解员展现工作产品的各部分，引导评审参与人员提出
问题。
-领导评审小组确定工作产品的评审结果。
现问题。
审会议做准备。
-参加评审，识别问题，给出改进建议。
1.3评审方式
F面主要描述了三种评审方式的实施过程。
1.3.1审查
131.1概述
审查是正式评审方式，一般有3-5人参与评审，以评审会议或email的形式进行。
以email方式进行审查时，评审参与人员需使用检查表，对待评审的工作产
品及相关资料进行审阅，将发现的问题记录在阶段/工作产品评审会议纪要的问
题列表中，以email方式告知项目经理。
如果没有问题，也需回复email说明。
在进行立项、计划、需求、设计的阶段评审时间建议采用审查方式。
另外，评审下列工作产品时一般也采用审查方式。
关键的工作产品。
复杂或关键的代码。
问题较多的工作产品。
关键工作产品的最终评审。
1、
项目经理为待评审的工作产品选择了审查的评审方式。
2、
作者准备好待评审的工作产品及相关文档。
3、
作者陈述了评审目标。
4、
配置经理为待评审的文档分配了版本号。
所有页面都标明了页码。
经过了拼写错误检查。
5、
配置经理为待评审的源代码分配了版本号。
代码清单标明了行号和页
文档
码。
代码通过了基本检查。
6、对于二次评审，前一次评审中发现的所有问题都已经解决。
131.3实施过程
13131评审准备
作者将待评审的工作产品和相关资料提交给项目经理。
项目经理确定工作产品是否满足评审入口准则。
项目经理根据工作产品的规模和复杂度确定需要多少次评审会议（评审工作产品的工作量最长不超过2-3小时，若工作量过大，要分成多次评审会议）。
项目经理和作者共同选择评审参与人员，为其分配角色。
在评审会议前，项目经理至少提前三个工作日向评审参与人员发布评审会议通知，待评审的工作产品、相关资料和检查表。
作者向评审参与人员陈述评审目标，描述工作产品的重要特征。
（可召开评审说明会议，或通过邮件说明）。
项目经理要求评审参与人员以特定的角度准备评审。
例如，检查交叉引用的一致性，检查接口错误，检查对以往的规范的可追溯性和一致性,检查对标准的符合性。
评审参与人员预评审工作产品，将发现的问题在阶段/工作产品评审会议纪要的问题列表中，在评审会议之前交给项目经理，由项目经理转交给作者。
项目经理确认准备情况：
了解每个评审参与人员的准备时间，如果准备
不充分，重新安排会议时间。
1.3.1.3.2召开评审会议
召开会议：
项目经理介绍评审会议参加者（可选），说明其角色（可选），陈述评审目标。
指导评审参与人员将精力集中于发现问题，而不是解决方法。
提醒参与人员要针对正在评审的工作产品，而不是作者。
展示工作产品：
讲解员向评审参与人员描述工作产品的各个部分。
提出问题：
每展示完工作产品的一部分，评审参与人员提出关心的问题,潜在的缺陷，疑问或改进建议。
解答问题：
作者简短回答提出的问题，使评审参与人员进一步了解工作产品，从而帮助确认是否真的是冋题。
记录问题：
对确认存在的问题，记录员记录到阶段/工作产品评审会议纪要的问题列表中。
大声读出记录，以确认问题被正确地记录。
1.3.1.3.3评审结果
1、确定产品评审结果：
所有评审会议结束以后，评审小组确定工作产品的
评审结果。
如果意见不一致，由项目经理协调，评审结果应确定为所有评审参与人员给出的评审结果中最保守的一个。
评审结果如下表所示:
含义
完全接受
可能需要做某些修改，但修改不需要审核。
有条件的接受
必须修改缺陷，所做的修改必须由指定的人审核。
需进行二次评审
工作产品的很大部分都需要修改或需要做很多变更。
作者完成修改工作后需要二次评审。
项目停止
由于项目存在重大缺陷或其它的原因，项目停止。
评审未完成
评审内容的重要部分没有评审或评审因某些原因中断。
2、签署评审结果：
所有评审参与者都要在阶段/工作产品评审会议纪要上签
字，说明他们同意评审结果。
1.3.1.3.4消除问题
作者改正问题和小错误，解决提出的问题，并相应地修改工作产品。
在
阶段/工作产品评审会议纪要的问题列表中标注已经处理过的问题。
作者基于工作产品评审发现的问题，修改其他相关文档。
作者向项目经理报告消除的问题数量，以及工作量。
1.3.1.3.5问题跟踪
由项目经理或指定的人员来确认作者已经对应了相应阶段/工作产品评
审会议纪要中的问题。
确定作者是否正确的判断了哪些问题不必改正,那些改进建议不必实现。
项目经理检查修改后的工作产品，对问题的修正工作进行确认，将结果告之作者。
项目经理统计问题数及相关工作量。
项目经理检查是否满足评审的结束基准。
如果满足，则评审结束。
1.3.1.3.6评审结束
项目经理简单总结此次评审活动，将问题记录在相应阶段/工作产品评
审会议纪要的问题列表中，提出建议和解决的方法。
评审活动结束。
基线化的工作产品。
完成的阶段/工作产品评审会议纪要（包括阶段/工作产品评审会议纪要
的冋题列表）。
所有评审目标都已达成。
评审中提出的确定必须消除的问题被跟踪直至关闭。
修改的工作产品已基线化到项目配置管理系统中。
如果修改了以前的工作产品，则已经正确地修改了这些工作产品，保存到了项目配置管理系统中。
项目经理记录了问题数和消除问题的工作量。
1.3.2小组评审
1.3.2.1概述
小组评审是非正式评审的方式，通常采用会议形式，有3-5人参与评审。
在进行实现、测试的阶段评审建议采用小组评审方式。
另外在下列情况下也使用小组评审的方式:
工作产品的初期评审。
非关键工作产品的最终评审。
当非关键工作产品发生大变更时。
项目经理为需要评审的工作产品选择了小组评审的评审方式。
作者在会议之前分发工作产品给评审参与人员。
在会议期间，作者以适当的方式向评审参与人员描述工作产品。
针对评
审参与人员关心的议题组织讨论。
评审参与人员提出可能的问题和改进建议，记录在阶段/工作产品评审
会议纪要及阶段/工作产品评审会议纪要的问题列表中。
作者根据评审参与人员的评论，对工作产品执行必要的修改。
修改的工作产品。
完成的阶段/工作产品评审会议纪要（包括阶段/工作产品评审会议纪要的冋题列表）。
1.325结束基准
作者已经对工作产品做了恰当的修改。
1.3.3个体检查
1.3.3.1概述
个体检查是非正式评审的形式，有2-n人参与评审。
通常由作者将工作产品及相关资料分发给评审参与人员，作者和评审参与人员之间进行讨论交流。
在下列情况下使用个体检查评审方式:
工作产品最初的设计和开发时。
当非关键工作产品发生小变更时。
项目经理选择了个体检查的评审方式。
作者对文档进行了拼写错误检查。
作者对代码进行了基本的检查。
作者将工作产品及相关文档发送或共享给每个评审参与人员。
作者通知评审参与人员工作产品已经准备好，指定评审的结束日期。
评审参与人员将发现的问题记入阶段/工作产品评审会议纪要的问题列
表中，交给作者。
作者在评审结束后，从共享目录中移走工作产品。
作者根据评审参与人员填写的阶段/工作产品评审会议纪要的问题列
表，对工作产品进行必要的修改。
修改后的工作产品。
作者已经对应了阶段/工作产品评审会议纪要的问题列表中的所有问题。
1.3.4评审检查表
评审检查表分为工作产品评审检查表（包含在《工作产品评审会议纪要》中）和阶段评审检查表（包含在《阶段评审会议纪要》中）。
开始时，检查表可以基于行业标准，但是不可以与组织的标准有冲突。
在个体检查中，评审人员在执行评审时，可以根据实际情况，对当前项目所
使用的检查表进行更新，对本项目的检查对象不适用的项目可以删除，而未被计
入的可以作为新项目添加到当前项目所使用的检查表模板中，但在对检查表进行修改时必须得到项目经理的认可。
组织将定期对检查表进行更新，确保其支持组织最新的开发模式，有些从来
没有发现过问题的检查项也可以逐渐从检查表中被删除。
135对代码的评审
仔细的分析代码发现的问题对于减少后期测试的工作量有很大的帮助，便于项目经理掌控整个项目的缺陷信息，我们将代码评审时发现的问题，当作缺陷处理，记录在《缺陷列表》中。
其处理流程参见2.3.2缺陷的记录、分析、解决和
跟踪。
软件测试是一个在可控的环境中执行软件的过程，其目的是为了验证软件是否按照预期运行。
这里所说的测试包括单体测试、结合测试和系统测试。
1、制定了《测试计划》，并在其中说明了测试策略。
1、需要测试的所有测试项均已准备就绪，测试经理会按照《项目开发进度表》中的测试进度来安排测试人员进行测试。
单体测试一般由开发人员进行。
可以记录在《缺陷列表》或Bugzilla中。
2、项目经理对缺陷进行原因分析，缺陷原因等信息详见《缺陷列表》3、确定了缺陷改正的措施，并解决了缺陷。
5、测试结束后，要对前一阶段的测试进行分析，将分析结果记录在《测试分析
报告》中。
1、《缺陷列表》。
2、《测试分析报告》。
1、《缺陷列表》中的缺陷均得到了解决、验证并通过了测试。
四、附录A瀑布模型生命周期中的评审计划
时机
立项阶段
计划阶段
开发阶段
评审
分类
专家评审
方式
目的
评审工作产品
评审后
的产物
评审检
查表
参加评审
人员
审查
小组
/个
体走
查
工作产品评审
阶段
工作
产品
《项目启动协
议书》
《执行计划书》
《项目开发计
划》
《裁减过程记
录》
《项目估计表》
《项目风险列
表》
《项目进度表》
《测试计划》
《项目度量数
据》
《要求列表》
《需求列表》
（需求规格式
样书）
已签字的《项目启动协议
《项目
立项协
议书检
查表》
书》
《计划
评审会
要》（含
签字）
《需求
要》
PMO、项
目经理、项
目支持人员、项目启
动支持人
员、QA
开发计
划评审检查表》
文档评审检查表》
目经理、
QA
领域专家、
客户代表、
项目经理、
设计阶段
《冋题列表》
《需求评审会
议纪要》
《需求阶段评审会议纪要》
《阶段
《概要设计式样书》
《详细设计式
样书》
《设计
《设计文档评审检查表》
架构师、设
计师、项目
经理、
MockuP
《软件设计对
应表》
《画面设计书》
《画面迁移图》《表定义书》《消息定义书》《系统架构设计书》
《米购需求定
义书》
《软件架构设计书》
《帐票设计书》
《文件设计书》
《外部接口说
明书》
实现
同级互查
个体
检查
测试
《设计评审会
代码
《单体测试式
《单体测试报
告》
《缺陷列表》
《项目风险列表》
《测试式样书》
《设计阶段评审会议纪要》
《单体测试式
样书评
审纪
《实现
阶段评
审会议
纪要》
《测试
式样书
评审纪
《代码走查检查表》
审检查
式样书评审检查表》
程序员
测试经理、
项目经理、测试人员
验收
结项
《测试分析报
《
升级会员 