1.1 什么是評審
1.1.1 IEEE729-1983規范
在正式的會議上將軟件項目的成果(包括各階段的文檔、產生的代碼等)提交給用戶、客戶或有關部門人員對軟件產品進行評審和批准。其目的是找出可能影響軟件產品質量開發過程、維護工作的適用性和環境方面的設計缺陷,並采取補救措施,以及找出在性能、安全性和經濟方面的可能的改進。
1.1.2 評審的目標
在軟件開發與測試的各個階段進行相應的檢查,有利於軟件產品與過程的質量提高。
1.1.3 定義
1.1.3.1 同行評審
由軟件工作產品創建者的同行們檢直該工作產品,識別產品的缺陷,改進產品的不足。
1.1.3.2 管理評審
由軟件項目/產品管理者對項目過程中管理活動進行評估,識別過程缺陷,改進管理活動。
1.1.3.3 單人評審
由單獨一個評審員對簡單的工作產品進行評估,識別產品的缺陷,改進產品的不足。
1.2 評審准確
1.2.1 評審入口准則
- 評審組長被任命
- 評審在相關計划中被定義
- 被評審的產品准備就緒
- 評審 員經過評審規程的培訓
- 評審員應經過被評審問題的技能的培訓
- 協調員應當受過如何執行評審的正式培訓,或者應當參加幾次評審的經驗
- 《項目計划》已經制定
1.3 評審過程
1.3.1 同行評審准則
- 評審產品,而不是評審設計者(不能使設計者有任何壓力)
- 會場要有良好的氣氛
- 限制爭論與反駁(評審會不是為了解決問題,而是為了發現問題)
- 指明問題范圍,而不是解決提到的問題
- 展示記錄(最好有黑板,將問題隨時寫在黑板上)
- 組評審時會議人數應在5-9人為佳
- 組評審時評審員中應包括被評審產品作者的同行。( 例如對程序設計文檔的評審,評審員中應包括其他程序設計人員)
- 組評審時評審員中應包括被評審產品的上下游相關人員。( 例如對程序設計文檔的評審,評審員中應包括詳細設計人員和后續的編碼人員)
- 堅持會前准備工作
- 對全部評審人員進行必要的培訓
- 參與人員不了解評審
- 評審沒有被安排進項目計划
- 評審會議變成了問題解決方案討論
- 評審人員事先對評審工件沒有足夠了解
- 評審人員關注於非實質性問題
- 忽視組織細節
- 會議時間過長
1.4 評審的誤區
1.4.1 評審的誤區
1.5 風險分析
學太多的歷史悲劇告訴我們風險無處不在,不學會控制它,就一 定會被它所控制必風險分類。
1.5.1 風險分類
1.5.1.1 軟件風險
這種風險分析主要是確定軟件中要測試什么,測試的優先級,測試的深度。
1.5.1.2 規划風險
這種風險主要是為了防范未計划而影響項目進度的事件發生。比如測試人員突然離開導致人員不足、軟件的需求的突然變更。