同行評審在軟件質(zhì)量管理中的應(yīng)用

同行評審在軟件質(zhì)量管理中的應(yīng)用

■ 牛少紅 朱彩云

按當(dāng)代軟件工程的一般認(rèn)識，嚴(yán)格的軟件測試是確保軟件質(zhì)量的重要手段。然而這是一項費(fèi)時、費(fèi)錢的浩大工程，用于測試的時間多于用于開發(fā)的時間，用于測試的費(fèi)用多于用于開發(fā)的費(fèi)用。即使通過嚴(yán)格的測試，發(fā)現(xiàn)的問題得到全部解決，也不能保證軟件不再出現(xiàn)各種問題。國外大型軟件公司在多年的實(shí)踐中，總結(jié)出了既能節(jié)約經(jīng)費(fèi)，縮短開發(fā)周期，又能提高軟件質(zhì)量的有效手段，這就是“同行評審”。

一、同行評審的基本概念

同行評審是指“由軟件開發(fā)者的同行遵循已定義的規(guī)程對軟件產(chǎn)品進(jìn)行的技術(shù)評審”。其目的是及早和高效地從軟件開發(fā)過程中識別并消除缺陷，讓軟件變得更易理解和維護(hù)，同時減少傳遞到最終軟件產(chǎn)品中的缺陷。同行評審的主要目的，一是發(fā)現(xiàn)開發(fā)過程中文檔和軟件的具體錯誤，二是通過對這些錯誤的分類和統(tǒng)計，發(fā)現(xiàn)共同的錯誤類型和將來避免這類錯誤的方法，提供今后對所發(fā)現(xiàn)的同類錯誤進(jìn)行控制的數(shù)據(jù)。通過對開發(fā)過程中文檔和軟件的反饋和從錯誤中汲取教訓(xùn)，避免今后類似的缺陷和錯誤發(fā)生。

同行評審并不能代替軟件測試，就像自檢、互檢不能代替專檢一樣。那么，為什么要引入同行評審呢？這是因為，有些軟件產(chǎn)品在早期階段就可以通過同行評審的方法發(fā)現(xiàn)缺陷，但無法對其進(jìn)行測試；即使到了編碼階段，測試活動也不能發(fā)現(xiàn)某些特定類型的缺陷（例如違反編程規(guī)范）。

在軟件的開發(fā)過程中，上一階段軟件產(chǎn)品中隱藏的缺陷不斷往下一階段軟件產(chǎn)品傳遞并擴(kuò)散，最終形成的軟件產(chǎn)品是一個包含多種缺陷的距離用戶真正需求很遠(yuǎn)的一個“東西”。這也要求軟件開發(fā)者在軟件開發(fā)的過程中不斷進(jìn)行同行評審，盡量減少傳遞到下一個階段的缺陷。軟件開發(fā)各階段缺陷放大圖如圖1所示：

成功的同行評審是提高軟件質(zhì)量和工作效率的重要因素，不管人們喜歡與否，審查過程會迫使每個人在一種開放式的環(huán)境中工作。一旦軟件開發(fā)人員意識到了他們的工作都要接受同行評審，他們就會較早地將他們的工作公之于眾，以待監(jiān)督。在同行評審上的投入能把組織的一些質(zhì)量成本從昂貴的測試以及后期大規(guī)模的返工轉(zhuǎn)變?yōu)樵缙诘娜毕莅l(fā)現(xiàn)。更重要的是，軟件開發(fā)人員學(xué)到了如何將工作做得更好，提高了組織的整體素質(zhì)，從而避免了缺陷。

