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

软件过程改进之 确认与验证过程指导书 V1.6.0 修 订 记 录 编号 章节 修订内容简述 修订日期 版本号 修订人 1 全部 初稿 2004-07-05 1.0.0 买志玉 2 1 增加了同级互查的描述 2005-9-19 1.0.0 孙海颖 3 3 增加了个体检查表的更新的描述。 2005-11-7 1.2.0 吴焱 4 附录B 评审计划中考虑并行项目的评审 2005-12-9 1.2.1 孙海颖 5 附录B 评审分类除了代码采用同级互查，其他为专家评审 2006-2-24 1.3.0 熊烈 6 全部 增加除评审以外其他的确认与验证活动。 2007-10-23 1.5.0 李卓 三 1中将采用审查进行评审时发现的缺陷改为问题，记录在相应评审会议纪要的问题列表中。 1.2中评审的角色在评审方式下统一介绍。 附录A 附录B 按照修改后的评审方式，修改《评审计划》 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 概述 软件确认与验证是贯穿于软件开发过程中十分细致的软件检验活动确认是从用户的角度，当前的开发成果符合用户的真正需求，即“做了正确的事”。验证是在软件开发的各个阶段，从软件技术人员的角度，测试当前的开发成果（文档，代码等）符合设计的规范，保证按照设计流程和要求进行开发，即“正确地做了事”。从根本上说，需求来源于用户的“需要”和“要求”，这些“需要”和“要求”被分析、整理、确认后形成完整的文档，该文档详细地说明了产品“应当”实现的功能。需求确认是指对需求的必要性和可行性进行分析，确定需求文档。。“需要”和“要求”是软件的功能和性能及其它特性是否与用户的要求一致。对软件的品质从功能、性能、可靠性、易用性等方面作全面的质量检测，帮助找出产品存在的问题需要测试的所有测试项均已准备就绪测试人员将装载所有软件和测试数据文件，并利用中的测试用例、测试脚本和预期测试结果来进行测试。预期结果与实际结果之间的差异一起记录下来。下过程中涉及的角色及责任。所有参与者除了自身担任的特定角色外，也都是。一次评审需要至少三个参与者，包括作者。作者一般不作或记录。被评审的工作产品的或维护者项目经理发起评审过程。陈述评审目标提交工作产品及文档给项目经理。与项目经理一起，并分配角色。对应。向项目经理报告数和时间。 ·计划，安排，组织评审活动。与作者一起，并分配角色。提前评审会议至少三天，将评审发送给。确定会议准备是否充分。如果不充分，重新安排会议时间。评审会议进行。纠正任何不适当的行为。随着展现工作产品的各部分，引导提出问题。领导评审小