1、WBANK項目的收尾分析報告范例1、差不多信息項目代碼Xxxx生命期業(yè)務領域金融業(yè)?；赪eb的帳戶治理應用項目領導/模塊領導Xxxx業(yè)務經理軟件質量顧咨詢Xxxx2、績效總結實際值估量值偏差偏差緣故（如果偏差大）總的工作量（人日）59750119%兩個要緊的變更申請最多時的團隊人數(shù)990N/A項目開始日期2000年4月2000年4月0N/A3日3日項目收尾日期2000年102000年1027天兩個要緊的變更申請花月3日月30日去了5%工作量質量（已交付產品的0.0020.0125由于故障預防和增量過故障數(shù)/FP）程的作用，質量提升了生產率58572%N/A質星成本31.4%33%5%N/A故

2、障引入率0.0220.03-26%由于故障預防故障引入率減少了故障排除效率97.497小N/A3、過程細節(jié)過種裁制利用了Rational統(tǒng)一過程迭代式地完成開發(fā)和分析一一開發(fā)迭代3次，而設計和分析迭代2次通過RequisitePro工具實現(xiàn)需求跟蹤4、所用的工具有關所用的工具的備外部工具：VSS、VJA、RequisitePeMSP注內部工具：BugsBunny、WAR5、風險治理項目開始時識不的風險風險1缺少客戶的數(shù)據(jù)庫設計師和數(shù)據(jù)庫治理員的支持風險2RUP使用不正確，因為這是第一次使用風險3不員流失風險4通過鏈路操作客戶數(shù)據(jù)的咨詢題項目執(zhí)行期間遇到的咨詢題風險1轉換到VAJ3.1的阻礙風險

3、2缺少客戶的數(shù)據(jù)庫設計師和數(shù)據(jù)庫治理員的支持風險3RUP使用不正確，因為這是第一次使用風險4不員流失風險1:明確地表達風險有助于客戶同意延遲轉換以及正確地預算阻礙。風險2:提早進行認確實規(guī)劃并利用聯(lián)機和諧者，如此遷移策略是有效的。風險3:有效的做法是對團隊進行RUP培訓，并將它及時地通知客戶。風險4:盡管沒有具體化，但它仍舊是一個風險，阻礙可能專門小，因為每個關鍵任務都被及時地通知給多個人。6、規(guī)模估量的規(guī)模實際規(guī)模簡單用例數(shù)量55中等復雜用例數(shù)量99復雜用例數(shù)量1212關于估量的備注最終源代碼的規(guī)模用LOC進行度量。并用公布的轉換表規(guī)范化成FP規(guī)模。關于Java,公布的轉換表達認為21LOC

4、等于1FP,而關于COBOL,107LOC等于1FP。結果語言LOC規(guī)模EP規(guī)模Java3386516127、進度打算時期實際所花的時估量的時落后（）落后的緣故刻（天）刻（天）需求分析28.6731-6.8概要設計000.0詳細設計38.842-6.7編俏132135-1.6單元測試910-9.3總構建141144-2.1集成測試40400系統(tǒng)測試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系統(tǒng)測試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(%)%時）時）工作量估量過高（以往項目的數(shù)據(jù)不能提供關心，因為它沒有那個時期）需求分2805.35475.01030析調計（概要設計和詳細設計）編也單測試集成測695.01204.0146.5734.013.3024.942.801404569.01235.3142.5331.01226372263120設計花去了

7、更多的時刻，因為團隊沒有履用RationalRose和OOAD的體會大量工作量用于修復與Synergy和WindowsResixed代碼和諧調期間引入的故障系統(tǒng)測90.01.7295.02-5試驗收測336.56.43285.0618驗收測試在10月3日沒有試完成，并有由于客戶的延蠟直連續(xù)至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故障分布情形檢測時期實際故障占發(fā)覺的總估量的故障占估量的總偏差（%）數(shù)故障數(shù)的百數(shù)數(shù)故障數(shù)的分比（%）百分比（%）需求和設計11102920-62評審代碼評審58502920100單元測試15135740-73集成和系統(tǒng)2925251716測試驗收測試3253-40總計116100145100-20顯現(xiàn)偏差的緣故(1) 故障預防措施減少了后面時期的故障引入率，導致總體故障引入率減少。(2) 估量所基于的以往項目只進行過極少量的代碼評審，同時嚴峻地依靠于UT(單元測試)。在那個項目中，因為更加嚴格和廣泛地執(zhí)行

9、代碼評審，在評審時發(fā)覺了更多的故障，因此單元測試時發(fā)覺的故障大大地減少了。故障排除效率故障檢測時期故障引入時期故障排除效率需求分析構建需求評審5100%設計評審06100%代碼評審005855%(58/58+15+29+3)單元測試001532%(15/15+29+3)集成/系統(tǒng)測試002991%(29/29+3)驗收測試003100%總的故障排除效率=113/116=97.4%故障按嚴峻性分布情形序號嚴峻性故障數(shù)總故障率(%)1裝飾性故障2622.42次要故障51443要緊故障36314緊急故障32.65其他總計116序號故障類型故障數(shù)總故障數(shù)(%1邏輯3328.42標準29253績效242

10、0.74冗余代碼14125用戶接口97.76體系結構43.57致性21.78重用性10.9總計36510因果分析和應吸取的教訓幾乎沒有專門大原過程績效偏差；實際偏差績效與期望的績效專門接近。關于那些大的偏差，給出偏差的同時還給出了顯現(xiàn)偏差的緣故。應吸取的一些關鍵教訓如下：(1) 增量式開發(fā)或者時期性開發(fā)關于實現(xiàn)更高的質量和生產率專門有關心，因為按照第一時期的數(shù)據(jù)確定故障預防措施，能夠改進其余時期的質量和生產率。(2) 故障預防能夠明顯地降低故障引入率。即使從工作量上看，故障預防也能專門好地得到回報；在故障預防上投入幾個小時的工作量，最多能夠使以后的返工工作量減少5至10倍。(3) 如果某個變更申請有較大的阻礙，則用一個詳細的阻礙分析與客戶討論，這在設置正確的期望和進行嚴格的成本效益分析時專門有益(這能夠迫便變更延遲進行，該項目確實是延遲了變更)。(4) 代碼評審和單無測試時期的故障排除效率專門低，為了改進這兩個時期的效率，必須評審這兩個時