关於 CMMI.doc

關於 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 - SG3CMMI Content 類別圖說明： CMMI Level (25) 包含(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.SG3 src=http:/www.kenming.idv.tw/mybase/soft_imgs/cmmi_content_example-1.jpg /圖2、範例-利用 RUP/XP 方法論實現 Requirement Development - SG3RUP 透過需求工作流程(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 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 CategoriesSP 1.2-1 Define Risk ParametersSP 1.3-1 Establish a Risk Management StrategySG1 - SP 1.3-1 src=http:/www.kenming.idv.tw/mybase/soft_imgs/cmmi_content_example-2.jpg /圖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)，兩者是互補，而非衝突。 回 到最本質的一面，“人” 才是影響軟體開發最關鍵的因子，我