品質管理 (Quality Management)

Presentation on theme: "品質管理 (Quality Management)"— Presentation transcript:

1 品質管理 (Quality Management)
管理軟體行程(process)和產品(product)的品質

2 目的 介紹品質管理的行程和品質管理的重要活動 說明品質管理中標準(standards)所扮演的角色
說明軟體度量(software metrics)、預測度量(predictor metrics)和控制度量(control metrics)的概念 說明測量(measurement)如何被用來評估軟體品質(access software quality)

3 主題 品質保證和標準(quality assurance and standard) 品質計劃(quality planning)
品質控制(quality control) 軟體測量和度量(software measurement and metric) 物件導向系統的技術性度量(technical metric for object-oriented system)

4 軟體品質管理 確保軟體產品達到所需的品質層次(required level of quality)
包括定義適當的品質標準和程序(procedures)，並確保遵循這些標準和程序 專注於發展品質文化(quality culture)，品質被視為每個人的責任

5 品質是什麼? 簡單來說，品質意指產品必須符合產品的規格 這對軟體系統是有問題的
顧客品質需求(效率、可靠度等)和開發者品質需求(可維護性、重覆使用性等)是有衝突的 有些品質的需求，很難清楚的指明 軟體規格常常不完整(incomplete)及不一致(inconsistent)

6 品質妥協 (Quality Compromise)
儘管規格有所不周(imperfect specification)，仍須將程序置入(put procedures into place)以改善品質 品質管理(quality management)不是只關心減少缺失(reduce defects)，而是也關心產品的品質

7 品質管理活動 品質保證(quality assurance) 品質計劃(quality planning)
建立品質的組織性程序及標準(organizational procedures and standards) 品質計劃(quality planning) 針對特定專案選擇適當的程序和標準，並視需要修改之

8 品質控制(quality control) 品質管理應該和專案管理(project management)分開以確保獨立性
確保軟體開發團隊遵循程序和標準 品質管理應該和專案管理(project management)分開以確保獨立性

9 品質管理和軟體發展 (Quality Management and Software Development)

10 ISO 9000 為品質管理的一系列國際標準 應用範圍可從製造業到服務業 ISO 9001是應用於設計、發展和維護產品的組織
ISO9001是一個品質行程的通用模型(generic model)，必須為每個組織實化(instantiated)

11 ISO 9001模型對品質保證的涵蓋領域 Management responsibility Quality system
Control of non-conforming products Design control Handling, storage, packaging and delivery Purchasing Purchaser-supplied products Product identification and traceability Process control Inspection and testing Inspection and test equipment Inspection and test status Contract review Corrective action Document control Quality records Internal quality audits Training Servicing Statistical techniques

12 ISO 9000認證 (ISO 9000 Certification)
品質標準和程序應被記錄在組織的品質手冊 外部機構(external body)可確認(certify)一個組織的品質手冊是否符合ISO 9000標準 越來越多的客戶要求供應商通過ISO 9000的認證

13 ISO 9000和品質管理

14 品質保證和標準 (Quality Assurance and Standards)
它們可以是國際的、全國的、組織的或專案的標準 產品標準(product standard)定義所有元件需呈現(exhibit)的特性(characteristics)，像是常用的程式語言型態(common programming style) 行程標準(process standard)定義軟體行程所扮演的角色(how the software process should be enacted)

15 標準的重要性 囊括最好的實踐方法(encapsulation of best practice)，避免重複過去的錯誤
品質保證行程(quality assurance process)的架構(framework) 涉及檢查符合標準(standard compliance) 提供連續性(continuity)，新員工可藉由了解所使用的標準而認識該組織

16 產品和行程的標準

17 標準的問題 (Problems with Standard)
涉及太多官僚文件的填寫(bureaucratic form filling) 缺乏軟體工具的支援，以致於需要繁鎖的人力以維護標準

18 標準的開發 (Standards Development)
開發中的實踐者(practitioners in development) 工程師應該了解標準的合理原因(rationale underlying a standard) 經常審查標準(review standards)及其用法 標準會很快過時，需經常審查標準 標準細節(detailed standards)應該有相關的支援工具

19 1.1 文件標準 特別重要-文件是軟體的有形呈現(tangible manifestation) 文件行程標準 文件標準 文件交換標準
文件應如何被開發、驗證和維護 文件標準 關於文件的內容(content)、結構(structure)和外觀(appearance) 文件交換標準 文件該如何在不同文件系統中被儲存和交換

20 文件產生行程包含品質檢查

21 文件標準 (Document Standards)
文件辨識標準(document identification standard) 文件如何被唯一識別(uniquely identified) 文件結構標準(document structure standard) 專案文件的標準結構 文件呈現標準(document presentation standard) 定義字型(font)和樣式(style)及商標(logo)的使用 文件更新標準(document update standard) 定義如何在文件中反應(reflect)與先前版本的差異

