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

VV-确认和验证过程指导书VV-确认和验证过程指导书VV-确认和验证过程指导书VV-确认和验证过程指导书编制仅供参考审核批准生效日期地址：电话：传真:邮编:SUBJECT软件过程改进之 确认与验证过程指导书修订记录编号章节修订内容简述修订日期版本号修订人1全部初稿2004-0买志玉21增加了同级互查的描述2005-9-19孙海颖33增加了个体检查表的更新的描述。2005-11-7吴焱4附录B评审计划中考虑并行项目的评审2005-12-9孙海颖5附录B评审分类除了代码采用同级互查，其他为专家评审2006-熊烈6全部增加除评审以外其他的确认与验证活动。2007-10-23李卓三1中将采用审查进行评审时发现的缺陷改为问题，记录在相应评审会议纪要的问题列表中。中评审的角色在评审方式下统一介绍。附录A附录B按照修改后的评审方式，修改《评审计划》2007-10-24三增加对代码的评审发现的问题的处理方法。2007-11-7

目录TOC\o"1-6"\h\z\u一、 概述 6二、 确认 61 需求确认 6 概述 6 开始基准 6 实施过程 6 输出工作产品 7 结束基准 72 验收测试和Beta测试 7 概述 7 开始基准 8 实施过程 8 实施测试 8 缺陷的记录、分析、解决和跟踪 8 输出工作产品 8 结束基准 9三、 验证 91 评审 9 评审分类 9 专家评审 9 同级互查 9 角色 10 评审方式 11 审查 11 概述 11 开始基准 11 实施过程 12.1 评审准备 12.2 召开评审会议 12.3 评审结果 13.4 消除问题 13.5 问题跟踪 14.6 评审结束 14 输出工作产品 14 结束基准 14 小组评审 15 概述 15 开始基准 15 实施过程 15 输出工作产品 15 结束基准 16 个体检查 16 概述 16 开始基准 16 实施过程 16 输出工作产品 17 结束基准 17 评审检查表 17 对代码的评审 172 测试 17 概述 17 开始基准 18 实施过程 18 实施测试 18 缺陷的记录、分析、解决和跟踪 18 输出工作产品 18 结束基准 19四、 附录A瀑布模型生命周期中的评审计划 19五、 附录B其它生命周期中的评审计划 22

