人世本苦，其苦何鉅-無我詩文舖

關於 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 表示。

圖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 內的陳述來具體實現。

[More:]

從主流開發流程找 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

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

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

圖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. 調整與修正手段→循環與漸進→往目標前進！