WBANK項(xiàng)目的收尾分析報(bào)告范例

1、WBAN頌?zāi)康氖瘴卜治鰣?bào)告范例1、基本信息項(xiàng)目代碼Xxxx開發(fā)期，整個(gè)生命期業(yè)務(wù)領(lǐng)域金融業(yè)?；?Web勺帳戶管理應(yīng)用項(xiàng)目領(lǐng)導(dǎo)/模塊領(lǐng)導(dǎo)Xxxx業(yè)務(wù)經(jīng)理軟件質(zhì)量顧問Xxxx2、績效總結(jié)績效參數(shù)實(shí)際值 估計(jì)值 偏差 偏差原因（如果偏差大）總的工作量（人日）59750119%兩個(gè)主要的變更申請(qǐng)最多時(shí)的團(tuán)隊(duì)人數(shù)990N/A項(xiàng)目開始日期2000年4月2000年4月0N/A3日3日項(xiàng)目收尾日期2000 年 102000 年 1027天兩個(gè)主要的笠更申請(qǐng)花月3日月30日去了 5%E作量質(zhì)量（已交付產(chǎn)品的0.0020.0125由于故障預(yù)防和增量過故障數(shù)/FP）程的作用，質(zhì)量提高了生產(chǎn)率58572%N/A質(zhì)量

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

3、目執(zhí)行期間遇到的問題風(fēng)險(xiǎn)1轉(zhuǎn)換到VAJ3.1的影響風(fēng)險(xiǎn)2缺少客戶的數(shù)據(jù)庫設(shè)計(jì)師和數(shù)據(jù)庫管理員的支持風(fēng)險(xiǎn)3RUF®用不正確，因?yàn)檫@是第一次使用風(fēng)險(xiǎn)4不員流失有關(guān)風(fēng)險(xiǎn)緩和措施的備注風(fēng)險(xiǎn)1:明確地表達(dá)風(fēng)險(xiǎn)有助于客戶同意延遲轉(zhuǎn)換以及正確地預(yù)算影響。風(fēng)險(xiǎn)2:提前進(jìn)行仔細(xì)的規(guī)劃并利用聯(lián)機(jī)協(xié)調(diào)者， 這樣遷移策略是有效的。風(fēng)險(xiǎn)3:有效的做法是對(duì)團(tuán)隊(duì)進(jìn)行 RU嘴訓(xùn)，并將它及時(shí)地通知客戶。風(fēng)險(xiǎn)4:雖然沒有具體化，但它仍然是一個(gè)風(fēng)險(xiǎn)，影響可能很小，因?yàn)槊?個(gè)關(guān)鍵任務(wù)都被及時(shí)地通知給多個(gè)人。6、規(guī)模實(shí)際規(guī)模12估計(jì)的規(guī)模簡單用例數(shù)量12中等復(fù)雜用例數(shù)量復(fù)雜用例數(shù)量關(guān)于估計(jì)的備注分類標(biāo)準(zhǔn)：用簡單用例、中等復(fù)雜

4、用例和復(fù)雜用例的標(biāo)準(zhǔn)定義進(jìn)行用例分 類。這樣的分類可以起到很好的作用。最終源代碼的規(guī)模用LOC此行度量。并用公布的轉(zhuǎn)換表規(guī)范化成 FP規(guī)模。 對(duì)于Java,公布的轉(zhuǎn)換表達(dá)認(rèn)為 21LO考于1FP,而又t于COBOL107LO/于 1FR結(jié)果語言LOO模EP規(guī)模Java33 8651612COBOL1241127、進(jìn)度計(jì)劃階段實(shí)際所花的時(shí)估計(jì)的時(shí)落后（為落后的原因間（天）間（天）需求分析28.6731-6.8概要設(shè)計(jì)000.0詳細(xì)設(shè)計(jì)38.842-6.7編碼132135-1.6單元測(cè)試910-9.3總構(gòu)建141144-2.1集成測(cè)試40400系統(tǒng)測(cè)試1500.0驗(yàn)收測(cè)試（AD3010200.0在

