利用 UML 類別圖表達 CMMI Content 與範例說明

關於 CMMI

  • 與其說 CMMI 是流程框架(Process Framework),倒不如說 CMMI 是目標框架(Objective Framework)。
  • CMMI 是以 “流程區域(Process Area)” 為主要完成目標。無論是以 “Continuous” 或 “Staged” 的途徑(approach),均以 “Process Area” 為單位,來檢驗 “軟體能力” 的成熟度。
  • Ex. “需求管理(Requirement Management)” 為一個 “Process Area”,是 CMMI level 2 必須完成的主要目標。(level 2 需完成 7 個主要的 “Process Area”;level 3 需完成 14 個”)。
  • 每一個 “流程區域” 會細分為多個子目標。若該子目標只對應單一的流程區域,稱為 “特定目標(Specific goal)”;若子目標會涵跨多個流程區域,則稱為 “一般目標(Generic goal)”。
  • 每一個特定目標/一般目標會列出一到多個 “期望(expected)” 的特定實務(specific-practice, sp)/一般實務(generic-practice, gp)。實務為一段陳述(statement),表達了完成子目標時的作法。
  • 實務並非為絕對、唯一達成子目標的唯一作法,它是 CMMI 建議、期望的作法,但仍可就現實狀況來找出 “自己” 的的實務作法,重點是,能達成(achieve)子目標(GG/SG)的規範與要求。
  • 既然實務僅為敘述性的陳述,可以把它視為是 “抽象(abstract)” 的 “How-to”,要能找出符合實務的作法,可以從主流軟體開發流程,如 RUP/Agile/XP 等,找出實踐的具體手段。

CMMI 的 Model Content 為:Process Area, GG/SG, GP/SP。其中,Process Area 與 GG/SG 為達成軟體能力成熟度的必要元件(required component);GP/SP 則為 "期望(expected)" 的元件,屬建議性,並非絕對需要。若以 UML 類別圖表達 CMMI Content 之間的關連,如下圖1 表示。

利用UML 類別圖表達 CMMI Content 之間的關連

圖1、範例-利用 RUP/XP 方法論實現 Requirement Development -> SG3

CMMI Content 類別圖說明:

  • CMMI Level (2~5) 包含(aggregate) 多個“流程區域(Process Area)”。
  • 每一個流程區域會包含多個子目標(Goal),子目標依性質區分為“一般目標(Generic Goal, GG)”與“特定目標(Specific Goal, SG)”。
  • 將 GG/SG 設計為“Interface”的意涵在於,任一個具體(concrete)的實務(practice)類別,只要符合該子目標的介面規範即可,也就是說,CMMI 不規定“how-to”,只要能確實達成(achieve)子目標的規範即可。
  • GP/SP 可視為是“抽象(abstract)”的“how-to”陳述(statement),因此,具體實務類別也可以依循 GP/SP 內的陳述來具體實現。

從主流開發流程找 How-to

  • CMMI 只規範達成目標的標準,但並沒有規定該如何(how)達成目標。
  • “如何”達成目標,需要找出具體的方法與解決方案,”How-to”的參考來源可以從 RUP/Agile/XP 方法論內的實務經驗與工作流程(Workflow)、樣版(Template)、實務案例等(當然,也可以由團隊內部自行找出最佳的實務經驗(Best Practices) )。
  • 具體的 “How-to” 會對應(mapping) 至 CMMI 內的 GG/SG (goal),也可以是 GP/SP (practice)。

範例一、Requirement Development -> SG3

Process Area: Requirement Development (需求開發)
Purpose:

The purpose of Requirements Development is to produce and analyze customer, product, and product-component requirements.
SG3: Analyze and Validate Requirements
The requirements are analyzed and validated, and a definition of required functionality is developed.

範例-利用 RUP/XP 方法論實現 Requirement Development -> SG3″  /></p>
<p align=圖2、範例-利用 RUP/XP 方法論實現 Requirement Development -> SG3

RUP 透過需求工作流程(Requirements Workflows) 內的幾個活動(activity),來達成主要對 CMMI “需求開發” 流程區域內對 SG-3 的實現:

  • 分析問題,找出關係人(stakeholder),找出系統邊界與限制,瞭解關係人的需要(Need)。
  • 定義系統範圍,利用使用案例模型(Use-case Model)描述系統的需求,以達成與客戶對系統功能性的共識;捕捉其它重要的需求,例如非功能性需求與設計限制等。
  • 撰寫測試案例(以 Use Case 為單位),由客戶提供測試腳本與數據,以作為在實作(Implementation)工作流程的自動化測試的契約。
  • 實現(Realize)使用案例,將需求工作轉移至 分析/設計 的工作流程。

