《WBANK项目的收尾分析报告范例》由会员分享，可在线阅读，更多相关《WBANK项目的收尾分析报告范例（10页珍藏版）》请在金锄头文库上搜索。
1、WBAN项目的收尾分析报告范例1、基本信息项目代码Xxxx生命期开发期，整个生命期业务领域金融业。基于 Web的帐户管理应用项目领导/模块领导Xxxx业务经理软件质量顾问Xxxx2、绩效总结绩效参数实际值估计值偏差偏差原因（如果偏差大）总的工作量（人日）59750119%两个主要的变更申请最多时的团队人数990N/A项目开始日期2000年4月2000年4月0N/A3日3日项目收尾日期2000 年 102000 年 1027天两个主要的变更申请花月3日月30日去了 5%工作量质量（已交付产品的由于故障预防和增量过故障数/FP）程的作用，质量提高了生产率58572%N/A质量成本%33%5%N/A
2、故障引入率-26% 由于故障预防故障引入率减少了故障排除效率97小 N/A3、过程细节过种裁制利用了 Rational统一过程迭代式地完成开发和分析一一开发迭代 3次，而设计和分析迭代2次通过Requisite Pro工具实现需求跟踪4、所用的工具有关所用的工具的备外部工具：VSS、VJA、Requisite Pro MSP注内部工具：BugsBunny、WAR5、风险管理项目开始时识别的风险风险1缺少客户的数据库设计师和数据库管理员的支持风险2RUP使用不正确，因为这是第一次使用风险3不员流失风险4通过链路操作客户数据的问题项目执行期间遇到的问题风险1转换到的影响风险2缺少客户的数据库设计师
3、和数据库管理员的支持风险3RUP使用不正确，因为这是第一次使用风险4不员流失有关风险缓和措施的备注风险1:明确地表达风险有助于客户同意延迟转换以及正确地预算影 响。风险2:提前进行仔细的规划并利用联机协调者，这样迁移策略是有 效的。风险3:有效的做法是对团队进行 RUP培训，并将它及时地通知客 户。风险4:虽然没有具体化，但它仍然是一个风险，影响可能很小，因 为每个关键任务都被及时地通知给多个人。6、规模估计的规模实际规模简单用例数量55中等复杂用例数量99复杂用例数量1212关于估计的备注分类标准：用简单用例、中等复杂用例和复杂用例的标准定义进行用 例分类。这样的分类可以起到很好的作用。最终
4、源代码的规模用LOC进行度量。并用公布的转换表规范化成 FP 规模。对于Java,公布的转换表达认为21LOC等于1FP,而对于COBOL，107LOC 等于 1FP。乡结果匚语 结果语言LOC规模EP规模Java33 8651612COBOL1241127、进度计划阶段实际所花的时估计的时落后（%）落后的原因间（天）间（天）概要设计00详细设计42编码132135单元测试910总构建141144集成测试40400系统测试150验收测试3010在客户的申请下AT完（AT）成时间质量成本COQ二(评审工作量+返工工作量+培训工作量)/总工作量X 100% =(+90+) / X100%=%工作量
5、阶段任务评审返工总计需求分析概要设计详细设计编码单元测试集成测试系统测试 验收测试偏差原因验收测试在10月3日没有 完成直并有至于 1 客户的延日LC阶段总工作量项目管理培训CM其他总计（包括管理、培训和其他）总工作量（人时）总工作量（人月）人工作量分布情况及实际的工作量与估计的工作量阶段 实际计工作量百分 工作 百分比 % （人比（%）量（人 （%）需求分280析10 30调计（概1222要设计和详丝田设计编码266单测试33集成测14047120试系统测2-5试验收测618试LC阶段66总计项目管153理工作量估计过高供以往项 因为它没有这个阶段）因为团队没有使用时间RationalRos
6、e和 OOAD 的 经验大量工作量用于修复与Synergy 禾口 Windows Resixed代码协调调期间 引入的故障时）时）培训10-77CM3123由于协调问题而产生的偏 差其他671更多是由于培训而引起的 偏差管理、34培训和其他总 计总计100100故障分布情况检测阶段实际故障数占发现的总故障数的百分比（%）估计的故障数占估计的总数故障数的百分比（%）偏差（%）需求和设计11102920-62评审代码评审58502920100单元测试15135740-73集成和系统2925251716测试验收测试3253-40总计116100145100-20出现偏差的原因（1）故障预防措施减少了
7、后面阶段的故障引入率，导致总体故障引入 率减少。（2）估计所基于的以往项目只进行过极少量的代码评审，并且严重地 依赖于UT （单元测试）。在这个项目中，因为更加严格和广泛地执行代码 评审，在评审时发现了更多的故障，所以单元测试时发现的故障大大地减 少了。故障排除效率故障检测阶段故障引入阶段故障排除效率需求分析构建需求评审5100%设计评审06100%代码评审005855%( 58/58+15+29+3)单元测试001532%( 15/15+29+3)集成/系统测试002991%( 29/29+3)验收测试003100%总的故障排除效率=113/116=%故障按严重性分布情况序号严重性故障数总故
8、障率（%）1装饰性故障262次要故障51443主要故障36314紧急故障35其他总计116故障按类型的分布情况序号故障类型故障数总故障数（%）1逻辑332标准29253绩效244冗余代码14125用户接口96体系结构47致性28重用性1总计36510因果分析和应吸取的教训几乎没有很大原过程绩效偏差；实际偏差绩效与期望的绩效非常接 近。对于那些大的偏差，给出偏差的同时还给出了出现偏差的原因。应吸 取的一些关键教训如下：（1）增量式开发或者阶段性开发对于实现更高的质量和生产率非常有 帮助，因为根据第一阶段的数据确定故障预防措施，可以改进其余阶段的 质量和生产率。（2）故障预防可以显着地降低故障引入
9、率。即使从工作量上看，故障 预防也能很好地得到回报；在故障预防上投入几个小时的工作量，最多可 以使以后的返工工作量减少5至10倍。（3）如果某个变更申请有较大的影响，则用一个详细的影响分析与客 户讨论，这在设置正确的期望和进行严格的成本效益分析时非常有益（这 可以迫便变更延迟进行，该项目就是延迟了变更）。（4）代码评审和单无测试阶段的故障排除效率很低，为了改进这两个 阶段的效率，必须评审这两个阶段的过程以及过程的实现。在这个项目中，系统/集成测试弥补了评审和单元测试绩效的低下。然而，对于更大 型的项目，这也许是不可能的，评审和单元测试绩效不高可能对质量有不 良的影响。11、提交的过程资源项目管理计划、项目进度计划、配置管理计划、Java编码标准、代码评审检查表、集成计划评审检查表、影响分析检查表、故障预防的因果分 析报告。
