fbpx
维基百科

軟體檢查

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

介紹 编辑

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

檢查流程 编辑

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

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

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

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

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

檢查的角色 编辑

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

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

相關的檢查類型 编辑

代码审查 编辑

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

同行評審 编辑

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

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

相關條目 编辑

參考資料 编辑

  1. ^ IBM Technical Report RC 21457 Log 96856 April 26, 1999.

軟體檢查, 是針對軟體工作文件的同行評審, 由受過訓練的人員進行, 有事先定義的程序, 目的是要找到軟體中的缺陷, 有一種正式的法, 稱為范根检查法, 得名自創建者michael, fagan, 目录, 介紹, 檢查流程, 檢查的角色, 相關的檢查類型, 代码审查, 同行評審, 相關條目, 參考資料介紹, 编辑是在軟體專案中最常見的評審活動, 檢查的目的是為了識別缺陷, 常見檢查的工作文件包括有需求分析以及測試計劃, 英语, test, plan, 檢查時會選定一份文件, 並且會召集成員開會來進行檢查, 會選定主持. 軟體檢查是針對軟體工作文件的同行評審 由受過訓練的人員進行 有事先定義的程序 目的是要找到軟體中的缺陷 有一種正式的軟體檢查法 稱為范根检查法 得名自創建者Michael Fagan 目录 1 介紹 2 檢查流程 3 檢查的角色 4 相關的檢查類型 4 1 代码审查 4 2 同行評審 5 相關條目 6 參考資料介紹 编辑軟體檢查是在軟體專案中最常見的評審活動 檢查的目的是為了識別缺陷 常見檢查的工作文件包括有需求分析以及測試計劃 英语 test plan 檢查時會選定一份文件 並且會召集成員開會來進行檢查 會選定主持人來主持會議 每一個參與的檢查者會閱讀工作文件 標示其中的缺陷 檢查過程中的 缺陷 是指檢查者認為有問題 無法通過的文件內容 例如在檢查軟體需求規格時 缺陷 就是檢查者不同意的需求文件內容 檢查流程 编辑檢查流程一開始是在1970年代中期發展 1 後來也有延展以及修改 流程中需要有進入準則 確認大家是否已預備好進入檢查流程 這可以避免未完成的工作文件進入檢查流程 進入準則可能是一份查檢表 其中包括許多項目 例如 文件中使用的拼字正確 檢查流程中的各階段包括有 計劃 簡介會議 準備 檢查會議 修正及追蹤 其中的準備 檢查會議和修正可能會重複幾次 計劃 Planning 由主持人針對檢查進行規劃 簡介會議 Overview meeting 作者說明工作文件的背景 準備 Preparation 所有的檢查者檢查工作文件 看其中是否有缺陷 檢查會議 Inspection meeting 在會議中朗讀者將工作文件的各部份唸出 檢查者指出各部份的缺陷 修正 Rework 作者依檢查會議的行動計劃修正工作文件 追蹤 Follow up 檢查作者所做的所有修改 確認全部正確 當流程滿足事先定義的結束準則時 主持人即可結束檢查流程 檢查 是在軟體工程專案執行過程中 很重要的一部份 檢查的角色 编辑在檢查過程中 會有以下的角色 作者 建立待檢查工作文件的人 主持人 領導檢查流程的人 主持人規劃檢查流程 並且進行協調 朗讀者 朗讀整份文件的人 一次讀出一部份 其他的檢查者會指出有缺陷之處 記錄 在檢查過程中記錄大家找到缺陷的人 檢查者 檢查工作文件中是否有缺陷的人 相關的檢查類型 编辑代码审查 编辑 代码审查也可以用軟體檢查的方式進行 由團隊來檢查程式碼 並且設法找出缺陷 在代码审查過程中 缺陷是指沒有正確實現需求的程式 沒有依設計者預期方式執行的程式 或是沒有不對 但還可以再進行改善的程式 例如可以提高可讀性 或是提昇其計算速度 代码审查除了幫助團隊找到缺陷並且修正缺陷 在審查程式碼時 程式設計者也可以彼此訓練 新進的程式設計者也可以學習新的程式設計技巧 同行評審 编辑 同行評審 英语 Software peer review 是可以提早找到軟體缺陷 並學習軟體文件 artifact 的最佳實務之一 同行評審是由許多的Walkthrough和軟體檢查所組成 是軟體產品工作活動之一 有許多有組織的知識 技術以及行為有助於同行評審的最佳實務 同行評審的元素包括了結構化的檢查流程 傑出產品查檢表的標準 已定義的成員角色 表單以及報告 軟體檢查是最嚴謹的同行評審方式 會充份使用這些元素來尋找軟體缺陷 軟體Walkthrough 走察 會選擇性的使用這些元素 協助參與者對軟體文件有更深入的瞭解 也讓參與者可以達成共識 由測量結果看出 同行評審可以加速學習 並且可以提早找到缺陷 這些投資回報十分值得 最好的情形下 同行評審是在組織中透過事先定義的計劃來達到的 計劃中包括有政策和程序的準備 訓練參與者和管理者 定義測量以及資料庫結構 並且持續維持這些基礎設施 相關條目 编辑軟體工程 软件工程主题列表 能力成熟度模型 CMM 參考資料 编辑 IBM Technical Report RC 21457 Log 96856 April 26 1999 取自 https zh wikipedia org w index php title 軟體檢查 amp oldid 68046342, 维基百科,wiki,书籍,书籍,图书馆,

文章

,阅读,下载,免费,免费下载,mp3,视频,mp4,3gp, jpg,jpeg,gif,png,图片,音乐,歌曲,电影,书籍,游戏,游戏。