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

软软件件过过程改程改进进之之 确确认认与与验证过验证过程指程指导书导书 V1.6.0 修 订 记 录 编号 章节修订内容简述修订日期版本号 修订人 1全部初稿2004-07-051.0.0买志玉 21增加了同级互查的描述2005-9-191.0.0孙海颖 33增加了个体检查表的更新的描述。 2005-11-71.2.0吴焱 4附录 B 评审计划中考虑并行项目的评审2005-12-91.2.1孙海颖 5附录 B 评审分类除了代码采用同级互查， 其他为专家评审 2006-2-241.3.0熊烈 全部增加除评审以外其他的确认与验 证活动。 三1 中将采用审查进行评审时发现 的缺陷改为问题，记录在相应评 审会议纪要的问题列表中。 1.2 中评审的角色在评审方式下 统一介绍。 2007-10-23 附录 A 附录 B 按照修改后的评审方式，修改评 审计划 2007-10-24 6 三增加 1.3.5 对代码的评审发现的 问题的处理方法。 2007-11-7 1.5.0李卓 目 录 一、概述 .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 召开召开评审评审会会议议 1、召开会议：项目经理介绍评审会议参加者（可选），说明其角色（可选），陈 述评审目标。指导评审参与人员将精力集中于发现问题，而不是解决方 法。提醒参与人员要针对正在评审的工作产品，而不是作者。 2、展示工作产品：讲解员向评审参与人员描述工作产品的各个部分。 3、提出问题：每展示完工作产品的一部分，评审参与人员提出关心的问题， 潜在的缺陷，疑问或改进建议。 4、解答问题：作者简短回答提出的问题，使评审参与人员进一步了解工作 产品，从而帮助确认是否真的是问题。 5、记录问题：对确认存在的问题，记录员记录到阶段/工作产品评审会议纪 要的问题列表中。大声读出记录，以确认问题被正确地记录。 1.3.1.3.3 评审结评审结果果 1、确定产品评审结果：所有评审会议结束以后，评审小组确定工作产品的 评审结果。如果意见不一致，由项目经理协调，评审结果应确定为所有评 审参与人员给出的评审结果中最保守的一个。 评审结果如下表所示： 评审结果含义 完全接受可能需要做某些修改，但修改不需要审核。 有条件的接受必须修改缺陷，所做的修改必须由指定的人审核。 需进行二次评审工作产品的很大部分都需要修改或需要做很多变更。作者 完成修改工作后需要二次评审。 项目停止由于项目存在重大缺陷或其它的原因，项目停止。 评审未完成评审内容的重要部分没有评审或评审因某些原因中断。 2、签署评审结果：所有评审参与者都要在阶段/工作产品评审会议纪要上签 字，说明他们同意评审结果。 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、修改的工作产品。 2、完成的阶段/工作产品评审会议纪要（包括阶段/工作产品评审会议纪要 的问题列表）。 1.3.2.5结结束基准束基准 作者已经对工作产品做了恰当的修改。 1.3.3个体个体检查检查 1.3.3.1概述概述 个体检查是非正式评审的形式，有 2-n 人参与评审。通常由作者将工作产品 及相关资料分发给评审参与人员，作者和评审参与人员之间进行讨论交流。 在下列情况下使用个体检查评审方式： 1、工作产品最初的设计和开发时。 2、非关键工作产品的最终评审。 3、当非关键工作产品发生小变更时。 1.3.3.2开始基准开始基准 1、项目经理选择了个体检查的评审方式。 2、作者对文档进行了拼写错误检查。 3、作者对代码进行了基本的检查。 1.3.3.3实实施施过过程程 1、作者将工作产品及相关文档发送或共享给每个评审参与人员。 2、作者通知评审参与人员工作产品已经准备好，指定评审的结束日期。 3、评审参与人员将发现的问题记入阶段/工作产品评审会议纪要的问题列 表中，交给作者。 4、作者在评审结束后，从共享目录中移走工作产品。 5、作者根据评审参与人员填写的阶段/工作产品评审会议纪要的问题列表， 对工作产品进行必要的修改。 1.3.3.4输输出工作出工作产产品品 1、修改后的工作产品。 2、完成的阶段/工作产品评审会议纪要（包括阶段/工作产品评审会议纪要 的问题列表）。 1.3.3.5结结束基准束基准 作者已经对应了阶段/工作产品评审会议纪要的问题列表中的所有问题。 1.3.4评审检查评审检查表表 评审检查表分为工作产品评审检查表（包含在工作产品评审会议纪要中） 和阶段评审检查表（包含在阶段评审会议纪要中）。开始时，检查表可以基于行 业标准，但是不可以与组织的标准有冲突。 在个体检查中，评审人员在执行评审时，可以根据实际情况，对当前项目所 使用的检查表进行更新，对本项目的检查对象不适用的项目可以删除，而未被计 入的可以作为新项目添加到当前项目所使用的检查表模板中，但在对检查表进 行修改时必须得到项目经理的认可。 组织将定期对检查表进行更新，确保其支持组织最新的开发模式，有些从来 没有发现过问题的检查项也可以逐渐从检查表中被删除。 1.3.5对对代代码码的的评审评审 仔细的分析代码发现的问题对于减少后期测试的工作量有很大的帮助，便于 项目经理掌控整个项目的缺陷信息，我们将代码评审时发现的问题，当作缺陷处 理，记录在缺陷列表中。其处理流程参见 2.3.2 缺陷的记录、分析、解决和跟 踪。 2 测试测试 2.1 概述概述 软件测试是一个在可控的环境中执行软件的过程，其目的是为了验证软件是 否按照预期运行。这里所说的测试包括单体测试、结合测试和系统测试。 2.2 开始基准开始基准 1、制定了测试计划，并在其中说明了测试策略。 2、准备了相关的测试式样书、测试脚本、测试工具和测试所用数据。 3、搭建好了测试环境。 2.3 实实施施过过程程 2.3.1实实施施测试测试 1、需要测试的所有测试项均已准备就绪，测试经理会按照项目开发进度表中 的测试进度来安排测试人员进行测试。单体测试一般由开发人员进行。 2、测试人员将装载所有软件和测试数据文件，并利用测试式样书中的测试用 例、测试脚本和预期测试结果来进行测试。 2.3.2缺陷的缺陷的记录记录、分析、解决和跟踪、分析、解决和跟踪 1、在测试过程中，记录测试结果，对于预期结果和实际结果不符的，需要将预期 结果与实际结果之间的差异一起记录下来。可以记录在缺陷列表或 Bugzilla 中。 2、项目经理对缺陷进行原因分析，缺陷原因等信息详见缺陷列表。 3、确定了缺陷改正的措施，并解决了缺陷。 4、解决了的缺陷得到了验证，并通过了测试。 5、测试结束后，要对前一阶段的测试进行分析，将分析结果记录在测试分析报 告中。 2.4 输输出工作出工作产产品品 1、 缺陷列表。 2、 测试分析报告。 2.5 结结束基准束基准 1、 缺陷列表中的缺陷均得到了解决、验证并通过了测试。 2、项目经理记录了缺陷数和解决缺陷的工作量。 、 附附录录 A 瀑布模型生命周期中的瀑布模型生命周期中的评审计评审计划划 时时机机评审评审 分分类类 评审评审 方式方式 评审评审 目的目的 评审评审工作工作产产品品评审评审后后 的的产产物物 评审检评审检 查查表表 参加参加评审评审 人人员员 立项 阶段 专家 评审 审查 工作 产品 评审 项目启动协议 书 已签字 的项 目启动 协议书 项目 立项协 议书检 查表 PMO、项目 经理、项目 支持人员、 项目启动 支持人员、 QA 计划 阶段 专家 评审 审查阶段 评审 执行计划书 项目开发计划 裁减过程记录 项目估计表 项目风险列表 项目进度表 测试计划 项目度量数据 计划 评审会 议纪要 （含签 字） 项目 开发计 划评审 检查表 PMO、项目 经理、QA 专家 评审 小组 评审 /个 体走 查 工作 产品 评审 要求列表 需求列表（需 求规格式样书） 需求 评审会 议纪要 需求 文档评 审检查 表 领域专家、 客户代表、 项目经理、 QA 需求 开发 阶段 专家 评审 审查阶段 评审 项目风险列表 问题列表 项目度量数据 项目进度表 需求评审会议 纪要 需求 阶段评 审会议 纪要 阶段 评审检 查表 PMO、项目 经理、QA 专家 评审 小组 评审 /个 体走 查 工作 产品 评审 概要设计式样 书 详细设计式样 书 Mockup 软件设计对应 表 画面设计书 画面迁移图 表定义书 消息定义书 系统架构设计 书 采购需求定义 书 软件架构设计 书 帐票设计书 文件设计书 外部接口说明 书 设计 评审会 议纪要 设计 文档评 审检查 表 架构师、设 计师、项目 经理、 设计 阶段 专家 评审 审查阶段 评审 项目风险列表 问题列表 项目度量数据 项目进度表 设计评审会议 纪要 设计 阶段评 审会议 纪要 阶段 评审检 查表 PMO、项目 经理、QA 同级 互查 个体 检查 工作 产品 评审 代码代码 走查检 查表 程序员实现 专家 评审 个体 检查 工作 产品 评审 单体测试式样 书 单体 测试式 样书评 审纪要 单体 测试式 样书评 审检查 表 程序员 专家 评审 小组 评审 阶段 评审 单体测试报告 缺陷列表 项目风险列表 问题列表 项目度量数据 项目进度