WBANK項目的收尾分析報告范例

1、WBAN頌目的收尾分析報告范例1、根本信息開發(fā)期,整個生命期業(yè)務領域金融業(yè).基于 Web的帳戶治理應用工程領導/模塊領導Xxxx業(yè)務經理軟件質量參謀Xxxx工程代碼Xxxx2、績效總結績效參數實際值估計值偏差原因如果偏差大總的工作量人日59750119%兩個主要的變更申請最多時的團隊人數990N/A工程開始日期2000年4月2000年4月0N/A3日3日工程收尾日期2000 年 102000 年 1027天兩個主要的變更申請花月3日月30日去了 5%工作量質量已交付產品的0.0020.0125由于故障預防和增量過故障數/FP程的作用,質量提升了生產率58572%N/A質量本錢31.4%33%5

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

3、J3.1的影響風險2缺少客戶的數據庫設計師和數據庫治理員的支持風險3RUP使用不正確,由于這是第一次使用風險4不員流失風險1:明確地表達風險有助于客戶同意延遲轉換以及正確地預算影響.風險2:提前進行仔細的規(guī)劃并利用聯機協(xié)調者, 這樣遷移策略是有效的.風險3:有效的做法是對團隊進行 RUP培訓,并將它及時地通知客戶.風險4:雖然沒有具體化,但它仍然是一個風險,影響可能很小,由于每 個關鍵任務都被及時地通知給多個人.6、規(guī)模估計的規(guī)模實際規(guī)模55中等復雜用例數量99復雜用例數量1212關于估計的備注分類標準：用簡單用例、中等復雜用例和復雜用例的標準定義進行用例分 類.這樣的分類可以起到很好的作用.

4、最終源代碼的規(guī)模用LOC進行度量.并用公布的轉換表標準化成FP規(guī)模. 對于Java公布的轉換表達認為 21LOC等于1FP,而又t于COBOL, 107LOC 等于1FP.結果語言LOC規(guī)模EP規(guī)模Java33 8651612COBOL1241127、進度方案階段實際所花的時估計的時落后落后的原因間天間天需求分析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)成時間質量本錢COQ=評審工作量+返工工作量+培訓工作

5、量/總工作量X 100% =69.5+343.5+129.5+567.5+90+336.5+104.5 /5229.5X 100% =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培訓1

6、04.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人工作量分布情況及實際的工作量與估計的工作量偏差分 求 需析概計細1 1 狽狽 統(tǒng)收 系試驗試LC階段總計工程管理 培訓CM其他工作某月分工作白分比 人比量人 時時2805.35475.010 30695.013.30569.012%偏差原因22工作量估計過高以往項 目的數據不能提供幫助, 由于它沒有這個階段由于團隊沒看使用R

7、ationalRose和 OOAD 的1204.0146.5734.024.942.8014041235.3142.5331.0263763120大量工作量用于修復與Synergy 和 WindowsResixed代碼協(xié)調調期間 引入的故障90.01.7295.0-5336.56.43285.018驗收測試在10月3日沒有 完成,并有由于客戶的延 誤一直延續(xù)至10月23日3586.568.583132.86614.5733.114.02713.015104.5317.02.006.06455.014259.34285.071由于協(xié)調問題而產生的偏：更多是由于培訓而

8、引起的 偏差治理、培 1643.0 31.421595.0 343.01訓和加總計總計 5229.5 1004727.8 10010.6故障分布情況檢測階段實際故障占發(fā)現的總估計的故障估的總(%)數故障數的百數數故障數的分比(%)百分比(%)需求和設計11102920-62評審代碼評審58502920100單元測試15135740-73集成和系統(tǒng)2925251716測試驗收測試3253-40總計116100145100-20出現偏差的原因(1)故障預防舉措減少了后面階段的故障引入率,導致總體故障引入率 減少.(2)估計所基于的以往工程只進行過極少量的代碼評審,并且嚴重地依 賴于UT (單元測試

9、).在這個工程中,由于更加嚴格和廣泛地執(zhí)行代碼評審, 在評審時發(fā)現了更多的故障,所以單元測試時發(fā)現的故障大大地減少了.故障排除效率故障檢測階段故障引入階段故障排除效率100%需求分析 構建需求評審設計評審06100%代碼評審005855% (58/58+15+29+3)單元測試001532% (15/15+29+3)集成/系統(tǒng)測試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.5致性8 重用性1.70.9總計36510幾乎沒有很大原過程績效偏差；實際偏差績效與期望的績效非常接近. 對 于那些大的偏差,給出偏差的同時還給出了出現偏差的原因. 應吸取的一些關 鍵教訓如下：(1)增量式開發(fā)或者階段性開發(fā)對于實現更高的質量和生產率非常有幫 助,由于根據第一階段的數據確定故障預防舉措,可以改良其余階段的質量和生產率.(2)故障預防可以顯著地降低故障引入率.即使從工作量上看,故障預 防也能很好地得到回報；在故障預防上投入幾個小時的工作量, 最多可以使以 后的返工工作量減少5至10倍.(3)如果某個變更申請有較大的影響,那么用一個詳細的影響分析與客戶 討論,這在設置正確的期望和進行嚴格的本錢效益分析時非常有益(這可以迫便變更延遲進行,該工程就是延遲了變更).(4)代碼評審和單無測試階段的故障排除效率很低,為了改良這兩個階 段的效率,必須評審這兩個階段的過程