XP 是透過 “使用者陳述 (User story)” 來達成主要對 CMMI “需求開發” 流程區域內對 SG-3 的實現:

  • 將需求寫成陳述(statement),並且寫在卡片(4×6 索引卡)上。
  • 客戶有權要求每個需求功能最細小的環節;程式設計師有權知道需求到底是什麼。
  • 每一個敘述必須都是可以測試的(testable),也就是可以寫成功能測試程式碼,來驗證敘述是否可以運作。
  • 若一個功能敘述無法在一至兩個星期內完成,代表敘述可能太大了,必須對其分割為多個敘述。切成適當的大小,以便於評估其難易度,並做為未來量化時,估算的計量單位(功能點, functional point)。

範例二、Risk Management -> SG1 -> SP 1.3-1

Process Area: Risk Management (風險管理)
Purpose:
The purpose of Risk Management is to identify potential problems before they occur, so that risk-handling activities may be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.
Specific Goal-1: Prepare for Risk Management
Specifice Practice:
 
SP 1.1-1 Determine Risk Sources and Categories
 
SP 1.2-1 Define Risk Parameters
 
SP 1.3-1 Establish a Risk Management Strategy

範例-利用 RUP/Agile 方法論實現 Risk Management -> SG1 -> SP 1.3-1″></p>
<p align=圖3、範例-利用 RUP/Agile 方法論實現 Risk Management -> SG1 -> SP1.3-1

RUP 透過專案管理工作流程(Project Management Workflows) 內的風險管理的部分,來達成主要對 CMMI “風險管理” 流程區域內對 SG 1-> SP 1.3-1 的實現:

  • 採用循環與漸進(I&I, iterative and incremental)的開發方式,及早降低風險。
  • 列出風險清單,並制訂風險高低指標(risk magnitude indicator) 辨識與描述風險的高低程度。
  • 利用架構 POC (proof of concepts),來找出會影響架構的風險因子,包括系統整合、人員技術與技能等問題。
  • 建立測試工作流程,及早獲得系統品質的相關回饋(feedback),並找出在分析設計與實作階段的隔閡(gap)。

Agile 並沒有建立與風險管理相關的計畫,而是透過頻繁溝通、大量取得回饋,儘早釐出風險,並透過實務來克服與解決風險。

  • 採用循環與漸進(I&I, iterative and incremental)的開發方式,及早降低風險。
  • 客戶與開發人員在專案進行期間一起工作,以降低溝通的風險。
  • 採測試先行與接受度測試,以降低需求變更的風險。
  • 早一點作整合,經常做整合測試,以降低系統整合的風險。
  • 經常釋出(release)可用的版本,週期可是數週到數個月(最好三個月內),較短時間間隔為佳。

結語:CMMI 綱要

  • CMMI 非高度儀式且為重型的開發製程,它是指導軟體開發的綱要,CMMI 也沒有給具體的實務手段,它是制訂了目標與方向,來引領軟體開發往 “對的方向” 走。
  • 找出達成 CMMI 所制訂的手段,可以透過主流的軟體開發流程,包括 RUP/Agile/XP 等,並依據專案的規模與性質,來對開發流程與產出(Artifacts),作適當的裁適(Tailor)。
  • 可以利用倒推式的目標設定與規劃(Backward Planning)的方式,來找出如何達成目標的手段。所以,若 CMMI 為目標(Goal),那麼,RUP/Agile/XP 就是可以達成目標的手段(How-to),兩者是互補,而非衝突。
  • 回到最本質的一面,“人” 才是影響軟體開發最關鍵的因子,我們更需要知道的是,在團隊開發人員的角色裡,應該具備的素養與修練是什麼,而要學習的技能與技術,又是那些,然後,才來找出適合軟體開發人員的 "利器(Tool)"。專案管理者,切莫本末倒置,先從工具與製程著手,而忘掉根本。

目標設定規劃與行動的精要

  1. 檢視目標與方向 → 找出手段(how-to) → 瞭解技能與技術/心理素養 → 善用利器
  2. 調整與修正手段→循環與漸進→往目標前進!

文章導覽

   

共有 6 則迴響

  1. 真是畫龍點睛的說明,請問站長是否有更完整的
    sp/gp 對 rup 與 agile 的對照圖,或那裡可以去尋找這方面的資料
    謝謝

  2. 矇矇 大哥
    您真得是讓我太敬佩了,小弟之前去軟協上過CMMI的課程,對於CMMI及專案管理,相當有興趣,而且希望把這些東西分享給朋友,我曾試過用Mind Map來表達,不過總是覺得沒有辦法很簡單而清楚的表達出來(可能我Mind Map的功能還不夠)不過,當我一看到你使用UML來闡述的時候,我真是覺得太精彩了
    未來還希望可以跟您多多學習

發佈回覆給「邱明昇」的留言 取消回覆

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *