WBANK项目管理计划范例

1、.：.；WBANK工程管理方案范例工程提要工程综述WBANK是一个基于美国的投资公司，该运用包括两个组成部分：一个是WBANK网站上的经纪帐户开户Brokerge Account Opening运用，它允许任何一个Internet用户开启一个WBANK经纪帐户；国一个是帐户开户和维护运用，主要是让WBANK代表对以书面格式恳求的帐户进展开户。这是一个Internet运用。该运用将提供诸如账户历史查看和账户结余、形状和义务信息。这将允许WBANK有效地开展为一个客户/账户效力运用，而不仅仅是一个账户开户引擎。这是对一个现有运用的加强：该运用的早期开发也是由Softprj完成。工程代码工程称号客户

2、XxxxxxxxWBANK工程WBANK公司工程指点PL配置控制人员CC业务经理BM候补PL候补CCBBSBHRBJHP工程类型平台阶段数开发工程Java、Win NT、DB24个阶段工程开场形状包括联机、脱机工程收尾日期估计的总收入联机 脱机2000年4月3日 2000年5月15日2000年10月3日XXX XXX美圆基目和客户联络人员名字和职称号码号码工程范围 提供一种高效而快速的账户维护方法 允许代表访问信息 向客户代表提供账户态、价值、定单形状和买卖义务的完好视罗图 添加更新过程的智能性 提供一个可以显示所需账户的历史要系的接口 提供封锁和重新激活一个账户的才干工程对客户的境值 该工程

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

4、迭代源代码、评审报告、测试报告、下一周期的迭代方案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月27日-11月3日新产品初次公开展

5、出和支持工程收尾其他要求序号要求1该工程将遵照Rational一致方法RUP假设规划时作出的假设 迁移到VisualAge for Java3.不由该团队完成 业务合伙人的智能更新仅与运用的维护部分结合，而不与“账户开户引擎结合 有资历的人员将同意用Rational一致过程方示实现该工程 在工程生命期中，功能和技术需求的变卦能够会对进度产生影响。由于这些变卦而导致对本钱或者进度的任何影响，都将通知WBANK WBANK评审人员将用7天时间来收进一个里程碑文档。假设在这期间没有收到注解，那么以为它曾经得到同意工程规划工程过程工程遵照的规范过程该工程将遵照Softprj的规范开发过程。然而，我们将

6、用Rational一致过程方法RUP对这一过程进展加强，由于这是客户的要求。为了符合RUP，将对规范的开发过程进展裁制。进度方案裁制备注与规范过程的偏向添加/修正/删除偏向的缘由只需那些在一次特定的迭代中将被细化验室用例修正基于迭代的开发才在那次迭代中被采用在前几次迭代中，将增量地开发逻辑对象模型 修正遵照RUP方法在前几次迭代中，将增量地开发物理对象模型修正遵照RUP方法物理数据库设计可以在后面几次迭代中精化修正遵照RUP方法在每次迭代中都要开发单元测试方案修正正在运用迭代方法缺点按每次迭代进展记录修正正在运用迭代方示需求跟踪将根据Requisite Pro工具完成修正遵照RUP方法没有图像

7、文档和业务用例，由于我们以范围文档开场，这所起的作用是一样的修正背叛RPU需求变卦管理过程变卦恳求跟踪 客户恳求的变卦将记录在ChangeRequest.xls文档中，并分析它们对工程的影响。一个变卦恳求 书将提交给客户以得到他确实认。经客户确认的变卦恳求将添加到工程合同中作为 其附录 主要变卦通常对工程的进度/按时交货有影响。客户需求正式地同意这些变卦 由于这是一个短期工程，假设任何一个变卦恳求或者一组变卦恳求超越了工程估计的任务量的2%，那么必需重新评价工程进度和任务量估计规范程序/函数用例规范简单用例3个或3个以下事务中等复杂用例4-7个事务复杂用例7个事务用例编号阐明复杂性用例编号阐明

