CMMI V1.3

概述

以下資料由CMMI專業機構 - 亞遠景科技整理提供

CMMI（Capability Maturity Model Integration）-能力成熟度模型集成，已在中國方興未艾地發展了十年，如今美國卡耐基●梅隆大學的SEI又計畫今年發布新的版本CMMI Ver1.3。

我們現在所貫徹的CMMI V1.2版本將於2010年11月進行一次重大的升級，最新改進的CMMI V1.3版本將會在原有基礎上增加了許多可以提升組織或企業能力的元素組件。

此次V1.3版本的升級包含了對處於相同開發周期的所有三個模型CMMI-Development (開發模型)、CMMI-Acquisition (採購模型)和CMMI-Services (服務模型)的改進，同時它也包含了對SCAMPI評估方式和CMMI培訓相關部分的改進。不過這個改進並不會對CMMI的三個主要模型進行太大的變動,所以企業並不需要重新培訓而造成原有培訓資源的浪費。

從2000年的時候開始，SEI利用他們所制定的CMMI產品工具包通過三個單獨的模型為組織提供了一個對於過程改進的先進架構，而且他們還在不斷的革新這些管理技術。這三個模型分為CMMI-DEV模型(建立於2000，於2002、2006年進行了兩次升級)、CMMI-ACQ模型(2007)和CMMI-SVC模型(2007)，CMMI-DEV模型幫助生產服務開發組織整合他們的軟體開發和系統工程來改進他們本身的性能和提高過程改進的效率。CMMI-ACQ模型幫助組織或企業為他們的客戶進行外包、採購、交易或者其他採購產品服務提供了管理架構。CMMI-SVC幫助服務性組織去建立質量服務過程架構使其能夠更好的改進服務表現和提高企業的服務收益性。

現有的三個CMMI模型

這些模型將可能被不同領域不同性質的組織和企業用於他們所有生產線上的開發工作，甚至有的組織或企業會使用兩個或全部的CMMI模型來達到他們的目的。三個模型實質上都是按照相同的架構，原理和標準來運作的。更深一層的來說其實三個模型中的大部分細節都是可以互通互用的。 儘管這些模型在不同的時間被建立並推出，他們都在V1.2版本中進行了最終的修正和整合，以下是他們在CMMIV1.2版本中的兩個比較重大的變動：

V1.2版本通過精煉CMMI的模型架構創建了CMMI群集，群集服務於一些組織或企業比較容易引起興趣的領域，比如開發、採購和服務。我們可以在CMMI-ACQ和CMMI-SVC模型的創建里看出這個變動的所產生的成果。

V1.2改進了SCAMPI評估方法並對其進行了整合，使它可以利用CMMI模型作為參照物來測量過程改進所達到的成果。SCAMPI是按照所制定的標準方法來評價組織或企業過程改進能力與CMMI模型的吻合度的事件。當你使用和引導一個SCAMPI評估時，所得到的評估結果將會反映出企業或組織的程度和能力。所以，剛起步的CMMI組織或企業理所當然的就會反映出低成熟度，而當這個企業或組織達到了一定的高評估的結果時，它自然會反映出更高的成熟度。

在CMMI V1.3升級的方案確定下來之前，開發組回顧了本來可能在V1.2a版本CMMI中得到的升級。在預計的這個版本中，開發組只確定了較少的改進並且只針對過程域的證據材料(實踐，目標等等)做了一小部分的升級。

CMMI V1.2版本模型的改進的計畫制定是首要任務，這個改進是為了使得對高成熟度企業或組織的評估更加的明確。CMMI高成熟度主任評估師和CMMI指導委員會於2008年9月底對本來預計的V1.2a升級進行了回顧並得到了結果。根據這些結果，CMMI指導委員會決定改進現有的規範材料使得4至5級成熟度的評估更加現代化，這比V1.2a的只是明確證據材料的升級更加明確完善。所以，儘管CMMI-DEV1.2a版本已經推出出來了，開發組仍然想將這些升級內容包含在新的版本之中(不僅僅是CMMI-DEV)。所以比起CMMI-DEV1.2a的升級，開發組更願意將這些升級內容放在V1.3版本的三個模型之中。

