# 物件導向軟體工程 - 軟體品質

---

# Software Quality Assurance (軟體品質保證)

# 概述:

是監控軟體工程流程和方法以確保品質的一系列手段。[來源請求] 實現這一目的有著多種方法，並且可以確保符合一個或多個標準

# 活動:

• Verfication 驗證 正確得建置產品 (建置方法正確)
• Validation 建置對的產品 (產品正確)
• Technical reviews
• Testing: 嘗試發現程式錯誤

# Cost of Quality 品質成本

包含

• Costs of preventing software failures (防止軟件故障的成本)
  • Costs to implement an SQA framework (one time)(實施 SQA 框架的成本（一次）)
  • Costs of perform SQA activities (on going)(執行 SQA 活動的成本（進行中）)
  • Costs to monitor and improve the framework (on going)(監控和改進框架的成本（進行中)
  • Costs of needed equipment (machines and tools)(所需設備（機器和工具）的成本)
• Costs of failure (故障成本)
  • Costs to analyze and remove failures (分析與除錯的成本)
  • Costs of lost productivity (developer and customer)(失去生產力的成本 (開發者與顧客))
  • Costs of liability,lawsuit,and increased insurance premium (責任成本、訴訟和增加的保險費)
  • Costs associated with damage to company’s reputation (與損害公司聲譽相關的成本)

軟體工程需要權衡品質與成本

# Software Quality Attributes (軟體品質屬性)

• Reliability (可靠性):(充分性：正確性、完整性、一致性；穩健性)
• Testability and Maintainability (可測試性和可維護性) 可理解性：模塊化、簡潔性、精確性、明確性、可讀性；可測量性：可評估性、可量化性
• Usability (可用性)
• Efficiency (效率)
• Portability (可移植性)

# Software Quality Metrics (軟體品質指標)

• Requirements metrics (需求指標)
• Design mertrics (設計指標)
• Implementation metrics (實作指標)
• System metrics (系統指標)
• Object-oriented software quality metrics (物件導向軟體品質指標)

# 需求指標

# Requirements Unambiguity (需求明確性)

Q1 = #of uniquely interpreted requiremenys/#of requirements

# Requirements Completeness (需求完整性)

Q2 = #of uniquely functions/#of combinations of states and stimuli

# Requirements Correctness (需求正確性)

Q3 = #of validated correct requirements/#of requirements

# Requirements Consistency (需求一致性)

Q4 = #of non-conflicting requirements/#of requirements

# 設計指標

# Fan-In 扇入

• 進入模組訊息或控制流程的數量
• 衡量模組的依賴性
• 高扇入 High Fan-In 表示神模組或神 class
• 模組可能被指派太多責任
• 可能導致低內聚

# Fan-Out 扇出

• 模組流出訊息數量
• 衡量模組與其他模組的依賴關係
• 高扇出 High Fan-Out 代表他會很難重複利用，因為其他模組也必須重複利用

# Modularity 模組化

• 透過內聚與耦合指標來衡量
• 模組化 = (a 內聚 + b 耦合)/(a+b) a 與 b 為內聚與耦合的權重

# Module Design Complexity mdc (模組設計複雜度)

• 模組與次要模組 (下屬模組) 整合所需的整合測試數量
• 是調用次要模組 (下屬模組) 的決策數 (總判斷)+1

# 設計複雜度 S0

• 樹狀結構模組數量
• 子節點 S0 (leaf)=1
• S0= mdc + 所有子節點的 S0

# 整合複雜度 S1

• 整合模組結構圖所需最小整合測試用例數量
• 整合複雜度 S1 (M) = S0 (M)-n+1 n 指結構圖中的模組數量

# 可靠性與可用性

• Mean time to failure (MTTF) 平均失效時間
• Mean time to repair (MTTR) 平均修復時間
• Mean time between failure (MTBF) 平均失效間隔 = MTTF+MTTR
• Availability 可用性 = MTTF/MTBF X 100%

# Implementation Metrics 實作指標

• 缺點 / KLOC
• 文件頁數 / KLOC
• 命令數量 / LOC
• 循環複雜度 Cyclomatic complexity
  • equals to number of binary predicates+1
  • 衡量理解模組 / 函式的難度
  • 衡量測試案例所需覆蓋的所有獨立路徑 (基本路徑) 數量

# 物件導向品質指標

參考文章

• Weighted Methods per Class (WMC) 類別加權方法
• Depth of Inheritance Tree (DIT) 繼承樹深度度量
• Number of Children (NOC) 子女數
• Coupling Between Object Classes (CBO) 類別之間耦合係數
• Response for a Class (RFC) 類別響應度量
• Lack of Cohension in Methods (LCOM) 欠缺內聚度量

