崔海霞

摘要:文章介紹了一般軟件評審涉及的內容和軟件評審中的各個角色與職責,重點說明軟件評審的過程及評審的標準和評審中要注意的問題。同時也著重闡述了不同的軟件開發(fā)可以根據此評審過程進行裁剪,評審過程是幫助作者提前發(fā)現評審對象的缺陷,而不是對評審對象的發(fā)布執(zhí)行。

關鍵詞:軟件;預審;評審;評審專家;缺陷;質量

中圖分類號:TP311文獻標識碼:A文章編號:1009-3044(2010)11-2629-02

On Software Review

CUI Hai-xia

(Shanghai Lida Computer Department, Polytechnic Institute, Shanghai 201609, China)

Abstract: This article outlines the general content of the software involved in the review process for software management, and shows in the software review in the various roles and responsibilities, focusing on the software review process, methods and review criteria adopted, the assessment is necessary to pay attention to issues. This article also focuses on the different software development can be carried out based on this review process, cutting the judging process is to help authors found that early assessment of defects in the object, rather than the release of the implementation of the review object.

Key words: software; preliminary review; review; review export; bug; quality

在軟件開發(fā)管理中,人們總是希望用戶的需求非常明確,軟件的設計非常合理,代碼的實現完全正確,并且軟件開發(fā)可以按開發(fā)前制定的計劃正常進行。但是,實際中這個要求在軟件開發(fā)管理中往往是無法實現的,在實際的軟件開發(fā)中,人們也是通過各種方法力求達到這一要求,其中軟件評審就是一個很好的方法。軟件評審可以組織項目組集體的力量,對軟件相關內容進行合理分析,盡可能的在軟件的生命前期發(fā)現并解決問題,所以軟件評審的過程就顯得尤為重要。

1 概述

在軟件開發(fā)過程中軟件評審至關重要,它貫穿軟件開發(fā)的整個生命周期,是提高軟件質量,降低軟件成本,保證軟件開發(fā)合理進行的重要保障。

1.1 軟件評審的主要內容

軟件評審一般包括計劃評審,技術評審,過程評審,合同評審,管理評審等。計劃評審一般是指項目級別計劃的評審,具體又分為項目過程手冊評審、項目計劃書評審、項目WBS評審、質量保證計劃評審、配置管理計劃評審、項目工作任務書評審等。技術評審主要指售前技術方案,工作產品等的評審,具體分為架構設計、需求規(guī)格說明書、設計、代碼、測試計劃與測試案例、測試報告、部署驗證案例等的評審。過程評審主要是指對公司各級管理規(guī)范及過程文檔的評審,合同評審主要指銷售合同、采購合同、外包合同等的評審,管理評審主要指項目立項評審、項目結項評審等。

1.2 軟件評審過程的改進

軟件評審過程的改進主要由質量管理部門負責。質量管理部門統(tǒng)一匯集本過程的改進需求后,提交公司級軟件工程過程組,完成定義的過程改進任務。

2 軟件評審過程中各角色與職責

軟件評審中一般有5個角色:評審專家,講解者,作者,QA。其中作者不能擔當組織者、評審專家或講解者的角色,別的角色之間可以兼任,下面具體介紹一下各角色的職責與分工。

2.1 組織者

組織者是被審對象方面的專家、權威。主要負責:確保評審對象滿足發(fā)起評審的前提條件;與作者共同確定參加評審的人員;與評審專家一起確定評審時間表;確保評審專家有充分的時間參加評審,并在評審會議前已做好準備工作;決定評審的形式,詳細說明評審目的,需要時,給評審專家分配評審的關注點;組織評審會議,組織評審專家發(fā)現評審對象的缺陷,并對發(fā)現的缺陷進行分類;保證相關人員完成了各自的職責,如評審專家完成預審并提交反饋意見、作者根據評審意見對評審對象做了修改、遺留問題得到解決等,確保在跟蹤過程中發(fā)現的任何新的缺陷都已被標注并且添加到缺陷列表中去;協(xié)調評審專家的意見,對評審結論達成一致;裁決評審結論,通過、不通過;評審組織者可以兼任評審專家,執(zhí)行相應的職責。

2.2 評審專家

評審專家主要負責:確保參加評審的時長達到評審質量的要求;理解評審對象;會前預審,發(fā)現缺陷并反饋;準備并參加評審會議,會上對評審對象的缺陷進行確認;驗證作者修訂的評審對象。

2.3 講解者、作者和QA

講解者主要負責理解評審對象并在介紹會、評審會上講解評審對象,引導大家瀏覽評審對象。作者主要負責準備待評審的評審對象,并在評審會議上,確認評審專家的問題,根據評審意見,修改評審對象。QA主要負責評審過程審計,提供流程指導和過程數據指導,評審結論審核等。

3 軟件評審流程

3.1 軟件評審的一般流程

軟件的評審過程一般可以分為提交評審申請,發(fā)評審通知,介紹會議,預審,評審會,第三小時會議,評審總結等,下面具體介紹。

1) 提交評審申請:作者提交評審申請給組織者,評審申請除提交評審對象外還需提交建議的評審專家及評審點,同時說明評審對象的背景及關鍵評審點,供組織者參考。

2) 發(fā)評審通知:組織者對評審對象及內容進行審核,對作者建議的評審專家進行審核,根據實際情況添加及刪除評審專家,并跟評審專家做好溝通,確定他們能參加,并明確各自的角色與職責,制定評審的質量目標,決策評審對象是否符合評審條件,如果符合發(fā)評審通知,不符合打回給作者。

3) 介紹會議:如果評審專家反饋需要對被評審對象進行講解,組織者安排介紹會議并由講解者介紹待評審的評審對象。介紹會議是可選的,評審專家提出后,由組織者來決定是否需要舉行,介紹會議的目的是幫助評審專家了解評審對象,以便進行評審。

4) 預審:評審專家檢查評審對象,記錄發(fā)現的問題及問題的嚴重程度并反饋給作者,作者對問題進行答復,對接受的問題完成文檔修訂,同時對問題的類型、引入根源、模式進行初步分析,并記錄。評審專家必須反饋預審意見,即使沒有發(fā)現問題,也要反饋無意見。

5) 評審會:講解者引導大家瀏覽評審對象,確認預審發(fā)現的問題及作者對問題的答復,并對預審發(fā)現的問題做出缺陷分析結果,即對問題的類型、引入根源、模式、嚴重程度等進行確認。組織者對原記錄的問題類型、引入根源、模式、嚴重程度可進行修改并引導大家發(fā)現新的缺陷。記錄所有新增問題,包括存在疑問以及暫時無法裁決的問題。

6) 第三小時會議:目的是探討問題的解決方案。作者在進行問題修改的時候,對于那些自己無法解決的問題,需要評審專家的協(xié)助,這時候可要求召開第三小時會議。

7) 評審結論:組織者對本次評審給出意見,如:通過、不通過、需重新評審、終止等。QA對組織者的評審結論進行審核,對于不符合通過條件的評審,QA可不予批準,并要求組織者重新評審或終止評審。組織者可對不符合評審過程的評審提出《例外報告》請求讓步放行,但需經QA審核同意,本次評審方可通過。

3.2評審通過、不通過、終止的條件

1) 判定評審通過的條件:

全部達到如下條件時,評審可以通過。① 本次評審的質量目標達到;② 本次評審的過程附合規(guī)范;③ 評審發(fā)現的問題全部關閉,結論無掛起的問題;④ 反饋評審意見(包括反饋無意見)的評審專家不少于50%;⑤ 評審時間未超過計劃結束時間達10個工作日以上。

2) 評審不通過須重新評審的條件

有如下情況之一時,評審不通過需重新評審的條件。① 本次評審的質量目標未達到;② 過程不附合規(guī)范;③ 發(fā)現問題未全部關閉,且經影響分析,遺留問題會給項目帶來較大風險;④ 反饋評審意見(包括反饋無意見)的評審專家少于50%。

3)評審終止條件

如存在以下情況之一可終止評審。

① 經預審或評審發(fā)現評審對象完全不具備評審價值,如技術方案出現原則性錯誤;