雖然同行評審的準(zhǔn)備、活動和跟蹤需要花費(fèi)一定的時間和工作量，但這些可以在測試中節(jié)省更多。從經(jīng)濟(jì)角度考慮，許多缺陷是在早期階段注入的，越早消除缺陷就越能降低開發(fā)成本。據(jù)統(tǒng)計，對于保存精確記錄的大系統(tǒng)，一套完整的同行評審體系能夠使項目在每個測試階段出現(xiàn)的錯誤減少90%。這樣一來，即使在綜合考慮同行評審活動成本的情況下，同行評審活動也會使測試成本下降50%～80%。同時，通過同行評審，開發(fā)人員能夠及時地得到專家的幫助和指導(dǎo)，加深對工作成果的理解，更好地預(yù)防缺陷，在一定程度上提高了開發(fā)生產(chǎn)率。

圖1 開發(fā)各階段缺陷放大圖

二、同行評審的種類和對象

同行評審的種類有很多，自從IBM的Fagan發(fā)明了同行評審之后，軟件行業(yè)提出了很多同行評審模型，比較著名的有IEEE1028評審、微軟的技術(shù)評審、GillGraham審查、VanEmden審查、Yourdon結(jié)構(gòu)化走查等。

（一）同行評審的種類

本文中按照CMMI模型的提法，將同行評審分為3 類。

1．正式評審（Inspection）。通常是由經(jīng)過同行評審培訓(xùn)的項目經(jīng)理或PPQA主持，規(guī)模在 3～7人之間為宜，一般在完成了一個階段軟件產(chǎn)品后對其進(jìn)行的評審。正式評審的目的在于定位并除去階段軟件產(chǎn)品中的缺陷。

2．技術(shù)審查（TechnicalReviews），或稱內(nèi)部評審，通常由技術(shù)負(fù)責(zé)人或項目經(jīng)理召集，三人以上參加。技術(shù)審查一般是在階段軟件產(chǎn)品的中期進(jìn)行或完成了某部分獨(dú)立的階段軟件產(chǎn)品時進(jìn)行，也可在書寫草案遇到問題時就其中專門的一兩項問題討論和審查，或是檢查階段軟件產(chǎn)品與規(guī)程、模板、計劃、標(biāo)準(zhǔn)的符合性或者變更是否被正確地執(zhí)行。技術(shù)審查的目的在于通過對開發(fā)人員的階段軟件產(chǎn)品的技術(shù)審查，提出改進(jìn)意見。

3．走查（Walkthrough），又叫代碼走查或代碼走讀，審查的范圍根據(jù)需求的優(yōu)先級通常由管理人員來確定，主要是靜態(tài)質(zhì)量分析和編程規(guī)則檢查。通常是小型討論會，一般是在階段軟件產(chǎn)品形成的早期進(jìn)行，編制者有一定的想法時，希望從中獲得一些幫助或補(bǔ)充一些想法。當(dāng)然也可以在編制階段軟件產(chǎn)品的任何階段進(jìn)行，兩三個人參加，由編制者主持，主要是評估和提高階段軟件產(chǎn)品的質(zhì)量或教育參加者。

其中，“正式評審”是正式的同行評審方法，“技術(shù)審查”和“走查”是常用的非正式同行評審方法。

（二）同行評審的對象

同行評審的對象包括所有軟件開發(fā)的中間和最終階段軟件產(chǎn)品，例如包括：

（1）產(chǎn)品需求規(guī)格說明書；

（2）用戶界面規(guī)范及設(shè)計；

（3）架構(gòu)設(shè)計、概要設(shè)計、詳細(xì)設(shè)計及模型；

（4）源代碼；

（5）測試計劃、設(shè)計、用例及步驟；

（6）項目計劃，包括開發(fā)計劃、配置管理計劃和質(zhì)量保證計劃等。

所有這些會涉及的評審內(nèi)容，應(yīng)該在編制的項目計劃或者小的開發(fā)計劃中體現(xiàn)，不應(yīng)該也不能是臨時性的安排。

三、同行評審的過程

根據(jù)同行評審的重要程度，正式評審、技術(shù)審查和走查三種形式的流程和評審結(jié)果的使用力度不盡相同，但其主要的步驟和內(nèi)容大體一致。