CMMI V1.3版本的開發

CMMI V1.3項目的開發開始於2009年的一月份，當這個CMMI的升級計畫被創立的時候，開發組計畫在開始的期間內使用2個月來回顧並且分析用戶所提供的最終改進要求。在2009年3月到6月這段時間，開發組收到並且回顧了超過1150個對於三個CMMI模型和850個對SCAMPI評估方式的改進要求，並且將這些改進要求考慮進了V1.3版本CMMI的升級編制之中。這段時間中，CMMI指導委員會也給予了對於CMMI V1.3產品集的可允許改進的範圍的重要指導(可參閱SEI於2009年8月發布的CMMI V1.3 –Plans for the next version這篇文獻 )。SEI所發布的這篇文獻關注於(但並不局限於)以下幾點：

1. 高成熟度

2. 更加有效率的GPs（通用目標）

3. 評估的效率

4. 跨群集中的共用內容

同樣的，它也對CMMI產品工具包的任務(比如模型、培訓材料和評估方法)的改進做出了要求。要求其必須符合下列準則 (同樣來自於CMMI V1.3 –Plans for the next version):

1. 正確的定義模型、培訓材料和評估方法的缺點，並且為他們提供改進方式。

2. 需要合併成熟度的擴大性和明確性。

3. 適合於模型潛在的特定方向的改進的涉及範圍(比如安全、保密和生命周期等等)只能被特定領域的CMMI指導委員會指定。

4. 如果可能的話儘量減小改進後的整個模型的大小，如果有對模型有增加的需求的話其不能超過模型的整體大小。

5. 模型或者方法的改進要盡力避免可能會對組織或企業傳統投資方式的不利的影響。

6. 對於模型架構的改進必須通過特定的CMMI指導委員會的授權。

7. 改進只能通過用戶的改進要求或者CMMI指導委員會進行。

8. 最新的培訓可能會在V1.3之前推出。

9. 對於模型的改進不需要重新培訓，因為有接近10萬人已經做過了CMMI培訓，會造成極大的資源浪費。而升級培訓可能只是需要講師，指導評估師和評估團隊組員進行。

CMMI的推出都將被CMMI指導委員會所提供的認可改進標準所引導。這些非常有特色的準則都和CMMI V1.3 –Plans for the next version 裡面的準則大致上一致；不過每一組準則也有一些方面被賦予了一定的特色並放在了新的版本之中。

其中一個很明顯且主要的需要改進的原因是對於缺陷的改正，SEI定義了錯誤訂正的正誤表並且將其正式發布在了他們的主頁上面。這些錯誤的訂正都將會被合併到下一個版本的CMMI中。不僅這些缺陷的訂正，用戶上交的對模型的改進要求也是一個他們覺得對模型改進的原因，這些改進將經常明確原有的模型材料。上面的第二條準則鼓勵使模型更加的明確，而這需要完全的弄明白模型的目標和評估方式。

對於模型來說，過多的改變會使得模型複雜化。準則3和準則4嘗試著去限制這些附加項的改進與推出。這兩條準則和準則5保護了組織或企業已經對使用CMMI產品工具包的巨大投資。準則9增加了額外的約束來使得V1.3版本的推出不再需要重新進行CMMI課程的培訓。

CMMI V1.3的重要元素

在V1.3版本中，對於模型的許多改進將會融合進產品工具包裡面，接下來將會陳述一些在CMMI V1.3版本比較重大的改進。

高成熟度的明確性

就像前面對評估明確性的關注的一樣，當你在接受一個SAMPI評估的時候，你所受到的評估結果會直接反映你的組織或者企業的成熟度。剛起步的CMMI組織或企業理所當然的就會反映出低成熟度，當這個企業或組織達到了一定的高評估的結果時，它會理所當然的反映出很高的成熟度。一般來說，已經被明確評估的以現有模型為焦點的高成熟度組織會使用階段開發模式(staged approach)，而使用高兼容性過程域的組織或企業則適合使用連續開發模式（continuous approach）。

