同行評審在軟件質量管理中的應用
■ 牛少紅 朱彩云
按當代軟件工程的一般認識,嚴格的軟件測試是確保軟件質量的重要手段。然而這是一項費時、費錢的浩大工程,用于測試的時間多于用于開發的時間,用于測試的費用多于用于開發的費用。即使通過嚴格的測試,發現的問題得到全部解決,也不能保證軟件不再出現各種問題。國外大型軟件公司在多年的實踐中,總結出了既能節約經費,縮短開發周期,又能提高軟件質量的有效手段,這就是“同行評審”。
同行評審是指“由軟件開發者的同行遵循已定義的規程對軟件產品進行的技術評審”。其目的是及早和高效地從軟件開發過程中識別并消除缺陷,讓軟件變得更易理解和維護,同時減少傳遞到最終軟件產品中的缺陷。同行評審的主要目的,一是發現開發過程中文檔和軟件的具體錯誤,二是通過對這些錯誤的分類和統計,發現共同的錯誤類型和將來避免這類錯誤的方法,提供今后對所發現的同類錯誤進行控制的數據。通過對開發過程中文檔和軟件的反饋和從錯誤中汲取教訓,避免今后類似的缺陷和錯誤發生。
同行評審并不能代替軟件測試,就像自檢、互檢不能代替專檢一樣。那么,為什么要引入同行評審呢?這是因為,有些軟件產品在早期階段就可以通過同行評審的方法發現缺陷,但無法對其進行測試;即使到了編碼階段,測試活動也不能發現某些特定類型的缺陷(例如違反編程規范)。
在軟件的開發過程中,上一階段軟件產品中隱藏的缺陷不斷往下一階段軟件產品傳遞并擴散,最終形成的軟件產品是一個包含多種缺陷的距離用戶真正需求很遠的一個“東西”。這也要求軟件開發者在軟件開發的過程中不斷進行同行評審,盡量減少傳遞到下一個階段的缺陷。軟件開發各階段缺陷放大圖如圖1所示:
成功的同行評審是提高軟件質量和工作效率的重要因素,不管人們喜歡與否,審查過程會迫使每個人在一種開放式的環境中工作。一旦軟件開發人員意識到了他們的工作都要接受同行評審,他們就會較早地將他們的工作公之于眾,以待監督。在同行評審上的投入能把組織的一些質量成本從昂貴的測試以及后期大規模的返工轉變為早期的缺陷發現。更重要的是,軟件開發人員學到了如何將工作做得更好,提高了組織的整體素質,從而避免了缺陷。
雖然同行評審的準備、活動和跟蹤需要花費一定的時間和工作量,但這些可以在測試中節省更多。從經濟角度考慮,許多缺陷是在早期階段注入的,越早消除缺陷就越能降低開發成本。據統計,對于保存精確記錄的大系統,一套完整的同行評審體系能夠使項目在每個測試階段出現的錯誤減少90%。這樣一來,即使在綜合考慮同行評審活動成本的情況下,同行評審活動也會使測試成本下降50%~80%。同時,通過同行評審,開發人員能夠及時地得到專家的幫助和指導,加深對工作成果的理解,更好地預防缺陷,在一定程度上提高了開發生產率。