② 評審時間超過計劃結束時間10個工作日以上仍無法關閉的情況;

③ 評審因其他情況被中止,如項目中止、評審對象被裁剪等。

3.3 評審中的注意事項

軟件評審雖然在軟件開發(fā)中非常重要,是軟件開發(fā)質量的重要保證,但軟件評審具體執(zhí)行時很容易形式話,或達不到預期的效果。下面總結了一些需要在評審中注意的問題。

評審之前,組織者對評審對象做審查,滿足一定的條件,才能啟動評審,審查內容包括文檔格式、模板、文檔名稱等是否合適;建議,每次評審的專家和組織者不能少于3人;有效代碼一般不超過500行;文檔一般不超過40頁;在有管理人員參加和有考核壓力的情況下,不會降低評審的效果;超過一定的工作量評審就會沒有效果,投入過多的工作量也不會發(fā)現更多的缺陷;準時參加評審會議;項目評審對象的評審,要作為項目的活動,在任務表中安排;評審過程中的評審會議階段的目的是為了確認缺陷,而不是解決缺陷,因此,評審會議要避免陷入對缺陷解決方案的討論之中;會議上無法達成一致或不能確定的問題,作為遺留問題進行跟蹤;評審一定對事不對人,所有的問題、矛盾、討論都是針對評審對象,絕對不能針對人,評審結果不能用來評價個人能力;會議之前做好準備工作,按照3-4-3原則進行,準備工作占30%,會議占40%,會后工作30%,切忌只管開會,會前會后啥都不管;如果做了預審,但沒有發(fā)現問題,也要反饋,在反饋表里填寫所用時間,不能以發(fā)現問題的多少來評定評審專家在評審中的作用;一定要做預審,把問題匯總,在會上先把問題確認一遍,然后講解者帶領大家一起瀏覽檢查評審對象,講解者需要有一定講課技巧;選定評審專家的時候,跟評審對象有影響關系的人員要參與,另外,一定要讓跟作者同一領域的技術專家參與,以保證評審能達到良好效果;啟動評審之前,一定要先做好相關人員溝通工作,保證他們能參加評審,尤其是評審專家。

4 評審的裁減

一般根據評審的內容及組織特點,可以對以上子過程進行裁剪,只保留必要的子過程。走查和輪查就是兩種常用的檢查方法。走查是對同行評審的精簡,取消預審會議,參與專家數也可以精簡3人左右。專家意見完全可以在閱讀評審對象提供的文檔時,提出給組織者或作者本人。輪查是非常簡單的一種檢查方式,通常是作者或部門主管拿到一個評審對象,召集3個左右的資料相關方,坐在位置上一起討論,給出評審意見。作者或部門主管結合評審意見進一步處理評審對象。

5 總結

評審是由相關的人員對評審對象進行檢查的一項活動,目的是幫助作者在早期有效地發(fā)現評審對象的缺陷,防止缺陷流到后邊的工作環(huán)節(jié),并判定評審對象是否滿足一定的要求,不是“發(fā)布執(zhí)行”,也不是對評審對象決策。對于評審對象的質量,評審專家不承擔責任,責任是作者的。至于如何考核評審專家,可通過行政處罰獎勵等措施鼓勵評審專家認真評審、盡可能發(fā)現缺陷。

參考文獻:

[1] Wiegers K E.軟件同級評審[M].北京:科學出版社,2004.

[2] 張萬軍, 儲善忠.基于CMMI的軟件工程教程[M].北京:北京交通大學出版社,2008.

[3] 朱少民.軟件質量保證和管理[M].北京:清華大學出版社,2007.

[4] 張瑾.軟件質量管理指南[M].北京:電子工業(yè)出版社,2009.

[5] 蘇秦,張涑賢.軟件過程質量管理[M].北京:科學出版社,2008.

[6] 錢樂秋,趙文耘,牛軍鈺.軟件工程[M].北京:清華大學出版社,2007.

[7] 梁成材.CMM中各類評審的綜合研究[J].計算機工程,2004,30(14):81-82.

[8] 范勇.一種有效的軟件評審模型[J].計算機工程與設計,2007,28(23):5585-5587.