项目计划表CMMI.docx
《项目计划表CMMI.docx》由会员分享，可在线阅读，更多相关《项目计划表CMMI.docx（19页珍藏版）》请在冰点文库上搜索。
项目计划表CMMI
蓝色斜体为模板说明或示例文字，使用时应删除。
“{}”中的内容连同括号本身应以实际内容代替。
正文：
宋体、小四、1.5倍行距，首行缩进2字符。
“■”所在位置应以实际文字代替。
“□”所在位置根据需要以实际文字代替或直接删除。
{项目名称}项目计划
文档编号：
版本：
密 级：
编写人：
编写日期：
批准人：
全通通信有限公司
文档修订记录
版本编号
变化状态
简要说明
日期
变更人
批准日期
批准人
V0.1
C
初次创建
*变化状态：
C――创建，A——增加，M——修改，D——删除
目录
第一章文档介绍1
1.1文档目的1
1.2文档范围1
1.3读者对象1
1.4参考文献1
1.5术语与缩写解释1
第二章项目介绍2
2.1项目目标2
2.2项目范围2
2.3项目组结构2
第三章项目分类及过程裁剪3
第四章项目生命周期定义5
第五章跟踪规划6
5.1度量计划6
5.2任务跟踪6
5.3质量跟踪6
5.4状态报告7
第六章工作量估算8
6.1项目规模估算8
6.2工作量估算8
第七章任务与进度计划10
第八章人力资源计划11
第九章干系人计划12
9.1干系人结构12
9.2矩阵结构图12
9.3沟通矩阵图12
9.4沟通计划13
第十章软硬件资源计划14
第十一章内部培训计划15
第十二章风险管理计划16
12.1风险分类16
12.2定义风险阈值17
12.3风险识别、分析与控制18
第十三章附属计划21
第一章文档介绍
一.1文档目的
提示：
本文档的目的。
一.2文档范围
提示：
本文档包含哪些部分的内容。
一.3读者对象
提示：
本文档的读者。
一.4参考文献
提示：
列出本文档的所有参考文献（可以是非正式出版物），格式如下：
[标识符]作者，文献名称，出版单位（或归属单位），日期
例如：
《项目建议书》、《可行性研究报告》
其它参考资料
一.5术语与缩写解释
缩写、术语
解释
SPP
精简并行过程，SimplifiedParallelProcess
PP
项目规划，ProjectPlanning
…
第二章项目介绍
二.1项目目标
提示：
说明本项目的目标，这些目标必须是“可实现”、“可验证”的。
二.2项目范围
提示：
（1）用简练的语言说明本项目“是什么”，“说明用途”。
（2）说明本项目“应当包含的内容”和“不包含的内容”。
（3）说明本项目“适用的领域”和“不适用的领域”。
二.3项目组结构
提示：
列明项目组中客户代表、开发经理、产品经理、质量经理、CCB成员、设计组成员、开发组成员、测试组成员、配置管理员及其它角色的具体人选。
角色
成员
客户代表
开发经理
产品经理
质量经理
CCB成员
设计组成员
开发组成员
测试组成员
配置管理员
其它
第三章项目分类及过程裁剪
提示：
首先按《项目分类》中的规则对项目进行类别区分，按本项目的所属类别对项目过程进行裁剪定义。
裁剪后的结果可从excel文档中粘贴到这里。
如下所示：
本项目类别为：
A类，工程过程裁剪如下（详见《裁剪记录》）：
特别声明：
需要裁剪部分应该报EPG进行审批，通过后方可裁剪。
项目过程
方案
工作产品
项目管理
可研
项目启动
√
项目启动《会议纪要》
项目计划
√
《项目计划》
计划变更
√
…
项目监督与控制
√
周例会
√
项目周报
√
工程
需求获取
√
需求分析
√
技术准备
规范制定
概要设计
√
详细设计
√
编码
√
系统测试
√
系统实施
√
项目总结
√
项目总结
√
需求变更
√
需求的追溯及跟踪
√
BUG管理
√
支持
配置管理
√
跟踪检查
√
度量汇报
√
第四章项目生命周期定义
提示：
在本章中对项目生命周期进行定义，项目生命周期参考模型见《项目分类》文档。
项目生命周期的定义需按实际情况考虑，不能生搬硬套理论模型，例如某项目整体上是按瀑布式演进，但需要在需求和设计阶段进行迭代，其它各阶段按传统模型进行。
在本章中说明项目实际情况、特点，并给出生命周期图示。
给出生命周期模型图示的同时，要对项目生命周期进行文字性的解释说明，用以阐述项目有什么样的特点，为何这样定义生命周期。
第五章跟踪规划
提示：
从度量计划、任务跟踪、质量跟踪和状态报告四个方面进行跟踪规划。
五.1度量计划
指标
度量单位
所用工具
进度
经过的时间（天）
Project
规模
LOC
自编写代码行统计工具
…
五.2任务跟踪
跟踪项
跟踪方法
任务分配
通过查看project文件获得
任务状态
通过每天检查实际工作完成情况与进度计划比对获得
…
五.3质量跟踪
质量任务
措施
缺陷跟踪
用ClearQuest记录Bug，并在其中跟踪缺陷，直到关闭
评审（需求、设计）
根据质量计划中的项目目标进行检查
…
五.4状态报告
报告目标
报告形式
报告周期
中心经理
将周报以电子邮件形式发送
每周
部门经理
将周报以电子邮件形式发送
每2周
公司经理
单独撰写电子邮件
每月
项目组全体成员
将周报以电子邮件形式发送
每周
第六章工作量估算
六.1项目规模估算
提示：
主要步骤如下，
1）搜集归纳《项目启动会议纪要》、《项目可行性研究报告》或《项目建议书》中软件功能点，并尽可能详细说明每个功能点的主要功能。
2）根据相似项目经验和历史数据，为每一个功能点估算出最底层（自底向上）可能详细的代码行。
3）估算出期望的规模加上标准偏差，即：
规模的最低值和最高值来反映名义值的不确定性。
在项目的早期阶段，最低和最高估算结果之间的范围可能是30-50%，例如：
概念阶段。
如果缺乏经验或有较高的技术风险，范围将会更大。
4）具有类似经验的软件工程师应该评审并优化估算结果直至达成一致意见。
经验表明，规模估算经常偏低，故最低规模估算结果应该给与特别审查。
需要罗列归纳的功能点，说明主要计算过程，规模估算得出的应该是整个项目估算的千行代码数（KLOC）。
六.2工作量估算
提示：
建议采用《规模估算单》进行估算，该表提供历史数据与试开发的两种方法，根据情况使用。
工作量估算也可以采用结构性成本模型COCOMO（constructivecostmodel），计算公式如下：
软件模式
a
b
工作量公式
独立
2.4
1.05
E=2.4*（规模）1.05
半分离
3.0
1.12
E=3.0*（规模）1.12
嵌入
3.6
1.20
E=2.4*（规模）1.20
规模为估算的软件规模，单位为千行代码数（KLOC），E为用人-月来表示的工作量，需要说明其软件模式，采用的公式，以及最后的计算结果。
第七章任务与进度计划
提示：
规划小组分配任务制定进度表，建议采用MicrosoftProject制作Gantt图（插入此处或作为附件）。
任务名称
起止时间
工作人员
工作量
预期工作成果
第八章人力资源计划
提示：
在此处明确人员的加入和退出时间以及人员的计划外变动应对办法。
姓名
职责
预期加入时间
预期退出时间
变动应对办法
张三
软件工程师
2008-03-01
2008-03-01
李四作为候补人员，或其工作由项目经理等分担
第九章干系人计划
提示：
干系人计划目的是明确所有项目相关人员的角色、职责，确定干系人在项目的主要活动中的责任，并体现干系人之间的关系、沟通方式与频度、如何协同工作。
九.1干系人结构
提示：
干系人组织结构图，体现与项目组的关系。
九.2矩阵结构图
提示：
干系人在项目开发中参与的活动。
人员
活动
人员1
人员2
人员3
人员4
人员5
需求获取
A
R
C
I
I
需求开发
R
A
I
C
I
技术攻关
R
R
A
I
I
概要设计
R
C
R
A
C
。
。
。
。
R=有责A=负责C=征询意见I=通报
九.3沟通矩阵图
提示：
干系人沟通矩阵图。
人员1
人员2
人员3
人员4
人员5
人员1
←
←
←
←
人员2
↑
〓
※
←
人员3
↑
〓
↑
↑
人员4
↑
※
←
〓
人员5
↑
↑
←
〓
。
。
。
。
↑←汇报方向〓双向沟通※无汇报关系
九.4沟通计划
提示：
干系人在项目中沟通计划。
时间
沟通形式
参与的角色
沟通内容
2007-11-14
访谈
客户代表、需求分析师
确认需求
。
。
。
第一十章软硬件资源计划
提示：
规划小组分析项目过程所需的软件、硬件、网络等资源，说明资源到位的计划时间，如下表：
软件名称
版本
用途
备注
硬件名称
型号
用途
备注
IP地址
用途
备注
第一十一章内部培训计划
提示：
内部培训计划是指对项目组成员根据项目需要，为提高成员技能进行的针对性的培训，培训计划以下面表格形式书写。
培训内容
培训人
受训人
开始时间
培训时长
Java培训
XXX
开发组
2007-11-21
7天
配置管理培训
XXX
项目组所有人
2007-11-29
2小时
小组评审
XXX
开发组、测试组
2007-12-3
3小时
…
第一十二章风险管理计划
一十二.1风险分类
{提示：
风险内容为参照《软件开发风险列表》识别或其它方式识别的风险分类和来源：
}
序号
分类
风险来源
1
政治
法律
市场
政府或者其他机构对本项目的开发有限制
有不可预测的市场动荡
……
2
需求
需求不稳定
……
3
调查
缺乏项目相关技术积累，调查不充分
……
4
设计
功能设计不正确
……
5
编码
代码的可测试性差
……
6
测试
集成或测试的环境不具备
……
7
产品
项目进行中，客户要求提前工期
……
8
工程特性
产品的可维护性
……
9
过程
是否有项目定义过程？
（没有裁减，没有项目的过程定义）
……
10
开发环境
新应用开发工具没有经过试用和培训
……
11
管理
管理人员的经验不足
……
12
工作环境
士气
……
13
资源
人员有可能缺乏
……
一十二.2定义风险阈值
提示：
规划小组参考组织级风险预警阈（阈，音：
yu，含义：
泛指界限或范围）值，根据项目实际情况对本项目的风险预警阈值进行细化或调整，明确规定风险权值在超出多少数值时需要执行风险处理。
参数定义说明：
1.可能性（发生的概率），分为五类：
a）能（5）
b）极可能（4）
c）可能（3）
d）有可能
（2）
e）稍有可能
（1）
2.影响程度，分为四类：
a）重大（4）
b）重要（3）
c）次要
（2）
d）微小
（1）
3.风险权值=可能性×影响程度。
数值
风险级别
说明
风险权值>12
高
必须在项目计划中体现应对措施
6<=风险权值<=12
中
可以不用在计划中体现应对，但是需要考虑应对
风险权值<6
低
项目计划中可以忽略应对措施
一十二.3风险识别、分析与控制
提示：
风险内容为参照《软件开发风险列表》识别或其它方式识别的风险：
可能性是发生的概率，分为能（5）、极可能（4）、可能（3）、有可能
（2）、稍有可能
（1）五类进行评价；
影响程度可以按照重大（4）、重要（3）、次要
（2）、微小
（1）四类进行区别评分；风险权值=可能性×影响程度；具体可参考项目计划过程描述。
组织级风险管理策略：
1.风险避免：
改变或降低需求，但仍符合使用者需要；
2.风险控制：
采取主动的步骤，以降低风险；
3.风险转移：
重新配置设计需求，以降低风险；
4.风险监督：
就指定的风险参数的变化，观察并定期重新评估风险；
5.风险接受：
对风险有认知，但不采取任何动作；
参数定义说明：
1.可能性（发生的概率），分为五类：
a）能（5）
b）极可能（4）
c）可能（3）
d）有可能
（2）
e）稍有可能
（1）
2.影响程度，分为四类：
f）重大（4）
g）重要（3）
h）次要
（2）
i）微小
（1）
3.风险权值=可能性×影响程度。
组织级风险管理策略：
1.风险避免：
改变或降低需求，但仍符合使用者需要；
2.风险控制：
采取主动的步骤，以降低风险；
3.风险转移：
重新配置设计需求，以降低风险；
4.风险监督：
就指定的风险参数的变化，观察并定期重新评估风险；
5.风险接受：
对风险有认知，但不采取任何动作；
分类
风险内容
风险趋势
可能性
影响程度
风险权值
管理策略
应对措施
负责人
第一十三章附属计划
提示：
附属计划是对《项目计划》的补充。
下属计划的名称
建议负责人
预计产生时间
文件名称
《配置管理计划》
配置管理员
《质量保证计划》
质量经理
升级会员 