CMMI3同行評審詳細過程定義

1、同行評審 4.1同行評審與測試的關(guān)系發(fā)現(xiàn)缺陷的手段為什么要引入同行評審而不是繼續(xù)完全使用測試呢？有些工作產(chǎn)品在早期階段就可以進行同行評審去發(fā)現(xiàn)缺陷，但無法對其進行測試；即使到了編碼階段，測試活動也不能發(fā)現(xiàn)某些特定類型的缺陷（例如違反編程規(guī)范）。從圖4-1（開發(fā)各階段缺陷放大圖）可以看出，隨著開發(fā)的不斷開展，缺陷不斷泄漏和放大，最終形成的產(chǎn)品是一個灰色的距離用戶真正需求很遠的一個"東西"。這就需要在開發(fā)的過程中不斷進行同行評審，減少泄漏到下一個階段的缺陷。成功的同行評審是提高質(zhì)量和生產(chǎn)率的重要因素，不管人們喜歡與否，審查過程會迫使每個人在一種開放式的環(huán)境中工作。一旦

2、人們懂得了他們的工作都要接受同行評審，他們就會越早地將他們的工作公之于眾，以待監(jiān)督。在同級評審上的投入把組織的一些質(zhì)量成本從昂貴的測試以及后期的大規(guī)模返工轉(zhuǎn)變?yōu)樵缙诘娜毕莅l(fā)現(xiàn)。更重要的是，工作產(chǎn)品的作者學到了如何將工作做得更好，從而避免了缺陷。固然同行評審的準備、活動和跟蹤需要花費一定的時間和工作量，但這些可以在測試中節(jié)省更多。從經(jīng)濟角度考慮，許多缺陷是在早期階段注入的，越早消除缺陷就越能降低開發(fā)成本。據(jù)統(tǒng)計，對于保存精確記錄的大系統(tǒng)，一套完整的同行評審體系能夠使項目在每個測試階段出現(xiàn)的錯誤減少了90%。這樣一來，即使在綜合考慮了同行評審活動成本的情況下，同行評審活動也會使測試成本下降50%8

3、0%。同時，通過同行評審，開發(fā)人員能夠及時地得到專家的幫助和指導，加深對工作成果的理解，更好地預(yù)防缺陷，在一定程度上提高了開發(fā)生產(chǎn)率。再者，消除工作成果的缺陷，可以提高產(chǎn)品質(zhì)量，提高客戶滿意度。 （點擊查看大圖）圖4-1 開發(fā)各階段缺陷放大圖 總之，同行評審有助于"提高質(zhì)量、提高生產(chǎn)率、降低成本"。但是要注意，同行評審不可能代替測試，正如測試不可能替代同行評審一樣。那么，工作產(chǎn)品通過了什么樣的評審才算合格呢？同行評審本身的要求有沒有在質(zhì)量目標里？評審的工作量和參加人員的資格、評審時間是否有要求呢?4.2 同行評審的種類和對象同行評審活

4、動的關(guān)注點應(yīng)該是工作產(chǎn)品中的缺陷，而不應(yīng)該是工作產(chǎn)品的作者或者生產(chǎn)者，管理者也不應(yīng)使用同行評審的結(jié)果去評價個人的行為。同行評審的分類有很多種，自從IBM的Fagan發(fā)明了同行評審之后，軟件行業(yè)提出了很多同行評審模型，比較著名的有IEEE 1028評審、微軟的技術(shù)評審、Gill Graham審查、Van Emden審查、Yourdon結(jié)構(gòu)化走查等。4.2.1 同行評審的種類本書中按照CMMI模型的提法，將同行評審分為3類。（1）正式評審（Inspection），通常是由經(jīng)過同行評審培訓的項目經(jīng)理或PPQA主持，規(guī)模在37人之間為宜，一般在完成了一個工作產(chǎn)品

5、后對其進行的評審。正式評審的目的在于定位并除去工作產(chǎn)品中的缺陷。（2）技術(shù)審查（Technical Reviews），或稱內(nèi)部評審，通常由技術(shù)負責人或項目經(jīng)理召集，三人以上參加。技術(shù)審查一般是在工作產(chǎn)品的中期進行或完成了某部分獨立的工作產(chǎn)品時進行，也可在書寫草案遇到問題時就其中專門的一兩項問題討論和審查。也可以是檢查工作產(chǎn)品與規(guī)程、模板、計劃、標準的符合性或者變更是否被正確地執(zhí)行。技術(shù)審查的目的在于通過對開發(fā)人員的工作產(chǎn)品的技術(shù)審查，提出改進意見。（3）走查（Walkthrough），又叫代碼走查或代碼走讀，審查的范圍根據(jù)需求的優(yōu)先級通常由管理人員來確定，主要是靜態(tài)質(zhì)量分析和編程規(guī)則

6、檢查。通常是小型討論會，一般是在工作產(chǎn)品形成的早期進行，作者有一定的想法時，希望從中獲得一些幫助或補充一些想法。當然也可以在編制工作產(chǎn)品的任何階段進行，兩三個人參加，由作者主持，主要是評估和提高工作產(chǎn)品的質(zhì)量或教育參加者。其中，"正式評審"是正式的，"技術(shù)審查"和"走查"是常用的非正式同行評審方法。4.2.2 同行評審的對象同行評審的對象包括所有軟件開發(fā)的中間和最終工作產(chǎn)品，例如包括：（1）產(chǎn)品需求規(guī)格說明書；（2）用戶界面規(guī)范及設(shè)計；（3）架構(gòu)設(shè)計、概要設(shè)計、詳細設(shè)計及模型；（4）源代碼；（5）測試計劃、設(shè)計、用例及步驟；

