软件开发过程验证和确认过程.docx
《软件开发过程验证和确认过程.docx》由会员分享，可在线阅读，更多相关《软件开发过程验证和确认过程.docx（18页珍藏版）》请在冰豆网上搜索。
软件开发过程验证和确认过程
验证和确认过程
Verification&ValidationProcess
文件状态：
[]草稿
[√]正式发布
[]正在修改
文件编号：
QUANTA-SEP-Process-13
当前版本：
1.0
版本历史
版本/状态
作者
参与者
日期
摘要
1．0
余成军
2008-9-26
创建
版权信息
本文件内容由海口量子网络科技有限公司开发部负责解释
本文件的版权属于海口量子网络科技有限公司
任何形式的散发都必须先得到海口量子网络科技有限公司的许可
【目录】
1概述4
1.1编写目的4
1.2适用范围4
1.3术语和缩写4
1.4参考资料4
2输入4
3输出5
4角色和职责5
5验证和确认概述6
6过程定义6
6.1入口条件6
6.2出口条件6
6.3过程流程图6
6.4过程活动描述6
6.4.1建立验证和确认计划6
6.4.2建立验证和确认环境7
6.4.3建立详细的验证和确认计划8
6.4.4执行同行评审8
6.4.5进行验证和确认8
6.4.6分析验证和确认的结果9
7验证和确认的工作产品10
8过程度量15
9过程剪裁准则15
1概述
1.1编写目的
定义和建立公司对项目验证和确认的规范和责任。
定义及规范软件产品的验证和确认过程，以保证工作产品在软件开发的整个生命周期中能满足其规定的要求，同时证明，产品或产品构件当被置于其预定环境中时，适合于其预定用途。
通过该规范来提高公司的验证和确认的能力。
1.2适用范围
本过程适用于公司内所有软件开发项目的验证和确认活动。
1.3术语和缩写
术语和缩写
解释
备注
VER
Verification
“验证”的目的在于保证工作产品满足其规定的要求。
VAL
Validation
“确认”的目的在于证明，产品或产品构件当被置于其预定环境中时，适合于其预定用途。
1.4参考资料
参考文件
备注
《CMMIV1.1》
2输入
输入制品
备注
待确认和验证工作产品
3输出
（具体输出制品请参阅7.验证和确认的工作产品的验证和确认记录）
4角色和职责
角色
职责
产品作者
●确保工作产品的完成，以便提交评审；
●与验证确认组长一起商量确定验证确认队伍；
●提供验证确认工作产品的副本；
●验证确认完成后，快速解决所有确定的缺陷；
●保持客观态度，避免抗拒思想。
验证确认组长
（可能是同行评审组长或测试负责人，不允许项目经理兼任）
●对确保验证确认正确的方式下进行以及遵循所有验证确认过程步骤负有全部责任；
●帮助作者选择验证确认者并安排他们的参与；
●安排验证确认活动；
●确保满足验证确认的进入条件；
●确保按时开始和结束验证确认；
●确保验证确认者一直关注的是识别缺陷这个主要任务；
●确保记录发现的所有缺陷，并与项目经理共同安排解决缺陷的责任人；
●负责完成验证确认的总结报告；
●负责验证缺陷被纠正；
●负责提供相关验证和确认的数据度量并提交。
验证确认者
（可能是同行评审者、测试人员、客户、最终用户等）
●客观地进行验证确认，对事不对人；
●关注问题，并在验证确认后给出针对阐述方式或解决方案的建议；
●如果有不清楚的地方，要提问清楚，直到理解为止；
项目经理
●负责建立验证和确认计划
●建立验证和确认环境
●制订详细的验证和确认计划
●协调验证和确认过程中出现的问题
5验证和确认概述
验证的目的是为了确保产品符合其指定的需求，包括指定用户需求、产品需求、工作产品组件的需求。
从需求开始验证直到最终产品完成的验证，该过程贯穿于整个软件生产过程中，是渐进式的过程；确认的目的是为了确保产品和产品组件在预期的使用环境中能够满足产品的使用需求。
确认和验证经常同时执行，确认一般会包括使用者。
“验证”过程方面与“确认”过程方面看起来类似，但是它们处理的问题不同。
“确认”是要证明所提供的（或将要提供的）产品适合其预计的用途，而“验证”则是要查明工作产品是否恰当地反映了规定的要求。
换句话说，验证要保证“做得正确”，而确认则要保证“做的东西正确”。
验证和确认过程贯穿在整个软件生命周期中，相关的过程域，都有验证和确认的要求（详细参见各过程域）。
6过程定义
6.1入口条件
需要验证和确认的工作产品完成。
6.2出口条件
验证和确认发现的缺陷已经验证确认通过并关闭
6.3过程流程图
参见《验证和确认流程》
6.4过程活动描述
6.4.1建立验证和确认计划
活动名称
建立验证和确认计划
角色和职责
产品作者
验证确认组长
项目经理
活动接口
进入条件
（或活动启动的事件）
项目启动
活动的输入
早期项目计划文档
活动的输出
《项目开发综合计划》的验证和确认计划
退出条件
（或触发其他活动的事件）
《项目开发综合计划》的验证和确认计划已经建立
任务
1.针对整个开发生存周期中产品或产品构件的验证和确认，确定关键的原则、特征和阶段。
2.提出切实可行的验证和确认环境的需求，产品必须是在其预定的运行环境中可维护的和可支持的。
3.规定对验证和确认的评价准则，确定预期的结果和容差，拟订用于判定是否满足需求的其他准则。
4.与相关的共利益者一起评审验证和确认计划，包括具体将进行同行评审和测试的工作产品。
使用工具
无
相关过程
项目管理过程
备注
6.4.2建立验证和确认环境
活动名称
建立验证和确认环境
角色和职责
产品作者
验证确认组长
项目经理
活动接口
进入条件
（或活动启动的事件）
验证和确认战略已经建立
活动的输入
《项目开发综合计划》
活动的输出
验证和确认环境
退出条件
（或触发其他活动的事件）
验证和确认环境已经建立
任务
1.确定验证和确认环境需求。
2.确定可供复用和修改的验证和确认资源。
3.确定验证和确认的设备和工具。
4.确定是否采购验证和确认的支持设备和环境，例如测试设备和测试软件。
使用工具
无
相关过程
供应商合同管理
备注
6.4.3建立详细的验证和确认计划
活动名称
制订详细的验证和确认计划
角色和职责
产品作者
验证确认组长
项目经理
活动接口
进入条件
（或活动启动的事件）
验证和确认环境已经建立
活动的输入
已经建立的验证和确认环境
活动的输出
工作产品的验证和确认计划
退出条件
（或触发其他活动的事件）
工作产品的验证和确认计划已经建立
任务
1.针对所选的工作产品制订并维护详细的验证和确认计划，可以是测试计划或同行评审计划。
2.审查产品需求，以确保识别和解决那些对产品验证和确认有影响的问题。
3.针对验证和确认战略把环境、运行场景、规程、输入、输出和预期结果形成文件。
4.随着设计在验证和确认环境的背景中趋于成熟，对设计进行同行评审和评估，以识别验证和确认问题。
使用工具
无
相关过程
需求开发和管理过程
系统设计过程
系统实现过程
系统测试过程
同行评审过程
缺陷管理过程
产品发布过程
备注
6.4.4执行同行评审
调用《同行评审过程》
6.4.5进行验证和确认
活动名称
进行验证和确认
角色和职责
产品作者
验证和确认组长
活动接口
进入条件
（或活动启动的事件）
验证和确认准备工作完成
活动的输入
工作产品的验证和确认计划
活动的输出
工作产品的验证和确认缺陷记录
退出条件
（或触发其他活动的事件）
工作产品的验证和确认缺陷进入公司缺陷库
任务
1.对外购产品和复用构件进行验证和确认，看其是否符合要求。
2.根据验证和确认战略和规程，对照需求，对产品和产品构件在其预定的运行环境中进行验证和确认。
3.汇集验证和确认活动的结果，根据工作产品验证和确认结果确定要采取的措施。
4.应该把运行式验证和确认规程形成文件并且在适当时，把验证和确认中发现的缺陷放入公司缺陷库，并通知相关的共利益者。
使用工具
无
相关过程
需求开发和管理过程
系统设计过程
系统实现过程
系统测试过程
同行评审过程
缺陷管理过程
产品发布过程
备注
6.4.6分析验证和确认的结果
活动名称
分析验证和确认的结果
角色和职责
产品作者
验证和确认组长
活动接口
进入条件
（或活动启动的事件）
验证和确认的缺陷已进公司缺陷库
活动的输入
工作产品的验证和确认缺陷
活动的输出
工作产品的验证和确认报告
退出条件
（或触发其他活动的事件）
工作产品的验证和确认报告已经完成
任务
1.把实际结果与预期结果相比较，确认缺陷和问题。
2.根据所建立的验证和确认准则，确定产品或产品构件是否满足其需求和适合于在其预定的运行环境中使用，确定验证和确认方法、准则或环境中是否存在问题。
3.分析有关缺陷的验证和确认数据，汇集分析结果和识别问题。
4.运用验证和确认结果比较实际的度量值、性能与技术性能参数和预期的使用或运行性能。
5.按缺陷管理过程对缺陷进行跟踪解决，并对修改好的缺陷进行再次验证和确认，只要准备进行测试的软件发生了变更或者软件环境发生了变更，就要进行回归测试。
使用工具
无
相关过程
需求开发和管理过程
系统设计过程
系统实现过程
系统测试过程
同行评审过程
缺陷管理过程
产品发布过程
备注
7验证和确认的工作产品
一般地，需要进行验证和确认的包括以下产品，项目经理可以根据实际情况做裁剪。
QA代表验证各验证和确认过程是否按过程定义执行。
具体内容请参见相关的过程域：
过程域
工作产品
过程描述
参考标准
输出制品
需求和管理过程
《需求调研报告》
借助系统原型或界面原型和用户更直观的沟通
和调研对象负责人确认
调研搜集的各种样表、资料
《工作任务书》
系统原型
经过调研对象负责人确认的《需求调研报告》
调研记录
《用户需求说明书》
同行评审
用户对《用户需求说明书》做出承诺，承诺的方式以签字确认为准。
《需求调研报告》
同行评审报告
用户签字的《用户需求说明书》
《需求规格说明书》
同行评审
用户对《需求规格说明书》进行确认。
《用户需求说明书》
同行评审报告
用户确认记录（确认的形式可以以签字，会议纪要，或反馈表形式体现。
）
《需求管理矩阵》
《需求管理矩阵》负责人定期填写有关跟踪数据，确保每项需求的落实实施
需求变更经SCCB评审通过，并且评审结论得以实施并验证通过。
《工作任务书》
《用户需求说明书》
《需求规格说明书》
《需求变更单》
《体系结构设计说明书》
《数据库设计说明书》
《用户界面设计说明书》
《模块设计说明书》
代码和测试文档等
依据《需求管理矩阵》分析对工作产品的影响，将变更的情况反映到《需求管理矩阵》。
依据《需求管理矩阵》对《体系结构设计说明书》、《数据库设计说明书》、《用户界面设计说明书》、《模块设计说明书》、代码和测试文档等进行相应修改，以反映需求变更。
系统设计过程
《体系结构设计说明书》
同行评审
评审要重点关注体系结构设计是否能够满足需求。
必要时可邀请用户一起参加评审。
《用户需求说明书》和《需求规格说明书》
同行评审报告
缺陷跟踪记录（TestDirector）
《数据库设计说明书》
同行评审
评审要重点关注上述设计是否能够满足需求。
必要时可邀请用户一起参加评审。
《用户需求说明书》和《需求规格说明书》
《体系结构设计说明书》
同行评审报告
缺陷跟踪记录（TestDirector）
《用户界面设计说明书》
同行评审
评审要重点关注上述设计是否能够满足需求。
必要时可邀请用户一起参加评审。
美工在设计界面过程中，尽可能多的跟用户（特别是最终用户）沟通，一些中间成果及时展示给用户，征求用户的意见，最终的设计成果应获得用户的确认。
《用户需求说明书》和《需求规格说明书》
《体系结构设计说明书》
同行评审报告
用户确认记录
缺陷跟踪记录（TestDirector）
《模块设计说明书》
同行评审
评审要重点关注上述设计是否能够满足需求。
必要时可邀请用户一起参加评审。
《用户需求说明书》和《需求规格说明书》
《体系结构设计说明书》
同行评审报告
缺陷跟踪记录（TestDirector）
系统实现过程
源代码
单元测试
集成测试
同行评审
评审要重点关注代码的规范性和逻辑性，代码是否能实现算法，代码和测试是否能够满足需求。
必要时可邀请用户一起参加评审。
源代码
项目的编码规范
基线的设计文档
基线的需求文档
单元测试用例
集成测试用例
单元测试报告
集成测试报告
同行评审报告
缺陷跟踪记录（TestDirector）
单元测试用例
同行评审
评审要重点关注代码的规范性和逻辑性，代码是否能实现算法，代码和测试是否能够满足需求。
必要时可邀请用户一起参加评审。
《用户需求说明书》和《需求规格说明书》
《模块设计说明书》
同行评审报告
抽查记录
缺陷跟踪记录（TestDirector）
集成测试用例
项目经理指派专人抽查集成测试报告，QA代表也应抽查集成测试报告。
《模块设计说明书》
《用户需求说明书》和《需求规格说明书》
抽查记录
缺陷跟踪记录（TestDirector）
系统测试过程
《系统测试用例》
在编写过程中，尽可能多的跟用户（特别是最终用户）沟通，一些中间成果及时展示给用户，征求用户的意见。
同行评审
评审要重点关注系统测试用例是否能够满足需求。
必要时可邀请用户一起参加评审。
需要强调的是需求分析师应该参加测试用例的同行评审，它的作用在于验证系统测试用例是否真正满足了需求。
《系统测试计划》
需求文档
设计文档
同行评审报告
征求意见记录
缺陷跟踪记录（TestDirector）
需系统测试的系统
执行测试过程
测试用例
《用户需求说明书》
《需求规格说明书》
《系统测试总结报告》
缺陷跟踪记录（TestDirector）
软件发布过程
《用户手册》
要明确手册的读者是谁及其特点。
有针对性的编写系统操作的流程。
必要时可邀请最终用户一起参与编写。
需求文档
设计文档
客户意见记录
《安装维护手册》
要明确手册的读者是谁及其特点。
有针对性的编写系统安装维护的流程。
必要时可邀请用户一起参与编写。
需求文档
设计文档
客户意见记录
《客户培训计划》和培训材料
要明确客户是谁及其特点。
有针对性的编写培训材料。
必要时可邀请用户一起参与编写。
完成系统的安装后，实施工程师对客户方进行有关系统操作等方面的培训；
客户方接受培训，并做出反馈。
需求文档
设计文档
客户意见记录
客户培训反馈记录
需安装系统
实施工程师与客户确认将要发布软件的版本信息。
这些版本信息可以从项目配置库的发布基线说明里面得到。
实施工程师从项目配置库中签出客户确认的软件版本，到客户现场安装并调试，使系统正常运行；
客户方派代表配合软件安装工作。
《安装维护手册》
客户确认记录
客户安装记录
需验收的系统
客户方对安装的系统实施验收测试，环境必须是客户环境
客户确认《客户验收报告》
验收测试用例（参考系统测试用例）
《用户需求说明书》
《需求规格说明书》
《客户验收报告》
需试运行的系统
客户方对安装的系统实施试运行
《用户需求说明书》
《需求规格说明书》
《试运行报告》
8过程度量
1.验证和确认的次数
2.验证和确认所用工时数
3.每次验证确认所发现的缺陷数
9过程剪裁准则
参见《过程剪裁报告》剪裁指南和《同行评审过程》的过程剪裁准则。
升级会员 