WBANK项目的收尾分析报告范例(1)16119.docx

《WBANK项目的收尾分析报告范例(1)16119.docx》由会员分享，可在线阅读，更多相关《WBANK项目的收尾分析报告范例(1)16119.docx（8页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

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

2、预防和增量量过程的作作用，质量量提高了生产率58572%N/A质量成本31.4%33%5%N/A故障引入率率0.02220.03-26%由于故障预预防故障引引入率减少少了故障排除效效率97.497小N/A3、过程细细节过种裁制 利用了Raationnal统一一过程 迭代式地完完成开发和和分析开发迭代代3次，而而设计和分分析迭代22次 通过Reqquisiite PPro工具具实现需求求跟踪4、所用的的工具有关所用的的工具的备备注 外部工具：VSS、VVJA、RRequiisitee Pro、MSP 内部工具：BugssBunnny、WAAR5、风险管管理项目开始时时识别的风风险风险1风险2风险

3、3风险4缺少客户的的数据库设设计师和数数据库管理理员的支持持RUP使用用不正确，因因为这是第第一次使用用不员流失通过链路操操作客户数数据的问题题项目执行期期间遇到的的问题风险1风险2风险3风险4转换到VAAJ3.11的影响缺少客户的的数据库设设计师和数数据库管理理员的支持持RUP使用用不正确，因因为这是第第一次使用用不员流失有关风险缓缓和措施的的备注风险1：明明确地表达达风险有助助于客户同同意延迟转转换以及正正确地预算算影响。风险2：提提前进行仔仔细的规划划并利用联联机协调者者，这样迁迁移策略是是有效的。风险3：有有效的做法法是对团队队进行RUUP培训，并并将它及时时地通知客客户。风险4：虽虽

4、然没有具具体化，但但它仍然是是一个风险险，影响可可能很小，因因为每个关关键任务都都被及时地地通知给多多个人。6、规模估计的规模模实际规模简单用例数数量55中等复杂用用例数量99复杂用例数数量1212关于估计的的备注分类标准：用简单用用例、中等等复杂用例例和复杂用用例的标准准定义进行行用例分类类。这样的的分类可以以起到很好好的作用。最终源代码码的规模用用LOC进进行度量。并并用公布的的转换表规规范化成FFP规模。对对于Javva，公布布的转换表表达认为221LOCC等于1FFP，而对对于COBBOL，1107LOOC等于11FP。结果语言LOC规模模EP规模Java33 86651612COBO

5、LL1241127、进度计计划阶段实际所花的的时间（天天）估计的时间间（天）落后（%）落后的原因因需求分析28.67731-6.8概要设计000.0详细设计38.842-6.7编码132135-1.6单元测试910-9.3总构建141144-2.1集成测试40400系统测试1500.0验收测试（AAT）3010200.00在客户的申申请下ATT完成时间间质量成本COQ=（评评审工作量量+返工工工作量+培培训工作量量）/总工工作量100% =（69.5+3443.5+129.5+5667.5+90+3336.55+1044.5）/52229.5100% =31.44%工作量阶段任务评审返工总计需

6、求分析210.0010.060.0280.00概要设计0.00.00.00.0详细设计652.0014.029.5695.55编码1188.039.576.51304.0单元测试129.550.017.0146.00集成测试567.556.0160.55734.00系统测试90.00.00.090.0验收测试336.550.00.0336.55LC阶段总总工作量3173.569.5343.553586.5项目管理733.110.00.0733.11培训104.550.00.0104.55CM317.000.00.0317.55其他488.550.00.0488.55总计（包括括管理、培培训和其

7、他他）1643.00.00.01643.0总工作量（人人时）4816.5069.500343.5505229.50总工作量（人人月）25.7660.371.8427.977人工作量分分布情况及及实际的工工作量与估估计的工作作量阶段实际 估计 偏差工作量（人人时）百分比（%）工作量（人人时）百分比（%）%偏差原因需求分析2805.35475.0010300工作量估计计过高（以以往项目的的数据不能能提供帮助助，因为它它没有这个个阶段）调计（概要要设计和详详细设计）695.0013.300569.001222设计花去了了更多的时时间，因为为团队没有有使用RaationnalRoose和OOOAD的的