7、（6）項目計劃，包括開發(fā)計劃、配置管理計劃和質(zhì)量保證計劃等。所有這些會涉及的評審內(nèi)容，應(yīng)該在編制的項目計劃或者小的開發(fā)計劃中體現(xiàn)，不應(yīng)該也不能是臨時性的安排。4.3 同行評審過程根據(jù)同行評審的重要程度，正式評審、技術(shù)審查和走查三種形式的流程和成果物的使用力度不盡相同，但其主要的步驟和內(nèi)容大體一致，參見如圖4-2所示的同行評審流程圖。 （點擊查看大圖）圖4-2 同行評審流程圖4.3.1 正式評審流程正式評審包括下述6個基本步驟。（1）預(yù)備：為保證評審的質(zhì)量，可以先進行一個預(yù)備會議。會議上，由作者花幾分鐘的時間向評審組概要介紹評審材料，例如講解一下本工作產(chǎn)品

8、的目標是什么，其他相關(guān)的實現(xiàn)細節(jié)、開發(fā)標準等。應(yīng)該允許甚至鼓勵評審組成員動手查看工作產(chǎn)品，或者查看開發(fā)過程中所用到的檢查單等。這個講解的過程從某種角度上來說，也保證了作者提交工作產(chǎn)品的質(zhì)量。會議結(jié)束時把文檔分發(fā)給每位與會者，下發(fā)的材料應(yīng)該控制在2小時之內(nèi)審核完成為宜。這些文檔可以包括：要審查的工作產(chǎn)品；參考文檔；工作產(chǎn)品評審檢查表；工作產(chǎn)品審閱情況記錄表。評審主持人負責根據(jù)具體情況確定什么時間開始真正的評審會議。（2）審查：在預(yù)備會和正式評審會之間，評審小組成員會對工作產(chǎn)品進行徹底檢查，并依據(jù)相關(guān)標準和準則評審工作產(chǎn)品，記錄發(fā)現(xiàn)的缺陷、問題種類與嚴重程度、所用的時間等。（3）評審：在預(yù)定的正式

9、評審時間內(nèi)（會議時間建議控制在2小時），評審小組成員以會議形式聚在一起，依次對產(chǎn)品進行檢查。每個評審員花一定的時間（一般為十幾分鐘）指出問題，并和作者確定問題和定義問題的嚴重程度。注意，評審過程中是發(fā)現(xiàn)錯誤，而不是現(xiàn)場改正它們。會議中，記錄員詳細記錄每一個已達成共識的缺陷，包括缺陷的位置、簡短描述缺陷、缺陷類別、該缺陷的發(fā)現(xiàn)者等。未達成共識的缺陷也將記錄下來，加入"待處理"或者TBD標識，評審主持人將指派作者和評審員在會后處理評審會議中未能解決的問題。（4）書寫評審報告：評審主持人根據(jù)記錄員的記錄和自己的總結(jié)，在一天內(nèi)寫出評審報告，內(nèi)容包括：根據(jù)評審專家個人的輸入創(chuàng)建總的問

10、題清單；加入會議中發(fā)現(xiàn)的問題；剔除經(jīng)確認屬于重復或者無效的問題；共同確定需要修改的問題及修改的程度。（5）返工：作者根據(jù)評審報告的決議，負責解決確定的所有缺陷和問題。（6）跟蹤：評審組長必須確保所提出的每個問題都得到了圓滿解決。必須仔細檢查對文檔的每個修正，以確保沒有注入新的錯誤。4.3.2 技術(shù)審查流程技術(shù)審查通常包括下述3個基本步驟。（1）準備：評審組長（通常是項目經(jīng)理）要求項目組成員提供需要考慮的特定問題并分發(fā)評審材料。評審組長確定評審重點：需要注意的特定問題；需要滿足的特殊標準或規(guī)格說明；需要審查的接口或依賴關(guān)系。（2）評審：評審人各自審查評審材料，目的是發(fā)現(xiàn)錯誤，而不是改正

11、它們（通常每次評審會不超過1小時）。評審組組長應(yīng)在一天內(nèi)寫出評審報告。評審會議內(nèi)容包括：匯總個人發(fā)現(xiàn)的問題；加入會議中發(fā)現(xiàn)的問題。（3）跟蹤：作者負責解決評審報告中的所有錯誤及問題。評審組長檢查所提出的每個問題都得到了解決。組長起草評審發(fā)現(xiàn)報告：問題或弱項清單；小組對如何解決這些問題或弱項清單的建議；行動事項。4.3.3 走查流程走查對形式的要求更為簡單，主要有下述兩種方式。（1）參與者驅(qū)動法：參與者按照事先準備好的列表，提出他們不理解的術(shù)語和認為不正確的術(shù)語。作者必須回答每個質(zhì)疑，要么承認確實有錯誤，要么對質(zhì)疑做出解釋。（2）文檔驅(qū)動法：作者向評審人仔細解釋文檔（或代碼）。在此過程

12、中，可以將評審的內(nèi)容（如關(guān)鍵代碼、架構(gòu)圖、業(yè)務(wù)邏輯圖等）用投影儀投射到屏幕上，作者對工作產(chǎn)品進行講解，評審人不時針對事先準備好的問題或解釋過程中發(fā)現(xiàn)的問題提出質(zhì)疑。它比參與者驅(qū)動法可能更有效，往往能檢查出更多錯誤。經(jīng)驗表明，使用文檔驅(qū)動法時許多錯誤是由文檔講解者自己發(fā)現(xiàn)的。在走查過程中，每個評審人都要記錄錯誤或建議，會后要整理會議記錄，作為走查報告。工作產(chǎn)品的作者可以根據(jù)自己的思路對走查報告質(zhì)疑。注：對代碼的同行評審其實就是代碼走查，可以使用投影儀打出關(guān)鍵代碼位置與參與人員一起讀，也可以幾個開發(fā)人員一起進行交叉走查。選定的進行代碼走查的范圍根據(jù)需求的優(yōu)先級來具體確定。4.4 同行評審

