【第174期 March 5, 2012】
 

CMMI與軟體工程

CMMI-DEV V1.3 度量與分析流程領域 (上)

作者/林靜蘭

[發表日期:2012/3/5]


前言

CMMI-DEV V1.2 於2011年11月30走入歷史。自12月1日起,卡耐基美隆大學軟體工程學院(Software Engineering Institute-SEI)將全面推行CMMI-DEV V1.3相關的訓練及評鑑活動。

CMMI-DEV V1.3 主要調整內容是將高能力成熟度(High Maturity Level-包括ML4 及 ML5)做更清楚的說明,把原本分佈於各流程領域內的“共同目標(Generic Goal)”及“共同執行方法(Generic Practice)”集中到各流程領域之前。對於每個流程領域的“典型工作產品(Typical Work Products)”改稱為“工作產品舉例(Example Work Products)”。另外,對於每個流程領域的內容描述也有改進與調整,並且增加關於“敏捷式開發方法(Agile Programming)”之內容。

度量與分析在CMMI模式中歸類為成熟度第二級的「支援類流程領域」。本文主要的目的是轉載V1.3中度量與分析流程領域的特定目標(Specific Goal)及特定執行方法(Specific Practice)的中譯版內容,其中與V1.2主要不同處將以紫色字特別標註,全文將分上、下兩篇刊登。

目的

度量與分析(Measurement and Analysis,MA)之目的在發展與維持度量能力,以支援管理的資訊需求。

簡介

度量與分析流程領域包括:

  • 指定度量與分析的目標,並使其配合已界定的資訊需求與專案、組織或經營目標
  • 指定度量、分析技術、資料蒐集、資料儲存以及報告與回饋機制
  • 對資料的蒐集、報告及回饋進行分析技術及機制
  • 提供客觀的結果以做出有根據的決策,並採取適當的矯正措施

將度量與分析活動整合到專案流程中,可支援下列活動:
  • 客觀的規劃與估計
  • 根據建立的計畫和目標,追蹤實際績效
  • 界定與解決流程相關議題
  • 提供將度量納入未來增訂流程的基礎

執行度量功能的同仁,不一定需參與組織層面的計畫;度量功能可以整合至個別專案,或其他的組織功能(例如:品質保證)。

度量活動最初的重點在於專案,而度量功能在處理組織面與(或)企業面的資訊需求上,亦經證明確實有用。為支援度量功能,度量活動應支援多層次的資訊需求,包括業務、組織單位、專案及當組織成熟時,支援減低重工。

專案可選擇在專案特定儲存庫中來儲存專案的資料與結果,當資料更廣為運用或會被分析來決定資料趨勢或基準時,則可存放於組織度量儲存庫。

針對供應商提供的產品組件進行度量與分析,對有效管理專案的品質與成本是必要的。經由謹慎的管理供應商協議,可深入瞭解支援供應商績效分析的資料。

度量目標衍生自專案、組織或經營目標。在這個流程領域,當用到「目標」但沒有標示「度量」修飾語,它表示專案、組織或經營目標。

相關流程領域
  • 有關誘導、分析及建立客戶需求、產品與產品組件,請參考需求發展流程領域,以獲得更多資訊。
  • 有關建立及維護工作產品的建構項目、建構管理 、建構狀況統計、建構稽核,請參考建構管理流程領域,以獲得更多資訊。
  • 有關建立組織度量儲存庫,請參考組織流程定義流程領域,以獲得更多資訊。
  • 有關監控專案計畫屬性,請參考專案監控流程領域,以獲得更多資訊。
  • 有關建立估算,請參考專案規劃流程領域,以獲得更多資訊。
  • 有關量化管理,請參考量化專案管理流程領域,以獲得更多資訊。
  • 有關維持需求的可溯性和相關資訊需求,請參考需求管理流程領域,以獲得更多資訊。

特定目標(Specific Goal – SG) 及執行方法(Specific Practice – SP) 摘要:

SG 1 安排度量與分析的活動
SP 1.1 建立度量目標
SP 1.2 指定度量
SP 1.3 指定資料蒐集與儲存程序
SP 1.4 指定分析程序