5、客戶的申請(qǐng)卜 AT完成時(shí)間質(zhì)量成本COQ=評(píng)審工作量+返工工作量+培訓(xùn)工作量)/總工作量X 100% =(69.5+343.5+129.5+567.5+90+336.5+104.5 ) /5229.5 X 100%=31.4%工作量階段任務(wù)評(píng)審返工總計(jì)需求分析210.010.060.0280.0概要設(shè)計(jì)0.00.00.00.0詳細(xì)設(shè)計(jì)652.014.029.5695.5編他1188.039.576.51304.0單元測(cè)試129.50.017.0146.0集成測(cè)試567.56.0160.5734.0系統(tǒng)測(cè)試90.00.00.090.0驗(yàn)收測(cè)試336.50.00.0336.5LC階段總工作量317

6、3.569.5343.53586.5項(xiàng)目管理733.10.00.0733.1培訓(xùn)104.50.00.0104.5CM317.00.00.0317.5其他488.50.00.0488.5總計(jì)（包括管理、培訓(xùn)和1643.00.00.01643.0其他）總工作量（人時(shí)）4816.5069.50343.505229.5025.760.371.8427.97總工作量（人月）人工作量分布情況及實(shí)際的工作量與估計(jì)的工作量工作量白 分 工作量 白分比%-偏差原因（ 人比（衿（人 （%需析概計(jì)細(xì) 、測(cè) #(設(shè)詳#)碼加成 町要和團(tuán)編筆集試2805.35475.010 30695.013.30 569.01222

7、工作量估計(jì)過高（以往項(xiàng) 目的數(shù)據(jù)不能提供幫助， 因?yàn)樗鼪]有這個(gè)階段）設(shè)計(jì)花去了更多的時(shí)間， 因?yàn)閳F(tuán)隊(duì)沒有使用RationalRose 和 OOAD勺1204.0 24.94146.52.80734.014041235.3 26142.53331.0763120大量工作量用于修復(fù)與Synergy 和 WindowsResixed代碼協(xié)調(diào)調(diào)期間 引入的故障測(cè)測(cè) 段管統(tǒng)收 階目”系試驗(yàn)試LC總項(xiàng)理培其90.01.7295.02-5336.56.43285.063586.5 68.58 3132.8 66733.114.02713.015104.52.00455.010317.06.06142.034

8、88.59.34285.0618 驗(yàn)收測(cè)試在10月3日沒有 完成，并有由于客戶的延 誤一直延續(xù)至10月23日14.53-77123由于協(xié)調(diào)問題而產(chǎn)生的偏差71更多是由于培訓(xùn)而引起的時(shí)）時(shí)）培其、口計(jì)理手總計(jì)訓(xùn)總5229.5 1004727.8 10010.6 故障分布情況檢測(cè)階段實(shí)際故障 占發(fā)現(xiàn)的總 估計(jì)的故障占估計(jì)的總 偏差（為數(shù)故障數(shù)的百數(shù)數(shù)故障數(shù)的分比（為百分比（衿需求和設(shè)計(jì)11102920-62評(píng)審代碼評(píng)審58502920100單元測(cè)試15135740-73集成和系統(tǒng)2925251716測(cè)試驗(yàn)收測(cè)試3253-40總計(jì)116100145100-20出現(xiàn)偏差的原因（1）故障預(yù)防措施減少了后

9、面階段的故障引入率，導(dǎo)致總體故障引入率減少。（2）估計(jì)所基于的以往項(xiàng)目只進(jìn)行過極少量的代碼評(píng)審， 并且嚴(yán)重地依賴 于UT （單元測(cè)試）。在這個(gè)項(xiàng)目中，因?yàn)楦訃?yán)格和廣泛地執(zhí)行代碼評(píng)審，在 評(píng)審時(shí)發(fā)現(xiàn)了更多的故障，所以單元測(cè)試時(shí)發(fā)現(xiàn)的故障大大地減少了。故障排除效率故障檢測(cè)階段故障引入階段故障排除效率需求分析 構(gòu)建需求評(píng)審5100%設(shè)計(jì)評(píng)審06100%代碼評(píng)審005855% (58/58+15+29+3)單元測(cè)試001532% (15/15+29+3)集成/系統(tǒng)測(cè)試002991% (29/29+3)驗(yàn)收測(cè)試003100%總的故障排除效率=113/116=97.4%故障按嚴(yán)重性分布情況序號(hào)嚴(yán)重性故障

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