22 文件交換標準 (Document Interchange Standards)
文件是透過不同電腦上的不同系統所產生 交換標準允許電子文件(electronic document)被交換(exchanged)、被寄送(mailed)等 可擴充性標記語言(XML)是一個文件交換的標準

23 1.2 行程及產品品質 開發產品的品質會受生產行程(production process)的品質影響
在軟體開發特別重要，因為有些產品品質的屬性難以評估(assess) 然而，在軟體行程和產品品質間常是非常複雜且難以理解

24 以行程為基礎的品質 (Process-Based Quality)
直接連結(straightforward link)製造商品的行程和產品 對於軟體更為複雜是因為 在軟體發展中，應用個人技巧(personal skills)和經驗(experience)是特別重要的 外部因素(external factors)，如對應用程式的新手經驗(novelty of an experience)或加速開發時程的需求(accelerated development schedule)，可能損害(impair)產品品質 必須注意不要加入不適當的行程序標準(process standard)

25 以行程為基礎的品質

26 實用的行程品質 (Practical Process Quality)
制定行程標準，例如應如何實施審查、組態管理等 監督開發行程(development process)以確保能遵循標準 行程回報給專案管理者(project management)和軟體取得者(software procurer)

27 2. 品質計劃 (Quality Planning)
品質計劃制定了期望的產品品質(desired product qualities)及它們該如何被評估和定義最有意義的品質屬性(quality attribute) 應定義品質評估行程(quality assessment process) 應制定引用哪個組織的標準，如有必要也可制定新的標準

28 品質計劃結構 產品介紹 產品計劃 行程描述 品質目標 風險及風險管理 品質計劃應該是簡短、簡潔的文件

29 軟體品質屬性 Resilience：恢復力

30 3. 品質控制 (Quality Control)
檢查軟體發展行程，以確保遵照程序和標準 兩個品質控制的方法 品質審查(quality reviews) 自動化軟體評估(software assessment)及軟體測量(software measurement)

31 3.1 品質審查 為主要驗證行程或產品品質的方法 檢查行程或系統的部份或全部以及它的文件，以發現潛在的問題
有不同目的(objectives)的審查類型(review types) 缺失移除檢查(產品) 進展評估(progress assessment)審查 (產品和程序) 品質審查(產品和標準)

32 審查類型 (Types of Review) Review type Principal purpose Design or program
inspections To detect detailed errors in the design or code and to check whether standards have been followed. The review should be driven by a checklist of possible errors. Progress reviews To provide information for management about the overall progress of the project. This is both a process and a product review and is concerned with costs, plans and schedules. Quality reviews To carry out a technical analysis of product components or documentation to find faults or mismatches between the specification and the design, code or documentation. It may also be concerned with broader quality issues such as adherence to standards and other quality attributes.

33 品質審查 (quality Reviews)
一群組人員仔細檢查軟體系統的部份或全部以及它的相關文件，包括 程式碼(code)、設計(design)、規格(specification)、測試計劃(test plan)、標準(standard)等 軟體或文件在審查時被管理者認可簽署(signed off)，表示可進展到下一個發展階段

34 品質審查的行程

35 審查功能 品質功能(quality function) 專案管理功能(project management function)
為一般品質管理行程的一部份 專案管理功能(project management function) 提供資訊給專案管理者 訓練和溝通功能(training and communication function) 產品知識在發展團隊成員間彼此傳送

36 品質審查 目的是發現系統缺失(defect)和不一致(inconsistency) 審查任何在行程中產生的文件
審查應被記錄，並且記錄應被保留

37 審查結果 審查的評論(comments)應做分類 需求和規格的錯誤可能需要諮詢客戶 不需動作(no action)：不需要改變軟體或文件
參考修復(refer for repair)：設計者或程式設計師應改正標示出的錯誤(identified fault) 重新考慮全部的設計(reconsider overall design)：審查中找到的問題會衝擊(impacts)到其它設計的部份，需經整體評估(overall judgment)以提出最高成本效益的問題解決方案 需求和規格的錯誤可能需要諮詢客戶

38 4. 軟體量測和度量 (Software Measurement and Metric)
軟體計量是關於取得軟體產品或行程之屬性的數值(numeric value) 此允許在技術(technique)和行程(process)中做客觀的比較(objective comparison) 雖然有些公司已引進量測程式(measurement program)，但系統化的使用量測(measurement)仍不常見(uncommon) 在此領域中有少數的標準(few standards)可供遵循

39 軟體度量 (Software Metric)
任何有關軟體系統(software system)、行程(process)或相關文件的量測類型(measurement types) 程式中程式碼的行數(lines of code) 霧指數(fog index)，一種對文件訊息(a passage of written text)可讀性(readability)的量度方法 開發一個元件(component)所需的人日(number of person-days) 允許軟體和軟體行程被量化 軟體行程或產品的量度(measures) 可用來預估產品屬性(attribute)或控制軟體行程