13、方式的選擇對于同一個工作產(chǎn)品，根據(jù)所處于的階段可以使用不同的評審方式。如對于工作產(chǎn)品剛剛勾畫、起草時，可以采用走查方式；對于完成了某一個單獨的章節(jié)，可以采用技術(shù)審查方式；待整個產(chǎn)品完成，使用正式評審全面考察。4.4.1 三種同行評審方式的比較對不同的工作產(chǎn)品，可以根據(jù)表4-1建議結(jié)合項目情況進行調(diào)整和裁剪。表4-1 三種同行評審方式的比較種類正式評審、技術(shù)審查、走查，目的以比較詳細的粒度，定位并去除工作產(chǎn)品中的缺陷表明工作產(chǎn)品與規(guī)約、計劃、標準的符合性或者變更被正確地執(zhí)行了評估、提高工作產(chǎn)品，教育參加者入口準則工作產(chǎn)品符合已建立的準備準則發(fā)布了評審目的，工作產(chǎn)品就緒，作者準

14、備好工作產(chǎn)品計劃中標識時機工作產(chǎn)品全部完成完成獨立的章節(jié)架構(gòu)、藍圖、草稿規(guī)模38人35人23人評審材料相對較少中等或較多，需要根據(jù)評審的目的確定中等準備時間35天準備2天準備 主持人專職主持人小組長/組長作者變更驗證主持人驗證返工組長驗證，作為評審報告的一部分由其他的項目控制手段執(zhí)行成果物缺陷清單和度量元總結(jié)技術(shù)評審報告，包括缺陷清單以及行動計劃走查報告，缺陷記錄以及改進建議4.4.2 同行評審的結(jié)果同行評審的結(jié)果通常有3種：（1）正常：評審專家做好了評審準備，會議正常，結(jié)果明確，不需要再次評審；（2）延期：30%以上評審專家沒有做好準備，會議無法正常進行，需要確定再次評審

15、時間；（3）取消：在初審階段就發(fā)現(xiàn)很多問題，需要作者進行修正，然后再進行第二次同行評審。4.4.3 正式評審的特征相對于走查和技術(shù)評審，正式評審具有一些明顯的特征。（1）評審以一種正式的形式進行，如有正式的、事先定義好的有關(guān)職責的各種角色，并遵循組織規(guī)定的標準流程。（2）對于任何工作產(chǎn)品的評審，都會組建與之對應(yīng)的專門評審組，包括作者、主持人、記錄員以及評審員若干。評審組成員也可以包括項目經(jīng)理、PPQA，但是不能有作者的直接領(lǐng)導或者管理者。（3）評審小組先召開一個預(yù)備會議，作者會針對工作產(chǎn)品向大家做一個總體的介紹，例如講解一下本工作產(chǎn)品的目標是什么，其他相關(guān)的實現(xiàn)細節(jié)、開發(fā)標準等。應(yīng)該

16、允許甚至鼓勵評審組成員動手查看工作產(chǎn)品，或者查看開發(fā)過程中所用到的檢查單等。（4）評審小組的主持人負責確定什么時間開始真正的評審會議，在預(yù)備會和正式評審會之間，評審小組成員會對工作產(chǎn)品進行徹底檢查，并依據(jù)相關(guān)標準和準則評審工作產(chǎn)品。（5）在預(yù)定時間，評審小組成員以會議形式聚在一起，依次對產(chǎn)品進行檢查，主持人負責對整個會議的進展進行控制，而記錄員則負責記錄下整個過程。（6）在工作產(chǎn)品中發(fā)現(xiàn)的每一個缺陷都會被認真記錄下來，并被適當分類。（7）會議結(jié)束后，負責人需要分析有關(guān)缺陷，找出產(chǎn)生此缺陷的原因并加以修正。（8）主持人應(yīng)確保所有的缺陷都會得到解決和修正。如果過程需要加以變更的話，應(yīng)將相關(guān)問題移交

17、相關(guān)的過程質(zhì)量組。正式評審的正規(guī)性特征還體現(xiàn)在按發(fā)生頻率和嚴重程度，仔細劃分缺陷的類型，并且把這些信息運用到缺陷預(yù)防階段以及未來產(chǎn)品的同行評審過程中。4.4.4 工作產(chǎn)品的同行評審方式對開發(fā)過程中產(chǎn)生的主要工作產(chǎn)品所采用的同行評審方式以及參加評審人員，可以參考表4-2確定。表4-2 常見工作產(chǎn)品的同行評審方式和參加評審人員工作產(chǎn)品同行評審方式參與評審人員項目總體計劃走查項目經(jīng)理、產(chǎn)品經(jīng)理、需求提出者、市場或銷售代表、技術(shù)負責人、質(zhì)量保證工程師、高層技術(shù)管理者和過程管理者用戶需求說明書走查需求分析師、項目經(jīng)理、架構(gòu)師、設(shè)計師、系統(tǒng)測試工程師、質(zhì)量保證經(jīng)理、用戶或市場代表、文檔

18、編寫者、業(yè)務(wù)專家和技術(shù)支持代表產(chǎn)品需求規(guī)格說明書正式評審需求分析師、項目經(jīng)理、架構(gòu)師、設(shè)計師、系統(tǒng)測試工程師、質(zhì)量保證經(jīng)理、用戶或市場代表、文檔編寫者、業(yè)務(wù)專家和技術(shù)支持代表項目已定義過程正式審查過程改進組負責人、過程改進工作組成員、管理級的過程擁有者和使用過程的實踐者的代表開發(fā)計劃技術(shù)審查創(chuàng)建者、項目經(jīng)理、維護者和程序員系統(tǒng)測試計劃技術(shù)審查測試工程師、程序員（單元測試）或架構(gòu)師（集成測試）或需求分析師（系統(tǒng)測試）和質(zhì)量保證代表系統(tǒng)測試用例走查測試工程師、程序員（單元測試）或架構(gòu)師（集成測試）或需求分析師（系統(tǒng)測試）、質(zhì)量保證代表概要設(shè)計說明書正式評審架構(gòu)師、需求分析師、設(shè)計師、項目經(jīng)理和集成