評審組的組成一般包括主持人一名、記錄人一名、評審人2-5人，被評人參加。

（一）正式評審流程

正式評審包括下述6個基本步驟。

1．預(yù)備：為保證評審的質(zhì)量，可以先進(jìn)行一個預(yù)備會議。

會議首先由作者花幾分鐘的時間向評審組概要介紹評審材料，例如講解一下本階段軟件產(chǎn)品的目標(biāo)是什么，其他相關(guān)的實(shí)現(xiàn)細(xì)節(jié)、開發(fā)標(biāo)準(zhǔn)等。應(yīng)該允許甚至鼓勵評審組成員動手查看階段軟件產(chǎn)品，或者查看開發(fā)過程中所用到的檢查單等。這個講解的過程從某種角度上來說，也保證了作者提交階段軟件產(chǎn)品的質(zhì)量。會議結(jié)束時把文檔分發(fā)給每位與會者，下發(fā)的材料應(yīng)該控制在2小時之內(nèi)審核完成為宜。這些文檔可以包括：

? 要審查的階段軟件產(chǎn)品；

? 參考文檔；

? 階段軟件產(chǎn)品評審檢查表；

? 階段軟件產(chǎn)品審閱情況記錄表。

2．審查：在預(yù)備會和正式評審會之間，評審小組成員對階段軟件產(chǎn)品進(jìn)行徹底檢查，并依據(jù)相關(guān)標(biāo)準(zhǔn)和準(zhǔn)則評審階段軟件產(chǎn)品，記錄發(fā)現(xiàn)的缺陷、問題種類與嚴(yán)重程度、所用的時間等。

3．評審：在預(yù)定的正式評審時間內(nèi)（會議時間建議控制在2小時），評審小組成員以會議形式聚在一起，依次對產(chǎn)品進(jìn)行檢查。每個評審員花一定的時間（一般為十幾分鐘）指出問題，并和作者確定問題和定義問題的嚴(yán)重程度。注意，評審過程中是發(fā)現(xiàn)錯誤，而不是現(xiàn)場改正它們。

會議中，記錄員詳細(xì)記錄每一個已達(dá)成共識的缺陷，包括缺陷的位置、簡短描述缺陷、缺陷類別、該缺陷的發(fā)現(xiàn)者等。未達(dá)成共識的缺陷也將記錄下來，加入“待處理”或者TBD標(biāo)識，評審主持人將指派作者和評審員在會后處理評審會議中未能解決的問題。

4．書寫評審報告：評審主持人根據(jù)記錄員的記錄和自己的總結(jié)，在一天內(nèi)寫出評審報告，內(nèi)容包括：

? 根據(jù)評審專家個人的輸入創(chuàng)建總的問題清單；

? 加入會議中發(fā)現(xiàn)的問題；

? 剔除經(jīng)確認(rèn)屬于重復(fù)或者無效的問題；

? 共同確定需要修改的問題及修改的程度。

5．返工：作者根據(jù)評審報告的決議，負(fù)責(zé)解決確定的所有缺陷和問題。

6．跟蹤：評審組長必須確保所提出的每個問題都得到了圓滿解決。必須仔細(xì)檢查對文檔的每個修正，以確保沒有注入新的錯誤。

（二）技術(shù)審查流程

技術(shù)審查通常包括下述3個基本步驟。

1．準(zhǔn)備：評審組長（通常是項目經(jīng)理）要求項目組成員提供需要考慮的特定問題并分發(fā)評審材料。評審組長確定評審重點(diǎn)：

? 需要注意的特定問題；

? 需要滿足的特殊標(biāo)準(zhǔn)或規(guī)格說明；

? 需要審查的接口或依賴關(guān)系。

2．評審：評審人各自審查評審材料，目的是發(fā)現(xiàn)錯誤，而不是改正它們（通常每次評審會不超過1小時）。評審組組長應(yīng)在一天內(nèi)寫出評審報告。評審會議內(nèi)容包括：

? 匯總個人發(fā)現(xiàn)的問題；

? 加入會議中發(fā)現(xiàn)的問題。

3．跟蹤：作者負(fù)責(zé)解決評審報告中的所有錯誤及問題。評審組長檢查所提出的每個問題都得到了解決。組長起草評審發(fā)現(xiàn)報告：

? 問題或弱項清單；

? 小組對如何解決這些問題或弱項清單的建議；

? 行動事項。

（三）走查流程

走查對形式的要求更為簡單，主要有下述兩種方式。

1．參與者驅(qū)動法：參與者按照事先準(zhǔn)備好的列表，提出他們不理解的術(shù)語和認(rèn)為不正確的術(shù)語。作者必須回答每個質(zhì)疑，要么承認(rèn)確實(shí)有錯誤，要么對質(zhì)疑做出解釋。

2．文檔驅(qū)動法：作者向評審人仔細(xì)解釋文檔（或代碼）。在此過程中，可以將評審的內(nèi)容（如關(guān)鍵代碼、架構(gòu)圖、業(yè)務(wù)邏輯圖等）用投影儀投射到屏幕上，作者對階段軟件產(chǎn)品進(jìn)行講解，評審人不時針對事先準(zhǔn)備好的問題或解釋過程中發(fā)現(xiàn)的問題提出質(zhì)疑。它比參與者驅(qū)動法可能更有效，往往能檢查出更多錯誤。經(jīng)驗表明，使用文檔驅(qū)動法時許多錯誤是由文檔講解者自己發(fā)現(xiàn)的。

在走查過程中，每個評審人都要記錄錯誤或建議，會后要整理會議記錄，作為走查報告。階段軟件產(chǎn)品的作者可以根據(jù)自己的思路對走查報告質(zhì)疑。

圖2 三種同行評審方式的比較

四、同行評審方式的選擇

對于同一個階段軟件產(chǎn)品，根據(jù)所處的階段可以使用不同的評審方式。如對于階段軟件產(chǎn)品剛剛勾畫、起草時，可以采用走查方式；對于完成了某一個單獨(dú)的章節(jié)，可以采用技術(shù)審查方式；待整個產(chǎn)品完成，使用正式評審全面考察。

（一）三種同行評審方式的比較

對不同的階段軟件產(chǎn)品，可以根據(jù)圖2建議結(jié)合項目情況進(jìn)行調(diào)整和裁剪。

（二）同行評審的結(jié)果

同行評審的結(jié)果通常有3種：

1．正常：評審專家做好了評審準(zhǔn)備，會議正常，結(jié)果明確，不需要再次評審；

2．延期：30%以上評審專家沒有做好準(zhǔn)備，會議無法正常進(jìn)行，需要確定再次評審時間；

3．取消：在初審階段就發(fā)現(xiàn)很多問題，需要作者進(jìn)行修正，然后再進(jìn)行第二次同行評審。

五、結(jié)束語

實(shí)踐表明，應(yīng)用同行評審這一手段，可極大提高發(fā)現(xiàn)軟件缺陷的效率，降低測試費(fèi)用。AT&T的貝爾實(shí)驗室在其開發(fā)大型電力交換系統(tǒng)時，發(fā)現(xiàn)單個錯誤的成本降低了90%。在發(fā)現(xiàn)錯誤方面，審查的成效是測試的20倍。TRW對一個大型軟件進(jìn)行了研究，發(fā)現(xiàn)2019個由用戶發(fā)現(xiàn)的錯誤導(dǎo)致代碼變更。分析結(jié)果表明，在這些錯誤中，通過代碼審查可以發(fā)現(xiàn)62.7%，通過設(shè)計審查可以發(fā)現(xiàn)57.7%。

（作者單位：駐北京地區(qū)軍事代表室，航天二院206所）