WBANK项目的收尾分析报告范例.docx

WBAN目的收尾分析报告范例 1、基本信息 项目代码 生命期 业务领域 项目领导 /模块领导 业务经理 软件质量顾问 2、绩效总结 绩效参数 总的工作量（人日） 最多时的团队人数 项目开始日期 项目收尾日期 质量（已交付产品的 故障数 /FP） 生产率 质量成本 故障引入率 Xxxx 开发期，整个生命期 金融业。 基于 Web的帐户管理应用 Xxxx Xxxx 实际值 597 9 2000 年 4 月 3 日 2000 年 10 月 3 日 0.002 58 31.4% 0.022 估计值 偏差 偏差原因 （如果偏差大） 501 19% 两个主要的变更申请 9 0 N/A 2000 年 4 月 0 N/A 3 日 2000 年 10 27 天 两个主要的变更申请花 月 30 日 去了 5%工作量 0.0125 由于故障预防和增量过 程的作用，质量提高了 57 2% N/A 33% 5% N/A 0.03 -26% 由于故障预防故障引入 率减少了 故障排除效率 97.4 97 小 N/A 3、过程细节 过种裁制 ● 利用了 Rational 统一过程 ● 迭代式地完成开发和分析——开发迭代 设计和分析迭代 2 次 ● 通过 Requisite Pro 工具实现需求跟踪 4、所用的工具 有 关 所用 的 工具的 ● 外部工具： VSS、 VJA、 Requisite 备注 ● 内部工具： BugsBunny、 WAR 5、风险管理 项目开始时识别的风险 3 次，而 Pro、 MSP 风险 1 风险 2 风险 3 风险 4 缺少客户的数据库设计师和数据库管理员的支持 RUP使用不正确，因为这是第一次使用 不员流失 通过链路操作客户数据的问题 项目执行期间遇到的问题 风险 1 风险 2 风险 3 风险 4 转换到 VAJ3.1 的影响 缺少客户的数据库设计师和数据库管理员的支持 RUP使用不正确，因为这是第一次使用 不员流失 有关风险缓和措施的备注 风险 1：明确地表达风险有助于客户同意延迟转换以及正确地预 算影响。 风险 2：提前进行仔细的规划并利用联机协调者，这样迁移策略 是有效的。 风险 3：有效的做法是对团队进行 RUP培训，并将它及时地通知 客户。 风险 4： 虽然没有具体化， 但它仍然是一个风险， 影响可能很小， 因为每个关键任务都被及时地通知给多个人。 6、规模 简单用例数量 中等复杂用例数量 复杂用例数量 估计的规模 5 9 12 实际规模 5 9 12 关于估计的备注 分类标准： 用简单用例、 中等复杂用例和复杂用例的标准定义进 行用例分类。这样的分类可以起到很好的作用。 最终源代码的规模用 LOC进行度量。 并用公布的转换表规范化成 FP 规模。对于 Java，公布的转换表达认为 21LOC等于 1FP，而对于 COBO，L 107LOC等于 1FP。 结果语言 Java COBOL 7、进度计划 阶段 LOC规模 33 865 1241 实际所花的时 估 计 的时 间（天） 间 EP规模 1612 12 落后（ %） 落后的原因 在客户的申请下 AT 在客户的申请下 AT 完 评审 10.0 0.0 14.0 39.5 0.0 任务 210.0 0.0 652.0 1188.0 129.5 返工 60.0 0.0 29.5 76.5 17.0 需求分析 28.67 概要设计 0 详细设计 38.8 编码 132 单元测试 9 总构建 141 集成测试 40 系统测试 15 验收测试（AT） 30 质量成本 COQ=（评审工作量 （天） 31 -6.