19、測試工程師集成測試計劃技術(shù)審查測試工程師、程序員（單元測試）或架構(gòu)師（集成測試）或需求分析師（系統(tǒng)測試）和質(zhì)量保證代表詳細設(shè)計說明書正式評審設(shè)計師、架構(gòu)師、程序員和集成測試工程師單元測試計劃走查測試工程師、程序員（單元測試）或架構(gòu)師（集成測試）或需求分析師（系統(tǒng)測試）和質(zhì)量保證代表代碼走查程序員、設(shè)計師、單元測試工程師、維護者、需求分析師和編碼標準專家集成/驗收測試記錄和報告走查測試工程師、程序員（單元測試）或架構(gòu)師（集成測試）或需求分析師（系統(tǒng)測試）和質(zhì)量保證代表用戶使用手冊走查文檔編寫者、需求分析師、用戶或市場代表、系統(tǒng)測試工程師、維護人員、設(shè)計師、用戶教育設(shè)計師、培訓師和技術(shù)支持代表用戶

20、界面設(shè)計技術(shù)審查用戶界面設(shè)計師、需求分析師、用戶、應(yīng)用領(lǐng)域?qū)＜摇⒖捎眯曰蛉梭w專家和系統(tǒng)測試工程師項目總結(jié)報告技術(shù)審查項目經(jīng)理、產(chǎn)品經(jīng)理、需求提出者、市場或銷售代表、技術(shù)負責人、質(zhì)量保證工程師、高層技術(shù)管理者和過程管理者4.5 迭代生命周期的審查審查是提高瀑布模型項目質(zhì)量的好方法。但對于迭代項目來說，如何在短的周期來做該工作呢？需要考慮迭代開發(fā)生命周期中審查的角色。在瀑布型過程中，審查對成功是至關(guān)重要的，因為團隊不看重較早開發(fā)的代碼，也就是說，他們不會回到前面的"階段"。同時，由于瀑布周期時段很長，以至于到下游階段發(fā)現(xiàn)錯誤時，原作者常常已經(jīng)幫不上忙，即使可以，他們也

21、已經(jīng)忘記了工作的內(nèi)容。使用瀑布方法時，審查是對抗糟糕質(zhì)量的唯一安全措施。相反，迭代開發(fā)周期短（平均39周），每個團隊成員都是確保迭代成功的關(guān)鍵，即當下游人員發(fā)現(xiàn)錯誤時，這些成員不僅可用，而且他們已經(jīng)準備好并期望在生命周期中盡早開始修復工作。通常在進行工作產(chǎn)品審查時，大家傾向于無論看到的問題對于迭代成功的重要性如何，都會猛撲向任何發(fā)現(xiàn)的錯誤（甚至是極其微小、無足輕重的）。盡管審查似乎要求成員盡量爭取完美，然而在短的迭代周期中，更應(yīng)該關(guān)注的是完成工作。一定要記住迭代方法的原則是"讓迭代自己證明自己"，允許質(zhì)量可疑的事情進行。當實際使用時，我們將認識到它是否足夠好。無論何種開發(fā)生

22、命周期，審查中的主要反饋來自下游的使用者，因為他們將不得不使用系統(tǒng)。對于迭代開發(fā)過程，唯一不同的是與其在交付到下一道"工序"前審查工作產(chǎn)品，不如把工作產(chǎn)品實際地立即投入使用，在實踐中進行檢驗，這是它最重要的改進。那么這意味著在迭代生命周期中不應(yīng)該有任何審查嗎？不是的，但確實進行的次數(shù)比大部分項目團隊少得多，特別是如果團隊一開始就采用瀑布型的方法。如果真的接受迭代方法，那么審查的數(shù)量應(yīng)該被自動地減少。舉例來說，如果迭代項目的生命周期是六周，則應(yīng)該考慮進行多少審查工作，而不影響完成迭代的工作。在迭代開發(fā)中，創(chuàng)建計劃證明迭代過程的正確性是非常必要的。對于重視審查的項目團隊，在初始

23、階段還有一個額外的步驟。就是要將需審查的每個工作產(chǎn)品映射到迭代中。假設(shè)限制每個迭代過程中最多三個工作產(chǎn)品，那么對于六周的迭代過程，三個審查會顯得很繁重，唯一的辦法就是減少審查的數(shù)量，因而需要為審查計劃提供許多提示，并且確保正確的人參與。，避免落入頻繁審查的圈套。4.6 同行評審的注意事項為了有效地提高同行評審過程的質(zhì)量，經(jīng)常需要對過程數(shù)據(jù)進行度量（關(guān)于軟件度量的專題，見本書第7章中相關(guān)內(nèi)容），作為進一步提高過程的依據(jù)。公司有一次組織產(chǎn)品需求的同行評審，會議定在5號上午9：0011：00進行。開始之前采用郵件形式通知了參會人員，并沒有把評審材料發(fā)給大家。會議邀請了兩位技術(shù)負責人，其他人

24、員都是對技術(shù)不是很了解，且不了解評審過程與意義的管理人員，沒有安排專門的人員做會議記錄。會議上，大多數(shù)管理人員按照個人的喜好與想法來評價軟件的優(yōu)缺點，并且對此軟件的開發(fā)人員進行評論，提出了偏離評審會議主題的各種意見，使得原本安排2個小時的評審會議時間延長到了4個小時。軟件中存在的問題給予了很少的關(guān)注。主持人宣布了會議的主題。作者開始簡述自己的產(chǎn)品需求，接下來評審提出自己的意見。評審員小李說："關(guān)于查詢結(jié)果排序：查詢后的表格應(yīng)該是動態(tài)的，現(xiàn)在FW是固定的，這個需要改進。"其他人也參與該問題的討論。"如果繼續(xù)使用FW提供排序功能，那么需要FW項目組進行修改，F(xiàn)W的負責

25、人小張說說是否可行，打算怎么修改。"小張開始提出自己的想法以及如何改進，幾個同行也都說出自己的想法，有時會遇到不統(tǒng)一的現(xiàn)象，開始解釋和說明，等這個問題討論完了，才發(fā)現(xiàn)時間已經(jīng)過去40分鐘。大家繼續(xù)后邊的問題，2個小時過去后，需求評審只進行了一半，會議以沒有評審結(jié)果而宣告結(jié)束，只能下次繼續(xù)進行，會議中沒有任何表格填寫。通過上邊的例子，我們看到在評審中發(fā)生了5個違反規(guī)則的做法：（1）采用郵件方式通知大家，沒有專門通知到個人。（2）沒有預(yù)先下發(fā)被評審的工作產(chǎn)品和檢查單。（3）會議的焦點不是在確定問題上，而是轉(zhuǎn)到了如何解決問題。針對問題的解決，討論很多，同行評審會議最主要的是找到和確定哪些是