# Weighted Methods per Class (WMC) 類別加權方法

WMC© = Cm1 + Cm2 + … + Cmn
Cmi = Class c 的方法複雜度指標

意義：了解 / 測試 / 維修 class C 的時間與心力 會指數型的成長根據 WMC

# Depth of Inheritance Tree (DIT) 繼承樹深度度量

被繼承的衍伸 class 到根 class 的繼承結構距離

• 衡量:
  1. 透過繼承重複利用的程度
  2. 預測 class 行為的難度
  • 假設有 3 個 class 成鏈狀繼承都有相同的 Method 當使用父 class 當作型別時會難以判斷實作內容
  • 造成當更改 Parent class 需重新測試 Child Class
  3. 由於父 class 改變，導致子 class 影響而產生的回歸測試相關成本

# Number of Children (NOC) 子女數

NOC© = | {C’ : C’ 是 C 的直接子 class}|

• 依賴於該 class 的子女數量，越多會增加 NOC
• 依賴性的增加會增加 C class 改變的造成 C 子類的影響 / 行為
• 會讓程式更複雜去理解 / 測試 / 維修

# Coupling Between Object Classes (CBO) 類別之間耦合係數

CBO© = |{C’ : C 依賴於 C’}|
CBO 依賴別的 class 的數量 (Inheritance,Association,Aggregation,Composition 都算)

• 更高的 C class CBO 會更難去理解 / 測試 / 維修 / 重用 class C

# Response for a Class (RFC) 類別響應度量

RFC© = |{m: m 是 C 的 method 或 m 是被 C 內部方法呼叫的}|

• 更高的 RFC 會更難去理解 / 測試 / 維修 / 重用一個 class，因為對其他 class 高度的依賴性
• Inheritance 被繼承的 class 也要統計 Inherit Method 的數量
• Association 使用其他 Class 也要統計被使用 class 的 Method 數量
• Aggregation 要統計擁有 Class 的 Method 數量

# Lack of Cohension in Methods (LCOM) 欠缺內聚度量

LCOM© = n (n-1)/2-2 |{(mi,mj):mi 與 mj 是 C class 的共同 Property}|

• LCOM 衡量 C class 不共用 Property 的 Method 組數
• (延伸) 內聚方法指標 ->2*(mi,mj):mi 與 mj 是 C class 的共同 Property
• LCOM 的結果可以是 range ex:[0,1] 因為 (mi,mj) 的組數標準不
• LCOM 最小值是 0 最大值是 n*n-1
• 無法得知哪個 Method 沒有 cohesion

# Usefulness of Quality Metrics 質量指標的用處

1. 定義與使用指派者
2. 追蹤有價值的資源去至限制區域
3. 量化比較相似專案與系統
4. 量化改進評估包含流程改善
5. 量化技術評估

# Software Verification and Validation Techniques 軟體驗證與有效檢驗技巧

• Desk checking 案頭檢查
• Inspection 檢查
• Walkthrough 演練
• Peer review 同行檢驗
• Testing 測試

# Software Inspections 軟體檢查

• 檢查者檢驗表示已檢測目標與偵測異常與缺點
• 他並不需要執行所以他可以在實作前做
• 它可以被應用在各種系統表示 (需求，設計，程式碼，測試資料)
• 他是個錯誤檢驗的有效技巧

# Program Inspection 程式檢查

• 一種針對缺陷的方法，而不是糾正缺陷的方法
• 缺陷可能是邏輯錯誤，異常在程式碼中可能有多種情況 (e.g. 未初始化的變數) 或不符合標準
• 一步一步的閱讀程式
• 檢查是否違反一系列的限制
  • 常見錯誤
  • 標準
  • 一致性準則

# Inspection Pre-condition 檢查前置條件

• 必須有精確的規格
• 團隊成員必須熟悉組織標準
• 程式碼必須正確語句
• 必須準備錯誤檢查清單
• 管理必須接受檢查會在軟體過程早期增加成本
• 管理不能用檢查當作效能評價

# Inspection Procedure 檢查過程

• 系統概述必須呈現給檢查團隊
• 程式碼與相關文件必須事先發行給檢查團隊
• 檢查進行與揭露錯誤並且標記
• 更改版本是用來維修被發現的錯誤
• 重新檢查可能是 / 不是必要的

# Fagan Inspection Technique 費根檢查技巧

• 檢驗項目清單
• 清單包含設計與程式碼檢驗
• 4~5 位檢查者包含：主席，設計者，程式設計師，檢查者
• 對即時系統友善因為錯誤並不會重複出現
• 不同的程式設計師傾向有不同的錯誤模式

# Design Inspection 設計檢查

• 前置條件：功能性需求與設計規格必須有
• 設計檢驗是檢驗:
  • 完整性
  • 一致性
  • 正確性

