WBANK项目管理计划范例

1、WBANK项目管理计划范例项目提要项目综述WBANK是一个基于美国的投资公司，该应用包括两个组成部分：一个是WBANK网站上的经纪帐户开户（Brokerge Account Opening）应用，它允许任何一个Internet用户开启一个WBANK经纪帐户；国一个是帐户开户和维护应用，主要是让WBANK代表对以书面格式申请的帐户进行开户。这是一个Internet应用。该应用将提供诸如账户历史查看和账户结余、状态和任务信息。这将允许WBANK有效地发展为一个客户/账户服务应用，而不仅仅是一个账户开户引擎。这是对一个现有应用的增强：该应用的早期开发也是由Softprj完成。项目代码项目名称客户Xx

2、xxxxxxWBANK项目WBANK公司项目领导（PL）配置控制人员（CC）业务经理（BM）候补PL候补CCBBSBHRBJHP项目类型平台阶段数开发项目Java、Win NT、DB24个阶段项目开始状态（包括联机、脱机）项目收尾日期估计的总收入联机 脱机2000年4月3日 2000年5月15日2000年10月3日XXX XXX美元基目和客户联系人员名字和职称电话号码传真号码E-mail项目范围 提供一种高效而快速的账户维护方法 允许代表访问信息 向客户代表提供账户态、价值、定单状态和交易任务的完整视罗图 增加更新过程的智能性 提供一个能够显示所需账户的历史要系的接口 提供关闭和重新激活一个账

3、户的能力项目对客户的境值 该项目将允许WBANK有产地发展成一个客户账户服务应用，而不仅仅是一账户开户相擎Softprj目标 通过按时交付高质量的软件，增强一WBANK公司的关系 通过发展有关WBANK产品和系统的专门知识，成为首选的软件商向客户作出的承诺序号里程碑日期里程碑提交的结果12000年5月26日项目开始：需求分析结束业务分析和需求规范、用例目录、屏幕、迭代计划22000年5月15-6月23日细化阶段：第1次迭代顺序图、类图、源代码、下一个周期的计划32000年6月26日-7月7日细化阶段：第2次迭代补充规范、顺序图、类图、体系结构文档、源代码、下一个周期的迭代计划42000年7月1

4、0日-7月21日构造阶段：第1次迭代源代码、评审报告、测试报告、下一周期的迭代计划52000年7月20日-28日构造阶段：第2次迭代源代码、评审报告、测试报告、下一个周期的迭代计划62000年7月31日-8月8日构造阶段：第3次迭代源代码、评审报告、测试报告、下一个周期的迭代计划、产品部署计划72000年8月9日-9月1日集成测试阶段测试计划、测试报告82000年9月4日-9月15日联机代码发行和安装代码92000年9月4日-9月22日验收测试和产品迁移测试报告102000年9月18日-9月29日联机协调和回归测试代码112000年10月2日-10月26日验收测试测试结果122000年10月2

5、7日-11月3日新产品首次公开展出和支持项目收尾其他要求序号要求1该项目将遵循Rational统一方法（RUP）假设规划时作出的假设 迁移到VisualAge for Java3.不由该团队完成 业务合伙人的智能更新仅与应用的维护部分结合，而不与“账户开户”引擎结合 有资格的人员将批准用Rational统一过程方示实现该项目 在项目生命期中，功能和技术需求的变更可能会对进度产生影响。由于这些变更而导致对成本或者进度的任何影响，都将通知WBANK WBANK评审人员将用7天时间来收进一个里程碑文档。如果在这期间没有收到注解，则认为它已经得到批准项目规划项目过程项目遵循的标准过程该项目将遵循Sof

6、tprj的标准开发过程。然而，我们将用Rational统一过程方法（RUP）对这一过程进行增强，因为这是客户的要求。为了符合RUP，将对标准的开发过程进行裁制。进度计划裁制备注与标准过程的偏差增加/修改/删除偏差的原因只有那些在一次特定的迭代中将被细化验室用例修改基于迭代的开发才在那次迭代中被采用在前几次迭代中，将增量地开发逻辑对象模型 修改遵循RUP方法在前几次迭代中，将增量地开发物理对象模型修改遵循RUP方法物理数据库设计可以在后面几次迭代中精化修改遵循RUP方法在每次迭代中都要开发单元测试计划修改正在使用迭代方法故障按每次迭代进行记录修改正在使用迭代方示需求跟踪将根据Requisite