SG 2 提供度量結果
SP 2.1 取得度量資料
SP 2.2 分析度量資料
SP 2.3 儲存資料與結果
SP 2.4 溝通結果

特定目標1 (SG1) 安排度量與分析的活動

度量目標與活動要配合已界定的資訊需求與目標。

本目標涵蓋的特定執行方法,可同時處理或依任意順序處理:
  • 建立度量目標時,專家經常先考量界定度量和分析程序的必要準則,同時也會考量資料蒐集與儲存程序的限制。
  • 在處理度量規格、資料蒐集或儲存等細節之前,先界定需進行的必要分析,這是重要的。

特定執行方法1.1 (Specific Practice– SP1.1) 建立度量目標

建立並維護度量目標,此度量目標衍生自已界定的資訊需求與目標
  • 度量目標記錄完成度量與分析活動的目的,並界定基於資料分析的結果,需要採取何種行動。基於實施度量和分析活動的結果,度量目標也確定了所需要改變的行為 。
  • 度量目標的來源可能是管理、技術、專案、產品或流程實施的需要。
  • 度量目標可能受限於現行的流程、可用的資源或其他的度量考量,需要判斷投入度量工作之資源與度量結果的價值是否相當。
  • 度量與分析的過程及結果,能影響已界定的資訊需求與目標的修改


資訊需求與目標的來源,舉例如下:
  • 專案計畫
  • 專案績效的監控
  • 與管理人員和其他具有資訊需求的人員進行訪談
  • 已建立的管理目標
  • 策略計畫
  • 經營計畫
  • 正式需求或合約義務
  • 再發的或其他棘手的管理或技術問題
  • 其他專案或組織的經驗
  • 外部的產業標竿
  • 流程改善計畫



度量目標舉例如下:
  • 提供洞察時程變動及進度
  • 提供了解實際與計畫的專案大小
  • 確定未被計畫的增長
  • 評估整個產品開發生命週期缺失偵測有效
  • 確定缺失矯正的成本
  • 提供了解實際與計畫成本
  • 評估供應商計畫進度與實際進度
  • 評估降低漏洞資訊系統的有效性


  • 有關誘導、分析及建立客戶需求和建立產品與產品組件,請參考需求發展流程領域,以獲得更多資訊。
  • 有關監控專案計畫屬性,請參考專案監控流程領域,以獲得更多資訊。
  • 有關建立估算,請參考專案規劃流程領域,以獲得更多資訊。
  • 有關維持需求的可追溯性和相關資訊需求,請參考需求管理流程領域,以獲得更多資訊。


工作產品舉例
  1. 度量目標

細部執行方法
  1. 記錄資訊需求與目標。

  2. 排定資訊需求與目標的優先順序。
    並非所有最初界定的資訊需求都需要度量與分析,在可用資源的限制下,必須排定優先順序。

  3. 記錄、審查及更新度量目標。
    仔細考量度量與分析之目的與預期用途是重要的。
    記錄度量目標,並交由管理人員和其他相關之關鍵人員審查,必要時給予更新,使得接續的度量與分析活動可以追溯,並幫助確保分析活動可適當的說明資訊需求與目標。
    讓度量與分析結果的使用者參與設定度量目標與決定行動計畫是重要的;而讓提供度量資料的人員參與也是適當的。

  4. 必要時提供回饋,以調修和釐清資訊需求與目標。
    設定度量目標後可能需修訂和釐清界定的資訊需求與目標。資訊需求的初始描述可能不清楚或模糊、現存的需求和目標之間可能產生抵觸,對一個已經存在的度量,要求精確的目標可能是不切實際的。

  5. 維持度量目標和指定資訊需求與目標之間的可溯性。
    對於「為何要作這項度量?」這樣的問題必須要有好的答案。
    當然,也可以改變度量目標,以反映不斷發展的資訊需求與目標。


特定執行方法1.2 (Specific Practice – SP1.2) 指定度量

指定度量以說明度量的目標

將度量目標調修為精確、可量化的度量。

度量項目和組織工作,通常可以追溯到一個或多個度量類別,這些類別包括期程和進度、人力和成本、規模大小和穩定度以及品質。

度量可以是基礎度量或衍生度量。基礎度量資料得自於直接度量,衍生度量資料來自其他資料,通常結合多個基礎度量而得。



