摘要 本文分析了 CMM 到 CMMI 的各級映射，指出了 CMM 與 CMMI 的差異之所在，討論了 CMM 升級到 CMMI 所需做的各項工作及過渡方法。對實施 CMM 的各級軟件組織順利升級到 CMMI 有一定的借鑒作用。 關鍵詞 KAP 、 CMM 、 CMMI 、 SCAMPI 、 KP 1 引言 自 1990 年起美國卡耐基梅隆大學軟件工程研究所發(fā)布 SW-CMM v1.0 （軟件能力成熟度模型）以來， SEI 針對不同領域的要求對 SW-CMM 先后進行改進，并衍生出了一系列成熟度模型。其中比較重要的包括：系統(tǒng)工程能力成熟度模型（ SE-CMM ） , 軟件采購能力成熟度模型（ SA-CMM ），集成產品開發(fā)能力成熟度模型（ IPD-CMM ）等。 但是這些具有針對性的模型又帶來了一些新的問題。軟件公司的業(yè)務一般都不是單一的，有的公司可能同時從事軟件開發(fā)、硬件開發(fā)、還可以進行軟件采購。此時采取多個模型必定會使很多關鍵過程域，關鍵實踐產生重疊，增加了開發(fā)費用。 2001 年 11 月 SIE 推出 CMMI V1.1 ，將以上模型集成，解決了多模型之間的重疊問題。同時 SEI 發(fā)表了針對 CMMI 的一套評估體系 SCAMPI SM V1.1 ，替代 CBA IPI and SCE SM 并打算 CMMI 取代 CMM 。已有許多組織開始向 CMMI 過渡。 CMMI 的基礎源模型包括：軟件 CMM 2.0 版（草稿 C ） , EIA-731 系統(tǒng)工程，以及 IPD CMM (IPD) 0.98a 版，它涵蓋了系統(tǒng)工程，軟件工程，集成的產品和過程開發(fā)（ IPPD ）和供應商來源四個知識領域。它有階段式（ staged ）和連續(xù)式（ continuous ）兩種表示法。本文為了方便和 CMM 進行對比，將 CMM 和 CMMI 均采用階段式表示。 關于 CMM 和 CMMI 本文不做詳細介紹，相關資料較多，對 CMM 和 CMMI 不太了解的讀者可見參考書 [1] 、 [2] 。 2 從 CMM 到 CMMI 的映射 CMM 到 CMMI 的映射是一個復雜的體系，它涉及到 KPA 重構， KP 的再組織。圖 1 只是從總體上描述了 CMM 到 CMMI 的映射關系。 圖 1 CMM 到 CMMI 的各級映射 關于 CMM 和 CMM 的映射關系的細節(jié)描述見參考文獻 3] 。 3 映射分析 CMMI 雖然是建立在 CMM 基礎之上，兩者大部分相似，但還是有很大差異。從總體上講， CMMI 更加清晰的說明各過程域和類屬實踐（ generic practice ）如何應用實施，并指出如何將工作產品納入相應等級的配置和數據管理基線，風險管理策略，驗證策略等。 CMMI 包含更多工程活動，如需求開發(fā)，產品集成，驗證等過程域；過程內容的定義更加清晰，較少強調文檔化規(guī)程。 如圖 1 ，在 CMMI2 級中增加了測量和分析 KPA （ Measurement and analysis ），將各測量分析實踐（ KP ）歸結為一個正式的關鍵過程域，而在 CMM 中測量分析實踐是散落在各等級中的。因此在 CMMI 中更加強調了量化管理，管理的透明度和軟件開發(fā)的透明度得到了升級。 CMMI3 級中增加了需求開發(fā)（ Requirements Development ）、技術解決方案（ Technical Solution ）、產品集成（ Product Integration ）、驗證（ Verification ）、確認（ Validation ）、風險管理（ Risk Management ）、決策分析和決定（ Decision Analysis and Resolution ） KPAs 。 CMM 中的軟件產品工程 KPA 被需求開發(fā)，技術解決方案，產品集成，驗證，確認 KPAs 所取代；同行評審 KPA 被融入到驗證 KPA 中； CMM 中集成軟件管理 KPA 所闡述的風險管理在 CMMI3 中形成了一個獨立風險管理 KPA 。同時集成軟件管理和組間協(xié)調 KPAs 合并成集成項目管理 KPA 。合成團隊、決定分析和解決方案、組織的一體化環(huán)境 KPAs 是全新的，其過程內容在 CMM 中沒有提及。 CMMI4 中沒有新的過程域，只是對原來的定量過程管理，軟件質量管理 KPAs 重新構建為定量項目管理和組織過程性能 KPAs 。 CMMI5 中的技術變更管理和過程變更管理 KPAs 合并為組織革新與技術推廣 KPA ，缺陷防范 KPA 重新構建為原因分析和解決方案 KPA 。 4 CMM 到 CMMI 的升級 4.1 升級前的準備工作 (1) 回顧 CMMI 模型和其他的 CMMI 信息，確定如何使 CMMI 最好的滿足組織需要（ 2 ）擬訂升級策略。（ 3 ） 在升級過程中確保以前用于 CMM 改進的投資得到維持和運用（ 4 ）將升級事項通告客戶（ 5 ）將對現有過程域和新增過程域的改進費用編入預算，并提供有關改進需要的培訓。（ 6 ）確定組織升級計劃的風險表并管理這些風險，關鍵要識別 CMM 和 CMMI 之間的差異以及這些差異如何得到支持。 4.2 ．升級的方法： 一旦做好了升級前的準備工作，弄清了升級可帶來的利益和成本，可執(zhí)行下列活動進行升級，這些活動是迭代的。 （ 1 ） 選擇適合組織最好的 CMMI 模型。 CMMI 覆蓋各種知識體，包括項目管理，軟件工程，系統(tǒng)工程，集成產品，過程開發(fā)供應商來源。按組織的商業(yè)目標選擇模型。 （ 2 ）選擇最適合組織的表示法。 CMMI 有階段式表示法和連續(xù)式表示法，由于 CMM 采用的是階段式的表示法，許多組織都采取 CMMI 階段式表示法，若組織對連續(xù)式表示法較熟悉，也可以采取連續(xù)式表示法。 （ 3 ）將選擇的 CMMI 模型與 CMM 對比，確定需要變更的范疇。具體的對比見上文。 變更的主要活動是對 CMMI 中重組的 KPA 及 CMMI 中新增的 KPA 進行更新。 （ 4 ） 確定升級會帶來的影響。 （ 5 ）向 CMMI 升級因該報高級管理層的認可。 （ 6 ）變更組織目前的過程改進計劃以支持 CMMI 升級。過程改進計劃要反映出工作的優(yōu)先級、組織所需增加的新部門。將該計劃送交評審，得到關鍵儲金保管者（ key stakeholders ）的許諾和認可，計劃要說明升級可能帶來的管理風險和進度風險，所需的培訓，工具，和服務支持。傳達這個計劃并保持更新。 （ 7 ）確保對工程過程組，技術工作組及其他相關的員工進行 CMMI 的培訓。 （ 8 ）獲取 SCAMPI 評估支持。 （ 9 ） 修改每個項目已定義的過程使其與項目改進計劃一致。 （ 10 ）給每個項目制定升級進度表 不同的項目升級進度表可能不同，如果有的升級工作已經完成則該工作可以拋棄。 （ 11 ）執(zhí)行 SCAMPI 評估，看是否所有的目標過程域和目標得到支持。 5 處于 CMM 不同成熟等級的組織所做的具體工作 ： （ 1 ） CMM1 級： 如果組織正使用 CMM 模型致力于過程改進而并處于 CMM1 級，那么組織應該繼續(xù)用 CMM 模型。在改進的同時，組織將 CMM2 與 CMMI2 進行對比和差異確認，分析這些差異中哪些是對組織有價值的。當組織剛達到 CMM2 級時其主要工作時立即從 CMM2 向 CMMI2 升級。 （ 2 ） CMM2 級， 組織應該把其當前的過程改進向 CMMI2 級映射，填補兩者之間的差距，從 CMM2 升級到 CMMI2 完成后，在下一步的工作中采用 CMMI 模型進行過程改進。主要有一下幾方面 (1) 將 CMM 中分散的測量分析活動集中到 CMMI2 級測量分析 KPA 中，形成一個獨立的過程域，提高開發(fā)的透明度。 (2) 重定位測量分析 KPA （ Measurement and Analysis ）的共同特征（ common feature ） 測量分析 KPA 重組見表 1 所示。 表 1 測量分析 KPA 重組 測量分析 KPA 的目標 CMM 共同特征∕目標 SG1 QPM Co 2 Ac1,3,4,5,6 SPT&O Ac 5,6,7,8,9,11 SG2 TCM Ab 4 QPM Ac 4,5,6 ODP Ac 5 SPP Ac 15 SPT&O Ac11 GG2 QPM Co 1 Ab 2,3,4 OPF Ac 1 Ab 2,3 SQM Ac 1,2 Ab 1,2,3 表示符說明： QPM Co 2 Ac1,3,4,5,6 表示定量過程管理（ Quantitative Process Management ）過程域執(zhí)行的約定（ Commitment to perform ） 2 和執(zhí)行活動（ Activities to perform ） 1,3,4,5,6 。 Co 表示執(zhí)行的約定； Ab 表示執(zhí)行的能力； Ac 表示執(zhí)行的活動； SG 表示特殊目標（ Special Goal ）； GG 表示一般目標（ Generic Goal ）；其他可類推。 （ 3 ） CMMI3 級 ①將 CMM 軟件產品工程 KPA 分解為需求開發(fā)、技術解決方案、產品集成、認證、確認 KPAs ，并進行擴充。 ②了解 CMMI3 級中新增的決定分析和解決方案、合成團隊，組織一體化環(huán)境 KPAs ，并填補。 ③迭代 CMM2 級的工作。 6 結束語 卡內基梅隆大學軟件工程研究所推出 CMM Version 2.0 draft C 后就停止了在 CMM 的改進。 CMM 被 CMMI 所取代是大勢所趨。許多正在運用 CMM 模型進行軟件過程改進的組織紛紛向 CMMI 升級。而 CMMI 模型迄今還沒有成熟，卡內基梅隆大學軟件工程研究所 推出了 CMMI-SE/SW 1.1 和 CMMI-SE/SW/IPPD ，在目前的產品集中沒有關于軟件采購方面的內容，估計以后還會推出這個科目。而且從 CMM 向 CMMI 升級也只是處于嘗試階段。組織升級的操作過程，運用 CMMI 模型所帶來的效益等信息還很匱乏，這些信息也為未能及時反饋到卡內基梅隆大學軟件工程研究所，這也給 CMMI 模型的改進及向 CMMI 的升級工作帶來了一定的難度。