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

品質管理
(Quality Management)
 管理軟體行程(process)和產品(product)的
品質
目的
 介紹品質管理的行程和品質管理的重要活動
 說明品質管理中標準(standards)所扮演的
角色
 說明軟體度量(software metrics)、預測度
量(predictor metrics)和控制度量
(control metrics)的概念
 說明測量(measurement)如何被用來評估
軟體品質(access software quality)
主題
1. 品質保證和標準(quality assurance and
standard)
2. 品質計劃(quality planning)
3. 品質控制(quality control)
4. 軟體測量和度量(software measurement and
metric)
5. 物件導向系統的技術性度量(technical metric
for object-oriented system)
軟體品質管理
 確保軟體產品達到所需的品質層次(required
level of quality)
 包括定義適當的品質標準和程序(procedures)，
並確保遵循這些標準和程序
 專注於發展品質文化(quality culture)，品質
被視為每個人的責任
品質是什麼?
 簡單來說，品質意指產品必須符合產品的
規格
 這對軟體系統是有問題的
 顧客品質需求(效率、可靠度等)和開發者品質
需求(可維護性、重覆使用性等)是有衝突的
 有些品質的需求，很難清楚的指明
 軟體規格常常不完整(incomplete)及不一致
(inconsistent)
品質妥協
(Quality Compromise)
 儘管規格有所不周(imperfect specification)，
仍須將程序置入(put procedures into place)以
改善品質
 品質管理(quality management)不是只關心減
少缺失(reduce defects)，而是也關心產品的
品質
品質管理活動
 品質保證(quality assurance)
 建立品質的組織性程序及標準
(organizational procedures and
standards)
 品質計劃(quality planning)
 針對特定專案選擇適當的程序和標準，並視需
要修改之
 品質控制(quality control)
 確保軟體開發團隊遵循程序和標準
 品質管理應該和專案管理(project
management)分開以確保獨立性
品質管理和軟體發展
(Quality Management and Software Development)
ISO 9000
 為品質管理的一系列國際標準
 應用範圍可從製造業到服務業
 ISO 9001是應用於設計、發展和維護產品的
組織
 ISO9001是一個品質行程的通用模型(generic
model)，必須為每個組織實化(instantiated)
ISO 9001模型對品質保證的涵蓋領域
Management responsibility
Control of non-conforming products
Handling, storage, packaging and
delivery
Purchaser-supplied products
Process control
Inspection and test equipment
Contract review
Document control
Internal quality audits
Servicing
Quality system
Design control
Purchasing
Product identification and traceability
Inspection and testing
Inspection and test status
Corrective action
Quality records
Training
Statistical techniques
ISO 9000認證
(ISO 9000 Certification)
 品質標準和程序應被記錄在組織的品質手冊
 外部機構(external body)可確認(certify)一個
組織的品質手冊是否符合ISO 9000標準
 越來越多的客戶要求供應商通過ISO 9000的
認證
ISO 9000和品質管理
1. 品質保證和標準
(Quality Assurance and Standards)
 標準(standard)是達到有效品質管理的關鍵
 它們可以是國際的、全國的、組織的或專案
的標準
 產品標準(product standard)定義所有元件需
呈現(exhibit)的特性(characteristics)，像是常
用的程式語言型態(common programming
style)
 行程標準(process standard)定義軟體行程所
扮演的角色(how the software process should
be enacted)
標準的重要性
 囊括最好的實踐方法(encapsulation of best
practice)，避免重複過去的錯誤
 品質保證行程(quality assurance process)的架
構(framework)
 涉及檢查符合標準(standard compliance)
 提供連續性(continuity)，新員工可藉由了解
所使用的標準而認識該組織
產品和行程的標準
標準的問題
(Problems with Standard)
 涉及太多官僚文件的填寫(bureaucratic form
filling)
 缺乏軟體工具的支援，以致於需要繁鎖的人
力以維護標準
標準的開發
(Standards Development)
 開發中的實踐者(practitioners in development)
 工程師應該了解標準的合理原因(rationale
underlying a standard)
 經常審查標準(review standards)及其用法
 標準會很快過時，需經常審查標準
 標準細節(detailed standards)應該有相關的支
援工具
1.1 文件標準
 特別重要-文件是軟體的有形呈現(tangible
manifestation)
 文件行程標準
 文件應如何被開發、驗證和維護
 文件標準
 關於文件的內容(content)、結構(structure)和外觀
(appearance)
 文件交換標準
 文件該如何在不同文件系統中被儲存和交換
文件產生行程包含品質檢查
文件標準
(Document Standards)
 文件辨識標準(document identification standard)
 文件如何被唯一識別(uniquely identified)
 文件結構標準(document structure standard)
 專案文件的標準結構
 文件呈現標準(document presentation standard)
 定義字型(font)和樣式(style)及商標(logo)的使用
 文件更新標準(document update standard)
 定義如何在文件中反應(reflect)與先前版本的差異
文件交換標準
(Document Interchange Standards)
 文件是透過不同電腦上的不同系統所產生
 交換標準允許電子文件(electronic document)
