第二章 軟體品質工程體系
- 2.1 軟體品質控制的基本方法
-
- 2.1.1 軟體品質控制的基本概念
- 2.1.2 軟體品質控制的基本方法
- 2.2 軟體品質控制模型和技術
- 2.2.1 軟體品質控制模型
- 2.2.2 軟體品質控制模型參數
- 2.2.3 軟體品質控制的實施過程
- 2.2.4 軟體 品質控制技術
- 2.3 軟體品質保證體系
-
- 2.3.1 能力成熟模型（CMM）
- 2.3.2 軟體品質保證SQA
- 2.4 小結
2.1 軟體品質控制的基本方法
2.1.1 軟體品質控制的基本概念
· 軟體品質控制是一組由開發組織和使用的程式和方法，使用他們可在規定的資金投入和實踐限制的條件下，提供滿足客戶品質要求的軟體産品并持續不斷地改善開發過程和開發組織本身，以提高将來生産高品質軟體産品的能力。
根據這個定義，我們可以看到：
軟體品質控制是開發組織執行的一系列過程。
軟體品質控制的目标是以最低的代價獲得客戶滿意的軟體産品。
對于開發組織本身來說，軟體品質控制的另一個目标是每一次開發過程中學習以便使軟體品質控制一次比一次好。
軟體品質因素
Functionality
Reliability
Usability
Portability
Efficiency
Maintainbility
軟體品質體系
品質保證
軟體品質控制和品質管理
軟體品質控制是軟體品質管理的指向器和原動力。而軟體品質管理，則是軟體品質控制的執行機構。
2.1.2 軟體品質控制的基本方法
目标問題度量法
· 對一個項目的各個方面（産品、過程和資源）規定具體的目标，這些目标的表達應非常明确。
· 對每一個目标，要引出一系列能反映出這個目标是否達到要求的問題，并要求對這些問題進行回答。這些問題的答案将有助于使目标定量化。
· 将回答這些問題的答案映射到對軟體品質等級的度量上，根據這種度量得出軟體目标是否達到的結論，或确認哪些做好了，哪些仍需改善。
· 收集資料。要為收集和分析資料做出計劃。
目标問題度量法示例圖
· 目标：改善現場使用中的軟體産品的品質。
可維護性
· 問題：可維護性開發過程在預防群組織缺陷發生方面有效嗎?正在發生哪些缺陷？産生缺陷的原因是什麼？
· 度量：産品的缺陷密度；按缺陷類别劃分的産品缺陷的發生頻率；缺陷産生的頻率分布以及缺陷發生所在階段的頻率分布。
準備開發–>進行開發–>運作維護–><–進行可維護性開發
風險管理法
根據經驗識别相關目要素的有關風險；
評估風險發生的機率和發生的代價；
按發生機率和代價劃分風險等級并排序；
在項目限定條件下選擇控制風險的技術并制定計劃；
執行計劃并監視程序；
持續評估風險狀态并采取正确的措施。
SEI風險管理模型
風險識别、風險分析、風險計劃、風險控制和風險跟蹤。
軟體項目各階段的風險
| 階段 | 可能面臨的風險問題 | |
|---|---|---|
| 計劃 | 目标不清 範圍不清 缺少溝通 | 業務不清 缺乏可行性分析 |
| 設計 | 缺乏經驗 沒有變更控制計劃 | 項目計劃倉促（進度風險） 設計疏漏 |
| 實施 | 缺乏環境 設計錯誤 開發能力 項目範圍變更 進度變更 | 人員變更 内部溝通不暢 備選方案無效 測試計劃不充分或缺少經驗 |
| 釋出 | 品質差 客戶不滿意 | 裝置未按時到貨 資金不能及時回收 |
風險嚴重程度等級
| 影響程度 | 标準 | 等級 |
|---|---|---|
| 危險 | 嚴重影響項目，可能導緻項目取消或者直接失敗 | 10-9 |
| 高 | 影響進度，導緻延期，客戶抱怨嚴重 | 8-7 |
| 中 | 影響預算或軟體性能差，客戶不滿意 | 6-5 |
| 低 | 影響程序但很快解決，客戶有些不滿 | 4-3 |
| 小 | 影響較小，客戶未察覺或認可 | 2-0 |
風險控制方法
在控制階段主要用到的風險控制方法有風險避免、風險弱化、風險承擔和風險轉移等，分别叙述如下：
· 風險避免，通過變更計劃消除風險的觸發條件，如采用成熟技術、增加資源、減少軟體範圍等。
· 風險弱化，降低風險發生的機率，如簡化流程、更多測試、開發原型系統等。
· 風險承擔，制定應急方案，随機應變。
· 風險轉移，将風險發生的結果連同應對
2.2 軟體品質控制模型和技術
2.2.1 軟體品質控制模型
前基于PDCA的全面統計品質控制（TSQC）模型，是我國實際采用的模型之一。
2.2.2 軟體品質控制模型參數
産品
過程
資源
2.2.3 軟體品質控制的實施過程
預開發階段
開發階段
維護階段
軟體品質控制技術的特征
| 品質控制技術 | 預防性特性 | 檢測性特征 |
|---|---|---|
| 因果分析 | 分析原因，提出改進建議，預防出錯 | |
| 配置管理 | 控制軟體配置，防止引入新的錯誤 | |
| 獨立的确認與驗證 | 及時發現和糾正需求、設計、編碼的錯誤 | |
| 檢查 | 在測試之前檢查并糾正設計和編碼的缺陷 | 檢查和糾正設計、編碼缺陷 |
| 管理度量 | 檢查早期問題并調整品質控制參數 | |
| 性能工程 | 提供某種方法避免潛在的性能問題 | 度量實際性能、确認是否滿足需求 |
| 初樣 | 對早期需求和問題的确認，使用者界面設計确認 | |
| 可靠性模組化 | 度量軟體的可靠性、并預測附加測試 | |
| 軟體審計 | 識别關鍵風險并提出規避方法 | 檢測逾時、超支和品質缺陷 |
| SEI軟體能力評估 | 評估組織的開發過程、确定成熟度等級 |
部分軟體品質控制技術對品質參數的影響
軟體品質控制問題與品質控制技術
最終産品的品質需求是什麼？
選擇什麼樣的開發組織？
為預防軟體品質缺陷應該做點兒什麼？
怎樣檢查軟體品質？
在檢查點應該獲得哪些資訊？
2.2.4 軟體 品質控制技術
選擇控制技術需要考慮的因素
~有些技術是任何時候都要考慮的，盡管它們的使用等級可以變化。
~要考慮所選技術的效益并使需求、風險和限制得到平衡。
~有些技術是備援的或是沖突的，隻需或隻能選擇其一。
~有些技術是互補的，同時使用可能提高效益。
~控制技術的選用不能與約定相沖突。
~有些技術隻能用于特定的開發階段或特定的開發活動中。
~檢測性技術宜盡早使用，以防早期缺陷的産生和傳播。
~對于高風險的設計和程式，品質控制活動和檢查點的安排時間上不要隔太久。
2.3 軟體品質保證體系
軟體品質保證是建立一套有計劃，有系統的方法，來向管理層保證拟定出的标準、步驟、實踐和方法能夠正确地被所有項目所采用。軟體品質保證的目的是使軟體過程對于管理人員來說是可見的。
· 它通過對軟體産品和活動進行評審和審計來檢驗軟體是合乎标準的。
· 軟體品質保證組在項目開始時就一起參與建立計劃、标準和過程。
· 這些将使軟體項目滿足機構方針的需求。
SQA（軟體品質保證）是CMM（軟體能力成熟度）2級中的一個重要關鍵過程區域，它是貫穿于整個軟體過程的第三方獨立審查活動，在CMM的過程中充當重要角色
SQA的目的是向管理者提供對軟體過程進行全面監控的手段，包括評審和審計軟體産品和活動，驗證它們是否符合相應的規程和标準，同時給項目管理者提供這些評審和審計的結果。
是以，滿足SQA是達到CMM2級要求的重要步驟之一。
2.3.1 能力成熟模型（CMM）
能力成熟度模型
能力成熟度模型的産生和發展：
1987年，美國卡内基·梅隆大學軟體研究所（Software Engineering Institute，SEI）受美國國防部的委托，率先在軟體行業從軟體過程能力的角度提出了軟體過程成熟度模型（Capability Maturity Model，CMM），随後在全世界推廣實施的一種軟體評估标準，用于評價軟體承包能力并幫助其改善軟體品質的方法。
~主要用于軟體開發過程和軟體開發能力的評價和改進。
~側重于軟體開發過程的管理以及工程能力的提高于評估。
CMM自1987年開始實施認證，現已成為軟體業最權威的評估認證體系。
CMM包括5個等級，共計18個過程域，52個目标，300多個關鍵實踐。
**軟體品質保證（SQA）**是建立一套有計劃、有系統的方法，來向管理層保證拟定出的标準、步驟、實踐、方法能夠正确地被所有項目所采用。
能力成熟度模型（CCM）
是對于軟體組織在定義、實施、度量、控制和改善其軟體過程的時間中各個發展階段的描述。
在美國國防部的指導下。由軟體開發團體和軟體工程學院及Carneigie Mellon大學共同開發的
CMM的核心：是把軟體開發視為一個過程，并根據這一原則對軟體開發和維護進行過程監控和研究，以使其更加科學化、标準化、使企業能夠更好地實作商業目标。
CMM的基本思想
CMM的基本思想是基于已有60多年曆史的産品品質原理。休哈特（Walter Shewart）在30年代發表了統計品質控制原理，戴明（W. Edwards）和朱蘭（Joseph Juran）的關于品質的著作又進一步發展和論證了該原理。
實際上，将品質原理變為成熟度架構的思想是克勞斯比（Philip Crosby），他在著作《品質免費》（Quality is Free）中首先提出，他的品質管理成熟度網絡描繪了采用品質實踐時的5個進化階段，而該架構後來又由IBM的拉迪斯（Rom Radice）和他的同僚們在漢弗萊（Watts Humphrey）指導下進一步改進以适應軟體過程的需要。
1986年，漢弗萊将此成熟架構帶到了SEI并增加了成熟度等級的概念，将這些原理應用于軟體開發，發展成為軟體過程成熟度架構，形成了目前軟體産業界正在使用的架構。
實施CMM的必要性
實施CMM是改進軟體品質的有效方法：控制軟體生産過程、提高軟體生産者組織性和軟體生産者個人能力的有效合理的方法軟體工程和很多研究領域及實際問題有關，主要相關領域和因素有：
需求工程（Requirements Engineering）。
理論上，需求工程是應用已被證明的原理、技術和工具，幫助系統分析人員了解問題或描述産品的外在行為。
軟體複用（Software Reuse），定義為利用工程知識或方法，由一已存在的系統，來建造一新系統。這種技術，可改進軟體産品品質和生産率。
還有軟體檢查、軟體計量、軟體可靠性、軟體可維修性、軟體工具評估和選擇等
2.3.2 軟體品質保證SQA
SQA背景
SQA目标
SQA任務
SQA在軟體開發不同階段的目标
SQA活動
SQA的實施
2.4 小結
軟體品質控制是一組由開發組織使用的程式和方法，使用它可在規定的資金投入和時間限制的條件下，提供滿足客戶品質要求的軟體産品并持續不斷地改善開發過程和開發組織本身，以提高将來生産高品質軟體産品的能力。
用于軟體控制的一般性方法：目标問題度量法；風險管理法；PCDA品質控制法。其中在我國最常用的是模型是基于PDCA的全面服務品質管理（TSQC）模型。
軟體品質保證（SQA）是建立一套有計劃，有系統的方法，來向管理層保證拟定出的标準、步驟、實踐和方法能夠正确地被所有項目所采用。
在提高軟體品質方面卓有成效。
注：經驗不足，請在評論區指正。會定期修改部落格，謝謝大家。