7、Pro工具完成修改遵循RUP方法没有图像文档和业务用例，因为我们以范围文档开始，这所起的作用是相同的修改背离RPU需求变更管理过程变更申请跟踪 客户申请的变更将记录在ChangeRequest.xls文档中，并分析它们对项目的影响。一个变更申请 书将提交给客户以得到他的确认。经客户确认的变更申请将添加到项目合同中作为 其附录 主要变更通常对项目的进度/按时交货有影响。客户需要正式地批准这些变更 因为这是一个短期项目，如果任何一个变更申请或者一组变更申请超过了项目估计的工作量的2%，则必须重新评估项目进度和工作量估计标准程序/函数（用例）标准简单用例3个或3个以下事务中等复杂用例4-7个事务复杂

8、用例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更新一个团体的就业情况中等复

9、杂25关闭/重新激活账户简单13更新一个团体的财政情况中等复杂26智能更新WBANK的商业伙伴复杂项目估计的构建工作量程序/函数工作量（基于以往项目的数据）单元数总的构建工作量（人日）简单用例1人日55中等复杂用例5人日945复杂用例8人日1296总工作量146按阶段的工作量估计任务/阶段人日占总工作量的百分比（%）需求5010设计6012构建14629集成测试357回归测试102验收测试376项目管理5015配置管理163培训5010其他406估计的工作量501100按迭代过程的工作量估计人日占总工作量的百分比（%）项目开始255初始阶段245细化阶段：第1次迭代459细化阶段：第2次迭代3

10、47构造阶段：第1次迭代275构造阶段：第2次迭代245构造阶段：第3次迭代214移交阶段11022项目收尾102项目管理7515配置管理163培训5010其他408估计的总工作量501100按角色人员分配角色所需人数日期PL12000年5月4日联机协调者1（5%时间）2000年5月4日模块领导12000年5月15日开发人员32000年5月15日开发人员12000年7月17日开发人员12000年8月1日开发人员12000年8月14日总人数9（实际为8.5）按技能和经验人员分配领域总人数0-12人月经验12个月的经验Java770DB2202总人数972人员需求计划月份脱机开发联机部署总人数20

11、00年5月41（50%）52000年6月5162000年7月5162000年8月8192000年9月7292000年10月325开发环境硬件软件NT ServerWin NT大DB2Intel PC VisuageAge for Jave,Jave, Win NT所需的硬件和软件资源项目描述所需数量日期PC（128RAM）62000年5月1日服务器上有IGB空间12000年5月1日VusyageAge for Java62000年5月4日DB262000年5月4日Rational Rose52000年5月15日Requisite Pro12000年5月15日工具工具列表项目要开发的工具无项目使

12、用的内部工具BugsBunny,WAR培训计划培训领域持续时间免培训条件Java 语言7天如果已经培训过VisualAge for Java 3天作为初始培训的一部分Java Applets4小时如果已经培训过Java Swing4小时如果已经培训过Persistence Builder4小时如果已经培训过Rational Rose 和Requisite Pro8小时必须培训OOAD1天如果已经培训过业务领域系统评估7天如果已经培训过与过程相关的领域质量系统3小时如果已经培训过配置管理2小时如果已经接受过CC培训。其他进行在职培训小组评审4小时如果已经培训过故障预防4.5小时必须培训SPC工具

13、4.5小时如果已经培训过RUP方法2小时必须培训质量计划项目质量目标目标值设置目标的基础组织范围的标准引入的总故障数1450.033个故障/人时。这要比Synergy好10%，后者为0.036个故障/人时0.052个故障/人时质量（验收故障密度）5估计的总故障数的3%或者以下估计的总故障数的6%生产率57生产率比Synergy提高3.4%50进度计划按时交货10%质量成本32%31.5%32%估计检测到的故障数评审/测试阶段估计检测到的故障数占估计的总故障数的百分比（%）估计基础需求和设计评审2920%参考同类项目的估计（Synergy）和PCB代码评审2920%参考同类项目的估计（Syner

14、gy）和PCB单元测试5740%参考同类项目的估计（Synergy）和PCB集成和回归测试2517%参考同类项目的估计（Synergy）和PCB验收测试53%参考同类项目的估计（Synergy）和PCB估计检测到总故障数143100%实现质量目标的策略策略期望的效益用标准的故障预防指南和过程进行故障预防：采用Synergy开发的编码标准故障个入减少10-20%，生产率提高2%小组评审前面几个或者逻辑上复杂的用例质量提高，因为总故障排除效率将提高；生产率会有所提高，因为故障在早期被发现项目领导、开发人员和一个顾问共同评审设计文档或者开发的第一个程序引入RUP方法，并迭代式地实现项目。在每次迭代后