被交換(exchanged)、被寄送(mailed)等
 可擴充性標記語言(XML)是一個文件交換的
標準
1.2 行程及產品品質
 開發產品的品質會受生產行程(production
process)的品質影響
 在軟體開發特別重要，因為有些產品品質的
屬性難以評估(assess)
 然而，在軟體行程和產品品質間常是非常複
雜且難以理解
以行程為基礎的品質
(Process-Based Quality)
 直接連結(straightforward link)製造商品的行程和產
品
 對於軟體更為複雜是因為
 在軟體發展中，應用個人技巧(personal skills)和
經驗(experience)是特別重要的
 外部因素(external factors)，如對應用程式的新手
經驗(novelty of an experience)或加速開發時程的
需求(accelerated development schedule)，可能損
害(impair)產品品質
 必須注意不要加入不適當的行程序標準(process
standard)
以行程為基礎的品質
實用的行程品質
(Practical Process Quality)
 制定行程標準，例如應如何實施審查、組態
管理等
 監督開發行程(development process)以確保能
遵循標準
 行程回報給專案管理者(project management)
和軟體取得者(software procurer)
2. 品質計劃
(Quality Planning)
 品質計劃制定了期望的產品品質(desired
product qualities)及它們該如何被評估和定義
最有意義的品質屬性(quality attribute)
 應定義品質評估行程(quality assessment
process)
 應制定引用哪個組織的標準，如有必要也可
制定新的標準
品質計劃結構






產品介紹
產品計劃
行程描述
品質目標
風險及風險管理
品質計劃應該是簡短、簡潔的文件
軟體品質屬性
3. 品質控制
(Quality Control)
 檢查軟體發展行程，以確保遵照程序和標準
 兩個品質控制的方法
 品質審查(quality reviews)
 自動化軟體評估(software assessment)及軟體測量
(software measurement)
3.1 品質審查
 為主要驗證行程或產品品質的方法
 檢查行程或系統的部份或全部以及它的文件
，以發現潛在的問題
 有不同目的(objectives)的審查類型(review
types)
 缺失移除檢查(產品)
 進展評估(progress assessment)審查 (產品和程序)
 品質審查(產品和標準)
審查類型
(Types of Review)
Review type
Design or
inspections
Progress reviews
Quality reviews
Principal purpose
program 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.
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.
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.
品質審查
(quality Reviews)
 一群組人員仔細檢查軟體系統的部份或全部
以及它的相關文件，包括
 程式碼(code)、設計(design)、規格(specification)、
測試計劃(test plan)、標準(standard)等
 軟體或文件在審查時被管理者認可簽署
(signed off)，表示可進展到下一個發展階段
品質審查的行程
審查功能
 品質功能(quality function)
 為一般品質管理行程的一部份
 專案管理功能(project management function)
 提供資訊給專案管理者
 訓練和溝通功能(training and communication
function)
 產品知識在發展團隊成員間彼此傳送
品質審查
 目的是發現系統缺失(defect)和不一致
(inconsistency)
 審查任何在行程中產生的文件
 審查應被記錄，並且記錄應被保留
審查結果
 審查的評論(comments)應做分類
 不需動作(no action)：不需要改變軟體或文件
 參考修復(refer for repair)：設計者或程式設計
師應改正標示出的錯誤(identified fault)
 重新考慮全部的設計(reconsider overall design)：
審查中找到的問題會衝擊(impacts)到其它設計
的部份，需經整體評估(overall judgment)以提
出最高成本效益的問題解決方案
 需求和規格的錯誤可能需要諮詢客戶
4. 軟體量測和度量
(Software Measurement and Metric)
 軟體計量是關於取得軟體產品或行程之屬性
的數值(numeric value)
 此允許在技術(technique)和行程(process)中
做客觀的比較(objective comparison)
 雖然有些公司已引進量測程式(measurement
program)，但系統化的使用量測
(measurement)仍不常見(uncommon)
 在此領域中有少數的標準(few standards)可
供遵循
軟體度量
(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)或控制軟體行程
預測程式和控制度量
(Predictor and Control Metrics)
度量假設
(Metrics Assumptions)
 可被測量的軟體性質(software property)
 介於”我們可以量測到什麼”和”我們想知道
什麼”之間的關係(relationship)
 這關係已被形式化(formalized)和驗證
(validated)
內部和外部屬性
(Internal and External Attributes)
4.1 計量行程
(Measurement Process)
 軟體量測行程(software measurement process)
可當做是品質控制行程的一部份
 在行程中搜集的資料(data collected)需要被維
護，當成一種組織的資源(organisational
resource)
 一旦量測資料庫(measurement database)被建
立，專案的評比(comparisons across projects)
便比較可行
產品量測行程
資料搜集
(Data Collection)
 一個度量程式(metrics program)應以一組產
品和處理資料(a set of product and process
data)為依據
 資料應立即被搜集，若可能，最好自動化的