# Walkthrough 演練

• 開發者必須大聲讀過程式
• 開發者提供解釋假設他認為有必要
• 其他團隊成員可以提問與激發疑點
• 開發者回答問題與證明回答

# Difference Between Walkthrough and Inspection 演練與檢查的差異

• Walkthrough 演練
  • 使用測試資料
  • 團隊是透過手動激發進行領導
  • 當朗讀時一步一步檢查產品
  • 激發疑點與討論
• Inspection 檢查
  • 使用規範清單
    • 常見錯誤
    • 標準
    • 一致性準則
  • 團隊檢查產品持件錯誤與符合標準與一致性準則

# Peer Review 同行回饋

• 產品受到同行回饋，以回饋問題清單為指導
• 回饋問題被設計去存取產品
• 回饋者被給予 1~2 周去檢驗工作
• 回饋結果可能有很大的不同取決於回饋者的知識 / 經驗 / 背景 / 關鍵性
• 回饋會議常常被安排討論回饋結果

# Peer Review Procedure 同行回饋過程

1. 產品概要需要呈現給檢驗者
2. 檢驗者評價產品與對於回饋問題個別的給予解答
3. 在回饋會議中，檢驗者呈現他們的意見，開發者回答問題與解惑
4. 回饋會議後，開發者修復問題與製作解決方案概要。回饋者會檢查他們所做的改變
5. 可能需要二次回饋

# Verfication and Validation in the Life Cylce (生命週期中的驗證與有效)

1. 軟體需求分析
2. 軟體設計
3. 撰寫程式與單元測試
4. 接受測試
5. 維修

• Verfication 確保開發活動正確執行
• Validation
  • static validation 確保 SRS 設計與程式碼的正確
  • dynamic validation & testing 確保軟體正確執行與正確回傳結果

# Verfication 驗證

• 驗證是檢查實作是否符合規格
• 低程度的抽象化是高階抽象化的實作
• 設計驗證包含檢查軟體設計是否符合需求規格

# Validation 有效

• 有效的目標是檢查 model 與現實中之間 e.g. 一個功能規格對照真實世界顧客所需要的
• 去尋找反駁模型的過程
• 功能測試是有效檢驗的技巧

# Static and Dynamic Verfication & Validation 靜態 / 動態的 V&V

• 回饋與檢察都專注於靜態系統分析的呈現去尋找問題 (靜態驗證 static verification)
• 測試專注於執行產品與檢驗他的行為 (動態驗證 dynamic verification)

# Formal Verification 正式驗證

• 一個精確的數理分析過程
• 他檢查規格與實作之間的差異
• 範例:
  • 規格：一個有邏輯的表達限制 - 一些壞事情不該發生的
  • 實作：一個狀態機模型表達系統狀態
  • 正是驗證：尋找違反邏輯表達的狀態模型檢查

# Informal Verification 非正式驗證

• 通常透過手動檢查相應的部分
• 技巧包含：桌面檢查，檢查，演練與同行回饋

# Verification Is Consistency Checking 驗證是一致性檢驗

• 內部一致性：一個不能有矛盾的規格
• 兩個抽象物件等級的一致性:
  • 軟體設計規格與需求規格
  • Data Flow Diagram 分解等級
• 產品與標準之間的一致性

# V&V 在需求階段

• 在需求階段會發生的活動包含:
  • 技術回饋，專家回饋與顧客回饋
  • 原型製作
  • 檢查與演練
  • 正式與非正式驗證與需求追蹤

Technival Review 技術回饋

• 技術回饋會被內部開發者之中尋找
  • 未完成的定義
  • 未完成的條件制定像是 if 條件中並沒有 else 的部分 或者少於 2* *n 規格的 n 元條件式
  • 不一致的需求 / 種類與邏輯表達式
  • 不同定義與需求
  • 重複的概念制定 需求或是限制
  • 需求追蹤問題
  • 不需要的實作細節 e.g.
    • 使用指標，定義實體資料結構
    • 使用 pseudo-code (偽代碼) 或是程式語言說明
  • 淺在的可行性 / 效能及成本問題

Checking Requirements and Constraints 檢查需求與限制

• 定義完整性
  • 每個在需求中被提到的概念需要明確的定義
  • 專注於重點但未定義形容詞 e.g. 好的顧客收到 20% 折扣 (誰是好顧客)
  • 每個定義出來的概念需要至少被利用一次
  • 型別一致性
    • 物件型別包含每一個對應定義的概念以及被用到的概念
  • 邏輯完整性與一致性

Ambiguity in Requirements 不同定義的需求

• And/Or 不同定義
• 邏輯一致性意思？

Completeness 完整性