8、复杂性1屏幕导航复杂14更新一个账户的细节中等复杂2更新个人概略中等复杂15维护一个账户的义务复杂3添加地址中等复杂16维护一个账户的备忘录简单4更新地址复杂17查看团体情况的历史复杂5删除地址复杂18查看账户情况的历史复杂6添加号码中等复杂19查看选项等级和效力选项的历史简单7更新电知号码复杂20查看义务和备忘录的历史简单8删除号码复杂21查看角色的历史复杂9添加中等复杂22查看账户细节简单10更新中等复杂23查看账户的一切权复杂11删除中等复杂24查看一个账户的紧迫定单复杂12更新一个团体的就业情况中等复杂25封锁/重新激活账户简单13更新一个团体的财政情况中等复杂26智能更新WBANK的

9、商业同伴复杂工程估计的构建任务量程序/函数任务量基于以往工程的数据单元数总的构建任务量人日简单用例1人日55中等复杂用例5人日945复杂用例8人日1296总任务量146按阶段的任务量估计义务/阶段人日占总任务量的百分比%需求5010设计6012构建14629集成测试357回归测试102验收测试376工程管理5015配置管理163培训5010其他406估计的任务量501100按迭代过程的任务量估计人日占总任务量的百分比%工程开场255初始阶段245细化阶段：第1次迭代459细化阶段：第2次迭代347构造阶段：第1次迭代275构造阶段：第2次迭代245构造阶段：第3次迭代214移交阶段11022工

10、程收尾102工程管理7515配置管理163培训5010其他408估计的总任务量501100按角色人员分配角色所需人数日期PL12000年5月4日联机协调者15%时间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人员需求方案月份脱机开发联机部署总人数2000年5月4150%52000年6月5162000年7月5162000年8月8192000年9月7292000

11、年10月325开发环境硬件软件NT ServerWin NT大DB2Intel PC VisuageAge for Jave,Jave, Win NT所需的硬件和软件资源工程描画所需数量日期PC128RAM62000年5月1日效力器上有IGB空间12000年5月1日VusyageAge for Java62000年5月4日DB262000年5月4日Rational Rose52000年5月15日Requisite Pro12000年5月15日工具工具列表工程要开发的工具无工程运用的内部工具BugsBunny,WAR培训方案培训领域继续时间免培训条件Java 言语7天假设曾经培训过VisualA

12、ge for Java 3天作为初始培训的一部分Java Applets4小时假设曾经培训过Java Swing4小时假设曾经培训过Persistence Builder4小时假设曾经培训过Rational Rose 和Requisite Pro8小时必需培训OOAD1天假设曾经培训过业务领域系统评价7天假设曾经培训过与过程相关的领域质量系统3小时假设曾经培训过配置管理2小时假设曾经接受过CC培训。其他进展在职培训小组评审4小时假设曾经培训过缺点预防4.5小时必需培训SPC工具4.5小时假设曾经培训过RUP方法2小时必需培训质量方案工程质量目的目的值设置目的的根底组织范围的规范引入的总缺点数1

13、450.033个缺点/人时。这要比Synergy好10%，后者为0.036个缺点/人时0.052个缺点/人时质量验收缺点密度5估计的总缺点数的3%或者以下估计的总缺点数的6%消费率57消费率比Synergy提高3.4%50进度方案按时交货10%质量本钱32%31.5%32%估计检测到的缺点数评审/测试阶段估计检测到的缺点数占估计的总缺点数的百分比%估计根底需求和设计评审2920%参考同类工程的估计Synergy和PCB代码评审2920%参考同类工程的估计Synergy和PCB单元测试5740%参考同类工程的估计Synergy和PCB集成和回归测试2517%参考同类工程的估计Synergy和PC

