项目策划管理计划范例

1、WBNK项目治理打算范例项目提要项目综述WBANK是一个基于美国的投资公司,该应用包括两个组成部分:一个是WBANK网站上的经纪帐户开户（Brerge AccntOnng)应用,它同意任何一个ternet用户开启一个WBAK经纪帐户;国一个是帐户开户和维护应用,要紧是让BANK代表对以书面格式申请的帐户进行开户。这是一个Internet应用。该应用将提供诸如账户历史查看和账户结余、状态和任务信息。这将同意WBNK有效地进展为一个客户/账户服务应用，而不仅仅是一个账户开户引擎。这是对一个现有应用的增强：该应用的早期开发也是由Softpj完成。项目代码项目名称客户XxxxxWBAN项目BANK公司

2、项目领导（P)配置操纵人员(CC）业务经理(BM)候补PL候补BBSBHRBJP项目类型平台时期数开发项目Ja、Wn N、D2个时期项目开始状态（包括联机、脱机）项目收尾日期可能的总收入联机 脱机200年4月日 2000年5月15日000年1月日XXX XX美元基目和客户联系人员名字和职称电话号码传真号码E-l项目范围 提供一种高效而快速的账户维护方法 同意代表访问信息 向客户代表提供账户态、价值、定单状态和交易任务的完整视罗图 增加更新过程的智能性 提供一个能够显示所需账户的历史要系的接口 提供关闭和重新激活一个账户的能力项目对客户的境值 该项目将同意BANK有产地进展成一个客户账户服务应用

3、,而不仅仅是一账户开户相擎tj目标 通过按时交付高质量的软件，增强一BANK公司的关系 通过进展有关WBNK产品和系统的专门知识，成为首选的软件商向客户作出的承诺序号里程碑日期里程碑提交的结果1000年5月2日项目开始:需求分析结束业务分析和需求规范、用例目录、屏幕、迭代打算2200年5月156月日细化时期:第1次迭代顺序图、类图、源代码、下一个周期的打算3200年月26日-7月7日细化时期：第2次迭代补充规范、顺序图、类图、体系结构文档、源代码、下一个周期的迭代打算400年7月10日-月21日构造时期:第1次迭代源代码、评审报告、测试报告、下一周期的迭代打算5200年7月20日28日构造时期

4、:第2次迭代源代码、评审报告、测试报告、下一个周期的迭代打算000年月3日8月8日构造时期:第3次迭代源代码、评审报告、测试报告、下一个周期的迭代打算、产品部署打算700年8月9日-9月日集成测试时期测试打算、测试报告8000年9月4日-月5日联机代码发行和安装代码9200年9月4日9月22日验收测试和产品迁移测试报告10200年9月18日9月2日联机协调和回归测试代码11200年10月2日-10月2日验收测试测试结果120年10月27日-1月日新产品首次公开展出和支持项目收尾其他要求序号要求1该项目将遵循tiona统一方法(RUP)假设规划时作出的假设迁移到saAge or Java3不由该

5、团队完成业务合伙人的智能更新仅与应用的维护部分结合,而不与“账户开户”引擎结合 有资格的人员将批准用Ratinl统一过程方示实现该项目 在项目生命期中,功能和技术需求的变更可能会对进度产生阻碍。由于这些变更而导致对成本或者进度的任何影响，都将通知WBNK ANK评审人员将用7天时刻来收进一个里程碑文档。假如在这期间没有收到注解,则认为它差不多得到批准项目规划项目过程项目遵循的标准过程该项目将遵循Sotpj的标准开发过程。然而，我们将用Raoal统一过程方法（RUP)对这一过程进行增强，因为这是客户的要求。为了符合RU,将对标准的开发过程进行裁制。进度打算裁制备注与标准过程的偏差增加/修改/删除

