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

1、WBANK项目的收尾分析报告范例1、差不多信息项目代码Xxxx生命期业务领域金融业。基于Web的帐户治理应用项目领导/模块领导Xxxx业务经理软件质量顾咨询Xxxx2、绩效总结实际值估量值偏差偏差缘故（如果偏差大）总的工作量（人日）59750119%两个要紧的变更申请最多时的团队人数990N/A项目开始日期2000年4月2000年4月0N/A3日3日项目收尾日期2000年102000年1027天两个要紧的变更申请花月3日月30日去了5%工作量质量（已交付产品的0.0020.0125由于故障预防和增量过故障数/FP）程的作用，质量提升了生产率58572%N/A质星成本31.4%33%5%N/A故

2、障引入率0.0220.03-26%由于故障预防故障引入率减少了故障排除效率97.497小N/A3、过程细节过种裁制利用了Rational统一过程迭代式地完成开发和分析一一开发迭代3次，而设计和分析迭代2次通过RequisitePro工具实现需求跟踪4、所用的工具有关所用的工具的备外部工具：VSS、VJA、RequisitePeMSP注内部工具：BugsBunny、WAR5、风险治理项目开始时识不的风险风险1缺少客户的数据库设计师和数据库治理员的支持风险2RUP使用不正确，因为这是第一次使用风险3不员流失风险4通过链路操作客户数据的咨询题项目执行期间遇到的咨询题风险1转换到VAJ3.1的阻碍风险

3、2缺少客户的数据库设计师和数据库治理员的支持风险3RUP使用不正确，因为这是第一次使用风险4不员流失风险1:明确地表达风险有助于客户同意延迟转换以及正确地预算阻碍。风险2:提早进行认确实规划并利用联机和谐者，如此迁移策略是有效的。风险3:有效的做法是对团队进行RUP培训，并将它及时地通知客户。风险4:尽管没有具体化，但它仍旧是一个风险，阻碍可能专门小，因为每个关键任务都被及时地通知给多个人。6、规模估量的规模实际规模简单用例数量55中等复杂用例数量99复杂用例数量1212关于估量的备注最终源代码的规模用LOC进行度量。并用公布的转换表规范化成FP规模。关于Java,公布的转换表达认为21LOC

4、等于1FP,而关于COBOL,107LOC等于1FP。结果语言LOC规模EP规模Java3386516127、进度打算时期实际所花的时估量的时落后（）落后的缘故刻（天）刻（天）需求分析28.6731-6.8概要设计000.0详细设计38.842-6.7编俏132135-1.6单元测试910-9.3总构建141144-2.1集成测试40400系统测试1500.0验收测试3010200.0在客户的申请卜AT完(AT)成时刻质量成本COBOL124112COQ=（评审工作量+返工工作量+培训工作量）/总工作量X100%=（69.5+343.5+129.5+567.5+90+336.5+104.5/5

5、229.5X100%=31.4%工作量时期任务评审返工总计需求分析210.010.060.0280.0概要设计0.00.00.00.0详细设计652.014.029.5695.5编俏1188.039.576.51304.0单元测试129.50.017.0146.0集成测试567.56.0160.5734.0系统测试90.00.00.090.0验收测试336.50.00.0336.5LC时期总工作量3173.569.5343.53586.5项目治理733.10.00.0733.1培训104.50.00.0104.5CM317.00.00.0317.5其他488.50.00.0488.5总计（包括

6、治理、培训1643.00.00.01643.0和其他）总工作量（人时）4816.5069.50343.505229.50总工作量（人月）25.760.371.8427.97人工作也分布情形及头际的工作也与估也的工作也时期实际估量偏差工彳乍量-百分工作百分比偏差缘故（人比（%）量（X(%)%时）时）工作量估量过高（以往项目的数据不能提供关心，因为它没有那个时期）需求分2805.35475.01030析调计（概要设计和详细设计）编也单测试集成测695.01204.0146.5734.013.3024.942.801404569.01235.3142.5331.01226372263120设计花去了

7、更多的时刻，因为团队没有履用RationalRose和OOAD的体会大量工作量用于修复与Synergy和WindowsResixed代码和谐调期间引入的故障系统测90.01.7295.02-5试验收测336.56.43285.0618验收测试在10月3日没有试完成，并有由于客户的延蜡直连续至10月23日LC时期3586.568.583132.86614.5总计项目治733.114.02713.0153理房训104.52.00455.010-77CM317.06.06142.03123由于和谐咨询题而产生的其他488.59.34285.0671更多是由于培训而引起的偏差治理、培1643.031.

8、421595.0343.01训和其他总计总计5229.51004727.810010.6故障分布情形检测时期实际故障占发觉的总估量的故障占估量的总偏差（%）数故障数的百数数故障数的分比（%）百分比（%）需求和设计11102920-62评审代码评审58502920100单元测试15135740-73集成和系统2925251716测试验收测试3253-40总计116100145100-20显现偏差的缘故(1) 故障预防措施减少了后面时期的故障引入率，导致总体故障引入率减少。(2) 估量所基于的以往项目只进行过极少量的代码评审，同时严峻地依靠于UT(单元测试)。在那个项目中，因为更加严格和广泛地执行

9、代码评审，在评审时发觉了更多的故障，因此单元测试时发觉的故障大大地减少了。故障排除效率故障检测时期故障引入时期故障排除效率需求分析构建需求评审5100%设计评审06100%代码评审005855%(58/58+15+29+3)单元测试001532%(15/15+29+3)集成/系统测试002991%(29/29+3)验收测试003100%总的故障排除效率=113/116=97.4%故障按严峻性分布情形序号严峻性故障数总故障率(%)1装饰性故障2622.42次要故障51443要紧故障36314紧急故障32.65其他总计116序号故障类型故障数总故障数(%1逻辑3328.42标准29253绩效242

10、0.74冗余代码14125用户接口97.76体系结构43.57致性21.78重用性10.9总计36510因果分析和应吸取的教训几乎没有专门大原过程绩效偏差；实际偏差绩效与期望的绩效专门接近。关于那些大的偏差，给出偏差的同时还给出了显现偏差的缘故。应吸取的一些关键教训如下：(1) 增量式开发或者时期性开发关于实现更高的质量和生产率专门有关心，因为按照第一时期的数据确定故障预防措施，能够改进其余时期的质量和生产率。(2) 故障预防能够明显地降低故障引入率。即使从工作量上看，故障预防也能专门好地得到回报；在故障预防上投入几个小时的工作量，最多能够使以后的返工工作量减少5至10倍。(3) 如果某个变更申请有较大的阻碍，则用一个详细的阻碍分析与客户讨论，这在设置正确的期望和进行严格的成本效益分析时专门有益(这能够迫便变更延迟进行，该项目确实是延迟了变更)。(4) 代码评审和单无测试时期的故障排除效率专门低，为了改进这两个时期的效率，必须评审这两个时