1、WBAN工程的收尾分析報告范例1、根本信息工程代碼Xxxx生命期開發期，整個生命期業務領域金融業。基于Web的帳戶管理應用工程領導/模塊領導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%

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

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

4、例分 類。這樣的分類可以起到很好的作用。鄉結果匚語 結果語言LOC規模EP規模Java33 8651612COBOL1241127、進度方案階段實際所花的時估計的時落后%落后的原因間天間天需求分析28.6731-6.8概要設計000.0最終源代碼的規模用 LOC進行度量。并用公布的轉換表標準化成FP規模。對于Java,公布的轉換表達認為 21LOC等于1FP,而對于 COBOL， 107LOC 等于 1FP。詳細設計38.842-6.7編碼132135-1.6單元測試910-9.3總構建141144-2.1集成測試40400系統測試1500.0驗收測試3010200.0在客戶的申請下AT完AT

5、成時間質量本錢COQ二評審工作量+返工工作量+培訓工作量/總工作量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系統測試90.00.00.090.0驗收測試336.50.00.0336.5LC階段總工作量3173.569.5343.535

6、86.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工作量估計過高以往項析目的數?據不能?提供幫助，因為它沒有這個階段調計概695.013.30569.01222設計花去了更多的時間，要設、 計一因為團隊沒有使用和詳細RationalRose和

7、 OOAD 的設計經驗編碼1204.024.941235.3266單測試146.52.80142.533集成測734.01404331.07120大量工作量用于修復與試Synergy和Win dowsResixed代碼協調調期間引入的故障系統測90.01.7295.02-5試驗收測336.56.43285.0618驗收測試在10月3日沒有試元成，并:有由于客尸的延誤一直延E續至10月23日LC階段3586.568.583132.86614.5總計工程管733.114.02713.0153理培訓104.52.00455.010-77CM317.06.06142.03123由于協調問題而產生的偏差

8、其他488.59.34285.0671更多是由于培訓而引起的階段 實際估計偏差工作量 百 分工作 百分比%偏差原因 人比%量人 % 時時偏差管 理、1643.031.421595.0 343.01培訓和其他總計總計 5229.51004727.8 10010.6故障分布情況檢測階段實際故障數占發現的總故障數的百分比%估計的故障數占估計的總數故障數的百分比%偏差%需求和設計11102920-62評審代碼評審58502920100單元測試15135740-73集成和系統2925251716測試驗收測試3253-40總計116100145100-20出現偏差的原因1故障預防措施減少了后面階段的故障引

9、入率，導致總體故障引入率減 少。2估計所基于的以往工程只進行過極少量的代碼評審，并且嚴重地依賴 于UT 單元測試。在這個工程中，因為更加嚴格和廣泛地執行代碼評審， 在評審時發現了更多的故障，所以單元測試時發現的故障大大地減少了。 故障排除效率故障檢測階段故障引入階段故障排除效率100%需求分析構建需求評審設計評審06100%代碼評審005855%( 58/58+15+29+3)單元測試001532%( 15/15+29+3)集成/系統測試002991%( 29/29+3)驗收測試003100%總的故障排除效率=113/116=97.4%故障按嚴重性分布情況序號嚴重性故障數總故障率%1裝飾性故障

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