一般使用的基礎度量,舉例如下:
  • 工作產品規模大小的估計及實際度量(例如:頁數)
  • 人力與成本的估計及實際度量(例如:人時)
  • 品質度量(例如:缺失數、依嚴重程度區分的缺失數)
  • 資訊安全度量值(例如:確認的系統漏洞數)
  • 客戶滿意度調查分數



一般使用的衍生度量,舉例如下:
  • 所得價值(Earned Value)
  • 時程績效指標(SPI)
  • 缺失密度
  • 同仁審查涵蓋度
  • 測試或驗證涵蓋度
  • 可靠度度量(例如:平均失敗時間)
  • 品質度量(例如:依嚴重程度區分的缺失數/總缺失數)
  • 資訊安全度量值(例如:降低系統漏洞數百分比)
  • 客戶滿意趨勢


衍生度量通常以比例、混合指標或其他合計度量來表示。衍生度量由基礎度量產生,通常比基礎度量更具數量可信度和說明意義。

資訊需求,度量目標,度量類別,基礎度量及衍生度量之間的直接關係。表MA.1用一些常見的例子描述之間的直接關係。

Table MA.1: 度量關係範例表

工作產品舉例
  1. 基礎與衍生度量規格

細部執行方法
  1. 依據文件化的度量目標,界定可能的度量。
    度量目標被調修為特定的度量,根據度量的名稱和單位,將這些可能的度量予以分類。

  2. 維護度量與度量目標的追溯性。
    選擇度量之間的相互依存關係的措施,確定之後的數據分析,驗證可以支持度量目標。


  3. 指定度量的操作定義。
    以精確和明白的方式陳述操作定義,有下列兩個重要準則:

    • 可溝通:度量什麼?如何度量?度量的單位是什麼?包括或排除什麼?
    • 可重複:在相同的定義下,度量是否可以重複執行,且獲得相同的結果?


  4. 將度量排序,並予以審查及更新。
    請可能的最終使用者和其他相關的關鍵人員,對所建議之度量規格的適當性進行審查。可設定或改變排序,必要時可更新度量規格。


特定執行方法1.3 (Specific Practice – SP1.3) 指定資料蒐集與儲存程序

指定度量資料如何獲得與儲存。

明確規範蒐集方法可確保適當的蒐集正確的資料,也幫助更進一步釐清資訊需求和度量目標。
注意儲存和取用程序,可協助確保資料將來的可用性及可存取性。

工作產品舉例
  1. 資料蒐集與儲存程序
  2. 資料蒐集工具

細部執行方法
  1. 界定由目前工作成果、流程或交易產生的資料來源。
    在指定度量時,可能已有現行的資料來源。不論相關的資料是否已蒐集,適當的資料蒐集機制可能已存在。

  2. 界定目前沒有資料,但需要的度量。

  3. 為每一項需要的度量,指定資料蒐集與儲存的方法。
    明確的規格包括什麼資料,如何,在哪裡被收集和儲存,以確保其有效性和支持後用於分析和文檔的目的。


    通常考量的問題包括如下:
    • 提供洞察時程變動及進度
    • 提供了解實際與計畫的專案大小
    • 確定未被計畫的增長
    • 評估整個產品開發生命週期之缺失、偵測有效性
    • 確定缺失矯正的成本
    • 提供了解實際與計畫成本
    • 評估供應商計畫進度與實際進度
    • 評估降低漏洞資訊系統的有效性


  4. 建立資料蒐集的機制與流程指引。
    資料蒐集與儲存的機制需與其他一般工作流程整合。資料蒐集的機制可以包括人工/自動的表格與樣板。負責這項工作的人員,提供清楚簡明的指引以正確執行工作,並視需要提供訓練,說明蒐集資料的流程,以便蒐集完整、正確的資料,並減輕負責提供和記錄資料人員的負擔。

  5. 適當且可行時,支援資料蒐集自動化。


    自動化的支援,舉例如下:
    • 時間戳記的活動日誌
    • 成果的靜態或動態分析

  6. 對資料蒐集與儲存程序加以排序,並進行審查及更新。
    資料蒐集與儲存程序的適當性與可行性,必須經過負責提供、蒐集及儲存資料人員的審查,他們對於如何改進現行的流程或建議其他有用的度量和分析,具備洞察力。

  7. 必要時更新度量與度量目標。


