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

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

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

3、问题风险1转换到VAJ3.1的影响风险2缺少客户的数据库设计师和数据库管理员的支持风险3RUP使用不正确，因为这是第一次使用风险4不员流失有关风险缓和措施的备注风险1明确地表达风险有助于客户同意延迟转换以及正确地预 算影响。风险2:提前进行仔细的规划并利用联机协调者，这样迁移策略 是有效的。风险3:有效的做法是对团队进行 RUP培训，并将它及时地通知 客户。风险4：虽然没有具体化，但它仍然是一个风险，影响可能很小, 因为每个关键任务都被及时地通知给多个人。6、规模估计的规模实际规模简单用例数量55中等复杂用例数量99复杂用例数量1212关于估计的备注分类标准：用简单用例、中等复杂用例和复杂用例

4、的标准定义进 行用例分类。这样的分类可以起到很好的作用。最终源代码的规模用LOCS行度量。并用公布的转换表规范化成 FP规模。对于Java，公布的转换表达认为21LOC等于1FP,而对于 COBQL 107LOC等 于 1FF。乡结果匚语 结果语言LOC规模EP规模Java33 8651612COBOL1241127、进度计划阶段实际所花的时估计的时落后（% 落后的原因间（天）间(天)需求分析28.6731-6.8概要设计000.0详细设计38.842-6.7编码132135-1.6单元测试910-9.3总构建141144-2.1集成测试40400系统测试1500.0验收测试（AT）30102

5、00.0在客户的申请下AT完成时间质量成本COQ（评审工作量+ 返工工作量+培训工作量）/总工作量X 100%=(69.5+343.5+129.5+567.5+90+336.5+104.5 ) /5229.5 X100%=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阶段总工作量

6、3173.569.5343.53586.5项目管理733.10.00.0733.1培训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工作量估计过高（以往项析目的数扌据不能?提供帮助，因为

7、它没有这个阶段）调计（概695.013.30569.01222设计花去了更多的时间，要设计因为团队没有使用和详细Ratio nalRose和OOAD 勺设计）经验编码1204.024.941235.3266单测试146.52.80142.533集成测734.01404331.07120大量工作量用于修复与试Syn ergy禾口Win dowsResixed代码协调调期间引入的故障系试验试统测90.01.7295.02收测336.56.43285.06项目管733.114.02713.015理培训104.52.00455.010CM317.06.06142.03其他488.59.34285.06

8、管理、培1643.031.421595.034训II和其他A总计总计5229.51004727.8100LC 阶段 3586.5 68.58 3132.8 66 总计-518验收测试在10月3日没有完成，并有由于客户的延 误一直延续至10月23日14.53-77123由于协调问题而产生的偏差71更多是由于培训而引起的偏差3.0110.6故障分布情况检测阶段实际故障 占发现的总 估计的故障 占估计的总 偏差（咧数故障数的百数数故障数的分比（%百分比（%需求和设计11102920-62评审代码评审58502920100单元测试15135740-73集成和系统2925251716测试验收测试3253

9、-40总计116100145100-20出现偏差的原因（1）故障预防措施减少了后面阶段的故障引入率，导致总体故 障引入率减少。（2）估计所基于的以往项目只进行过极少量的代码评审，并且 严重地依赖于UT（单元测试）。在这个项目中，因为更加严格和广泛 地执行代码评审，在评审时发现了更多的故障，所以单元测试时发现 的故障大大地减少了。故障排除效率故障检测阶段故障引入阶段故障排除效率需求E分构建析需求评审5100%设计评审06100%代码评审005855% (58/58+15+29+3)单元测试001532% (15/15+29+3)集成/系统测002991% (29/29+3)试验收测试003100

10、%总的故障排除效率=113/116=97.4%故障按严重性分布情况序号严重性故障数总故障率（%1装饰性故障2622.42次要故障51443主要故障36314紧急故障32.65其他116总计故障按类型的分布情况序号故障类型故障数总故障数（%1逻辑3328.42标准29253绩效2420.74冗余代码14125用户接口97.76体系结构43.57致性21.78重用性10.9总计36510因果分析和应吸取的教训几乎没有很大原过程绩效偏差；实际偏差绩效与期望的绩效非常 接近。对于那些大的偏差，给出偏差的同时还给出了出现偏差的原因。 应吸取的一些关键教训如下：（1）增量式开发或者阶段性开发对于实现更高的质量和生产率 非常有帮助，因为根据第一阶段的数据确定故障预防措施， 可以改进 其余阶段的质量和生产率。（2）故障预防可以显着地降低故障引入率。 即使从工作量上看， 故障预防也能很好地得到回报；在故障预防上投入几个小时的工作量，最多可以使以后的返工工作量减少 5至10倍。（3）如果某个变更申请有较大的影响，则用一个详细的影响分 析与客户讨论，这在设置正确的期望和进行严格的成本效益分析时非 常有益（这可以迫便变更延迟进行，该项目就是延迟了变更） 。（4）代码评审和单无测试阶段的故障排除效率很低，为了改进 这两个阶段的效率，必须评审这两个阶段的