01-发版计划.doc

文档编码 密级 文档版本 拟制人 日期 [项目编号和项目名称] 发版计划 版本号 郑重声明：XX软件股份有限公司版权所有。本文档中任何部分未经XX软件股份有限公司书面授权，不得将材料泄露给第三方，不得以任何手段、任何形式进行复制与传播。 变更履历 版本 日期 变更位置 变更理由/变更内容 变更人 备注 目 录 1 发版目的 3 2 背景说明 3 3 版本定义 3 4 参与主要人员 3 5 进度计划及里程碑 3 6 工作产品清单 5 7 附件：编写指南与评审检查表 5 1 发版目的 明确本次版本的版本号，以及发布该版本的目的及目标。 2 背景说明 项目背景简要介绍，简要说明上一个版本的基本情况； 如果是产品，说明本次发版主要有哪些项目提出了发版的申请，申请的重点在哪些方面。 3 版本定义 定义此版本的范围，该版本的主要特性，主要为哪些项目发布该版本（接收了哪些项目的发版申请） 1．调整范围详细列表： 编号 类型 描述 提出项目 优先级别 重大缺陷 重大需求 业务合并 说明需求冻结时间点、最晚开发完成时间点 2．详细版本清单：包含哪些编译环境的版本，哪些子版本、哪些模块、哪些工具 3．说明需要支持哪些主要用户环境 4 参与主要人员 说明本次发版的角色及参与成员 角色 人员 职责 发版负责人 研发人员 测试人员 测试顾问 5 进度计划及里程碑 任务 时间 人员 工作成果 发版准备阶段 发版测试阶段 发版收尾 里程碑说明： 里程碑 说明及标志 具体时间 需求冻结 需求冻结后原则上不在增加任何新提出的需求，缺陷仍然需要处理 需求冻结后提交的需求将放入下次版本 开发完结 为保证测试执行时间，给出开发完成所有新需求可提交测试的最晚时间点 待发布阶段 所有测试项测试执行完成，新增缺陷成明显下降趋势，版本趋于稳定 1．可以提交版本给测试顾问进行测试和确认，或者项目试用 2．此阶段后发现的缺陷需要进行“缺陷升级”，为保证版本的相对稳定性对新发现缺陷的修改要采取谨慎态度，需要及时对缺陷进行确认和讨论 3．此阶段的关键修改可以在研发人员环境中测试通过在提交到版本库中 测试结束、版本发布 无严重未解决、无严重缺陷反馈，所有已发现缺陷都已确认只有关闭和遗留状态 6 工作产品清单 l 发版计划 l 发版测试计划（包含主要测试设计） l 相关需求设计文档 l 阶段测试总结 l 发版测试报告 l 更新说明 l 发版程序包及发版清单 7 附件：编写指南与评审检查表 检查点： 1．是否明确需求冻结时间点，严格确定版本范围 2．是否明确正式发版时间，有明确的版本号 3．阶段划分是否合理，是否有明确的阶段目标 4．对版本的定义是否全面 5．是否明确了本次发版参与的具体人员，及每个人的具体职责 编写指南： 1．项目经理在接到各项目的发版申请后，综合考虑版本发布的需要： l 如果是产品发版的频率要进行一定控制，最好在一个季度或者两个季度推出一个完整版本比较合适 l 需要和各方面：测试、研发、实施技服确认时间是否合适，工作能否协调和保证 l 考虑对关键项目及终验项目的支持力度，确定的时间点对这些项目的影响程度 2．最终经研发部门、测试部门、技服部门部门经理确认后，确定明确的发版时间点 3．发版时间点确认后，讨论商榷需求冻结时间点，掌握到目前为止所有关键需求 4．在需求冻结时间点上发版计划既要定稿并发布。