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

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

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

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

4、的標準定義進 行用例分類。這樣的分類可以起到很好的作用。最終源代碼的規(guī)模用LOCS行度量。并用公布的轉換表規(guī)范化成 FP規(guī)模。對于Java，公布的轉換表達認為21LOC等于1FP,而對于 COBQL 107LOC等 于 1FF。鄉(xiāng)結果匚語 結果語言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驗收測試（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系統(tǒng)測試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工作量估計過高（以往項析目的數(shù)扌據不能?提供幫助，因為

7、它沒有這個階段）調計（概695.013.30569.01222設計花去了更多的時間，要設計因為團隊沒有使用和詳細Ratio nalRose和OOAD 勺設計）經驗編碼1204.024.941235.3266單測試146.52.80142.533集成測734.01404331.07120大量工作量用于修復與試Syn ergy禾口Win dowsResixed代碼協(xié)調調期間引入的故障系試驗試統(tǒng)測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日沒有完成，并有由于客戶的延 誤一直延續(xù)至10月23日14.53-77123由于協(xié)調問題而產生的偏差71更多是由于培訓而引起的偏差3.0110.6故障分布情況檢測階段實際故障 占發(fā)現(xiàn)的總 估計的故障 占估計的總 偏差（咧數(shù)故障數(shù)的百數(shù)數(shù)故障數(shù)的分比（%百分比（%需求和設計11102920-62評審代碼評審58502920100單元測試15135740-73集成和系統(tǒng)2925251716測試驗收測試3253

9、-40總計116100145100-20出現(xiàn)偏差的原因（1）故障預防措施減少了后面階段的故障引入率，導致總體故 障引入率減少。（2）估計所基于的以往項目只進行過極少量的代碼評審，并且 嚴重地依賴于UT（單元測試）。在這個項目中，因為更加嚴格和廣泛 地執(zhí)行代碼評審，在評審時發(fā)現(xiàn)了更多的故障，所以單元測試時發(fā)現(xiàn) 的故障大大地減少了。故障排除效率故障檢測階段故障引入階段故障排除效率需求E分構建析需求評審5100%設計評審06100%代碼評審005855% (58/58+15+29+3)單元測試001532% (15/15+29+3)集成/系統(tǒng)測002991% (29/29+3)試驗收測試003100

10、%總的故障排除效率=113/116=97.4%故障按嚴重性分布情況序號嚴重性故障數(shù)總故障率（%1裝飾性故障2622.42次要故障51443主要故障36314緊急故障32.65其他116總計故障按類型的分布情況序號故障類型故障數(shù)總故障數(shù)（%1邏輯3328.42標準29253績效2420.74冗余代碼14125用戶接口97.76體系結構43.57致性21.78重用性10.9總計36510因果分析和應吸取的教訓幾乎沒有很大原過程績效偏差；實際偏差績效與期望的績效非常 接近。對于那些大的偏差，給出偏差的同時還給出了出現(xiàn)偏差的原因。 應吸取的一些關鍵教訓如下：（1）增量式開發(fā)或者階段性開發(fā)對于實現(xiàn)更高的質量和生產率 非常有幫助，因為根據第一階段的數(shù)據確定故障預防措施， 可以改進 其余階段的質量和生產率。（2）故障預防可以顯著地降低故障引入率。 即使從工作量上看， 故障預防也能很好地得到回報；在故障預防上投入幾個小時的工作量，最多可以使以后的返工工作量減少 5至10倍。（3）如果某個變更申請有較大的影響，則用一個詳細的影響分 析與客戶討論，這在設置正確的期望和進行嚴格的成本效益分析時非 常有益（這可以迫便變更延遲進行，該項目就是延遲了變更） 。（4）代碼評審和單無測試階段的故障排除效率很低，為了改進 這兩個階段的效率，必須評審這兩個階段的