所有有的用例 Usecase 都被覆蓋

• External completeness 外部完整性: a validation problem 確認問題有效性
• Internal completeness 內部完整性: a verification problem 確認問題正確性

Consistency 一致性

不存在衝突，系統在理論上可行的

Unambigutiy 無異意性

所有需求不存在多個不同的解釋

Expert Review 專家回饋

專家回饋會發生在該專業領域的專家，他們尋找

• 不正確的領域概念 / 規則 / 政策 / 標準
• 概念化問題
• 制定錯誤的業務規則
• 其他領域的特定問題

Csutomer Review 客戶回饋

這些回饋者會發生在顧客代表與使用者，他們尋找

• 不符合的需求與實際估能
• UI 問題，像是操作順序，外觀，GUI 實作技術
• 提出非技術需求問題
• 應用程式特殊限制像是作業系統 / 成本 / 政策考量問題

Requirements Tracing 需求追蹤

• 發生於需求發起者優先於外部回饋者
• 確保每個高級需求對應一些低級需求
• 確保每個低級需求對應一些高級需求
• 確保低級需求能足夠去了解高級需求

V&V in the Requirements Phase 有效與驗證在需求階段

• V&V 在需求階段同樣的要檢查 需求用例 UseCase 追朔舉證
  • 確保每個需求是可以被其他用例 UseCase 實現的
  • 每個用例實現一些需求
• 使用雛形去展示系統對於客戶代表與使用者代表的能力

V&V of Architetctural Design 有效與確認之架構設計

• Activities 活動:
  • 同行設計回饋
  • 設計檢驗
  • 設計演練
• 檢查設計品質指標
• 檢查確保需求與限制都是履行的
• 檢查去確保軟體設計原則與安全原則都符合

Desirable Properties for Architectural Design 架構設計可取得屬性

• 子系統與模組應該被功能上有內聚力
• 子系統與模組之間的交流應該明確
• 模組應該小又精簡去理解
• 決策應該被侷限在一個單一模組
• 模組應該簡單去測試與維修
• 避免隱含的全域假設

V&V in the Implementation Phase 確認與有效在實作階段

• Activities 活動:
  • 細節設計回饋
  • 程式碼回饋，檢查與演練
  • 測試
  • 可靠性評估
• 檢查
  • 相對應實作與設計
  • 模組介面的一致性
  • 實作的正確性
  • 程式碼標準一致性
  • 正確使用程式結構
  • 未初始化 / 不恰當的 初始化變數，結構或是指標
  • 根據不同的程式碼品質指標的程式碼品質
    • cyclomatic complexity 循環複雜度
    • information hiding 資訊隱藏程度
    • cohesion and coupling 內聚與耦合程度
    • modularity 模組化程度

# Software Quality Assurance Functions 軟體品質保證函式

• 流程 (Process) 與標準 (Standard) 的定義
  • 流程與方法論 (Methodology) 的定義
  • 軟體品質保證 (SQA) 標準與程序 (Procedure) 定義
  • 指標 (Metrics) 與指標 (Indicator) 的定義
• 品質管理
  • 品質計畫
  • 軟體品質保證 (SQA) 確認
• 流程改善

# Definition of Processes and Standards 流程與標準的定義

• 軟體品質保證框架的定義
  • 定義開發，品質保證與流程管理與方法論
  • 定義軟體品質保證標準，過程與準則
  • 定義品質指標與品質衡量與評估的指標

# Quality Management Planning 品質管理計畫

• 品質計畫定義一套會被執行的活動的行程順序去確保想要的軟體品質

Components of an SQA Plan 軟體品質保證計畫的元件

• 目的
• 管理
• 標準與慣例
• 回饋與審計
• 軟體設置管理
• 會被使用的流程，方法論，工具與技術
• 會被使用的指標 (Metrics) 與指標 (Indicators)

Humphrey’s Quality Plan Outline 漢弗萊的質量計劃大綱

• 產品介紹
• 產品計畫
• 流程描述
• 品質目標
• 風險與風險管理

SQA Control 軟體品質保證控制

• 她確保軟體品質保證計畫會被正確的執行
• 監控專案軟體開發
• 收集與管理軟體品質保證相關資料
• 他回報軟體流程改善流程資料

Process Improvement 流程改善

• 定義與執行改善流程形成 (process improvement process,PIP)
• 定義流程改善指標
• 集合改善流程資料
• 計算指標 (metrics) 與指標 (indicators)
• 產生流程改善建議去管理

Applying Agile Principles 應用敏捷原則

• 足夠好就好
• 保持簡單且容易遵守
• 管理支援式必要的
• 相關與合作的會在股東之間是必要得˙
• 團隊必須被授權去做決策
• 軟體所有文件的運作價值