26、問題，至于如何解決問題，可以在評審會后相關(guān)人員繼續(xù)討論。（4）主持人沒有經(jīng)驗，沒有很好地主持和控制會場局面，當遇到會議跑題的時候，一定要記住會議主題，將討論的焦點帶回來，不然容易越走越遠。（5）沒有作缺陷的記錄和發(fā)現(xiàn)工作量的記錄。同行評審時，需要注意以下幾點事項。4.6.1 同行評審遵循的原則同行評審有所謂的"123準則"：同行評審準備時間大于開會時間，同行評審期間發(fā)現(xiàn)的缺陷數(shù)量應(yīng)該是同行評審準備期間發(fā)現(xiàn)的缺陷數(shù)量2倍以上，同行評審發(fā)現(xiàn)缺陷的效率是測試發(fā)現(xiàn)缺陷的3倍。（1）同行評審需要管理層的支持，如果沒有，即使是目標明確的開發(fā)組成員也會抵制進行評審。管理層的支持

27、包括建立評審策略和目標，提供資源、時間、培訓和激勵，并遵守評審小組的決定等。（2）同行評審是結(jié)構(gòu)化的過程，涉及許多參與人員的角色，在評審專家的選擇性上，一定要注意其中的互補性。經(jīng)驗表明，同行評審的參加人員在他相關(guān)的技術(shù)領(lǐng)域與方向發(fā)現(xiàn)缺陷的效率較高，需要為參加人員分配職責，會議參加人員要從不同的技術(shù)角度發(fā)現(xiàn)缺陷。（3）對于每種類型的同行評審，應(yīng)制定通用的工作產(chǎn)品評審檢查表，必要時可以進行裁剪以適應(yīng)特定項目的要求。工作產(chǎn)品評審檢查表應(yīng)涵蓋審查計劃、準備、實施、結(jié)束和報告準則。（4）評審開始前，評審人應(yīng)提前準備好自己所關(guān)注和將要提出的問題。（5）評審的重點在于發(fā)現(xiàn)問題，而非解決問題，再加上認真細致的

28、準備工作，可以最大程度避免在評審中浪費時間。（6）對于技術(shù)人員工作的審查，應(yīng)由技術(shù)人員進行，管理人員不要參與。但應(yīng)將評審結(jié)果和解決所發(fā)現(xiàn)問題的日期通知管理人員。（7）評審的過程是對事不對人的，例如用"這個假設(shè)是錯誤的"來表述，而不是尖刻地說"你的假設(shè)根本不對"。（8）成功的審查要求所有參與人員精力高度集中，可能會使參與人員十分疲憊。因此，每個審查階段最好不要超過2小時。對每個人來說，一天最好只參加一個階段審查。（9）將評審數(shù)據(jù)輸入到組織度量庫中，用于監(jiān)測評審效果，并管理和跟蹤產(chǎn)品質(zhì)量。相關(guān)的度量數(shù)據(jù)示例有：在全過程使用同行評審，要占10%的開發(fā)工作量；每

29、20頁敘述性文檔，需要40人時；每12頁概要設(shè)計，需要30人時；每1000行代碼，需要55人時；使用一段時間后，評價一個項目或一個組織的審查結(jié)果需要1人月。4.6.2 同行評審關(guān)注的問題（1）有同行評審計劃，并在每次評審前進行詳細安排，如邀請合格的專家參加評審，邀請被評審產(chǎn)品的作者參加評審，明確定義應(yīng)該評審哪些內(nèi)容，評審人員要有明確的分工。（2）對同行評審中發(fā)現(xiàn)的缺陷進行詳細記錄，如缺陷所屬模塊、缺陷嚴重程度、解決期限等，并安排相關(guān)人員對缺陷進行跟蹤直至解決。（3）對評審的過程進行度量，如評審準備時間和評審時間以及這兩個時間之比，評審準備期間發(fā)現(xiàn)的缺陷數(shù)和評審期間發(fā)現(xiàn)的缺陷數(shù)以及這兩

30、個數(shù)值之比，評審工作產(chǎn)品的規(guī)模和評審效率等。（4）為保證同行評審的獨立性、公正性，需要有經(jīng)驗的組外同行參加，需要對評審人員的能力定期衡量，及時更新保證其有效。（5）對類似的軟件進行評審和測試。有句話說得很好"你想不到的你的敵人會告訴你"，通過對競爭對手產(chǎn)品研究，可以很好地提高工作效率。4.6.3 同行評審通過的準則同行評審通過需要滿足以下的準則。1最小準則（1）工作產(chǎn)品已經(jīng)返工和確認；（2）主持人已經(jīng)發(fā)布審查報告。2基于組織的度量元或早期的審查，可以為這類工作產(chǎn)品設(shè)置出口準則（1）剩余主要缺陷數(shù)的估計是否在限定范圍內(nèi)；（2）剩余次要缺陷數(shù)的估計是否在限定范圍內(nèi)；（

31、3）變更數(shù)量在限制范圍內(nèi)（例如：IBM一個部門的指南規(guī)定，變更代碼應(yīng)少于評審代碼的5%。Ebenau，1994，p.58）。4.6.4 同行評審的經(jīng)驗共享只有軟件的生產(chǎn)者是唯一可能做到生產(chǎn)出無缺陷程序的人，其他任何人都對此無能為力。（1）所有的缺陷最終都應(yīng)追溯到需求，因為最嚴重的錯誤是"導致程序無法滿足需求"的錯誤。（2）軟件開發(fā)人員和管理人員首先應(yīng)該盡早地和不斷地進行各種軟件質(zhì)量保證活動（如需求和設(shè)計階段同行評審和走查等）。（3）軟件開發(fā)人員應(yīng)避免檢查自己的程序，利用同行評審的方式對代碼進行審查（因為自己檢查容易依照原有的程序設(shè)計思路進行，往往查不出問題）。（4

32、）在進行各種分析和修復工作中，要充分注意修復工作所產(chǎn)生的影響效果和波及效果。（5）統(tǒng)計表明大約有60%的錯誤是在設(shè)計階段之前注入的，并且修正一個軟件錯誤所需的費用將隨著軟件生存期的進展而上升。錯誤發(fā)現(xiàn)得越晚，修復它的費用就越高，而且呈指數(shù)增長的趨勢（見附錄中1:10:100公理）。（6）程序中的大部分錯誤往往是在一小部分模塊中發(fā)現(xiàn)的，遵循普遍適用的"二八定理"（即80%的錯誤往往是由20%的模塊所造成的）。（7）缺陷會掩蓋或加重其他缺陷。也就是說，當一個程序有許多缺陷時，由于缺陷相互作用，使得發(fā)現(xiàn)和修復缺陷的過程更加復雜。這使得一些缺陷很難查找和修復。一個缺陷可能掩蓋其他缺

33、陷，使得這些被掩蓋的缺陷難以發(fā)現(xiàn)，增加了它們逃過測試的可能性。（8）遵照規(guī)范化的方法，仔細復查和測試每個小程序模塊，這比讓任何測試組在你的程序中發(fā)現(xiàn)缺陷的效果要好。也就是說，盡早地將缺陷排除掉。測試不能避免缺陷的發(fā)生，只能是一種補救。4.6.5 文檔審查重點文檔審查要對文檔的完整性、一致性和正確性進行審查。1文檔的完整性審查（1）用人工審查的方法，驗證所提交軟件文檔是否齊全；（2）文檔中是否包含對軟件接收輸入數(shù)據(jù)類型和邊界值的描述或說明，包括最大值、最小值、鍵長、文件記錄的最大長度、搜索準則最大值、最小樣本尺寸；（3）對不可能提供固定的邊界值（例如，某些邊界值依賴于應(yīng)用類型或輸入數(shù)據(jù)

34、）的情況，是否說明極值；（4）是否包含與保密信息有關(guān)的信息，應(yīng)包括防止非法授權(quán)訪問的措施說明。2文檔的一致性審查（1）用人工審查的方法，審查文檔內(nèi)容和術(shù)語的含義前后是否一致，有沒有自相矛盾的地方；（2）檢查文檔與程序的一致性；（3）檢查書面文檔與聯(lián)機幫助文檔的一致性。3文檔的正確性審查（1）用人工審查的方法，審查文檔內(nèi)容是否正確和準確；（2）是否有錯別字；（3）是否有二義性的定義、術(shù)語或內(nèi)容。4.7 同行評審的度量同行評審和測試被業(yè)界認為是最主要的有效發(fā)現(xiàn)缺陷的手段（二者所發(fā)現(xiàn)的缺陷可以占到發(fā)現(xiàn)的缺陷總數(shù)80%90%，因此對二者的度量分析工作將更加重要。具體的度量過程、方法、度量元，

35、會在本書中的"軟件度量"相關(guān)章節(jié)中詳細描述。本節(jié)僅就同行評審中應(yīng)該注意搜集的數(shù)據(jù)進行一下說明。為了有效地提高同行評審過程的質(zhì)量，經(jīng)常需要對過程數(shù)據(jù)進行度量，通過度量分析可以看到同行評審效率怎樣，測試效果如何，作為進一步提高過程的依據(jù)，不斷改進的過程，提高產(chǎn)品質(zhì)量。某款軟件產(chǎn)品的設(shè)計文檔有20頁，按以往的估計，評審中將會有100個缺陷。但是，這次評審實際上僅僅發(fā)現(xiàn)了60個，原因何在？可以使用魚骨圖、因果圖對發(fā)現(xiàn)內(nèi)容進行分析，是具體的同行評審過程執(zhí)行得不好？還是經(jīng)驗不足？抑或是同行評審過程規(guī)定得有缺陷？是否規(guī)定了先看過再評審？還是產(chǎn)品的設(shè)計文檔質(zhì)量比較高？這些都需要考慮一下。4

36、.7.1 常用度量元對同行評審應(yīng)進行度量，如需要獲得評審準備的時間和評審時間以及這兩個時間之比，評審準備期間發(fā)現(xiàn)的缺陷數(shù)和評審期間發(fā)現(xiàn)的缺陷數(shù)以及這兩個數(shù)值之比，評審工作產(chǎn)品的規(guī)模和評審效率等主要內(nèi)容。具體的度量數(shù)據(jù)應(yīng)該包括：（1）主要問題的個數(shù)/同行評審投入的總工作量。這些工作量一般用人時來表示，其中包括準備、發(fā)現(xiàn)以及更正等所有環(huán)節(jié)和方面的工作量。（2）一般在缺陷會議結(jié)束時估計，然后在同行評審結(jié)束時得到實際值。（3）我們的效率是否正常/工作產(chǎn)品是否正常。（4）評審準備時發(fā)現(xiàn)缺陷數(shù)和評審時發(fā)現(xiàn)缺陷數(shù)及其比率。（5）記錄問題的個數(shù)/評審會議所用的時間，一般用個數(shù)/分鐘表示。（6）評審會

37、議結(jié)束后得到問題記錄的速率。（7）反映評審會議的控制是否得當。（8）評審專家的準備是否充分。（9）主要問題與所有記錄項的比率。（10）主要問題個數(shù)/所有記錄項個數(shù)。（11）判斷角色分配是否合理。（12）缺陷密度。（13）同行評審總?cè)毕輸?shù)和有效缺陷數(shù)及其比率。（14）評審文檔頁數(shù)（代碼行數(shù)）。（15）缺陷移除率和缺陷泄漏率。（16）準備時間和評審時間（小時）及其比率。（17）同行評審的缺陷打開和關(guān)閉的情況統(tǒng)計。（18）同行評審的效率、評審速率的度量。（19）同行評審的覆蓋率。4.7.2 同行評審的質(zhì)量準則根據(jù)Watte Humphrey于1998年提出的經(jīng)驗數(shù)據(jù)，設(shè)計階段同行

