项目管理计划范例.docx
- 文档编号:12583959
- 上传时间:2023-06-06
- 格式:DOCX
- 页数:22
- 大小:24.36KB
项目管理计划范例.docx
《项目管理计划范例.docx》由会员分享,可在线阅读,更多相关《项目管理计划范例.docx(22页珍藏版)》请在冰点文库上搜索。
项目管理计划范例
项目管理计划范例
项目提要
项目综述
WBANK是一个基于美国的投资公司,该运用包括两个组成局部:
一个是WBANK网站上的经纪帐户开户〔BrokergeAccountOpening〕运用,它允许任何一个Internet用户开启一个WBANK经纪帐户;国一个是帐户开户和维护运用,主要是让WBANK代表对以书面格式央求的帐户停止开户。
这是一个Internet运用。
该运用将提供诸如账户历史检查和账户结余、形状和义务信息。
这将允许WBANK有效地开展为一个客户/账户效劳运用,而不只仅是一个账户开户引擎。
这是对一个现有运用的增强:
该运用的早期开发也是由Softprj完成。
项目代码
项目称号
客户
Xxxxxxxx
WBANK项目
WBANK公司
项目指导〔PL〕
配置控制人员〔CC〕
业务经理〔BM〕
候补PL
候补CC
BB
SB
HR
BJ
HP
项目类型
平台
阶段数
开发项目
Java、WinNT、DB2
4个阶段
项目末尾形状〔包括联机、脱机〕
项目收尾日期
估量的总支出
联机脱机
2000年4月3日2000年5月15日
2000年10月3日
XXXXXX美元
基目和客户联络人员
名字和职称
号码
号码
项目范围
●提供一种高效而快速的账户维护方法
●允许代表访问信息
●向客户代表提供账户态、价值、定单形状和买卖义务的完整视罗图
●添加更新进程的智能性
●提供一个可以显示所需账户的历史要系的接口
●提供封锁和重新激活一个账户的才干
项目对客户的境值
●该项目将允许WBANK有产地开展成一个客户账户效劳运用,而不只仅是一账户开户相擎
Softprj目的
●经过按时交付高质量的软件,增强一WBANK公司的关系
●经过开展有关WBANK产品和系统的专门知识,成为首选的软件商
向客户作出的承诺
序号
里程碑日期
里程碑
提交的结果
1
2000年5月26日
项目末尾:
需求剖析完毕
业务剖析和需求规范、用例目录、屏幕、迭代方案
2
2000年5月15-6月23日
细化阶段:
第1次迭代
顺序图、类图、源代码、下一个周期的方案
3
2000年6月26日-7月7日
细化阶段:
第2次迭代
补充规范、顺序图、类图、体系结构文档、源代码、下一个周期的迭代方案
4
2000年7月10日-7月21日
结构阶段:
第1次迭代
源代码、评审报告、测试报告、下一周期的迭代方案
5
2000年7月20日-28日
结构阶段:
第2次迭代
源代码、评审报告、测试报告、下一个周期的迭代方案
6
2000年7月31日-8月8日
结构阶段:
第3次迭代
源代码、评审报告、测试报告、下一个周期的迭代方案、产品部署方案
7
2000年8月9日-9月1日
集成测试阶段
测试方案、测试报告
8
2000年9月4日-9月15日
联机代码发行和装置
代码
9
2000年9月4日-9月22日
验收测试和产品迁移
测试报告
10
2000年9月18日-9月29日
联机协谐和回归测试
代码
11
2000年10月2日-10月26日
验收测试
测试结果
12
2000年10月27日-11月3日
新产品初次公展开出和支持
项目收尾
其他要求
序号
要求
1
该项目将遵照Rational一致方法〔RUP〕
假定
规划时作出的假定
●迁移到VisualAgeforJava3.不由该团队完成
●业务合伙人的智能更新仅与运用的维护局部结合,而不与〝账户开户〞引擎结合
●有资历的人员将同意用Rational一致进程方示完成该项目
●在项目生命期中,功用和技术需求的变卦能够会对进度发生影响。
由于这些变卦而招致对本钱或许进度的任何影
响,都将通知WBANK
●WBANK评审人员将用7天时间来收进一个里程碑文档。
假设在这时期没有收到注解,那么以为它曾经失掉同意
项目规划
项目进程
项目遵照的规范进程
该项目将遵照Softprj的规范开发进程。
但是,我们将用Rational一致进程方法〔RUP〕对这一进程停止增强,由于这是客户的要求。
为了契合RUP,将对规范的开发进程停止裁制。
进度方案
裁制备注
与规范进程的偏向
添加/修正/删除
偏向的缘由
只要那些在一次特定的迭代中将被细化验室用例
修正
基于迭代的开发
才在那次迭代中被采用
在前几次迭代中,将增量地开发逻辑对象模型
修正
遵照RUP方法
在前几次迭代中,将增量地开发物理对象模型
修正
遵照RUP方法
物理数据库设计可以在前面几次迭代中精化
修正
遵照RUP方法
在每次迭代中都要开发单元测试方案
修正
正在运用迭代方法
缺点按每次迭代停止记载
修正
正在运用迭代方示
需求跟踪将依据RequisitePro工具完成
修正
遵照RUP方法
没有图像文档和业务用例,由于我们以范围文档末尾,这所起的作用是相反的
修正
背叛RPU
需求变卦管理进程
变卦央求跟踪
●客户央求的变卦将记载在ChangeRequest.xls文档中,并剖析它们对项目的影响。
一个变卦央求
书将提交给客户以失掉他确实认。
经客户确认的变卦央求将添加到项目合同中作为
其附录
●主要变卦通常对项目的进度/按时交货有影响。
客户需求正式地同意这些变卦
●由于这是一个短期项目,假设任何一个变卦央求或许一组变卦央求超越了项目估量的任务量的2%,那么必需重新评价项目进度和任务量
估量规范
顺序/函数〔用例〕
规范
复杂用例
3个或3个以下事务
中等复杂用例
4-7个事务
复杂用例
>7个事务
用例
编号
说明
复杂性
用例
编号
说明
复杂性
1
屏幕导航
复杂
14
更新一个账户的细节
中等复杂
2
更新团体概略
中等复杂
15
维护一个账户的义务
复杂
3
添加地址
中等复杂
16
维护一个账户的备忘录
复杂
4
更新地址
复杂
17
检查集团状况的历史
复杂
5
删除地址
复杂
18
检查账户状况的历史
复杂
6
添加号码
中等复杂
19
检查选项等级和效劳选项的历史
复杂
7
更新电知号码
复杂
20
检查义务和备忘录的历史
复杂
8
删除号码
复杂
21
检查角色的历史
复杂
9
添加E-mail
中等复杂
22
检查账户细节
复杂
10
更新E-mail
中等复杂
23
检查账户的一切权
复杂
11
删除E-mail
中等复杂
24
检查一个账户的紧迫定单
复杂
12
更新一个集团的失业状况
中等复杂
25
封锁/重新激活账户
复杂
13
更新一个集团的财政状况
中等复杂
26
智能更新WBANK的商业同伴
复杂
项目估量的构建任务量
顺序/函数
任务量〔基于以往项目的数据〕
单元数
总的构建任务量〔人日〕
复杂用例
1人日
5
5
中等复杂用例
5人日
9
45
复杂用例
8人日
12
96
总任务量
146
按阶段的任务量估量
义务/阶段
人日
占总任务量的百分比〔%〕
需求
50
10
设计
60
12
构建
146
29
集成测试
35
7
回归测试
10
2
验收测试
37
6
项目管理
50
15
配置管理
16
3
培训
50
10
其他
40
6
估量的任务量
501
100
按迭代进程的任务量估量
人日
占总任务量的百分比〔%〕
项目末尾
25
5
初始阶段
24
5
细化阶段:
第1次迭代
45
9
细化阶段:
第2次迭代
34
7
结构阶段:
第1次迭代
27
5
结构阶段:
第2次迭代
24
5
结构阶段:
第3次迭代
21
4
移交阶段
110
22
项目收尾
10
2
项目管理
75
15
配置管理
16
3
培训
50
10
其他
40
8
估量的总任务量
501
100
按角色人员分配
角色
所需人数
日期
PL
1
2000年5月4日
联机协调者
1〔5%时间〕
2000年5月4日
模块指导
1
2000年5月15日
开发人员
3
2000年5月15日
开发人员
1
2000年7月17日
开发人员
1
2000年8月1日
开发人员
1
2000年8月14日
总人数
9〔实践为8.5〕
按技艺和阅历人员分配
范围
总人数
0-12人月阅历
>12个月的阅历
Java
7
7
0
DB2
2
0
2
总人数
9
7
2
人员需求方案
月份
脱机开发
联机部署
总人数
2000年5月
4
1〔50%〕
5
2000年6月
5
1
6
2000年7月
5
1
6
2000年8月
8
1
9
2000年9月
7
2
9
2000年10月
3
2
5
开发环境
硬件
软件
NTServer
WinNT
大
DB2
IntelPC
VisuageAgeforJave,Jave,WinNT
所需的硬件和软件资源
项目描画
所需数量
日期
PC〔128RAM〕
6
2000年5月1日
效劳器上有IGB空间
1
2000年5月1日
VusyageAgeforJava
6
2000年5月4日
DB2
6
2000年5月4日
RationalRose
5
2000年5月15日
RequisitePro
1
2000年5月15日
工具
工具列表
项目要开发的工具
无
项目运用的外部工具
BugsBunny,WAR
培训方案
培训范围
继续时间
免培训条件
Java言语
7天
假设曾经培训过
VisualAgeforJava
3天
作为初始培训的一局部
JavaApplets
4小时
假设曾经培训过
JavaSwing
4小时
假设曾经培训过
PersistenceBuilder
4小时
假设曾经培训过
RationalRose和RequisitePro
8小时
必需培训
OOAD
1天
假设曾经培训过
业务范围
系统评价
7天
假设曾经培训过
与进程相关的范围
质量系统
3小时
假设曾经培训过
配置管理
2小时
假设曾经接受过CC培训。
其他停止在职培训
小组评审
4小时
假设曾经培训过
缺点预防
4.5小时
必需培训
SPC工具
4.5小时
假设曾经培训过
RUP方法
2小时
必需培训
质量方案
项目质量目的
目的
值
设置目的的基础
组织范围的规范
引入的总缺点数
145
0.033个缺点/人时。
这要比Synergy好10%,后者为0.036个缺点/人时
0.052个缺点/人时
质量〔验收缺点密度〕
5
估量的总缺点数的3%或许以下
估量的总缺点数的6%
消费率
57
消费率比Synergy提高3.4%
50
进度方案
按时交货
10%
质量本钱
32%
31.5%
32%
估量检测到的缺点数
评审/测试阶段
估量检测到
的缺点数
占估量的总缺点
数的百分比〔%〕
估量基础
需求和设计评审
29
20%
参考同类项目的估量〔Synergy〕和PCB
代码评审
29
20%
参考同类项目的估量〔Synergy〕和PCB
单元测试
57
40%
参考同类项目的估量〔Synergy〕和PCB
集成和回归测试
25
17%
参考同类项目的估量〔Synergy〕和PCB
验收测试
5
3%
参考同类项目的估量〔Synergy〕和PCB
估量检测到总缺点数
143
100%
完成质量目的的战略
战略
希冀的效益
用规范的缺点预防指南和进程
停止缺点预防:
采用Synergy开
发的编码规范
缺点个入增加10-20%,消费率提高2%
小组评审前面几个或许逻辑上
复杂的用例
质量提高,由于总缺点扫除效率将提高;消费率会有所提高,由于缺点在早期被发现
项目指导、开发人员和一个顾问
共同评审设计文档或许开发的
第一个顺序
引入RUP方法,并迭代式地实
现项目。
在每次迭代后,执行里
程碑剖析和缺点预防义务
缺点引入率大约增加5%,并且总消费率提高1%
评审
评审机遇
评审条目
评审类型
项目规划完毕时
项目方案
缺点控制〔DCS〕方案
项目进度方案
小组评审
软件质量顾问〔SQA〕评审
软件质量顾问〔SQA〕评审
项目规划完毕时
CM方案
小组评审
过成90%的需求剖析时〔这必需在细化阶段的第1次迭代完毕时〕
业务剖析和需求规范文档、用例目录
小组评审
完成90%的设计时〔这必需在细化阶段的第2次迭代完毕时〕
设计文档、对象模型
小组评审
每次迭代末尾时
迭代方案
团体评审
详细设计完毕时
复杂的顺序规范和第一次
发生的顺序规范,包括测
试案例、交互图
小组评审
前面几个顺序编码以后
代码
小组评审
自我测试一个进程以后
代码
团体评审
单元测试方案完毕时
单元测试方案
团体评审
集成测试末尾时
集成测试方案
小组评审
WBANK项目的风险管理方案
序号
风险
概率
影响
风险暴
露度
风险紧张方案
1
需求客户的数据库设计师和数据库管理员的支持
0.5
8
4
细心肠规划每组义务所需的时间,并事前给予充沛的留意
联机协调者与这些小组严密协作
2
由于第一次运用RUP,团队对RUP的了解能够不片面
0.9
3
2.7
与SoftprjR&D实验室专家亲密协作在整个项目中,坚持与客户的沟通并提交任何进度或许任务量偏向
对团队停止RUP方法培训
3
人员流失:
团队成员能够暂时分开
0.3
7
2.1
分配义务时,使多团体从事项目中的每个单元和用例
4
经过链路与客户的大型机DB2通讯:
链路能够不如希冀的那样有效
0.1
8
0.8
执行额外的代码评审、桌面反省等以
使对链路的依赖最小
链路绩效下降时立刻提交
度量方案
目的
度量单位
所用的工具
规模
LOC、EP、S/M/C
行计数量
任务量
人日
WAR
缺点
缺点数
BubsBunny
进度
经过的时间
MSP
3.2义务跟踪
义务
顺序
义务调度
PL用MSProject调度义务
需求将停止精化和重新调度
义务分配
使团队成员知道最新的进度方案。
进度方案一旦上载到
WAP-MSP系统,义务将在各自的WAR中出现
义务形状跟踪
每天执行义务跟踪
项目会议
每周一次
因果剖析会议
每次迭代后
效果跟踪
效果类型
在哪里记载
谁记载
谁评审
何时评审
保果提交
联机效果
IssueTracker.xls
任何一个项目成员
PL
每天评审
2天内
客户效果
IssueLog.xls
联机团队,PL
PL
每天评审
2天内
业务经理效果
每周形状报告
BM
BM,PL,
每周评审
5天内
支持效劳效果
央求跟踪器
任何团队成员
支持效劳
每天评审
2天内
客户反应信处息
项目
记载和跟踪进程
客户反应
AM/PL处置客户反应信息。
BM保管它
客户赞扬
接到的客户赞扬将输入到CustomerComplaints.xls中,并用它停止跟踪
质量跟踪
质量任力
措施
缺点跟踪
用DCS记载缺点,并用它跟踪缺点,直到完毕
评审〔需求、概要设计、详细设计〕
依据质量方案中的项目目的停止反省
代码评审
经过SPC工具依据每个顺序的极限停止反省
独立的单元测试
经过SPC工具依据每个顺序的极限停止反省
集成测试/系统测试
依据质量方案中的项目目的停止反省
初级管理人员〔BM〕评审
序号
评审项目
评审频度
1
进度方案
每次版本变化时
2
项目方案
作出严重改动时
3
里程碑报告
里程碑完毕时
形状报告
向谁报告
报告频度
业务经理
每周周一经过电子邮件报告
客户
每周周一
里程碑处的偏向极限
实践与估量的偏向
前面5个里碑
其他里程碑
任务量
10%
5%
进度
10%
5%
缺点数
20%
20%
向客户报告
●里程碑报告和每周形状报告
●需求廓清的效果
●假设有任何需求提交的效果,那么提交它们
向BM报告
●客户反应
●里程碑和每周形状报告
●需求廓清/留意的问
●假设有任何需求提交的效果,那么提交它们
●需求变卦量及其估量的任务量
●方案的主要变卦
提交顺序
提交地点
提交期限
提交人姓名
提交人的职称
在WBANK
3天内
Xxxx
项目经理
在Softprj
3天内
Xxxx
财务经理
在Softprj
3天内
Xxxx
业务经理
项目团队
序号
姓名缩写
责任
末尾日期
希冀的完毕日期
1
BB
项目经理
2000年4月4日
2000年11月3日
2
KP
联机协调者
2000年4月4日
2000年11月3日
3
BJ
模块指导、候选项目指导
2000年5月15日
2000年11月3日
4
SP
配置控制人员
2000年5月22日
2000年10月13日
5
DD
开发人员
2000年5月22日
2000年9月29日
6
HP
开发人员,候选配置控制人员
2000年5月22日
2000年9月29日
7
NA
开发人员
2000年7月17日
2000年11月3日
8
SH
开发人员
2000年8月1日
2000年9月15日
9
AL
开发人员
2000年8月14日
2000年8月31日
10
JP
开发人员
2000年12月1日
2000年9月22日
11
SDS
财务经理
2000年4月4日
2000年11月3日
12
SR
SOA
2000年5月15日
2000年11月3日
角色和责任
角色
责任
业务经理〔BM〕
●处置提交的效果
●反省项目形状
●参与关键技术评审
客户
●评审设计
●处置提交的效果
●验收测试方案和测试
财务经理〔AM〕
●客户感到满意
●业务增长
●项目的财务方案
●销售和推销
●与培训相关的效果
●与雇员相关的效果
项目经理〔PM〕
●项目规划和调度
●设计
●客户交互
●评审
●测试
●报告
●义务分配和跟踪
●与SEPG的软件质量顾问交互
●保证按合同交付产品
●依据需求,与其他部门的交流
●保证正确地处置未处置的效果/客户赞扬
●保证项目成员失掉充沛的培训
模块指导〔ML〕
●设计
●开发
●测试
●报告
缺点预防〔DP〕
团队
●惹起团队对缺点及其预防的留意
●剖析缺点数据
●确定增加缺点引及的方法
开发人员〔DV〕
●用例的详细设计
●开发
●单元测试和集成测试
配置控制人员
〔CC〕
●预备CM方案
●依据CM方案管理配置0
SEPG的软件质
量顾问〔SQA〕
●进程顾问
●质量保证〔审计〕
联机协调者
●装置度量工具和培训项目人员
●依据需求参与项目方案的进程的评审
●处置来自客户/脱机开发的任何效果
●开发时期的支持
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 项目 管理 计划 范例