40 預測程式和控制度量 (Predictor and Control Metrics)

41 度量假設 (Metrics Assumptions)
可被測量的軟體性質(software property) 介於”我們可以量測到什麼”和”我們想知道什麼”之間的關係(relationship) 這關係已被形式化(formalized)和驗證(validated)

42 內部和外部屬性 (Internal and External Attributes)

43 4.1 計量行程 (Measurement Process)
軟體量測行程(software measurement process)可當做是品質控制行程的一部份 在行程中搜集的資料(data collected)需要被維護，當成一種組織的資源(organisational resource) 一旦量測資料庫(measurement database)被建立，專案的評比(comparisons across projects)便比較可行

44 產品量測行程

45 資料搜集 (Data Collection)
一個度量程式(metrics program)應以一組產品和處理資料(a set of product and process data)為依據 資料應立即被搜集，若可能，最好自動化的被搜集 三種自動化資料搜集的類型 靜態產品分析(static product analysis) 動態產品分析(dynamic product analysis 處理資料校對(process data collation)

46 自動化資料搜集

47 資料正確性 (Data Accuracy) 勿搜集不必要的資料 告訴人們為何要搜集這些資料 不要依賴記憶
待回答的問題應事先決定，並確認所需的資料 告訴人們為何要搜集這些資料 它不該是用以做人員評估(personal evaluation)的一部份 不要依賴記憶 當資料產生時就當搜集資料，而非專案完成後才搜集

48 4.2 產品度量 品質度量應是一個產品品質的預測程式(predictor) 產品度量的類別
動態度量(dynamic metric)是在程式執行時由量測所搜集到的 靜態度量(static metric)是由系統表示方式(system representations)量測所搜集到的 動態度量(dynamic metric)協助評估效能(efficiency)和可用度(reliability)；靜態度量(static metric)協助評估複雜度(complexity)、可理解性(understandability)與可維護性(maintainability)

49 動態和靜態度量 動態度量(dynamic metric)與軟體品質屬性十分相關
相對來說，它可以簡單的量測(measure)出系統的回應時間(效能屬性)或失敗的次數(可靠度屬性) 靜態度量(static metric)和品質屬性沒有直接關係 需試圖得到這些度量(metrics)和性質(properties)間的關係，這些性質如複雜度(complexity)、可理解性(understandability)和可維護性(maintainability)

50 軟體產品度量 (Software Product Metric)

51 5. 物件導向系統的技術性度量 (Technical Metrics for Object-Oriented Systems)
Berard [BER95] 認為下列特徵(characteristics)需要特別物件導向的度量 局部化(localization) 資訊在程式內集中(information is concentrated in a program)的方式 封裝(encapsulation) 資料和行程(data and processing)的包裹(packaging)

52 資訊隱藏(information hiding)
用一個安全的介面(secure interface)，隱藏操作細節(operational details)的方式 繼承(inheritance) 一個類別傳遞(propagated)給另一個類別的方法 抽象化(abstraction) 允許專注(focus)在必要細節(essential details)之設計的機制

53 類別導向度量 (Class-Oriented Metric)
由 Chidamber and Kemerer提出 每類加權的方法(weighted methods per class) 繼承樹(inheritance tree)的深度(depth) 子(children)的數目 物件類別間的耦合(coupling between object classes) 對類別的回應(response for a class) 方法中缺乏凝聚性的程度(lack of cohesion in methods)

54 由Lorenz and Kidd [LOR94]提出
類別大小(class size) 被子類別覆蓋的操作數目(number of operations overridden by a subclass) 由子類別增加的操作數目(number of operations added by a subclass) 特殊化索引(specialization index)

55 物件導向度量 (Operation-Oriented Metric)
由Lorenz and Kidd [LOR94]提出 平均操作大小(average operation size) 運算複雜度(operation complexity) 每個操作的平均參數數目

56 可測試性度量 (Testability Metric)
由Binder [BIN94]提出 相關封裝(encapsulation related) 方法所缺少的凝聚性(lack of cohesion in methods) 公用的(public)和受保護的(protected)百分比 對資料成員的公用存取(public access to data members) 繼承相關(inheritance related) 根類別的數目 扇形收斂(fan in) 子(children)的數目和繼承樹(inheritance tree)的深度(depth)

57 物件導向專案度量 (OO Project Metric)
由Lorenz and Kidd [LOR94] 提出 情境版本(scenario script)的數目 鍵值類別(key classes)的數目 子系統(subsystems)的數目

58 物件導向度量 (Object-Oriented Metric)

59 參考資料 Ian Sommerville, Software Engineering, 7th ed., Addison-Wesley，2004.