一、軟件質量管理的基本概念
- 軟件質量就是軟件與用戶需求相一致的程度。具體地說，軟件質量是軟件符合明確敘述的功能和性能需求、以及所有專業開發的軟件都應具有的隱含特征的程度。
- 用戶需求是衡量軟件質量的基礎。
- 除滿足明確定義的需求外，還要滿足隱含的需求。
（一）軟件質量的重要性
- 軟件質量問題可能導致經濟損失甚至災難性的后果。
- 質量是軟件產品和軟件組織的生命線。
- 質量問題會增加開發和維護軟件產品的成本。
（二）軟件質量屬性
McCall軟件質量模型
（三）軟件質量的形成
- 軟件的質量形成於軟件的整個開發過程中，而不是事后的檢查（如測試）。
- 20世紀80年代起，質量管理逐步從單一的關注產品，轉移到關注生產好產品的過程上，並且將過程的作用擴大到了組織運行的所有領域。
（四）質量產生於過程
- 要真正地提高軟件質量，必須有一個成熟和穩定的軟件過程。
- 特殊原因造成過程性能不穩定。
根除特殊原因，使過程性能穩定，防止質量問題的出現。
（五）質量成本（CoQ）
- 質量成本是為了達到產品或服務的質量而付出的所有努力的總成本，包括三部分：
- 預防成本：為防止將缺陷引入軟件而進行的預防工作所消耗的費用。
- 評價成本：檢查軟件是否包含缺陷的工作所消耗的費用。
- 失效成本：修復缺陷工作所消耗的成本。
- PAF（Prevention / Appraisal / Failure）成本模型
- 在項目早期預防和檢測缺陷比在項目晚期檢測和排除缺陷更有效、更節省成本。
（六）軟件項目質量管理的目標
- 軟件項目質量管理的目標無疑是保證軟件產品的質量。但是，對於一個具體的軟件項目來說，保證軟件產品的質量並不意味着追求“完美的質量”。
- 對於絕大多數普通軟件來說，沒有必要付出巨大代價追求“零缺陷”，如果由於追求完美質量而造成嚴重的成本超支和進度拖延，而獲得的質量提升為用戶所帶來的效益又極為有限，就得不償失了。
- 在軟件項目中，對於軟件的各種質量屬性並不是放在同等重要的位置上，項目組織應該把關注點放在那些用戶最關心的，對軟件整體質量影響最大的質量屬性上，這些質量屬性稱為“質量要素”。
- 軟件項目質量管理的目標是在項目整體目標的約束之下，使軟件質量滿足用戶需求。
二、全面軟件質量管理
（一）質量管理計划
- 質量管理計划就是為了實現項目的質量目標，對項目的質量管理工作所做的全面規划。軟件項目質量管理計划一般應滿足以下要求：
- 確定項目應達到的質量目標和所有特性的要求；
- 確定項目中的質量活動和質量控制程序；
- 確定項目采用的控制手段及合適的驗證手段和方法；
- 確定和准備質量記錄。
- 質量管理計划一般包括以下主要內容：
- 質量要素分析；
- 質量目標；
- 人員與職責；
- 過程檢查計划；
- 技術評審計划；
- 軟件測試計划；
- 缺陷跟蹤工具。
- 模板
（二）評審（Review）
* 評審相當於軟件開發過程的“過濾器”，在軟件開發的一些時間點上對中間產品執行評審，發現和排除錯誤，防止錯誤被遺留到后續階段。
因此評審對於保證軟件質量和降低開發成本都極為重要。 * 評審可以在軟件項目的任何階段執行，不必等到軟件可運行之后，因此可以盡早發現和消除缺陷，提高軟件質量，並降低開發成本。 * 有統計數據表明，評審可發現75%的設計錯誤。
（1）技術評審（Technical Review）
- 技術評審（Technical Review, TR）就是對工作成果進行審查和分析，發現其中的缺陷，並幫助開發人員及時消除缺陷。
- 技術評審的主要對象：需求和設計規格說明、代碼、測試計划、用戶手冊等。
1、正式和非正式技術評審
- 技術評審分為正式技術評審和非正式技術評審兩種基本類型，前者比較嚴格，需要舉行評審會議，參加人員比較多，后者的形式比較靈活，通常在同伴之間開展，不必舉行評審會議，參與人員相對較少。
- 一般來說，對重要性和復雜性較高的工作成果，應進行正式技術評審，對重要性和復雜性相對較低的工作成果，可進行非正式技術評審。
2、技術評審會議
- 技術評審以會議形式進行，一般有如下約束：
- 評審會議通常由3~5人參加。
- 會議之前評審人員要做准備，但每人的准備時間不超過2個小時。
- 評審會議的時間不超過2個小時。
- 一次技術評審只關注軟件的某一特定部分（例如需求或設計規格說明的一部分）。縮小評審焦點可提高發現錯誤的可能性。
3、正式技術評審流程
- 評審組長把待評審的材料分發給每個評審者，評審者（包括評審組長）審查材料，記下相關的要點，為評審會議做准備。
- 開評審會議。評審會議由評審組長、評審者、評審對象的開發者參加。其中的一個評審者充當記錄員，負責記錄會議中發現的所有問題。
- 由開發小組對提交的評審對象進行講解。同時評審者可對開發者提問，提出建議和要求，展開討論。
- 在討論中如果發現了問題和錯誤，由記錄員記錄下來。
- 會議結束時必須做出以下三個決策之一：
##接受該產品，不需要做修改。
##由於錯誤嚴重，拒絕接受。等到錯誤改正后，還要進行另一次評審。
##暫時接受該產品，但需要對某一部分進行修改，修改后不需要再進行另一次評審。
- 決定作出后，所有參加會議的人員簽字，確認會議結果。
- 技術評審會議后，要完成一個“評審總結報告”，其內容包括：評審對象是什么？誰參加了評審？評審的結論是什么？有哪些重要發現？
- 評審會議上所記錄的問題列表通常作為評審總結報告的附件。
- 跟蹤與審核。開發者修改工作成果，消除已發現的缺陷。由指定的審查人員跟蹤每個缺陷的狀態，直到工作成果合格為止。
4、技術評審的注意事項
- 評審產品，而不是評審人。評審會議的氣氛要輕松和愉快，注意提出問題時的方式和態度，不要讓產品開發者產生被審問的感受。
- 制訂評審會議的議程並遵守進度。不要讓會議過分拖延。問題的具體解決方案可以在會后討論。
- 使用檢查清單。為不同的軟件產品（需求、設計、代碼等）開發檢查清單，在檢查清單中列出所有重要的、常見的問題，這樣可以使評審會議聚焦於一些重要問題。
（2）同行評審（Peer Review）
- 同行評審是一種特殊類型的技術評審。
- 由與工作產品開發人員具有同等背景和能力的人員對工作產品進行技術評審，因此非常有利於發現工作產品中的問題。
（3）代碼評審（Code Review）
- 編碼階段的一種技術評審，由一組人員對程序進行閱讀和靜態分析，可以很有效地檢查程序代碼中的缺陷。
- 評審內容：程序是否符合編碼規范，程序結構是否合理，算法和程序邏輯是否正確，程序性能怎樣等。
- 很多程序邏輯錯誤很難通過測試發現。
（三）軟件測試
- 軟件測試是通過執行軟件來發現缺陷，它是控制軟件質量的重要手段和關鍵活動。
- 軟件測試要在有了軟件編碼后才能執行，但測試的計划和設計應在項目前期就開始。測試計划確定了測試的內容和目標，明確了測試范圍，制定了測試策略和用例設計方法，安排人力和設備資源等。測試設計就是利用各種測試用例設計方法，編寫測試用例，並准備測試數據，開發輔助測試工具和編寫自動化測試腳本。
- 在測試執行階段，要執行測試用例，發現和記錄軟件缺陷。測試執行完畢后，還要對測試的結果進行分析總結，撰寫測試報告，給出結論。
（四）過程檢查
- 過程檢查就是檢查軟件項目的工作過程和工作成果是否符合既定的規范。在軟件項目中，如果工作過程和工作成果不合規范，很可能會導致質量問題。
- 例如，代碼和文檔的版本及其命名不符合版本控制規范，重要的變更不遵循變更控制流程，都有可能造成開發工作的混亂，進而導致產品質量下降。
- 工作過程和工作成果符合既定規范，也並不意味着產品質量一定能得到保證。因此過程檢查只是保證質量的一個必要條件，而不是充分條件，它還需要與技術評審、軟件測試、缺陷跟蹤、過程改進等各方面措施互相配合，共同促進軟件質量的提高。
- 對過程檢查要事先做出規划，確定主要檢查項、檢查時間（或頻度）、負責人等。過程檢查計划一般包含在軟件項目質量管理計划中。
（五）軟件過程改進
- 軟件過程（Software Process）是指開發和維護軟件產品的活動、技術、實踐的集合。軟件過程描述了為了開發和維護用戶所需的軟件，什么人（who）、在什么時候（when）、做什么事（what）以及怎樣做（how）。
- 軟件開發的過程觀認為，軟件是由一組軟件過程生產的，因此軟件質量和生產率在很大程度上是由軟件過程的質量和有效性決定的，而軟件過程可以被定義、控制、度量和不斷改進。
- 所謂軟件過程改進是指根據實踐中對軟件過程的使用情況，對軟件過程中的偏差和不足之處進行不斷優化。
- 軟件過程改進是面向整個軟件組織的。一個成熟的軟件組織應該對其軟件過程進行定義，形成一套規范的、可重用的軟件過程，稱為“組織級過程資產”。
- 軟件過程改進示意圖
- 軟件過程改進可遵循某種過程改進模型（如CMMI）來執行。
三、 缺陷跟蹤
- 缺陷跟蹤是指從缺陷被發現開始到被改正為止的整個跟蹤流程。
（一）缺陷跟蹤工具
- 缺陷跟蹤一般需要軟件工具支持。常用的工具有Bugzilla、ClearQuest、JIRA、TrackRecord 等。
（二）缺陷跟蹤工具Bugzilla
- Bugzilla是Mozilla公司提供的一個開源的缺陷跟蹤工具，在全世界擁有大量用戶。
- 它能夠為軟件組織建立一個完善的缺陷跟蹤體系，包括報告缺陷、查詢缺陷記錄並產生報表、處理解決缺陷、管理員系統初始化和設置等。
（1）Bugzilla的功能和特點：
- 基於Web方式運行，易於掌握。
- 缺陷從最初的報告到最后的關閉，都有詳細的操作記錄，確保了缺陷不會被忽略，並允許用戶在檢查缺陷狀態時獲取歷史記錄。
- 提供強大的查詢匹配能力，能根據各種條件組合進行缺陷查詢，並能夠記憶搜索條件。
（2）Bugzilla的特點：
- 當缺陷狀態發生改變時，會自動發送郵件通知相關責任人。
- 自帶基於數據庫的報表生成功能，主要生成兩類圖表：基於表格的視圖和圖形視圖（條形圖、線圖、餅狀圖）。
（3）Bugzilla的基本操作說明
- 報告缺陷
- 分配缺陷
- 處理缺陷
- 驗證已解決的缺陷
四、缺陷移除和預防
- 為了提高軟件質量，必須在軟件開發的各階段盡量多地移除缺陷，並通過缺陷預防盡量少地引入缺陷。
（一）缺陷移除效率
- 軟件開發階段的缺陷移除效率是衡量該階段軟件過程能力的一個重要指標，該指標可以定義為：
- 例如，在某軟件項目的高層設計階段通過設計審查發現和移除了730個缺陷，在該階段開始時存在120個缺陷，在該階段引入了860個缺陷，則該階段的缺陷移除效率為：
（二）缺陷的早期發現百分比
- 應該在軟件項目的早期階段盡可能多地移除缺陷，這樣不僅能夠提高軟件質量，還有利於降低項目成本。IBM公司用來管理質量的四個度量之一就是缺陷的早期發現百分比，也就是審查缺陷移除效率，如下式：
（三）早期開發階段的缺陷移除
- 早期開發階段的缺陷移除一般來說代價較低。缺陷的發現距離被引入的時間越近，移除缺陷所需的工作量就越少。
- 有研究者對來自IBM Santa Teresa實驗室的數據進行了分析，發現軟件生命周期的三個主要階段，即設計、編碼和用戶使用（維護階段）的缺陷移除代價的比率為：1：20：82。
（四）缺陷預防
- 優點：主動
- 改進軟件過程，降低出錯幾率
- 降低質量成本，實現項目效益
（五）缺陷的概念
- 軟件缺陷是指軟件對其期望屬性的偏離，它包含三個層面的信息：
- 失效(failure)：指軟件系統在運行時其行為偏離了用戶的需求，即缺陷的外部表現。
- 錯誤(fault)：指存在於軟件內部的問題，如設計錯誤、編碼錯誤等，即缺陷的內部原因。
- 差錯(error)：指人在理解和解決問題的思維和行為過程中所出現的問題，即缺陷的產生根源。
（六）缺陷原因分析
- 一個差錯可導致多個錯誤，一個錯誤又可導致多個失效。
- 軟件缺陷原因的分析不能只停留在“錯誤”這一層面上，而要深入到“差錯”層面，才能防止一個缺陷（以及類似缺陷）的重復發生。
- 因此軟件缺陷的根本原因往往與過程及人員問題相關，缺陷預防總是伴隨着軟件過程的改進。
- 軟件缺陷原因分析過程一般包括選擇缺陷數據、分析缺陷數據、識別公共原因並提出改進措施三個步驟。采用該方法的軟件組織通常是在軟件項目的每個開發階段結束后，或者定期（如每個月末）進行缺陷原因分析，提出改進措施，從而促進組織的過程改進。
（七）軟件缺陷原因分析方法
- Step1：選擇缺陷數據。
- 對小項目，可選擇某一時期內發現的所有缺陷。
- 對大項目，可選擇一個缺陷樣本集合。
- Step2：分析缺陷的根本原因
- 對缺陷逐個進行分析，常以會議的方式進行。
- 可對分析出的根本原因進行分類，例如：
- IBM：疏忽、培訓、通信失效、書寫錯誤
- Motorola：開發階段相關、人員相關、項目相關、復審相關
- 缺陷原因分析工具——因果圖（魚骨圖）
- Step3:識別公共原因，制定改進措施。
在逐個分析了缺陷之后，還要對分析得到的根本原因進行綜合和歸納，識別導致缺陷產生的公共原因，並制定有關過程、技術和人員管理方面的改進措施。
五、軟件質量的常用度量
- 初期故障率：指軟件在初期故障期（一般以軟件交付給用戶后的三個月內為初期故障期）內單位時間的故障數。
用來評價交付使用的軟件的質量，預測什么時候軟件運行達到基本穩定。
一般以每100小時的故障數為單位。
- 偶然故障率：指軟件在偶然故障期（一般以軟件交付給用戶后的4個月以后為偶然故障期）內單位時間的故障數。
它用來度量軟件處於穩定狀態下的質量。
一般以每1000小時的故障數為單位。
- 平均失效前時間（Mean Time to Failure，MTTF）：指軟件在失效前（兩次失效之間）正常工作的平均統計時間。
用來度量軟件的可靠性。
- 平均修復時間（Mean Time to Reparation，MTTR）：指軟件失效后，使其恢復正常工作所需要的平均統計時間。
用來度量軟件的可維護性。
- 缺陷密度:指軟件單位數量的源代碼隱藏的缺陷數量
通常以每千行無注解代碼為一個單位
六、案例分析
- “軟件缺陷管理和度量系統”質量管理計划
- 改進軟件質量的一些要求
- 軟件質量活動必須經過規划並明文規定
- 質量活動必須盡早開始
- 質量小組必須獨立存在
- 質量小組的人員應該經過必要的培訓
七、本章內容小結
- 理解質量管理的基本概念
- 軟件質量、質量屬性、質量形成、質量成本
- 理解全面軟件質量管理所包含的措施
- 理解缺陷跟蹤流程
- 理解缺陷預防的作用和方法
- 掌握常用質量度量
原文鏈接：https://blog.csdn.net/yongchaocsdn/article/details/80882869