為了使得什麼是高成熟度的概念更明確並且提供如何達到它而必須的導引，SEI專門成立了一個高成熟度概念小組。小組領導者是從各個工業項目計畫者中挑選的，這樣可以有助於確認所產生的是實際工作領域中最有代表性的改進。

這個高成熟度概念小組了解對於高成熟度的評估現在其實並不非常明確，它可能會導致用戶對其產生多種的理解和認識。而他們在V1.3版本上所做的工作的目標就是確認讓所有的CMMI用戶將擁有一個對於CMMI的三個模型中的高成熟度實踐含義的共通的理解。

直到現在為止，高成熟度概念小組明確了下面的這些內容：

證據材料在高成熟度實踐中所扮演的角色；

過程模型和過程建模的含義與套用；

如何關聯商務目標並將其引導向高成熟度；

什麼是一般原因和預期他們將被如何套用；

什麼是在單獨的PA表現上的高成熟度期望；

選項、定義和子過程例示的等級。

高成熟度的證據材料是早期的V1.2a版本的焦點成果，不過它只是高成熟度概念小組為了完成V1.3版本模型開發的改進要求所總結的一小部分。他們也制定了同樣的計畫改進模型中的高成熟度的架構的定義，比如包含了使成熟度4和成熟度5級之間的實踐的間隙更加明顯的作用等等。

這個高成熟度概念小組的工作是對於高成熟度PA(過程域)進行關注，比如：組織過程性能，量化項目管理，因果分析和解決方案，組織創新和部署(Organizational Process Performance, Quantitative Project Management, Causal Analysis and Resolution, and Organizational Innovation and Deployment.)。

群集的共通性質

正如開發組在CMMI-DEV模型的內容基礎上建立了CMMI-ACQ和CMMI-SVC模型一樣，他使得16個核心PA中的證據材料符合實際工作並適合所有的三個群集。這個含義是，開發組重新的利用CMMI-DEV的過程域PA來使得這些群集完全符合實際工作。儘管群集中部分差異性是被故意設計並也可以講得通得，但是有一部分差異依然將會被消除來使得三個群集更加的一致並且更容易被同時的套用。

下面將列出一部分為了在三個模型之中達到普遍性所產生改進的地方：

核心過程域PA

這些過程域PA出現在所有的CMMI模型中。而在V1.3版本中，這些PA可以有不同的預期效果和證據材料(實踐或目標等等)，比如項目計畫(PP)有一個特定的實踐放在服務群集之中，不過在開發群集中的PA項目計畫就沒有這個實踐。同樣的，一小部分PA有可能被一個或多個模型共享使用，而這些被共享的PA內部同樣會有不同的預期效果和證據材料。不過，當V1.3的開發工作完成後還必須要確認這些核心PA仍然可以很好的運行在每一個模型中並且保持通用和一致。如果不是，那么證明PA中的證據材料的不同依然使得他不符合使用。

團隊

在CMMI的模型中將有兩種不同的方式來組織團隊。在CMMI-DEV中，一共有兩個目標是包含團隊的概念的，這兩個通用目標被處理為可選項或附加項。而在CMMI-ACQ和CMMI-SVC中，團隊組成涵蓋了兩個PA過程域的兩個特定實踐（組織過程定義與集成項目管理）。在這兩個模型中，這些實踐是這兩個模型的預期並且不是他們的可選項。

開發組決定在CMMI V1.3版本中的最佳方式是在CMMI-ACQ和CMMI-SVC中使用所有的三個CMMI群集。這個工作確認了組成團隊的方式，這個方式可以從團隊軟體過程（Team Software Process）中證明了高能力團隊的潛在性能的重要性。

過程域PA種類

在V1.3版本中共有六個PA(過程域)類別，他們分別是1.過程管理2.項目管理3.支持4.工程5.採購6.服務建立和交付。所有的過程域PA必須有相通的核心PA類存在於三個模型之中，並且這個PA類必須是下面的一種：過程管理類，項目管理類和支持類。非核心類的PA必須被分配到下面的PA類之中：工程類，採購類和服務建立和交付類中。總之，需求管理將在所有的V1.3版本模型里被分配到項目管理類別種。