6、偏差的缘故只有那些在一次特定的迭代中将被细化验室用例修改基于迭代的开发才在那次迭代中被采纳在前几次迭代中，将增量地开发逻辑对象模型 修改遵循RU方法在前几次迭代中,将增量地开发物理对象模型修改遵循RP方法物理数据库设计能够在后面几次迭代中精化修改遵循方法在每次迭代中都要开发单元测试打算修改正在使用迭代方法故障按每次迭代进行记录修改正在使用迭代方示需求跟踪将依照Requi Pro工具完成修改遵循RP方法没有图像文档和业务用例，因为我们以范围文档开始,这所起的作用是相同的修改背离RPU需求变更治理过程变更申请跟踪客户申请的变更将记录在CangeReuestxs文档中，并分析它们对项目的阻碍。一个变

7、更申请 书将提交给客户以得到他的确认。经客户确认的变更申请将添加到项目合同中作为 其附录 要紧变更通常对项目的进度/按时交货有阻碍。客户需要正式地批准这些变更 因为这是一个短期项目,假如任何一个变更申请或者一组变更申请超过了项目可能的工作量的2%,则必须重新评估项目进度和工作量可能标准程序/函数(用例)标准简单用例3个或3个以下事务中等复杂用例4-个事务复杂用例7个事务用例编号讲明复杂性用例编号讲明复杂性屏幕导航复杂14更新一个账户的细节中等复杂2更新个人详情中等复杂15维护一个账户的任务复杂3增加地址中等复杂16维护一个账户的备忘录简单4更新地址复杂17查看团体情况的历史复杂删除地址复杂1查

8、看账户情况的历史复杂6添加电话号码中等复杂19查看选项等级和服务选项的历史简单7更新电知号码复杂查看任务和备忘录的历史简单8删除电话号码复杂21查看角色的历史复杂9添加mail中等复杂22查看账户细节简单10更新E-m中等复杂23查看账户的所有权复杂11删除E-al中等复杂4查看一个账户的紧迫定单复杂12更新一个团体的就业情况中等复杂5关闭重新激活账户简单13更新一个团体的财政情况中等复杂26智能更新WBANK的商业伙伴复杂项目可能的构建工作量程序/函数工作量（基于以往项目的数据)单元数总的构建工作量(人日)简单用例1人日5中等复杂用例5人日94复杂用例8人日12总工作量6按时期的工作量可能任

9、务/时期人日占总工作量的百分比（）需求501设计601构建1462集成测试357回归测试102验收测试376项目治理515配置治理3培训5010其他06可能的工作量501100按迭代过程的工作量可能人日占总工作量的百分比（%)项目开始55初始时期245细化时期:第次迭代459细化时期：第2次迭代37构造时期:第1次迭代75构造时期:第2次迭代25构造时期：第3次迭代214移交时期1102项目收尾102项目治理7515配置治理13培训5010其他408可能的总工作量50100按角色人员分配角色所需人数日期PL12000年月日联机协调者（%时刻)200年5月4日模块领导12年5月15日开发人员30

10、00年5月1日开发人员100年7月17日开发人员1000年8月日开发人员2000年8月日总人数9(实际为8.5）按技能和经验人员分配领域总人数-人月经验12个月的经验a0DB20总人数972人员需求打算月份脱机开发联机部署总人数2000年月41（5%)5200年6月200年7月516200年8月892000年9月7292000年10月3开发环境硬件软件NT ervrWin 大BIntel PC isuageAge forae,ave， Win T所需的硬件和软件资源项目描述所需数量日期PC（128RM)62000年5月1日服务器上有IGB空间120年月1日usyeAge foJva20年5月4

11、日B2600年5月日RionaRose2000年5月15日Reuse o12000年5月1日工具工具列表项目要开发的工具无项目使用的内部工具Bgunn,WA培训打算培训领域持续时刻免培训条件aa 语言7天假如差不多培训过Vsulefo av 3天作为初始培训的一部分ava Aplets4小时假如差不多培训过Jaa Swig4小时假如差不多培训过esistnce Bilder4小时假如差不多培训过atinal ose 和Reqie Pr8小时必须培训OD1天假如差不多培训过业务领域系统评估7天假如差不多培训过与过程相关的领域质量系统3小时假如差不多培训过配置治理2小时假如差不多同意过C培训。其他