被搜集
 三種自動化資料搜集的類型
 靜態產品分析(static product analysis)
 動態產品分析(dynamic product analysis
 處理資料校對(process data collation)
自動化資料搜集
資料正確性
(Data Accuracy)
 勿搜集不必要的資料
 待回答的問題應事先決定，並確認所需的資料
 告訴人們為何要搜集這些資料
 它不該是用以做人員評估(personal evaluation)的
一部份
 不要依賴記憶
 當資料產生時就當搜集資料，而非專案完成後
才搜集
4.2 產品度量
 品質度量應是一個產品品質的預測程式
(predictor)
 產品度量的類別
 動態度量(dynamic metric)是在程式執行時由量測
所搜集到的
 靜態度量(static metric)是由系統表示方式(system
representations)量測所搜集到的
 動態度量(dynamic metric)協助評估效能
(efficiency)和可用度(reliability)；靜態度量(static
metric)協助評估複雜度(complexity)、可理解性
(understandability)與可維護性(maintainability)
動態和靜態度量
 動態度量(dynamic metric)與軟體品質屬性十分相關
 相對來說，它可以簡單的量測(measure)出系統
的回應時間(效能屬性)或失敗的次數(可靠度屬
性)
 靜態度量(static metric)和品質屬性沒有直接關係
 需試圖得到這些度量(metrics)和性質(properties)
間的關係，這些性質如複雜度(complexity)、可
理解性(understandability)和可維護性
(maintainability)
軟體產品度量
(Software Product Metric)
Software metric
Fan in/Fan-out
Length of code
Cyclomatic
complexity
Length of
identifiers
Depth of
conditional nesting
Fog index
Description
Fan-in is a measure of the number of functions that call some other
function (say X). Fan-out is the number of functions which are called
by function X. A high value for fan-in means that X is tightly
coupled to the rest of the design and changes to X will have
extensive knock-on effects. A high value for fan-out suggests that the
overall complexity of X may be high because of the complexity of
the control logic needed to coordinate the called components.
This is a measure of the size of a program. Generally, the larger the
size of the code of a program’s components, the more complex and
error-prone that component is likely to be.
This is a measure of the control complexity of a program. This
control complexity may be related to program understandability. T he
computation of cyclomatic complexity is covered in Chapter 20.
This is a measure of the average length of distinct identifiers in a
program. The longer the identifiers, the more likely they are to be
meaningful and hence the more understandable the program.
This is a measure of the depth of nesting of if-statements in a
program. Deeply nested if statements are hard to understand and are
potentially error-prone.
This is a measure of the average length of words and sentences in
documents. The higher the value for the Fog index, the more difficult
the document may be to understand.
5. 物件導向系統的技術性度量
(Technical Metrics for Object-Oriented Systems)
 Berard [BER95] 認為下列特徵(characteristics)
需要特別物件導向的度量
 局部化(localization)
 資訊在程式內集中(information is
concentrated in a program)的方式
 封裝(encapsulation)
 資料和行程(data and processing)的包裹
(packaging)
 資訊隱藏(information hiding)
 用一個安全的介面(secure interface)，隱藏操
作細節(operational details)的方式
 繼承(inheritance)
 一個類別傳遞(propagated)給另一個類別的方
法
 抽象化(abstraction)
 允許專注(focus)在必要細節(essential details)
之設計的機制
類別導向度量
(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)
 由Lorenz and Kidd [LOR94]提出
 類別大小(class size)
 被子類別覆蓋的操作數目(number of operations
overridden by a subclass)
 由子類別增加的操作數目(number of operations
added by a subclass)
 特殊化索引(specialization index)
物件導向度量
(Operation-Oriented Metric)
 由Lorenz and Kidd [LOR94]提出
 平均操作大小(average operation size)
 運算複雜度(operation complexity)
 每個操作的平均參數數目
可測試性度量
(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)
物件導向專案度量
(OO Project Metric)
 由Lorenz and Kidd [LOR94] 提出
 情境版本(scenario script)的數目
 鍵值類別(key classes)的數目
 子系統(subsystems)的數目
物件導向度量
(Object-Oriented Metric)
Objectoriented metric
Depth of
inheritance tree
Method fanin/fan-out
Weighted
methods per
class
Number of
overriding
operations
Description
This represents the number of discrete levels in the inheritance tree where sub-classes
inherit attributes and operations (methods) from super-classes. The deeper the inheritance
tree, the more complex the design as, potentially, many different object classes have to be
understood to understand the object classes at the leaves of the tree.
This is directly related to fan-in and fan-out as described above and means essentially the
same thing. However, it may be appropriate to make a distinction between calls from other
methods within the object and calls from external methods.
This is the number of methods included in a class weighted by the complexity of each
method. Therefore, a simple method may have a complexity of 1 and a large and complex
method a much higher value. The larger the value for this metric, the more complex the
object class. Complex objects are more likely to be more difficult to understand. They may
not be logically cohesive so cannot be reused effectively as super-classes in an inheritance
tree.
These are the number of operations in a super-class which are over-ridden in a sub-class. A
high value for this metric indicates that the super-class used may not be an appropriate
parent for the sub-class.
參考資料
 Ian Sommerville, Software Engineering, 7th ed.,
Addison-Wesley，2004.