圖1 開發各階段缺陷放大圖
同行評審的種類有很多,自從IBM的Fagan發明了同行評審之后,軟件行業提出了很多同行評審模型,比較著名的有IEEE1028評審、微軟的技術評審、GillGraham審查、VanEmden審查、Yourdon結構化走查等。
(一)同行評審的種類
本文中按照CMMI模型的提法,將同行評審分為3 類。
1.正式評審(Inspection)。通常是由經過同行評審培訓的項目經理或PPQA主持,規模在 3~7人之間為宜,一般在完成了一個階段軟件產品后對其進行的評審。正式評審的目的在于定位并除去階段軟件產品中的缺陷。
2.技術審查(TechnicalReviews),或稱內部評審,通常由技術負責人或項目經理召集,三人以上參加。技術審查一般是在階段軟件產品的中期進行或完成了某部分獨立的階段軟件產品時進行,也可在書寫草案遇到問題時就其中專門的一兩項問題討論和審查,或是檢查階段軟件產品與規程、模板、計劃、標準的符合性或者變更是否被正確地執行。技術審查的目的在于通過對開發人員的階段軟件產品的技術審查,提出改進意見。
3.走查(Walkthrough),又叫代碼走查或代碼走讀,審查的范圍根據需求的優先級通常由管理人員來確定,主要是靜態質量分析和編程規則檢查。通常是小型討論會,一般是在階段軟件產品形成的早期進行,編制者有一定的想法時,希望從中獲得一些幫助或補充一些想法。當然也可以在編制階段軟件產品的任何階段進行,兩三個人參加,由編制者主持,主要是評估和提高階段軟件產品的質量或教育參加者。
其中,“正式評審”是正式的同行評審方法,“技術審查”和“走查”是常用的非正式同行評審方法。
(二)同行評審的對象
同行評審的對象包括所有軟件開發的中間和最終階段軟件產品,例如包括:
(1)產品需求規格說明書;
(2)用戶界面規范及設計;
(3)架構設計、概要設計、詳細設計及模型;
(4)源代碼;
(5)測試計劃、設計、用例及步驟;
(6)項目計劃,包括開發計劃、配置管理計劃和質量保證計劃等。
所有這些會涉及的評審內容,應該在編制的項目計劃或者小的開發計劃中體現,不應該也不能是臨時性的安排。
根據同行評審的重要程度,正式評審、技術審查和走查三種形式的流程和評審結果的使用力度不盡相同,但其主要的步驟和內容大體一致。
評審組的組成一般包括主持人一名、記錄人一名、評審人2-5人,被評人參加。
(一)正式評審流程
正式評審包括下述6個基本步驟。
1.預備:為保證評審的質量,可以先進行一個預備會議。
會議首先由作者花幾分鐘的時間向評審組概要介紹評審材料,例如講解一下本階段軟件產品的目標是什么,其他相關的實現細節、開發標準等。應該允許甚至鼓勵評審組成員動手查看階段軟件產品,或者查看開發過程中所用到的檢查單等。這個講解的過程從某種角度上來說,也保證了作者提交階段軟件產品的質量。會議結束時把文檔分發給每位與會者,下發的材料應該控制在2小時之內審核完成為宜。這些文檔可以包括:
? 要審查的階段軟件產品;
? 參考文檔;
? 階段軟件產品評審檢查表;
? 階段軟件產品審閱情況記錄表。
2.審查:在預備會和正式評審會之間,評審小組成員對階段軟件產品進行徹底檢查,并依據相關標準和準則評審階段軟件產品,記錄發現的缺陷、問題種類與嚴重程度、所用的時間等。
3.評審:在預定的正式評審時間內(會議時間建議控制在2小時),評審小組成員以會議形式聚在一起,依次對產品進行檢查。每個評審員花一定的時間(一般為十幾分鐘)指出問題,并和作者確定問題和定義問題的嚴重程度。注意,評審過程中是發現錯誤,而不是現場改正它們。
會議中,記錄員詳細記錄每一個已達成共識的缺陷,包括缺陷的位置、簡短描述缺陷、缺陷類別、該缺陷的發現者等。未達成共識的缺陷也將記錄下來,加入“待處理”或者TBD標識,評審主持人將指派作者和評審員在會后處理評審會議中未能解決的問題。
4.書寫評審報告:評審主持人根據記錄員的記錄和自己的總結,在一天內寫出評審報告,內容包括:
? 根據評審專家個人的輸入創建總的問題清單;
? 加入會議中發現的問題;
? 剔除經確認屬于重復或者無效的問題;
? 共同確定需要修改的問題及修改的程度。
5.返工:作者根據評審報告的決議,負責解決確定的所有缺陷和問題。
6.跟蹤:評審組長必須確保所提出的每個問題都得到了圓滿解決。必須仔細檢查對文檔的每個修正,以確保沒有注入新的錯誤。
(二)技術審查流程
技術審查通常包括下述3個基本步驟。
1.準備:評審組長(通常是項目經理)要求項目組成員提供需要考慮的特定問題并分發評審材料。評審組長確定評審重點:
? 需要注意的特定問題;
? 需要滿足的特殊標準或規格說明;
? 需要審查的接口或依賴關系。
2.評審:評審人各自審查評審材料,目的是發現錯誤,而不是改正它們(通常每次評審會不超過1小時)。評審組組長應在一天內寫出評審報告。評審會議內容包括:
? 匯總個人發現的問題;
? 加入會議中發現的問題。
3.跟蹤:作者負責解決評審報告中的所有錯誤及問題。評審組長檢查所提出的每個問題都得到了解決。組長起草評審發現報告:
? 問題或弱項清單;
? 小組對如何解決這些問題或弱項清單的建議;
? 行動事項。
(三)走查流程
走查對形式的要求更為簡單,主要有下述兩種方式。
1.參與者驅動法:參與者按照事先準備好的列表,提出他們不理解的術語和認為不正確的術語。作者必須回答每個質疑,要么承認確實有錯誤,要么對質疑做出解釋。
2.文檔驅動法:作者向評審人仔細解釋文檔(或代碼)。在此過程中,可以將評審的內容(如關鍵代碼、架構圖、業務邏輯圖等)用投影儀投射到屏幕上,作者對階段軟件產品進行講解,評審人不時針對事先準備好的問題或解釋過程中發現的問題提出質疑。它比參與者驅動法可能更有效,往往能檢查出更多錯誤。經驗表明,使用文檔驅動法時許多錯誤是由文檔講解者自己發現的。
在走查過程中,每個評審人都要記錄錯誤或建議,會后要整理會議記錄,作為走查報告。階段軟件產品的作者可以根據自己的思路對走查報告質疑。

圖2 三種同行評審方式的比較
對于同一個階段軟件產品,根據所處的階段可以使用不同的評審方式。如對于階段軟件產品剛剛勾畫、起草時,可以采用走查方式;對于完成了某一個單獨的章節,可以采用技術審查方式;待整個產品完成,使用正式評審全面考察。
(一)三種同行評審方式的比較
對不同的階段軟件產品,可以根據圖2建議結合項目情況進行調整和裁剪。
(二)同行評審的結果
同行評審的結果通常有3種:
1.正常:評審專家做好了評審準備,會議正常,結果明確,不需要再次評審;
2.延期:30%以上評審專家沒有做好準備,會議無法正常進行,需要確定再次評審時間;
3.取消:在初審階段就發現很多問題,需要作者進行修正,然后再進行第二次同行評審。
實踐表明,應用同行評審這一手段,可極大提高發現軟件缺陷的效率,降低測試費用。AT&T的貝爾實驗室在其開發大型電力交換系統時,發現單個錯誤的成本降低了90%。在發現錯誤方面,審查的成效是測試的20倍。TRW對一個大型軟件進行了研究,發現2019個由用戶發現的錯誤導致代碼變更。分析結果表明,在這些錯誤中,通過代碼審查可以發現62.7%,通過設計審查可以發現57.7%。
(作者單位:駐北京地區軍事代表室,航天二院206所)