2022年WBANK项目收尾分析报告范例.docx

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

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

2、，质量提高了生产率58572%N/A质量成本31.4%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 使

3、用不正确，由于这是第一次使用不员流失通过链路操作客户数据的问题工程执行期间遇到的问题风险 1风险 2风险 3风险 4转换到 VAJ3.1 的影响缺少客户的数据库设计师和数据库治理员的支持RUP 使用不正确，由于这是第一次使用不员流失有关风险缓和措施的备注风险 1：明确地表达风险有助于客户同意推迟转换以及正确地预算影响；风险 2：提前进行认真的规划并利用联机和谐者，这样迁移策略是有效的；风险 3：有效的做法是对团队进行RUP 培训，并将它准时地通知客户；风险 4：虽然没有具体化，但它仍旧是一个风险，影响可能很小，由于每个关键任务都被准时地通知给多个人；6、规模估量的规模实际规模55991212简

4、洁用例数量中等复杂用例数量复杂用例数量关于估量的备注分类标准：用简洁用例、中等复杂用例和复杂用例的标准定义进行用例分类；这样的分类可以起到很好的作用；=（69.5+343.5+129.5+567.5+90+336.5+104.5）/5229.5 100%=31.4%结果语言JavaLOC 规模33 865EP 规模1612COBOL1241127、进度方案阶段实际所花的时估量的时落后落后的缘由间（天）间（%）（天）需求分析28.6731-6.8概要设计000.0具体设计38.842-6.7最终源代码的规模用 LOC 进行度量；并用公布的转换表规范化成 FP 规模；对于 Java，公布的转换表达

5、认为 21LOC 等于 1FP，而对于 COBOL ，107LOC 等于 1FP；编码132135-1.6单元测试910-9.3总构建141144-2.1集成测试40400系统测试1500.0验 收 测试3010200.0在客户的申请下AT 完（ AT）成时间质量成本COQ= （评审工作量+返工工作量+培训工作量）/ 总工作量100%工作量阶段任务评审返工总计需求分析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.

6、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总计（ 包括治理、1643.00.00.01643.0培训和其他）总工作量（人时）4816.5069.50343.505229.50总工作量（人月）25.760.371.8427.97人工作量分布情形及实际的工作量与估量的工作量阶段实际估量偏差工作量（ 人时）百分比（%）工 作 百 重量比（ 人 （%）

7、时）%偏差缘由需 求 分析2805.35475.01030工作量估量过高（以往工程的数据不能供应帮忙， 由于它没有这个阶段）调 计（ 概 要设 计 和详 细 设计）695.0 13.30 569.0 12 22 设计花去了更多的时间，因 为 团 队 没 有 使 用RationalRose 和 OOAD 的体会编码1204.024.941235.3266单测试146.52.80142.533集 成 测试734.01404331.07120大量工作量用于修复与Synergy和Windows Resixed 代码和谐调期间引入的故障系 统 测试验 收 测试90.01.7295.02-5336.56.

8、43285.0618验收测试在 10 月 3 日没有完成，并有由于客户的 延误始终连续至10 月 23 日LC 阶段总计工 程 治理3586.568.583132.86614.5733.114.02713.0153培训104.52.00455.010-77CM317.06.06142.03123由于和谐问题而产生的偏差其他488.59.34285.0671更多是由于培训而引起的偏差管培其理 、他 总1643.031.421595.0343.01总计5229.51004727.810010.6故障分布情形检测阶段实际故障占发觉的总估量的故障占 估 计 的 总偏差数故障数的百数数 故 障 数 的（

9、%）分比（ %）百分比（ %）需 求 和 设 计11102920-62评审代码评审58502920100单元测试15135740-73集 成 和 系 统2925251716测试验收测试3253-40总计116100145100-20训 和计显现偏差的缘由（ 1）故障预防措施削减了后面阶段的故障引入率，导致总体故障引入率削减；（ 2）估量所基于的以往工程只进行过极少量的代码评审，并且严峻地依靠于 UT （单元测试）；在这个工程中，由于更加严格和广泛地执行代码评审，在评审时发觉了更多的故障，所以单元测试时 发觉的故障大大地削减了；故障排除效率需求分构建析5100%06100%005855%0015

10、（58/58+15+29+3）32%（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绩效2420.74冗余代码14125用户接口97.76体系结构43.57一样性21.78重用性10.9总计365故障按类型的分布情形10 因果分

11、析和应吸取的教训几乎没有很大原过程绩效偏差；实际偏差绩效与期望的绩效特别接近；对于那些大的偏差，给出偏差的同时仍给出了显现偏差的缘由；应吸取的一些关键教训如下：（ 1）增量式开发或者阶段性开发对于实现更高的质量和生产率特别有帮忙，由于依据第一阶段的数据确定故障预防措施，可以改进其余阶段的质量和生产率；（ 2）故障预防可以显著地降低故障引入率；即使从工作量上看，故障预防也能很好地得到回报；在故障预防上投入几个小时的工作量，最多可以使以后的返工工作量削减 5 至 10 倍；（ 3）假如某个变更申请有较大的影响，就用一个具体的影响分析与客户争论，这在设置正确的期望和进行严格的成本效益分析时特别有益（这可以迫便变更推迟进行，该工程就是推迟了变更）；（ 4）代码评审和单无测试阶段的故障排除效率很低，为了改进这两个阶段的效率，必需评审这两个阶段的过程以及过程的实现；在这个工程中，系统 /集成测试补偿了评审和单元测试绩效的低下；然而，对于更大型的工程，这或许是不行能的，评审和单元测试绩 效不高可能对质量有不良的影响；11、提交的过程资源工程治理方案、工程进度方案、配置治理方案、Java 编码标准、代码评审检查表、集成方案评审检查表、影响分析检查表、故障预防的因果分析报告；