版本计划.docx
- 文档编号:24950313
- 上传时间:2023-06-03
- 格式:DOCX
- 页数:17
- 大小:67.13KB
版本计划.docx
《版本计划.docx》由会员分享,可在线阅读,更多相关《版本计划.docx(17页珍藏版)》请在冰豆网上搜索。
版本计划
技术文件
技术文件名称:
XXXVX.X.XX版本计划
技术文件编号:
版本:
V1.0
(第一次归档为V1.0,修订后为V1.1,V1.2一次类推)
共页
(包括封面)
拟制
审核
会签
标准化
批准
深圳市鼎力网络有限公司
版本变更记录:
这表包含文档修订的历史记录,“版本描述”中简述主要的变更内容,“存档编号”在存档时填写。
下面输入项提供了一个单独的例子作为解释。
当你创建修订信息时应该删除以下输入项。
文档本身应该处于修订控制之下,并且每个版本应在修订控制系统中输入一个简要的描述。
在这部分的简要描述可以重复。
版本号
拟制日期
拟制人
版本描述
存档编号
草案
2006年9月4日
为分发和评审而创建的最初草案。
初步
2006年9月4日
合并了最初评审意见的第二版草案,为最终评审而分发。
终版
2006年9月4日
第一次完整草案,被置于变更控制之下。
修订本1
2006年9月4日
根据变更控制过程而修订过和在变更控制之下的维护过的草案。
修订本2
2006年9月4日
根据变更控制过程而修订过和在变更控制之下的维护过的草案。
修订本3
2006年12月18日
根据变更控制过程而修订过和在变更控制之下的维护过的草案。
修订本4
2007年7月10日
根据评估师建议增加了版本的2.1,2.2,和7
注:
1)拟制、审核、会签、批准不走电子流程时,必须用钢笔或签字笔填写,不得用铅笔、圆珠笔填写。
将新段落格式化为标题1、标题2和标题3,标题号就会自动增加。
用MicrosoftWord,把光标置于表中的任何位置后按F9,即可更新表中的内容。
如果你想容易地维护此表,就不要手工更改它。
XX版本计划
1介绍
1.1目的
阐明制定此软件项目版本计划的目的,可能的读者。
如:
制定本计划是为了便于高层管理、产品经理、产品总工、项目经理、软件工程组、质量保证组、配置管理组人员以及相关组成员等进行交流沟通,为版本活动的开展和跟踪控制提供依据。
1.2范围
描述此计划的范围。
如:
本计划描述了版本的目标和范围,明确版本的各项任务以及完成各项任务的时间进度、责任人和所需的资源预算。
1.3定义与缩略语
本小节应提供正确理解此软件项目版本计划所需的全部术语、首字母缩写词和缩略语的定义。
这些信息可以通过引用软件项目词汇表来提供。
1.4引用
本小节应完整地列出此软件项目版本计划中其他部分所引用的所有文档。
每个文档应标有标题、编号或版本号(如果适用)、日期和发布组织。
这些信息可以通过引用附录或其他文档来提供。
下表中列出了软件项目版本计划所引用文档的例子:
表1 引用文档
文档名称
编号或版本号(可选)
发布日期(可选)
发布组织
测试计划
最新版
测试组
配置管理计划
最新版
配置管理组
质量保证计划
最新版
软件质量保证组
2版本概述
2.1版本的目标和范围
<简要说明研制此软件版本的目的、目标和版本的范围>
2.2假设与约束
<列出此计划所依据的假设和对软件版本的所有约束(如预算、人员、设备、进度等>
2.3新增功能
2.4方案改进
2.5故障更改
2.6版本提交及发布时间
2.7版本的最终提交产品
以表格的形式列出将在软件项目中创建的所有要交付给客户(包括外部顾客、内部用户等)的主要产品。
列出交付产品、交付日期、交付地点、交付方法(email、FTP、CD等),以及满足软件项目需求所必须的数量。
表2 最终交付产品
序号
交付产品名称
数量
交付日期
交付地点
交付方法
1
用户手册
1
2
3
4
5
2.8版本的验收标准
<说明项目的验收标准或结束准则.可以通过引用附加>
3项目组织
3.1组织结构
说明软件项目团队内部(包括管理人员)的组织结构(如命令链或管理报告结构)。
使用图表,矩阵图或其它适当的符号来描述职权、职责和软件项目内部的沟通。
例子:
图中实线表示资源线上管理关系,虚线表示项目组内的报告关系,红色的线表示虚线与实线重合。
此例子仅是一个示意图,各开发单位可以给出其内部的结构模块,各项目可根据实际填写。
3.2角色与职责
指项目组内的角色与职责。
要求识别和描述每个主要功能和活动,并识别负责每个功能和活动的人员或组织单位。
可以使用如下表格。
表3 角色与职责
名称/姓名
角色
职责
联系方式
备注
项目经理
全面负责项目的管理,如计划的制定(含估算)、评审、跟踪等管理职责
SE
负责软件设计,参与计划的制定(含估算)、评审等
开发经理
负责版本任务的开发及管理,参与计划的制定(含估算)、评审与跟踪等
测试经理
负责版本任务的测试及管理,参与计划的制定(含估算)、评审与跟踪等
开发工程师
负责软件开发,参与计划的制定(含估算)、评审等
测试工程师
负责软件测试,参与计划的制定(含估算)、评审等
质量保证人员
负责质量保证工作,为项目组提供培训、指导和资询,参与计划的制定、评审,对过程审核、评审工作产品
软件配置管理员
进行配置管理,参与计划的制定、评审
文档工程师
最终用户文档负责人,参与计划的制定、评审
3.3外部接口
表4 外部接口
名称/姓名
角色
职责
联系方式
备注
人力资源组
提供人员信息和招聘人员
市场人员
负责市场信息的了解,对外沟通交流
产品总经理
项目的直接上级,负责批准计划,对外约定的承诺
SEPG
过程改进
本列表应包括负责软件项目与其它组织之间接口的特定人员或软件项目角色的描述(如联系人和联系方式)。
例如,描述软件项目与下面组织之间的关系:
●父组织(上层管理组织)
●顾客组织(内部或外部)
●如果有分包,则包括分包组织。
●如果有独立的最终用户支持组织,则包括最终用户支持组织。
●任何对软件项目有影响的组织。
4管理过程
软件工程过程包括管理活动和技术活动,这里的管理过程是指其中的管理活动。
在下一章节中的技术过程是指软件工程过程中的技术活动。
除非有其它目的,否则上面标题与下面标题之间不必有文本说明。
4.1项目估算
估算软件规模、工作量、成本与进度的依据和方法,请参见《软件项目估算报告》记录。
软件项目中将定期进行重新估计的时间点和结果(见下表):
表5 软件估算计划
估算次数
阶段点
规模
工作量
成本
进度
初始估算
需求分析前
第一次重新估算
系统设计前
第二次重新估算
编码前
第三次重新估算
系统测试前
4.2工作分解结构(WBS)及进度计划
这部分可以附件方式参见工具文档(如MS Project文档)。
4.3依赖计划
<描述工作包之间以及软件项目的工作包与外部事件之间的依赖关系。
软件项目工作包之间的依赖关系可以参见工具文档(如MS Project文档),软件项目的工作包与外部事件之间的依赖关系,即外部依赖关系,可以用下表来说明。
例子:
<1.项目工作包与外部事件之间的以来关系参见下表:
>
表6 依赖计划
序号
任务名称
关联任务
采取措施
责任人
备注
1
设备的转产
XX中试进度
XX
XXX
4.4资源计划
4.4.1软件和硬件资源计划
<说明您将如何确定并得到软件项目所需的软件和硬件资源。
>
表7 软/硬件资源需求
序号
资源名称
需求数量
到位日期
如何获得
责任人
备注
4.4.2关键计算机资源计划
表8 XX版本关键计算机资源需求清单
CPU要求
内存要求
主频要求
CPU利用率
内存容量
内存利用率
版本
注:
如果不需要估算关键计算机资源,请注明原因。
4.4.3人力资源计划
表9 人力资源计划
序号
资源名称
需求数量
到位日期
如何获得
责任人
备注
4.4.4其它资源类计划
可以列出的资源包括、但不限于资金计划、物资计划、培训需求计划。
也可参见其它附件,例如:
项目计划等。
4.5风险管理
表8 风险应对计划
编号
风险描述
发生概率
后果
综合评价
责任人
预审计划
处理计划
备注
1
2
3
4
5
6
7
8
9
10
5技术过程计划
5.1过程模型
5.1.1软件生存周期模型
可以这样写:
每个小版本采用瀑布模型:
按图式模型,按需求分析、设计、开发(编码、自测、集成测试)、系统测试、维护等顺序,(可以根据需要选取版本有的各阶段进行描述)
5.1.2主要里程碑
里程碑所属的阶段、里程碑标志、内容和规定日期。
这部分可以附件方式参见工具文档(如MS Project文档)。
表9 主要里程碑
阶段
里程碑标志
日期
内容描述
软件概要设计阶段
软件总体方案通过评审
2005/12/18
描述里程碑的意义
软件详细设计阶段
软件模块设计说明通过评审
2006/2/11
5.2方法、工具和技术
描述如下:
●计算机系统环境包括硬件、操作系统环境和编程语言等。
●工具包括:
仪器仪表、设计工具,源代码控制,时间统计,编译器或IDE,调试辅助工具,缺陷跟踪,等等。
●开发方法论包括需求开发实践、设计方法和符号、系统集成程序,等等。
(这些在软件项目计划第一版草案创建时不会全部定义,随着计划越来越详细这部分应该更新。
)
●质量控制手段包括技术同行评审方法,单元测试,代码单步调试、系统测试和自动回归测试,等等
●使用的技术标准、编码标准、文档标准、方针政策和规程等
表10 方法、工具和技术
软件项目阶段
计算机系统环境
软件工具
开发方法论
质量控制手段
使用标准
版本计划
WINDOWS2000
MSWORD
MSProject
逐步逼近法
同行评审手段
《项目计划规程》《同行评审规程》
详细设计
WINDOWS2000
Clearcase
面向对象设计方法
模块设计
同行评审手段
《版本开发规程》
《同行评审规程》
代码编写
IRMX
VisualC++
面向对象设计方法
同行评审手段
《版本开发规程》《同行评审规程》
5.3产品验收计划
可通过引用附加。
6支持过程计划
6.1软件质量保证计划
通过引用附加。
6.2软件配置管理计划
通过引用附加。
6.3用户文档支持计划
指文档组参加用户文档编写的计划,通过引用附加。
6.4工作产品与评审计划
作为计划的一部分,本小节说明软件项目的所有工作产品(强调:
工作产品按包括代码、不要忽视)及其评审计划。
表11工作产品及评审计划
阶段
工作产品名称
作者
评审者
评审日期
评审方式
设计
建议按《设计文件(报告)齐套性要求》来规范地写工作产品名称
XXX
XXX
XXX
尽量选同行评审,如果是同行评审请具体写上审查、走查、或单人复审,如果不是请注明“会议评审”或“XXX”
6.5项目跟踪与控制机制(Trackingandcontrolmechanism)
6.5.1数据收集
表12 跟踪一览表
跟踪项
跟踪内容
工具
责任人
跟踪频度
跟踪策略/机制
项目简介
版本开始日期、期望结束日期
项目经理
每月
通过项目状态报告
项目计划信息
计划基线日期、计划最近修订日期、计划修订次数、进度最近修订日期、进度修订次数
项目经理
每月
通过项目状态报告
项目跟踪与监督活动信息
项目周例会、项目月例会、里程碑评审会议、其它跟踪活动
项目经理或项目管理员
每月
通过项目状态报告
项目主要状态概述
软件项目的主要状态进行简单描述
项目经理
每月
通过项目状态报告
提交产品配置控制委员会裁定的情况
项目提交给产品配置控制委员会裁定的情况介绍
项目经理
每月
通过项目状态报告
需求
需求数及需求变更
RequisitePro库
SCM
每月
通过项目状态报告
规模
代码行
文档页数
项目经理、开发经理或项目管理员
阶段点或发生重大变更时
通过状态报告或团队会议
工作量
项目经理、开发经理或项目管理员
每周
通过状态报告或周会议
进度
MSPROJECT
项目经理、开发经理
每周
通过状态报告或周会议
风险
状态报告
项目经理或模块负责人
每周
通过状态报告或周会议
缺陷
各类缺陷统计及缺陷比较
ClearQuest库
SCM
每月
通过项目状态报告
依赖
项目经理
每月
通过项目状态报告
同行评审
状态报告、PR库
模块负责人
每周
团队会议
软硬件资源
项目经理
每月
通过项目状态报告
成本资源
项目经理
每月
通过项目状态报告
培训
项目经理
每月
通过项目状态报告
关键计算机资源
项目经理
每月或阶段点
通过项目状态报告
审计信息
SQA不合格项
SQA
每月
通过项目状态报告
人员资源
项目经理
阶段点或发生重大变更时
通过项目状态报告
问题
项目经理
每周
通过周例会纪要或项目状态报告
6.5.2状态评审与报告
<描述本项目将在每周的第几天召开周例会。
在每月的第几天召开月例会,以及在哪些阶段点/里程碑处召开评审会议。
这些会议分别由哪些人应该参加,会议的输入是什么,输出是什么。
>
7计划维护
<根据项目的跟踪情况(请各项目详细写自己的跟踪频度、机制),在跟踪中发现当如下条件之一出现时需要修订计划。
Ø当版本的需求(包括技术需求和非技术需求)发生变化时(故障更改清单发生变化时除外);
Ø当实际进度偏差超过一周时;
Ø当再次的估算结果有变化时;
Ø及其它必要情况
修订计划时可根据规程要求进行适当裁剪步骤,但评审、批准,发布和受控管理的步骤不能裁剪。
>
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 版本 计划