概述软件“确认”与“验证”是贯穿于软件开发过程中十分细致的软件检验活动。“确认”是从用户的角度，检验当前的开发成果符合用户的真正需求，即“做了正确的事”。“验证”是在软件开发的各个阶段，从软件技术人员的角度，测试当前的开发成果（文档，代码等）符合设计的规范，保证按照设计流程和要求进行开发，即“正确地做了事”。确认需求确认概述从根本上说，需求来源于用户的“需要”和“要求”，这些“需要”和“要求”被分析、整理、确认后形成完整的文档，该文档详细地说明了产品“应当”实现的功能。需求确认是指项目经理和客户经过充分的沟通和交流，对项目的开发要求达成共识并做出承诺。开始基准1、对需求的必要性和可行性进行分析，确定需求文档。2、已识别了被确认的工作的产品和产品组件。实施过程1、将客户的“需要”和“要求”记录在《要求记录表》中，内容主要包括：功能性要求、非功能性要求、关于组件的重用和开发的要求以及业务流程图。客户需要在《要求记录表》上签字。2、项目经理与客户代表双方经过充分的沟通和交流，对项目的开发需求已经达成共识，将已确认的需求记录在《要求记录表》中，作为进行项目开发的依据。客户需要在《需求记录表》上签字。3、如果要对《要求记录表》或《需求记录表》中的内容进行变更，必须由双方协商确认。4、在项目过程中，客户无法签字的情况，可采用Q&A的方式确认。当对业务的理解有疑问，需要就需求文档，设计文档等工作产品与客户进行确认时，可使用《Q&A》和客户进行沟通，在《Q&A》中项目经理向客户提供主要的确认点(可从技术评审检查表中提出主要的检查项)，请客户确认；对技术有疑问而内部不能达成一致的或得到解决时，通过《Q&A》和客户沟通，在《Q&A》中记录疑问，请客户回答。输出工作产品1、《要求记录表》。2、《需求记录表》。3、《Q&A》或客户返回的确认邮件。结束基准1、客户在《要求记录表》和《需求记录表》上签字。2、客户针对《Q&A》确认点或疑问，进行了确认或回答。3、项目经理记录了《Q&A》的问题数和确认工作的工作量。验收测试和Beta测试概述验收测试和Beta测试是检验软件的功能和性能及其它特性是否与用户的要求一致。对软件的品质从功能、性能、可靠性、易用性等方面作全面的质量检测，帮助项目组找出产品存在的问题。验收测试主要针对项目来实施，Beta测试主要针对产品实施，可以把Beta测试看作是对产品的验收测试。开始基准1、制定了《验收测试计划》和《Beta测试计划》。2、准备了相关的《测试式样书》、测试脚本、测试工具和测试所用数据。3、搭建好了测试环境。实施过程实施测试1、需要测试的所有测试项均已准备就绪，测试经理会按照《项目开发进度表》中的测试进度来安排测试人员进行测试。2、测试人员将装载所有软件和测试数据文件，并利用《测试式样书》中的测试用例、测试脚本和预期测试结果来进行测试。缺陷的记录、分析、解决和跟踪1、在测试过程中，记录测试结果，对于预期结果和实际结果不符的，需要将预期结果与实际结果之间的差异一起记录下来。可以记录在《缺陷列表》或Bugzilla或客户的不具合一览表中。所有的缺陷都要进行记录。2、项目经理对缺陷进行分析，确定是客户原因的缺陷还是己方原因的缺陷，对于己方原因的缺陷，需要分析缺陷产生的原因。缺陷原因分类：设计错误，代码错误，功能遗漏，式样理解错误，共通错误，其他等。3、确定了缺陷改正的措施，并解决了缺陷。4、解决了的缺陷得到了验证，并通过了测试。输出工作产品1、《缺陷列表》或客户的不具合一览表。结束基准1、《缺陷列表》或客户的不具合一览表中己方原因的缺陷均得到了解决、验证并通过了测试。2、项目经理记录了缺陷数和解决缺陷的工作量。验证评审评审分为：专家评审、同级互查两种类型，每种类型都可以采用三种评审方式（审查，小组评审，个体检查）之一进行评审，评审目的有两个：工作产品评审和阶段评审。一般来讲，阶段评审在每个阶段结束前进行，工作产品评审一般安排在阶段评审之前或同时进行。在制定计划的时候，项目经理识别出哪些工作产品将要进行同级互查，哪些工作产品将要进行专家评审，计划采用哪种评审方式，评审的目的是什么等。并将评审的进度安排在项目进度表中并明确评审者。评审分类专家评审专家的定义：与另一个人或其他人在等级、阶级上不一定具有同等地位，但在某些领域具有足够的经验和技能，能够在此领域对某些问题提出有见地的意见和建议。专家评审的目的：在项目组成员内或外对工作产品进行专家级的检查，尽可能在生命周期的早期发现并除去问题。同级互查同级的定义：与其他人处于相同等级、阶级地位的人。同级互查的概念：由作者的同级按照预定的规程对软件工作产品进行的评审，不得由作者本人对自己的工作产品进行评审。同级互查的目的：在项目组成员内对工作产品进行相互检查，尽可能在生命周期的早期发现并除去问题。角色下表列出了在评审过程中所有可能涉及的角色及其责任。每个参与者可以担任多个角色。所有参与者除了自身担任的特定角色外，也都是评审参与人员。一次评审需要至少三个参与者，包括作者。作者一般不作讲解员或记录员。角色责任作者·被评审的工作产品的创建者或维护者，与项目经理一起发起评审过程。·陈述评审目标·提交工作产品及相关文档给项目经理。·与项目经理一起选择评审参与人员，并分配角色。·对应阶段/工作产品评审会议纪要的问题列表中的问题。·向项目经理报告问题数和消除问题所用的时间。项目经理·计划，安排，组织评审活动。·与作者一起选择评审参与人员，并分配角色。·提前评审会议至少三天，将待评审的工作产品及相关文档发送给评审参与人员。·确定会议准备是否充分。如果不充分，重新安排会议时间。·保证评审会议进行。纠正任何不适当的行为。随着讲解员展现工作产品的各部分，引导评审参与人员提出问题。·领导评审小组确定工作产品的评审结果。记录员·记录并分类评审会议中提出的问题。讲解员·讲解工作产品，帮助评审参与人员理解工作产品，发现问题。评审参与人员·在评审会议之前浏览工作产品，发现缺陷，为参加评审会议做准备。·参加评审，识别问题，给出改进建议。评审方式下面主要描述了三种评审方式的实施过程。审查概述审查是正式评审方式，一般有3-5人参与评审，以评审会议或email的形式进行。以email方式进行审查时，评审参与人员需使用检查表，对待评审的工作产品及相关资料进行审阅，将发现的问题记录在阶段/工作产品评审会议纪要的问题列表中，以email方式告知项目经理。如果没有问题，也需回复email说明。在进行立项、计划、需求、设计的阶段评审时间建议采用审查方式。另外，评审下列工作产品时一般也采用审查方式。关键的工作产品。复杂或关键的代码。问题较多的工作产品。关键工作产品的最终评审。开始基准项目经理为待评审的工作产品选择了审查的评审方式。作者准备好待评审的工作产品及相关文档。作者陈述了评审目标。配置经理为待评审的文档分配了版本号。所有页面都标明了页码。文档经过了拼写错误检查。配置经理为待评审的源代码分配了版本号。代码清单标明了行号和页码。代码通过了基本检查。对于二次评审，前一次评审中发现的所有问题都已经解决。实施过程评审准备作者将待评审的工作产品和相关资料提交给项目经理。项目经理确定工作产品是否满足评审入口准则。项目经理根据工作产品的规模和复杂度确定需要多少次评审会议（评审工作产品的工作量最长不超过2-3小时，若工作量过大，要分成多次评审会议）。项目经理和作者共同选择评审参与人员，为其分配角色。在评审会议前，项目经理至少提前三个工作日向评审参与人员发布评审会议通知，待评审的工作产品、相关资料和检查表。作者向评审参与人员陈述评审目标，描述工作产品的重要特征。（可召开评审说明会议，或通过邮件说明）。项目经理要求评审参与人员以特定的角度准备评审。例如，检查交叉引用的一致性，检查接口错误，检查对以往的规范的可追溯性和一致性，检查对标准的符合性。评审参与人员预评审工作产品，将发现的问题在阶段/工作产品评审会议纪要的问题列表中，在评审会议之前交给项目经理，由项目经理转交给作者。项目经理确认准备情况：了解每个评审参与人员的准备时间，如果准备不充分，重新安排会议时间。召开评审会议召开会议：项目经理介绍评审会议参加者（可选），说明其角色（可选），陈述评审目标。指导评审参与人员将精力集中于发现问题，而不是解决方法。提醒参与人员要针对正在评审的工作产品，而不是作者。展示工作产品：讲解员向评审参与人员描述工作产品的各个部分。提出问题：每展示完工作产品的一部分，评审参与人员提出关心的问题，潜在的缺陷，疑问或改进建议。解答问题：作者简短回答提出的问题，使评审参与人员进一步了解工作产品，从而帮助确认是否真的是问题。记录问题：对确认存在的问题，记录员记录到阶段/工作产品评审会议纪要的问题列表中。大声读出记录，以确认问题被正确地记录。评审结果确定产品评审结果：所有评审会议结束以后，评审小组确定工作产品的评审结果。如果意见不一致，由项目经理协调，评审结果应确定为所有评审参与人员给出的评审结果中最保守的一个。评审结果如下表所示：评审结果含义完全接受可能需要做某些修改，但修改不需要审核。有条件的接受必须修改缺陷，所做的修改必须由指定的人审核。需进行二次评审工作产品的很大部分都需要修改或需要做很多变更。作者完成修改工作后需要二次评审。项目停止由于项目存在重大缺陷或其它的原因，项目停止。评审未完成评审内容的重要部分没有评审或评审因某些原因中断。签署评审结果：所有评审参与者都要在阶段/工作产品评审会议纪要上签字，说明他们同意评审结果。消除问题作者改正问题和小错误，解决提出的问题，并相应地修改工作产品。在阶段/工作产品评审会议纪要的问题列表中标注已经处理过的问题。作者基于工作产品评审发现的问题，修改其他相关文档。作者向项目经理报告消除的问题数量，以及工作量。问题跟踪由项目经理或指定的人员来确认作者已经对应了相应阶段/工作产品评审会议纪要中的问题。确定作者是否正确的判断了哪些问题不必改正，那些改进建议不必实现。项目经理检查修改后的工作产品，对问题的修正工作进行确认，将结果告之作者。项目经理统计问题数及相关工作量。项目经理检查是否满足评审的结束基准。如果满足，则评审结束。配置经理将工作产品基线化到项目配置管理系统中。评审结束项目经理简单总结此次评审活动，将问题记录在相应阶段/工作产品评审会议纪要的问题列表中，提出建议和解决的方法。评审活动结束。输出工作产品基线化的工作产品。完成的阶段/工作产品评审会议纪要（包括阶段/工作产品评审会议纪要的问题列表）。结束基准所有评审目标都已达成。评审中提出的确定必须消除的问题被跟踪直至关闭。修改的工作产品已基线化到项目配置管理系统中。如果修改了以前的工作产品，则已经正确地修改了这些工作产品，保存到了项目配置管理系统中。项目经理记录了问题数和消除问题的工作量。小组评审概述小组评审是非正式评审的方式，通常采用会议形式，有3-5人参与评审。在进行实现、测试的阶段评审建议采用小组评审方式。另外在下列情况下也使用小组评审的方式：工作产品的初期评审。非关键工作产品的最终评审。当非关键工作产品发生大变更时。开始基准项目经理为需要评审的工作产品选择了小组评审的评审方式。作者陈述了评审目标。实施过程作者在会议之前分发工作产品给评审参与人员。在会议期间，作者以适当的方式向评审参与人员描述工作产品。针对评审参与人员关心的议题组织讨论。评审参与人员提出可能的问题和改进建议，记录在阶段/工作产品评审会议纪要及阶段/工作产品评审会议纪要的问题列表中。作者根据评审参与人员的评论，对工作产品执行必要的修改。输出工作产品修改的工作产品。完成的阶段/工作产品评审会议纪要（包括阶段/工作产品评审会议纪要的问题列表）。结束基准作者已经对工作产品做了恰当的修改。个体检查概述个体检查是非正式评审的形式，有2-n人参与评审。通常由作者将工作产品及相关资料分发给评审参与人员，作者和评审参与人员之间进行讨论交流。在下列情况下使用个体检查评审方式：工作产品最初的设计和开发时。非关键工作产品的最终评审。当非关键工作产品发生小变更时。开始基准项目经理选择了个体检查的评审方式。作者对文档进行了拼写错误检查。作者对代码进行了基本的检查。实施过程作者将工作产品及相关文档发送或共享给每个评审参与人员。作者通知评审参与人员工作产品已经准备好，指定评审的结束日期。评审参与人员将发现的问题记入阶段/工作产品评审会议纪要的问题列表中，交给作者。作者在评审结束后，从共享目录中移走工作产品。作者根据评审参与人员填写的阶段/工作产品评审会议纪要的问题列表，对工作产品进行必要的修改。输出工作产品修改后的工作产品。完成的阶段/工作产品评审会议纪要（包括阶段/工作产品评审会议纪要的问题列表）。结束基准作者已经对应了阶段/工作产品评审会议纪要的问题列表中的所有问题。评审检查表评审检查表分为工作产品评审检查表（包含在《工作产品评审会议纪要》中）和阶段评审检查表（包含在《阶段评审会议纪要》中）。开始时，检查表可以基于行业标准，但是不可以与组织的标准有冲突。在个体检查中，评审人员在执行评审时，可以根据实际情况，对当前项目所使用的检查表进行更新，对本项目的检查对象不适用的项目可以删除，而未被计入的可以作为新项目添加到当前项目所使用的检查表模板中，但在对检查表进行修改时必须得到项目经理的认可。组织将定期对检查表进行更新，确保其支持组织最新的开发模式，有些从来没有发现过问题的检查项也可以逐渐从检查表中被删除。对代码的评审仔细的分析代码发现的问题对于减少后期测试的工作量有很大的帮助，便于项目经理掌控整个项目的缺陷信息，我们将代码评审时发现的问题，当作缺陷处理，记录在《缺陷列表》中。其处理流程参见缺陷的记录、分析、解决和跟踪。测试概述软件测试是一个在可控的环境中执行软件的过程，其目的是为了验证软件是否按照预期运行。这里所说的测试包括单体测试、结合测试和系统测试。开始基准1、制定了《测试计划》，并在其中说明了测试策略。2、准备了相关的《测试式样书》、测试脚本、测试工具和测试所用数据。3、搭建好了测试环境。实施过程实施测试1、需要测试的所有测试项均已准备就绪，测试经理会按照《项目开发进度表》中的测试进度来安排测试人员进行测试。单体测试一般由开发人员进行。2、测试人员将装载所有软件和测试数据文件，并利用《测试式样书》中的测试用例、测试脚本和预期测试结果来进行测试。缺陷的记录、分析、解决和跟踪1、在测试过程中，记录测试结果，对于预期结果和实际结果不符的，需要将预期结果与实际结果之间的差异一起记录下来。可以记录在《缺陷列表》或Bugzilla中。2、项目经理对缺陷进行原因分析，缺陷原因等信息详见《缺陷列表》。3、确定了缺陷改正的措施，并解决了缺陷。4、解决了的缺陷得到了验证，并通过了测试。5、测试结束后，要对前一阶段的测试进行分析，将分析结果记录在《测试分析报告》中。输出工作产品1、《缺陷列表》。2、《测试分析报告》。结束基准1、《缺陷列表》中的缺陷均得到了解决、验证并通过了测试。2、项目经理记录了缺陷数和解决缺陷的工作量。附录A瀑布模型生命周期中的评审计划时机评审分类评审方式评审目的评审工作产品评审后的产物评审检查表参加评审人员立项阶段专家评审审查工作产品评审《项目启动协议书》已签字的《项目启动协议书》《项目立项协议书检查表》PMO、项目经理、项目支持人员、项目启动支持人员、QA计划阶段专家评审审查阶段评审《执行计划书》《项目开发计划》《裁减过程记录》《项目估计表》《项目风险列表》《项目进度表》《测试计划》《项目度量数据》《计划评审会议纪要》（含签字）《项目开发计划评审检查表》PMO、项目经理、QA需求开发阶段专家评审小组评审/个体走查工作产品评审《要求列表》《需求列表》（需求规格式样书）《需求评审会议纪要》《需求文档评审检查表》领域专家、客户代表、项目经理、QA专家评审审查阶段评审《项目风险列表》《问题列表》《项目度量数据》《项目进度表》《需求评审会议纪要》《需求阶段评审会议纪要》《阶段评审检查表》PMO、项目经理、QA设计阶段专家评审小组评审/个体走查工作产品评审《概要设计式样书》《详细设计式样书》Mockup《软件设计对应表》《画面设计书》《画面迁移图》《表定义书》《消息定义书》《系统架构设计书》《采购需求定义书》《软件