12、进行在职培训小组评审4小时假如差不多培训过故障预防45小时必须培训SPC工具4.5小时假如差不多培训过方法2小时必须培训质量打算项目质量目标目标值设置目标的基础组织范围的标准引入的总故障数10.033个故障/人时。这要比Synergy好0%,后者为0.36个故障/人时0.052个故障/人时质量（验收故障密度）可能的总故障数的3%或者以下可能的总故障数的6%生产率57生产率比Synergy提高3.4%50进度打算按时交货10质量成本32%1.5%32%可能检测到的故障数评审/测试时期可能检测到的故障数占可能的总故障数的百分比(）可能基础需求和设计评审2920%参考同类项目的可能（Syngy）和P

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

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

15、后代码个人评审单元测试打算结束时单元测试打算个人评审集成测试开始时集成测试打算小组评审WBA项目的风险治理打算序号风险概率阻碍风险暴露度风险缓和打算需要客户的数据库设计师和数据库治理员的支持0.584认真地规划每组任务所需的时刻,并事先给予充分的注意联机协调者与这些小组紧密合作2因为第一次使用RUP，团队对RU的理解可能不全面0.932.7与SoftprjR&D实验室专家紧密合作在整个项目中,保持与客户的沟通并提交任何进度或者工作量偏差对团队进行RUP方法培训人员流失:团队成员可能临时离开0.37.1分配任务时，使多个人从事项目中的每个单元和用例4通过链路与客户的大型机2通信:链路可能不如期望

16、的那样有效0.8.8执行额外的代码评审、桌面检查等以使对链路的依靠最小链路绩效下降时立即提交度量打算指标度量单位所用的工具规模LOC 、EP 、S/行计数量工作量人日WAR故障故障数Bubs Bunny进度通过的时刻MSP3.2 任务跟踪任务程序任务调度PL用SProject调度任务需要将进行精化和重新调度任务分配使团队成员明白最新的进度打算。进度打算一旦上载到W-MSP系统,任务将在各自的AR中出现任务状态跟踪每天执行任务跟踪项目会议每周一次因果分析会议每次迭代后问题跟踪问题类型在哪里记录谁记录谁评审何时评审保果提交联机问题Isue Tracer.xs任何一个项目成员PL每天评审2天内客户问

17、题Issueog.xls联机团队,PL每天评审2天内业务经理问题每周状态报告BMBM,PL，每周评审5天内支持服务问题申请跟踪器任何团队成员支持服务每天评审2天内客户反馈信处息项目记录和跟踪过程客户反馈M/L处理客户反馈信息。M保存它客户投诉接到的客户投诉将输入到ustomerCoplit.xls中，并用它进行跟踪质量跟踪质量任力措施故障跟踪用记录故障,并用它跟踪故障,直到结束评审(需求、概要设计、详细设计)依照质量打算中的项目目标进行检查代码评审通过SPC工具依照每个程序的极限进行检查独立的单元测试通过S工具依照每个程序的极限进行检查集成测试/系统测试依照质量打算中的项目目标进行检查高级治理

18、人员()评审序号评审项目评审频度1进度打算每次版本变化时项目打算作出重大改变时3里程碑报告里程碑结束时状态报告向谁报告报告频度业务经理每周周一通过电子邮件报告客户每周周一里程碑处的偏差极限实际与可能的偏差前面5个里碑其余里程碑工作量0%5进度0%5%故障数0%20%向客户报告里程碑报告和每周状态报告 需要澄清的问题 假如有任何需要提交的问题，则提交它们向B报告 客户反馈 里程碑和每周状态报告 需要澄清注意的问 假如有任何需要提交的问题，则提交它们 需求变更量及其可能的工作量打算的要紧变更提交程序提交地点提交期限提交人姓名提交人的职称在BANK天内Xxxx项目经理在Softj3天内xx财务经理在Stpr3天内Xxxx业务经理项目团队序号姓名缩写责任开始日期期望的结束日期1B项目经理20年4月日2000年11月3日2K联机协调者200年4月日2000年1月日BJ模块领导、候选项目领导年 5月15日200年11月3日4SP配置操纵人员200年 5月2日20年0月1