WBANK项目管理计划范例.docx
《WBANK项目管理计划范例.docx》由会员分享，可在线阅读，更多相关《WBANK项目管理计划范例.docx（22页珍藏版）》请在冰点文库上搜索。
WBANK项目管理计划范例
WBANK项目管理计划例
项目提要
项目综述
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美元
基目和客户联系人员
名字和职称
传真
E-mail
项目围
●提供一种高效而快速的账户维护方法
●允许代表访问信息
●向客户代表提供账户态、价值、定单状态和交易任务的完整视罗图
●增加更新过程的智能性
●提供一个能够显示所需账户的历史要系的接口
●提供关闭和重新激活一个账户的能力
项目对客户的境值
●该项目将允许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）
●过程顾问
●质量保证（审计）
联机协调者
●安装度量工具和培训项目人员
●根据需要参与项目计划的过程的评审
●解决来自客户/脱机开发的任何问题
●开发期间的支持
升级会员 