通用目標與實踐

在V1.2版本的模型中，通用目標(GG)、通用實踐（GP）和通用實踐的詳細說明在不同的模型中總是被不同的描述。比如說CMMI-DEV模型將這些元素的一部分陳述在Part one，其他的部分則被放在了Part Two的每個PA的結尾。而在CMMI-ACQ和CMMI-SVC中，這些元素出現在Part Two的PA之前的一個單獨的章節之里。在V1.3中，這些通用元素將都會被安放在三個模型中的Part Two的第一個章節中心位置。

術語庫(Glossary)

三個模型中的術語庫變得不一致的原因是因為它們的推出時間的不同所造成的。在V1.3版本中，儘管一些術語定義可能沒有出現在一個或多個模型之中，但是術語庫任然將會完全修改為一致的內容。同樣的對字典庫的格式的修改也會進行，將會在其中列出不同部分的差異使得識別更加容易。

實踐的現代化

對於多數過程域內的實踐的改進都將被升級來確認他們是現代化(最新的)並且最好的反映了實踐的有效性的。

敏捷(Agile)

材料將被加入模型來幫助那些在敏捷環境中正確詮譯的時間，儘管可能有不見得非常合適的部分。

架構相關開發

材料將被升級和增加到產品開發期中，包含在了非功能和功能要求的考慮之中。

供貨商契約管理

供貨商契約管理的範圍將被明確，部分被視為COTS(Commercial-Off-The-Shelf，商務現貨供應)，內部資源和客戶屬性。

組織培訓

由於組織培訓時間的升級所以他們將需要申請更多的課時來說明並進行補充培訓。

翻譯

CMMI模型現在有法語、德語、日語、西班牙語和繁體中文5種版本。隨著時間的推移，葡萄牙語也將被發表。翻譯小組被要求模型的開發易於翻譯並且改進。舉一個簡單的例子，像在V1.2版本中使用的Stovepipe這樣的單詞將被取消或替代。這是一個非常難融入其他語言的辭彙因為其字面上的意思和它在CMMI中所表達的含義是不同的。

擴大覆蓋範圍

(Expanded Coverage)

對於CMMI模型的改進要求，有很大一部分是關於模型在新領域的進一步擴充的。CMMI指導委員會和開發小組覺得在這個版本的推出中作出特別重大的擴充並不合適，比如兩個最近的群集的附加項。他們更願意在架構，軟體保證，敏捷和Lean 6 Sigma中增加升級信息。開發組也鼓勵應該增加更多重點在客戶的滿意程度上。而這些對於現代化模型的擴充的類型並不會增加到新的PA之中。

多群集覆蓋範圍

(Multi-Constellation Coverage)

有許多的學生接受了一天的補充課程，這個課程涵蓋了採購或交付的注釋，有些組織的涵蓋範圍跨好幾個領域。在V1.3版本的推出其中主題就是，使一些共享的最好的跨群組能力具有可行性。一但一些有效的試行被引導開發，開發組將計畫改進SCAMPI方法定義文檔去促進評估，並且此評估將使用多群集中的PA。

評估效率

(Appraisal Efficiency)

SCAMPI評估方式是基於使用在CMM軟體和為內部改進的CMM-Based評估方法的(CMM是CMMI的前身).SCAMPI的評估方法從以CBA-IPI發現為焦點轉移到了以認證為焦點，這個改進設計可以節省許多重要的評估時間。實踐實現知識文檔(PIIDS)將會減少現場評估的時間。這些文檔陳列出了每一個評估點使得評估小組能看得到實踐實現的證據。同時開發小組會調查組織是否會在PIIDS上花費過多的時間來準備證據材料，如果是的話開發小組將通過測試的方式來評估不會增加準備時間和費用消耗的方式。SCAMPI升級小組正在尋找創新的方式來達到這個目的。

V1.3版本其他的關於SCAMPI方法定義文檔的改進內容將列在下面:

去除有問題的術語、定義並列出評估範圍的考慮因素和合適的準備方法來讓實踐組的成員給予三個CMMI模型提供支持。

改正所有在SCAMPI V1.2版本中使用的錯誤的定義，包含通常用戶遇到的隱患和在SEI評估的回顧中經常遇到的問題。

明確了焦點和非焦點項目以及直接和間接的證據的意義

明確評估範圍的所引導的是在一個多寬的範圍的組織類型和大小。

提供用來確認包含GP的控制的導引。

分析CMMI文獻中的有特色的條例和評分的規則。

模型體積

(Model Sizing)

從第四個規則中可以看出它限制了整個CMMI模型的體積，開發小組正尋找一種方法來平衡刪減模型的附加項。刪減的這個回執結果來自於ATLAS收集的輸入的成果。ATLAS全稱為”Ask The Lead Appraisers”。 是由PAT O’Toole所倡導的行為小組。這個小組上交的改進需求定義低價值的評估，並移除他們來減少體積用來增加其他現在看起來更重要的元素。可以看出來早期加入PA的附加項其實並不鼓勵放入V1.3版本。

V1.3版本的升級

(Upgrade to V1.3)

CMMI指導委員會指定了V1.3的升級和CMMI V1.2的退役之間的重要事件的周期表。開發小組也提供了V1.3版本的草稿交給了部分用戶來獲得回饋的調查，對CMMI來說這樣的改進是一種創新的信息收集方式。不過，並不鼓勵用戶為了等待V1.3版本的升級而延遲他們的過程改進程式的進行。

V1.3的培訓

（V1.3 Training）

在CMMI V1.3中，將提供一個從V1.2到V1.3的三個模型的簡單的升級培訓。這個培訓是可以線上進行的，線上培訓一共是三天。而到期的企業將需要重新培訓得到升級。

V1.3的開發時間表

(Development Schedule for V1.3)

開發組將以解決改進要求和有爭議的文獻等問題為首要任務。對於其所涉及的關於V1.3開發進度完成，計畫將在三個群集建立完成後於2010年11月1日推出V1.3，不過這個日期也許在分析完回饋草稿後會有一定的變動。圖2是V1.3的高等級視圖模型進度圖。而圖3是對於SCAMPI改進的進度圖。

從圖2中可以看出模型的開發項目起始於2009年的1月並且結束於2010年的11月。開發過程包括了計畫、組成團隊和定義過程與開發，這個過程從2009年1月到5月。按照這個過程從2009年6月到10月，改進包（CP）將被創建、審核和批准。CP是對基於接收到的改進要求來進行計畫改進的陳述。開發組使用CMMI變更控制委員會（CCB）審核和改進了他們。CCB是對CMMI的產品工具包的控制改進的反應。

圖 2:CMMI V1.3 模型開發計畫進度圖

一旦他們被批准，模型組件的實際改進計畫會被劃入紅線(Redlines).這些紅線被進度表所創建、審核和批准實施於2009年8月與2010年7月之間。這些紅線也將被開發組與CCB審核和批准。

實現組織意向的試行計畫是在試行改進客戶的回饋和套用之前。這裡有三個試行草稿現在已經在計畫了。其中2009年11月的草稿包含了的改進改進了所有的三個模型和其他項目的內容，而2010年1月的草稿則包含一些對於模型的改進(特別是所有高成熟度模型的改進)。最後一個2010年6月的草稿將包含對所有模型的精簡，將由質量保證部門(QA)負責。升級是建立在回饋的基礎之上的，而回饋來自於試行。這段過程實施於2010年5月與7月之間。最後QA將於2010年7月至11月的推出前將模型準備完畢。

圖3展示了CMMI V1.3 SCAMPI方法定義文檔的開發進度，平行線顯示了模型的開發成果。

圖3：CMMI V1.3 SCAMPI 升級進程表。

總結

即將推出的CMMI V1.3，其中新的變化包括了對高成熟度的改進和明確、改進評估效率、和模型內的架構與內容共享。在開發的生命周期內的這個重點中，改進並不需要對V1.2的原有產品工具包的進行重大的改進。