某项目的收尾分析报告范例VIP免费

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