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

1、.：.；WBANK工程的收尾分析报告范例1、根本信息 工程代码Xxxx生命期开发期，整个生命期业务领域金融业。基于Web的帐户管理运用工程指点/模块指点Xxxx业务经理软件质量顾问Xxxx2、绩效总结绩效参数实践值估计值偏向偏向缘由假设偏向大总的任务量人日59750119%两个主要的变卦恳求最多时的团队人数990N/A工程开场日期2000年4月3日2000年4月3日0N/A工程收尾日期2000年10月3日2000年10月30日27天两个主要的变卦恳求花去了5%任务量质量已交付产品的缺点数/FP0.0020.0125由于缺点预防和增量过程的作用，质量提高了消费率58572%N/A质量本钱31.4

2、%33%5%N/A缺点引入率0.0220.03-26%由于缺点预防缺点引入率减少了缺点排除效率97.497小N/A3、过程细节过种裁制利用了Rational一致过程迭代式地完成开发和分析开发迭代3次，而设计和分析迭代2次经过Requisite Pro工具实现需求跟踪4、所用的工具有关所用的工具的备注外部工具：VSS、VJA、Requisite Pro、MSP内部工具：BugsBunny、WAR5、风险管理工程开场时识别的风险风险1风险2风险3风险4短少客户的数据库设计师和数据库管理员的支持RUP运用不正确，由于这是第一次运用不员流失经过链路操作客户数据的问题工程执行期间遇到的问题风险1风险2风

3、险3风险4转换到VAJ3.1的影响短少客户的数据库设计师和数据库管理员的支持RUP运用不正确，由于这是第一次运用不员流失有关风险缓和措施的备注风险1：明确地表达风险有助于客户赞同延迟转换以及正确地预算影响。风险2：提早进展仔细的规划并利用联机协调者，这样迁移战略是有效的。风险3：有效的做法是对团队进展RUP培训，并将它及时地通知客户。风险4：虽然没有详细化，但它依然是一个风险，影响能够很小，由于每个关键义务都被及时地通知给多个人。6、规模估计的规模实践规模简单用例数量55中等复杂用例数量99复杂用例数量1212关于估计的备注分类规范：用简单用例、中等复杂用例和复杂用例的规范定义进展用例分类。这

4、样的分类可以起到很好的作用。最终源代码的规模用LOC进展度量。并用公布的转换表规范化成FP规模。对于Java，公布的转换表达以为21LOC等于1FP，而对于COBOL，107LOC等于1FP。结果言语LOC规模EP规模Java33 8651612COBOL1241127、进度方案阶段实践所花的时间天估计的时间天落后%落后的缘由需求分析28.6731-6.8概要设计000.0详细设计38.842-6.7编码132-1.6单元测试910-9.3总构建141144-2.1集成测试40400系统测试1500.0验收测试AT3010200.0在客户的恳求下AT完成时间质量本钱COQ=评审任务量+返工任务

5、量+培训任务量/总任务量100% =69.5+343.5+129.5+567.5+90+336.5+104.5/5229.5100% =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培训

6、104.50.00.0104.5CM317.00.00.0317.5其他488.50.00.0488.5总计包括管理、培训和其他1643.00.00.01643.0总任务量人时4816.5069.50343.505229.50总任务量人月25.760.371.8427.97人任务量分布情况及实践的任务量与估计的任务量阶段实践 估计 偏向任务量人时百分比%任务量人时百分比%偏向缘由需求分析2805.35475.01030任务量估计过高以往工程的数据不能提供协助 ，由于它没有这个阶段调计概要设计和详细设计695.013.30569.01222设计花去了更多的时间，由于团队没有运用RationalR

7、ose和OOAD的阅历编码1204.024.941235.3266单测试146.52.80142.533集成测试734.01404331.07120大量任务量用于修复与Synergy和Windows Resixed代码协调调期间引入的缺点系统测试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由于协调问题而产生的偏向其他

8、488.59.34285.0671更多是由于培训而引起的偏向管理、培训和其他总计1643.031.421595.0343.01总计5229.51004727.810010.6缺点分布情况检测阶段实践缺点数占发现的总缺点数的百分比%估计的缺点数占估计的总数缺点数的百分比%偏向%需求和设计评审11102920-62代码评审58502920100单元测试15135740-73集成和系统测试2925251716验收测试3253-40总计116100145100-20出现偏向的缘由1缺点预防措施减少了后面阶段的缺点引入率，导致总体缺点引入率减少。2估计所基于的以往工程只进展过极少量的代码评审，并且严重地

9、依赖于UT单元测试。在这个工程中，由于更加严厉和广泛地执行代码评审，在评审时发现了更多的缺点，所以单元测试时发现的缺点大大地减少了。缺点排除效率缺点检测阶段缺点引入阶段缺点排除效率需求分析构建需求评审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缺点按类型的分布情况序号缺点类型

10、缺点数总缺点数%1逻辑3328.42规范29253绩效2420.74冗余代码14125用户接口97.76体系构造43.57一致性21.78重用性10.9总计36510 因果分析和应汲取的教训几乎没有很大原过程绩效偏向；实践偏向绩效与期望的绩效非常接近。对于那些大的偏向，给出偏向的同时还给出了出现偏向的缘由。应汲取的一些关键教训如下：1增量式开发或者阶段性开发对于实现更高的质量和消费率非常有协助 ，由于根据第一阶段的数据确定缺点预防措施，可以改良其他阶段的质量和消费率。2缺点预防可以显著地降低缺点引入率。即使从任务量上看，缺点预防也能很好地得到报答；在缺点预防上投入几个小时的任务量，最多可以使以后的返工任务量减少5至10倍。3假设某个变卦恳求有较大的影响，那么用一个详细的影响分析与客户讨论，这在设置正确的期望和进展严厉的本钱效益分析时非常有益这可以迫便变卦延迟进展，该工程就是延迟了变卦。4代码评审和单无测试阶段的缺点排除效率很低，为了改良这两个阶段的效率，必需评审这两个