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

---

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(C) = 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’ 是 C的直接子class}|

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

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

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

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

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

RFC(C) = |{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(C) = 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 應用敏捷原則

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