軟體檢查

軟體檢查是針對軟體工作文件的同行評審，由受過訓練的人員進行，有事先定義的程序，目的是要找到軟體中的缺陷。有一種正式的軟體檢查法，稱為范根檢查法，得名自創建者Michael Fagan。

介紹

軟體檢查是在軟體專案中最常見的評審活動。檢查的目的是為了識別缺陷。常見檢查的工作文件包括有需求分析以及測試計劃。檢查時會選定一份文件，並且會召集成員開會來進行檢查. 會選定主持人來主持會議，每一個參與的檢查者會閱讀工作文件，標示其中的缺陷。檢查過程中的「缺陷」是指檢查者認為有問題，無法通過的文件內容。例如在檢查軟體需求規格時，「缺陷」就是檢查者不同意的需求文件內容。

檢查流程

檢查流程一開始是在1970年代中期發展，後來也有延展以及修改。

流程中需要有進入準則，確認大家是否已預備好進入檢查流程。這可以避免未完成的工作文件進入檢查流程。進入準則可能是一份查檢表，其中包括許多項目，例如「文件中使用的拼字正確。」

檢查流程中的各階段包括有：計劃、簡介會議、準備、檢查會議、修正及追蹤。其中的準備、檢查會議和修正可能會重複幾次。

• 計劃（Planning）：由主持人針對檢查進行規劃。
• 簡介會議（Overview meeting）：作者說明工作文件的背景。
• 準備（Preparation）：所有的檢查者檢查工作文件，看其中是否有缺陷 。
• 檢查會議（Inspection meeting）：在會議中朗讀者將工作文件的各部份唸出，檢查者指出各部份的缺陷。
• 修正（Rework）：作者依檢查會議的行動計劃修正工作文件。
• 追蹤（Follow-up）：檢查作者所做的所有修改，確認全部正確。

當流程滿足事先定義的結束準則時，主持人即可結束檢查流程。 「檢查」是在軟體工程專案執行過程中，很重要的一部份。

檢查的角色

在檢查過程中，會有以下的角色。

• 作者：建立待檢查工作文件的人。
• 主持人：領導檢查流程的人，主持人規劃檢查流程，並且進行協調。
• 朗讀者：朗讀整份文件的人，一次讀出一部份，其他的檢查者會指出有缺陷之處。
• 記錄：在檢查過程中記錄大家找到缺陷的人。
• 檢查者：檢查工作文件中是否有缺陷的人。

相關的檢查類型

代碼審查

代碼審查也可以用軟體檢查的方式進行，由團隊來檢查程式碼，並且設法找出缺陷。在代碼審查過程中，缺陷是指沒有正確實現需求的程式，沒有依設計者預期方式執行的程式，或是沒有不對，但還可以再進行改善的程式（例如可以提高可讀性，或是提昇其計算速度）。代碼審查除了幫助團隊找到缺陷並且修正缺陷，在審查程式碼時，程式設計者也可以彼此訓練，新進的程式設計者也可以學習新的程式設計技巧。

同行評審

軟體同行評審是可以提早找到軟體缺陷，並學習軟體文件（artifact）的最佳實務之一。同行評審是由許多的Walkthrough和軟體檢查所組成，是軟體產品工作活動之一。有許多有組織的知識、技術以及行為有助於同行評審的最佳實務。同行評審的元素包括了結構化的檢查流程、傑出產品查檢表的標準、已定義的成員角色、表單以及報告。

軟體檢查是最嚴謹的同行評審方式，會充份使用這些元素來尋找軟體缺陷。軟體Walkthrough（走察）會選擇性的使用這些元素，協助參與者對軟體文件有更深入的瞭解，也讓參與者可以達成共識。由測量結果看出，同行評審可以加速學習，並且可以提早找到缺陷，這些投資回報十分值得。最好的情形下，同行評審是在組織中透過事先定義的計劃來達到的，計劃中包括有政策和程序的準備，訓練參與者和管理者、定義測量以及資料庫結構，並且持續維持這些基礎設施。

相關條目

• 軟體工程
• 軟件工程主題列表
• 能力成熟度模型 (CMM)