项目计划书模板.docx
- 文档编号:22847905
- 上传时间:2023-04-28
- 格式:DOCX
- 页数:18
- 大小:40.08KB
项目计划书模板.docx
《项目计划书模板.docx》由会员分享,可在线阅读,更多相关《项目计划书模板.docx(18页珍藏版)》请在冰豆网上搜索。
项目计划书模板
文档编号:
ICSSHS-QMS-PP-QT-03
密级:
公开
版本号:
V1.0
文件类别:
质量管理体系文件
发布状态:
已发布
项目计划书
2008年10月
文档更改历史记录
初始信息
文件名称
项目计划书模板
批准人
罗万达
初始版本号
V1.0
发布日期
2008-12-1
编写人
谢镇宇
实施日期
2008-12-1
更改记录
版本号
更改要点
对应章节
修改人
审批人
批准日期
1.项目概述
2.
2.1.目的和范围
2.2.
描述本项目的目的、范围和适用性。
2.3.术语
2.4.
列出本文件中适用的专门术语(包括外文缩写的原文词组)。
名词定义
CCB
变更控制委员会(SoftwareChangeControlBoard)
CM
配置管理(SoftwareConfigurationmanagement)
CMO
配置管理经理(ConfigurationManagementOfficer)
QA
质量保证人员(QualityAssuranceEngineer)
CL
配置库(ConfigurationLibrary)
CI
配置项(ConfigurationItem):
是一组功能或者物理属性的组合,在配置管理过程中,配置项被作为一个单一的实体对待
CR
变更请求(ChangeRequest)
基线
基线就是配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态
审计
对配置管理的独立的查检过程,确认受控配置项满足需求并就绪。
2.5.工作环境
2.6.
按照下表描述的工作环境开展项目活动:
网络环境
以《中软海晟资源组织工作环境》的网络环境要求组织进行。
开发环境
参见《XXX项目设计书》中软硬件资源要求描述。
测试环境
参见《XXX项目测试计划》中软硬件资源要求描述。
其它环境
参见《中软海晟资源组织工作环境》的XX环境要求组织进行。
2.7.参考资料
2.8.
描述制定本项目计划中参考的标准、规范、样本等。
2.9.项目总体目标
2.10.
根据《中软海晟项目管理办法》中的项目绩效指标和集团过程能力基线(PCB)设定项目总体目标。
以下指标仅做参考,除进度偏差及工作量偏差必需记录外,别的偏差依据项目情况自行增加或删除。
项目总体绩效目标
项目目标
偏差目标
计算办法
进度偏差
-15%≤进度偏差≤+15%
(实际工期-基准工期)/基准工期。
基准工期:
来自项目实施立项时的《项目估算表》中的预算工期。
实际工期:
从项目开始到项目关闭的自然日历,扣除挂起期间工期。
工作量偏差
-20%≤工作量偏差≤+20%
(实际实施工作量-基准预算实施工作量)/基准预算实施工作量。
基准预算实施工作量:
来自项目实施立项时的《项目估算表》中的工作量估算。
3.组织机构及项目人员
4.
4.1.组织机构图
4.2.
4.3.
部门经理
项目经理
变更控制委员会(CCB)
需求分析人员
设计人员
开发人员
测试人员
配置管理员(CMO)
质量保证人员(QA)
4.4.
提示:
请根据项目的实际情况增删和修改上图。
4.5.项目人员及职责
角色
责任描述
姓名
电话号码
客户经理
联系客户,与客户进行沟通和承诺。
项目经理
项目经理履行的任务是对整个项目的总体业务负责;项目经理是指导、控制、管理和调整项目进行构造软件或硬件/软件系统工作的个人,项目经理是最终向顾客负责的个人。
高层经理
获得对项目的承诺和支持,以及对项目的总体控制。
客户代表
需求的提出者,也是软件开发的约定者。
用户代表
软件产品的使用者,有时与客户是同一对象。
需求人员
对客户的需求进行收集,然后分析成归于软件的需求。
开发人员
根据需求,通过设计和编码实现软件的需求。
测试人员
对软件产品进行测试,保证满足软件设计要求和客户的需求。
SQA人员
在整个软件生命周期中,监督和检验软件过程与标准的符合性以及软件产品生产规范的符合性。
SCM人员
在整个软件生命周期中,控制软件产品的状态和一致性,确保产品的有序变更和发布。
培训人员
负责对项目人员进行相应技能的培训。
系统管理员
数据库/运行/网络支持。
CCB
管理项目软件基线的委员会。
(主席)
【注意:
一个人可以担任多个角色,如王建民是项目经理、需求人员、开发人员和CCB主席。
】
4.6.技能要求
4.7.
描述本项目的相关背景知识,技能等的要求。
如:
角色
知识技能要求
项目经理
熟悉CMM用于项目管理,熟练掌握MSProject、MSWord、MSExcel和MSVisio。
软件需求开发者
熟练运用UML进行软件需求开发,熟练掌握MSVisio或RationalRose。
软件框架设计者
熟练运用UML进行软件框架设计,熟练掌握MSVisio或RationalRose,精通至少一门面向对象设计语言(如Delphi或Java),熟练掌握MSWord和MSExcel。
开发组长
熟悉UML,精通最终选定的开发语言,熟悉通用数据库接口,会使用MSWord和MSExcel初级功能。
编程人员
熟练掌握最终选定的开发语言,会使用MSWord和MSExcel初级功能。
测试人员
熟悉测试理论,熟练掌握相关测试工具,会使用MSWord和MSExcel初级功能。
质量保证人员
熟练掌握CMM用于项目质量保证,熟练掌握MSWorkd和MSExcel。
配置管理人员
熟悉配置管理过程,熟练掌握至少一种配置管理软件(如MSVSS)。
部署上线人员
熟悉CCIS系统,熟悉最终选定的数据库、Web服务器的配置管理,熟练掌握MSWord。
5.项目提交物
6.
6.1.项目阶段提交物说明
6.2.
本项目的主要里程碑和交付物如下:
序号
里程碑(Milestone)
时间
交付物
产品规模
1
项目启动和计划
《项目软件过程定义》
《项目计划书》
不适用
2
需求分析开发(RA)
《需求分析规格书》
XX页
3
高层设计(HLD)
《概要设计说明书》
XX页
4
详细设计(DD)
《详细设计说明书》
XX页
5
编码和单元测试(CUT)
程序代码
《单元测试报告》
XX行
不适用
6
集成测试(IT)
测试用例
《集成测试报告》
XX个
不适用
7
系统测试(ST)
测试用例
《系统测试报告》
XX个
不适用
8
发布(REL)
《操作手册》
XX页
9
关闭(CLS)
《验收报告》
不适用
提示:
请根据项目的实际情况增删和修改上表,如:
参考软件过程定义,集成测试与系统测试合并,则删除集成测试部分。
7.项目策划
8.
8.1.软件生命周期模型定义
8.2.
本项目选择的项目生命周期模型是:
生命周期模型
标准V-瀑布生命周期(SVW)
阶段V-瀑布生命周期(V4)
阶段V-瀑布生命周期(V3)
阶段交付模型
请在此粘贴生命周期模型图
说明:
1.如果您对项目生命周期模型不熟悉,请参考《软件开发生命周期模型》和《软件开发生命周期选择指南》,同时咨询EPG人员。
2.如果您的项目需要对生命周期模型裁剪,请遵循《裁剪准则和指南》规定。
8.3.项目估算
8.4.
项目估算范围包括:
规模、工作量、成本和进度。
估算过程将严格遵守公司的估算流程。
(如果对估算流程有裁剪,请在此处详细描述)。
本节可直接注明规模、工作量及成本估算参见项目估算表,进度估算参见项目软件计划估计书(project文档),而不再具体说明。
8.4.1.估算规模
8.4.2.
8.4.3.估算工作量
8.4.4.
8.4.5.估算进度
8.4.6.
可采用Project制作WBS方式,参见《XXX项目软件计划估计书》。
8.4.7.估算成本
8.4.8.
8.5.项目质量目标
8.6.
提示:
1、项目过程性能目标是“组织过程性能目标”和“项目特有过程性能目标”的集合。
2、
3、参考集团组织过程能力基线PCB设定里程碑和质量目标,目的是为了更好的控制过程和产品质量,如项目实际中不涉及的目标或过程可行删除。
4、
5、在项目过程中应定期对比项目实际执行情况与目标,当出现偏差时,应对偏差产生的原因进行分析和采取措施。
以问题的形式记录在PMS中的问题跟踪表中。
目标来源
过程性能度量指标
里程碑
定义
是否选择
不选择说明
组织值
项目计划值
偏差下限
偏差上限
偏差下限
偏差上限
工作量偏差率
项目结束后
((累积实际工作量-估算工作量)/估算工作量)*100%
是/否
-20%
20%
编码开发效率(LOC/人天)
编码结束
(实际规模/编码工作量)
是/否
240
400
整体开发效率(LOC/人天)
项目结束后
(实际规模/总工作量)
是/否
140
390
测试缺陷识别率(个/KLOC)
项目结束后
系统测试缺陷数/规模
是/否
2.22
4.39
评审缺陷识别率(个/KLOC)
项目结束后
评审发现的缺陷数/规模
是/否
0.09
0.27
项目特有过程性能目标
8.7.设备及工具估计
设备和工具列表
说明
数量
预计日期
完成日期
负责人
DB27.0
采购
3
2003-02-10
CforAIX
采购
5
203-02-10
测试工具
开发
1
2003-03-30
任务管理系统
任务管理
1
2004-7-26
缺陷管理工具
缺陷管理
1
2004-7-26
。
。
。
9.需求开发计划
10.
需求开发计划一般包含在项目计划,在进行WBS时对需求阶段进行任务分解既可。
但对于大型项目,除了在WBS中拆分任务外,还应对需求调研进行详细的计划。
参考项目自己的过程定义,在些说明需求开计划是参见MPP还是MPP+需求调研计划。
11.数据管理计划
12.
描述本项目涉及的文档,代码,客户财产等数据的管理计划。
如:
电子类文档参见配置管理计划,非电子类文档遵照公司《纸质文档管理规范》执行。
电子类文档参见配置管理计划,本处主要写非电子类文档的管理办法,如项目无特殊需求,可注明遵照公司纸质文档管理规范执行。
13.沟通计划
14.
[列出整个生命周期内的不同阶段、不同组之间中需要沟通和协调活动等事项(预期的产品交付即组间产品交换、需要通知其他受影响组的决定如初步的技术方案即通讯交流)、负责人、参加组和(或)个人、议程(如果是会会议形式,内容包括:
客户的需求、技术问题、关键依懒关系、项目整体状态)、计划日期、计划地点(如果适用)、方式/工具(正式会议、电子交流会议、电子邮件、配置库系统、缺陷跟踪系统等),达到协调项目相关组和个人的活动和交流。
如:
序号
事项
方式/工具
计划日期
负责人
相关组或个人
1
开发团队成立、成员介绍
面谈
2006-11-20
莫亮
部门经理、QA、项目组
2
软件需求研讨、风险分析
内部会议
2006-11-22
莫亮
项目组
3
第1次周例会
内部会议
2006-11-24
莫亮
QA、项目组
4
软件需求基线发布会议
正式会议
2006-11-28
莫亮
客户代表、客户经理、QA、项目组
5
第2次周例会
内部会议
2006-12-1
莫亮
QA、项目组
。
。
。
15.培训计划
16.
参见《XXX项目培训计划》。
17.软件质量保证计划
18.
参见《XXX项目软件质量保证计划》。
19.配置管理计划
20.
参见《XXX项目软件配置管理计划》。
21.度量分析计划
22.
请参考《XX项目度量分析计划》。
23.软件集成计划
24.
请参考《XX项目集成计划》。
25.评审计划
26.
序号
评审内容
评审方式
评审日期
1
业务需求、软件需求规格说明书
同行评审
2006.11.14
2
项目计划(包括:
QA计划、CM计划、测试计划)及软件过程定义
同行评审
2006.11.27
3
概要设计、详细设计
同行评审
2006.12.4
4
测试用例
同行评审
5
代码
代码审查
2006.12.15
6
用户手册
同行评审
2007.1.5
27.软件测试计划
28.
参见《XXX项目软件测试计划》。
29.风险管理计划
30.
本项目的风险管理过程严格遵守公司的风险管理流程。
每周对前五名及一级风险进行跟踪,每里程碑对所有项目风险进行跟踪并再次识别。
31.里程碑会议
序号
里程碑阶段名称
会议方式
参加人员
评审日期
1
需求结束阶段
正式会议
XXX,XXX
2006.11.14
2
设计结束阶段
正式会议
XXX,XXX
2006.11.27
3
编码结束阶段
正式会议
XXX,XXX
2006.12.4
4
测试结束阶段
正式会议
XXX,XXX
2006.12.15
5
试运行结束阶段
正式会议
XXX,XXX
2007.1.5
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 计划书 模板