38、評審工作量應(yīng)該占到該階段工作量1/3或以上，代碼評審工作量也要占到編碼和單元測試階段的工作量1/3以上。如果它們都只占到15%，此時同行評審的質(zhì)量系數(shù)僅僅是0.5。業(yè)界的通用準則如下：（1）設(shè)計同行評審工作量應(yīng)占設(shè)計階段總工作量的1/3以上，其質(zhì)量準則為：設(shè)計文檔同行評審應(yīng)該至少發(fā)現(xiàn)3個缺陷/頁。經(jīng)評審修改后，缺陷清除率1級100%，2級100%，3級80%以上，殘留缺陷密度控制在0.5個/頁以下。（2）代碼同行評審工作量應(yīng)占實現(xiàn)階段總工作量的1/3以上。（3）同行評審準備過程發(fā)現(xiàn)的缺陷數(shù)應(yīng)該是同行評審會上發(fā)現(xiàn)的缺陷數(shù)的2倍以上。4.7.3 建議的同行評審效率如果在軟件開發(fā)全過程中使

39、用同行評審及審查，它們的總工作量要占10%的開發(fā)工作量。1同行評審準備效率（1）需求250行（5頁）/小時；（2）概要設(shè)計200行（4頁）/小時；（3）詳細設(shè)計150行（3頁）/小時；（4）源碼150行（無注釋）/小時。2同行評審會議效率（1）每20頁敘述性文檔，需要40人時；（2）每12頁概要設(shè)計，需要30人時；（3）每1000行代碼，需要55人時。審查的效率取決于以下因素：（1）在準備和實施過程中所耗費的時間和工作量；（2）實際的審查速度超過推薦的審查速度時，審查效率往往會降低；（3）最佳的審查速度取決于所審查的產(chǎn)品類型與審查人員的技能和經(jīng)驗。4.7.4 同行評審覆蓋率在有效的開

40、發(fā)過程中，一般對同行評審有如下的覆蓋率要求。（1）對需求的同行評審覆蓋率要求100%；（2）對設(shè)計的同行評審覆蓋率要求100%；（3）對系統(tǒng)和驗收測試用例的同行評審覆蓋率要求100%；（4）對代碼的同行評審覆蓋率要求不少于30%。新編代碼的關(guān)鍵部位和關(guān)鍵算法要進行100%的同行評審（此比例不能放松，每個分支的組合條件都要審查）。非新編代碼采取采樣評審，采樣比不少于25%。4.8 評審常見問題根據(jù)Humphrey的經(jīng)驗，審查不能發(fā)揮作用的原因大致如下：（1）最大的問題是進度緊張而且管理重視不足，使得審查流于形式；（2）實施審查的方法不當；（3）準備不足；（4）參與人員太多或者參與人員不

41、能勝任，或者有管理人員參與；（5）一次涵蓋的內(nèi)容太多；（6）在記錄會議中試圖修復問題；（7）記錄會議拖沓冗長；（8）對個人進行評價等。同行評審常見問題總結(jié)如圖4-3所示。 （點擊查看大圖）圖4-3 同行評審常見問題其中有些原因和解決方式在前面"同行評審遵循的原則"中已經(jīng)講到了，在本書的后續(xù)章節(jié)中也會述及。4.8.1 文化問題現(xiàn)象1：進度驅(qū)動而不是質(zhì)量驅(qū)動沒有重視產(chǎn)品質(zhì)量，造成評審的時間被一再擠壓，特別是工作產(chǎn)品的預(yù)審時間?，F(xiàn)象2：管理層沒有為評審明確期望的目標管理者沒有為評審提供有效的方針和環(huán)境，同時對于沒有參加評審的人員或者不合格的評審沒有任

42、何說法或者措施。此時，可以請管理者發(fā)布管理方針，闡明審核目標；要求開發(fā)組成員遵守政策?，F(xiàn)象3：一些開發(fā)組成員拒絕評審其他人的工作或者合作不理解軟件開發(fā)是集體努力的結(jié)果，怕暴露自己的缺點或不足，怕評審過程得罪人。要教育大家，所有工作人員作的努力可以幫助同事改進他們的產(chǎn)品，延長產(chǎn)品的生命周期，使產(chǎn)品的維護人員、公司及客戶受益。參與評審的人員以及他們對于質(zhì)量的態(tài)度最能決定評審的成功與否。其中最重要的是開發(fā)組成員自覺地希望同行來發(fā)現(xiàn)錯誤，而不是由用戶最終發(fā)現(xiàn)?，F(xiàn)象4：人身攻擊和諷刺很普遍，作者處于防衛(wèi)狀態(tài)當組建評審小組時，要預(yù)防個人沖突，個人沖突將會降低評審的效率。如果有必要，將犯規(guī)者趕出評審小組或停

43、止評審過程，并向過程管理者說明為什么要這樣做。安排一個關(guān)于如何在團體內(nèi)進行有效溝通的輔導課程，要確保那些犯規(guī)者必須參加，并說明這是進修的培訓而不是懲罰措施。現(xiàn)象5：評審中收集的數(shù)據(jù)沒有在其他任何地方使用確保數(shù)據(jù)提供給同行評審主持人，并且將數(shù)據(jù)存儲在知識庫中。采取措施讓管理層、同級評審過程擁有者和同級評審協(xié)調(diào)者決定哪些數(shù)據(jù)是重要的，以及如何最好地提交數(shù)據(jù)。提供適當?shù)臄?shù)據(jù)分析和報告工具。如果經(jīng)過所有這些努力，數(shù)據(jù)仍然不能被使用，停止收集數(shù)據(jù)。4.8.2 準備問題評審的問題很大一部分出現(xiàn)在準備上，這不僅僅是說某個項目的評審準備，甚至可能是整個組織內(nèi)部對評審工作沒有制定相關(guān)的標準和規(guī)范，沒有