8、经验编码1204.024.9441235.3266单测试146.552.80142.5533集成测试734.001404331.007120大量工作量量用于修复复与Synnergyy和Winddows Resiixed代代码协调调调期间引入入的故障系统测试90.01.7295.02-5验收测试336.556.43285.00618验收测试在在10月33日没有完完成，并有有由于客户户的延误一一直延续至至10月223日LC阶段总总计3586.568.5883132.86614.5项目管理733.1114.022713.00153培训104.552.00455.0010-77CM317.006.06

9、142.003123由于协调问问题而产生生的偏差其他488.559.34285.00671更多是由于于培训而引引起的偏差差管理、培训训和其他总总计1643.031.4221595.0343.01总计5229.51004727.810010.6故障分布情情况检测阶段实际故障数数占发现的总总故障数的的百分比（%）估计的故障障数占估计的总总数故障数数的百分比比（%）偏差（%）需求和设计计评审11102920-62代码评审58502920100单元测试15135740-73集成和系统统测试2925251716验收测试3253-40总计116100145100-20出现偏差的的原因（1）故障障预防措施施

10、减少了后后面阶段的的故障引入入率，导致致总体故障障引入率减减少。（2）估计计所基于的的以往项目目只进行过过极少量的的代码评审审，并且严严重地依赖赖于UT（单单元测试）。在在这个项目目中，因为为更加严格格和广泛地地执行代码码评审，在在评审时发发现了更多多的故障，所所以单元测测试时发现现的故障大大大地减少少了。故障排除效效率故障检测阶阶段故障引入阶阶段故障排除效效率需求分析构建需求评审5100%设计评审06100%代码评审005855%（558/588+15+29+33）单元测试001532%（115/155+29+3）集成/系统统测试002991%（229/299+3）验收测试003100%总的

11、故障排排除效率=113/116=97.44%故障按严重重性分布情情况序号严重性故障数总故障率（%）1装饰性故障障2622.42次要故障51443主要故障36314紧急故障32.65其他总计116故障按类型型的分布情情况序号故障类型故障数总故障数（%）1逻辑3328.42标准29253绩效2420.74冗余代码14125用户接口97.76体系结构43.57一致性21.78重用性10.9总计36510 因果果分析和应应吸取的教教训几乎没有很很大原过程程绩效偏差差；实际偏偏差绩效与与期望的绩绩效非常接接近。对于于那些大的的偏差，给给出偏差的的同时还给给出了出现现偏差的原原因。应吸吸取的一些些关键教训

12、训如下：（1）增量量式开发或或者阶段性性开发对于于实现更高高的质量和和生产率非非常有帮助助，因为根根据第一阶阶段的数据据确定故障障预防措施施，可以改改进其余阶阶段的质量量和生产率率。（2）故障障预防可以以显著地降降低故障引引入率。即即使从工作作量上看，故故障预防也也能很好地地得到回报报；在故障障预防上投投入几个小小时的工作作量，最多多可以使以以后的返工工工作量减减少5至110倍。（3）如果果某个变更更申请有较较大的影响响，则用一一个详细的的影响分析析与客户讨讨论，这在在设置正确确的期望和和进行严格格的成本效效益分析时时非常有益益（这可以以迫便变更更延迟进行行，该项目目就是延迟迟了变更）。（4）代码码评审和单单无测试阶阶段的故障障排除效率率很低，为为了改进这这两个阶段段的效率，必必须评审这这两个阶段段的过程以以及过程的的实现。在在这个项目目中，系统统/集成测测试弥补了了评审和单单元测试绩绩效的低下下。然而，对对于更大型型的项目，这这也许是不不可能的，评评审和单元元测试绩效效不高可能能对质量有有不良的影影响。11、提交交的过程资资源项目管理计计划、项目目进度计划划、配置管管理计划、JJava编码码标准、代代码评审检检查表、集集成计划评评审检查表表、影响分分析检查表表、故障预预防的因果果分析报告告。