15、，执行里程碑分析和故障预防任务故障引入率大约减少5%，并且总生产率提高1%评审评审时机评审条目评审类型项目规划结束时项目计划故障控制（DCS）计划项目进度计划小组评审软件质量顾问（SQA）评审软件质量顾问（SQA）评审项目规划结束时CM计划小组评审过成90%的需求分析时（这必须在细化阶段的第1次迭代结束时）业务分析和需求规范文档、用例目录小组评审完成90%的设计时（这必须在细化阶段的第2次迭代结束时）设计文档、对象模型小组评审每次迭代开始时迭代计划个人评审详细设计结束时复杂的程序规范和第一次产生的程序规范，包括测试案例、交互图小组评审前面几个程序编码以后代码小组评审自我测试一个过程以后代码个人

16、评审单元测试计划结束时单元测试计划个人评审集成测试开始时集成测试计划小组评审WBANK项目的风险管理计划序号风险概率影响风险暴露度风险缓和计划1需要客户的数据库设计师和数据库管理员的支持0.584仔细地规划每组任务所需的时间，并事先给予充分的注意联机协调者与这些小组紧密合作2因为第一次使用RUP，团队对RUP的理解可能不全面0.932.7与Softprj R&D实验室专家密切合作在整个项目中，保持与客户的沟通并提交任何进度或者工作量偏差对团队进行RUP方法培训3人员流失：团队成员可能临时离开0.372.1分配任务时，使多个人从事项目中的每个单元和用例4通过链路与客户的大型机DB2通信：链路可能

17、不如期望的那样有效0.180.8执行额外的代码评审、桌面检查等以使对链路的依赖最小链路绩效下降时立即提交度量计划指标度量单位所用的工具规模LOC 、EP 、S/M/C行计数量工作量人日WAR故障故障数Bubs Bunny进度经过的时间MSP3.2 任务跟踪任务程序任务调度PL用MS Project调度任务需要将进行精化和重新调度任务分配使团队成员知道最新的进度计划。进度计划一旦上载到WAP-MSP系统，任务将在各自的WAR中出现任务状态跟踪每天执行任务跟踪项目会议每周一次因果分析会议每次迭代后问题跟踪问题类型在哪里记录谁记录谁评审何时评审保果提交联机问题Issue Tracker.xls任何一

18、个项目成员PL每天评审2天内客户问题IssueLog.xls联机团队，PLPL每天评审2天内业务经理问题每周状态报告BMBM，PL，每周评审5天内支持服务问题申请跟踪器任何团队成员支持服务每天评审2天内客户反馈信处息项目记录和跟踪过程客户反馈AM/PL处理客户反馈信息。BM保存它客户投诉接到的客户投诉将输入到CustomerComplaints.xls中，并用它进行跟踪质量跟踪质量任力措施故障跟踪用DCS记录故障，并用它跟踪故障，直到结束评审（需求、概要设计、详细设计）根据质量计划中的项目目标进行检查代码评审通过SPC工具根据每个程序的极限进行检查独立的单元测试通过SPC工具根据每个程序的极限

19、进行检查集成测试/系统测试根据质量计划中的项目目标进行检查高级管理人员（BM）评审序号评审项目评审频度1进度计划每次版本变化时2项目计划作出重大改变时3里程碑报告里程碑结束时状态报告向谁报告报告频度业务经理每周周一通过电子邮件报告客户每周周一里程碑处的偏差极限实际与估计的偏差前面5个里碑其余里程碑工作量10%5%进度10%5%故障数20%20%向客户报告 里程碑报告和每周状态报告 需要澄清的问题 如果有任何需要提交的问题，则提交它们向BM报告 客户反馈 里程碑和每周状态报告 需要澄清/注意的问 如果有任何需要提交的问题，则提交它们 需求变更量及其估计的工作量 计划的主要变更提交程序提交地点提交期限提交人姓名提交人的职称在WBANK3天内Xxxx项目经理在Softprj3天内Xxxx财务经理在Softprj3天内Xxxx业务经理项目团队序号姓名缩写责任开始日期期望的结束日期1BB项目经理2000年 4月4日2000年11月3日2KP联机协调者2000年 4月4日2000年11月3日3BJ模块领导、候选项目领导2000年 5月15日2000年11月3日4SP配置控制人员2000年 5月22日2000年10月13日5DD开发人员2000年 5月22日20