14、B验收测试53%参考同类工程的估计Synergy和PCB估计检测到总缺点数143100%实现质量目的的战略战略期望的效益用规范的缺点预防指南和过程进展缺点预防：采用Synergy开发的编码规范缺点个入减少10-20%，消费率提高2%小组评审前面几个或者逻辑上复杂的用例质量提高，由于总缺点排除效率将提高；消费率会有所提高，由于缺点在早期被发现工程指点、开发人员和一个顾问共同评审设计文档或者开发的第一个程序引入RUP方法，并迭代式地实现工程。在每次迭代后，执行里程碑分析和缺点预防义务缺点引入率大约减少5%，并且总消费率提高1%评审评审时机评审条目评审类型工程规划终了时工程方案缺点控制DCS方案工程

15、进度方案小组评审软件质量顾问SQA评审软件质量顾问SQA评审工程规划终了时CM方案小组评审过成90%的需求分析时这必需在细化阶段的第1次迭代终了时业务分析和需求规范文档、用例目录小组评审完成90%的设计时这必需在细化阶段的第2次迭代终了时设计文档、对象模型小组评审每次迭代开场时迭代方案个人评审详细设计终了时复杂的程序规范和第一次产生的程序规范，包括测试案例、交互图小组评审前面几个程序编码以后代码小组评审自我测试一个过程以后代码个人评审单元测试方案终了时单元测试方案个人评审集成测试开场时集成测试方案小组评审WBANK工程的风险管理方案序号风险概率影响风险暴露度风险缓和方案1需求客户的数据库设计师

16、和数据库管理员的支持0.584仔细地规划每组义务所需的时间，并事先给予充分的留意联机协调者与这些小组严密协作2由于第一次运用RUP，团队对RUP的了解能够不全面0.932.7与Softprj R&D实验室专家亲密协作在整个工程中，坚持与客户的沟通并提交任何进度或者任务量偏向对团队进展RUP方法培训3人员流失：团队成员能够暂时分开0.372.1分配义务时，使多个人从事工程中的每个单元和用例4经过链路与客户的大型机DB2通讯：链路能够不如期望的那样有效0.180.8执行额外的代码评审、桌面检查等以使对链路的依赖最小链路绩效下降时立刻提交度量方案目的度量单位所用的工具规模LOC 、EP 、S/M/C

17、行计数量任务量人日WAR缺点缺点数Bubs Bunny进度经过的时间MSP3.2 义务跟踪义务程序义务调度PL用MS Project调度义务需求将进展精化和重新调度义务分配使团队成员知道最新的进度方案。进度方案一旦上载到WAP-MSP系统，义务将在各自的WAR中出现义务形状跟踪每天执行义务跟踪工程会议每周一次因果分析会议每次迭代后问题跟踪问题类型在哪里记录谁记录谁评审何时评审保果提交联机问题Issue Tracker.xls任何一个工程成员PL每天评审2天内客户问题IssueLog.xls联机团队，PLPL每天评审2天内业务经理问题每周形状报告BMBM，PL，每周评审5天内支持效力问题恳求跟踪

18、器任何团队成员支持效力每天评审2天内客户反响信处息工程记录和跟踪过程客户反响AM/PL处置客户反响信息。BM保管它客户赞扬接到的客户赞扬将输入到CustomerComplaints.xls中，并用它进展跟踪质量跟踪质量任力措施缺点跟踪用DCS记录缺点，并用它跟踪缺点，直到终了评审需求、概要设计、详细设计根据质量方案中的工程目的进展检查代码评审经过SPC工具根据每个程序的极限进展检查独立的单元测试经过SPC工具根据每个程序的极限进展检查集成测试/系统测试根据质量方案中的工程目的进展检查高级管理人员BM评审序号评审工程评审频度1进度方案每次版本变化时2工程方案作出艰苦改动时3里程碑报告里程碑终了时

19、形状报告向谁报告报告频度业务经理每周周一经过电子邮件报告客户每周周一里程碑处的偏向极限实践与估计的偏向前面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