特定執行方法1.4 (Specific Practice – SP1.4) 指定分析程序

指定度量資料如何分析與溝通

事先指定度量的分析程序,可確保執行適當的分析與報告,藉以說明已記錄的度量目標(亦說明了資訊需求和目標,因其為度量目標的基礎)。此方法也是必要資料蒐集的一種查核。分析程序應注意所有納入分析(無論從專案,組織的度量資料庫,或其他來源)的資料的品質(如年齡,可靠性),應考慮數據的品質以助於選擇適當的分析過程和評估結果的分析。

工作產品舉例
  1. 分析規格與程序
  2. 資料分析工具

細部執行方法
  1. 指定將要執行的分析與將準備的報告,並排定優先順序。
    及早注意所執行的分析,以及分析報告呈現的方式。應符合下列準則:
    • 分析可以清楚的說明度量目標。
    • 表達結果的方式,能讓需處理此結果的人員清楚瞭解。
      在可取得的資源內排定優先順序。

  2. 選擇適當的資料分析方法與工具。

    考量點通常包括如下:
    • 選擇視覺顯示方法和其他呈現技術(例如:圓形圖、長條圖、柱狀圖、雷達圖、線條圖、分佈圖或表格)
    • 選擇適合的敘述統計方法(例如:算數平均數、中數或眾數)
    • 當無法或無必要檢驗每一資料元素時,決定統計取樣的準則
    • 當出現缺少資料元素時,決定如何處理分析
    • 選擇適當的分析工具

    敘述統計通常用於資料分析,以執行下列事項:
    • 審查指定度量的分佈(例如:集中趨勢、變化程度、資料點呈現異常變異)
    • 審查指定度量之間的相互關係(例如:以產品生命週期的不同階段或產品組件來比較缺失)
    • 顯示隨著時間的變化

  3. 指定分析資料和溝通結果的管理程序。

    考量點通常包括如下:
    • 指定適合的人員和團體負責分析資料和簡報結果
    • 決定分析資料和簡報結果的時間
    • 決定溝通結果的方式(例如:進度報告、傳送備忘錄、書面報告或工作人員會議)

  4. 審查並更新分析與報告的內容和形式。
    所有提出的分析與報告內容和形式應予審查、修正,包括分析方法和工具、管理程序及優先順序。相關關鍵人員的諮詢應該包括預期的最終使用者、贊助者、資料分析人員及資料提供人員。

  5. 必要時,更新度量與度量目標。
    正如同度量需求會導引資料分析,清楚的分析準則會影響度量。以資料分析程序為基礎,某些度量規格可能會進一步調修,其他度量可能並不需要,或發現需要其他的度量。
    當描述度量如何分析和報告時,可能同時會建議調修度量目標。

  6. 指定評估分析結果有用性及評估度量與分析活動的準則。

    評估分析結果有用性的準則,可以考慮下列項目的應用程度:
    • 提供及時容易瞭解的結果,以及可用來制定決策
    • 分析工作的執行成本不應比它提供的效益高


    度量與分析活動的評估準則可考慮下列項目的應用程度:
    • 資料缺少與不一致的數量是否超出門檻
    • 資料取樣是否有偏差(例如:僅調查滿意的使用者以評估最終使用者滿意度,或只評估不成功的專案以決定整體生產力)
    • 度量資料是否可重複(例如:統計上的可靠性)
    • 統計的假設是否滿足(例如:關於資料的分佈或關於度量單位的合適性)

    結語

    度量與分析流程領域包括兩項特定目標。

    本篇將特定目標1(Specific Goal 1) 於CMMI-DEV V1.3 與V1.2的主要差異部分提出標示比對(紫色部分),供讀者參考。特定目標2(Specific Goal 2)的內容,則將於下篇陳述。

    正式的中文版本預期在不久後會由資策會領導的翻譯團隊完成並公佈發行。

    參考資料
    1. SEI. CMMI For Development Version 1.2, CMMI-DEV V1.2, 2007
    2. SEI. CMMI For Development Version 1.3, CMMI-DEV V1.3, Nov 2010