44、建立組織級過程?，F(xiàn)象1：在項目計劃中沒有列入大的評審工作由于沒有明確的組織過程遵循，造成評審計劃草率、不合實際，或沒有及時調(diào)整，或?qū)嵤┎涣?。由于計劃組織不充分，評審資源沒有得到保證，資深技術(shù)人員或者評審人員忙于其他工作，沒有投入足夠的時間?，F(xiàn)象2：沒有接受培訓此評審人員的選拔是很重要的。如果確實沒有合適的人選，那么在評審準備階段進行評審所需的知識和技能的培訓是很有必要的。評審員一般是領(lǐng)域?qū)＜叶皇窃u審活動的專家，他們沒有掌握進行評審的方法、技巧、過程等，因此需要對評審員進行培訓。對評審員的培訓也可以區(qū)分為簡單培訓與詳細培訓兩種。簡單培訓可能需要十幾分鐘或者幾十分鐘，需要將在評審過程中需要把握的

45、基本原則及要注意的常見問題說清楚；詳細培訓需要對評審的方法、技巧、過程進行正式的培訓，需要花費較長的時間，是一個獨立的活動。對于主持人來說，掌握完整的審查原則和方法對他們來說是絕對必要的。培訓不僅可以向他們傳授基本技能，同時也有助于他們建立信心，來組織往往有爭議的審查工作?，F(xiàn)象3：直到評審會議上評審人員才看文檔，而沒有提前閱讀文檔并提出大部分問題造成這一現(xiàn)象的原因可能是評審人員事情太多，也可能是因為評審人員對會議有依賴心理，不愿意閱讀文檔，只希望到會議上聽別人解說。不做準備而完全靠評審會議上的有限時間來進行評審是評審失敗的主要原因?，F(xiàn)象4：文檔質(zhì)量太差作者缺少自我檢查，或因計劃不合理，提交的文

46、檔是沒有任何復查的"草稿"。一定要注意，正式評審中提交的文檔應(yīng)該是經(jīng)過被評審人員自己充分檢查過的文檔，不能把查問題的責任完全推給評審人員。對于明顯未達到要求的文檔，需要退回修改后再提交評審。判斷作者在提交評審前是否試圖完善了他們的產(chǎn)品。在工作進行了一小部分后即進行預(yù)評審以糾正系統(tǒng)錯誤，及早提供改進的機會，以便作者能夠保持適度的熱情。4.8.3 焦點問題現(xiàn)象1：沒有遵循2/8原則注意評審的重點要評審的對象內(nèi)容需要有側(cè)重點，一般按照2/8原則確定主要內(nèi)容進行評審，而不要泛泛地對整篇文章進行處理?，F(xiàn)象2：就某個文檔而孤立地評審該文檔，沒有對照已有的成果和標準需求和設(shè)計是

47、軟件開發(fā)項目的中間文檔，前面會有一些約定輸入，也可能會要求遵守相關(guān)標準。除非是對這些輸入的內(nèi)容已經(jīng)了如指掌，可以敏感地發(fā)現(xiàn)互相之間的不一致性；否則一定要考慮仔細對照相關(guān)的輸入。就某個系統(tǒng)而評審該系統(tǒng)，沒有考慮相關(guān)系統(tǒng)。當客戶或企業(yè)已經(jīng)開發(fā)了多個軟件系統(tǒng)之后，系統(tǒng)之間的相關(guān)性必須是考慮的因素，這些相關(guān)性包括數(shù)據(jù)之間的關(guān)系、業(yè)務(wù)之間的關(guān)系、用戶管理、系統(tǒng)管理的一致性，操作習慣和界面的關(guān)聯(lián)性和軟件復用等。現(xiàn)象3：會議上過多地討論問題如何改正評審的目的主要在于定位問題，一旦正確地確認了問題，大多數(shù)都能很快找到解決方案，對于一時無法給出解決方案的問題可以在評審后研究討論。因此，一般的同行評審會建議如果在

48、一個問題上超過3分鐘，可以做出結(jié)論并到下一個問題；如果評審專家之間有不同意見，做出記錄，得到結(jié)論并到下一個問題。當評審專家討論起解決方案時，主持人可以要求他們在會后討論?，F(xiàn)象4：評審與評價混淆評審的目的是指出具體問題以便改進，評價是給最終工作結(jié)果及人員工作績效下結(jié)論。不能把這二者混為一談，尤其是把評審結(jié)果作為評價個人能力的指標時，對評審活動的進一步開展很不利。4.8.4 人員問題為了保證評審的質(zhì)量和效率，需要精心挑選評審員?，F(xiàn)象1：評審人員選擇不合理無論什么領(lǐng)域評審，都是同樣的評審專家。首先，要保證不同類型的人員都要參與進來，否則很可能會漏掉很重要的需求。其次，在不同類型的人員中要選擇那些真正和系統(tǒng)相關(guān)的，對系統(tǒng)有足夠了解的人員參與進來，否則很可能使評審效率降低或者最終不切實際地修改了系統(tǒng)的范圍?，F(xiàn)象2：評審人員搭配不合理在選擇評審人員時，遺漏了某些角度或?qū)哟蔚娜藛T。一定要注意，和每個軟件開發(fā)項目團隊的人員搭配一樣，評審人員的搭配也應(yīng)該盡可能合理，考慮全面性和有效性?？梢杂蒙鲜鲈u審角色層次結(jié)構(gòu)與角度結(jié)構(gòu)（可進一步完善）來發(fā)現(xiàn)選拔各個層次和角度的評審人員，建立公司級別的評審人員庫，在需要評審的項目中針對具體情況組合評審隊伍?，F(xiàn)象3：評審專家的狀態(tài)在評審過程中應(yīng)當要有實事求是的態(tài)度，不知道的事情應(yīng)當問清楚，不要不懂裝懂，盲目地下結(jié)論。軟件開發(fā)隊伍中總