作者：高艷明（來源：51CMM）  http://www.csai.cn  2003年05月19日
原文鏈接：http://edu.csai.cn/rjsp/NO000014.htm

引子

　　CMM理論和知識是最近幾年的熱點，在最近兩年的系統分析員上午試卷中都有一題考察CMM知識的，一般有3-5分的樣子。估計未來的系統分析員考試還會有這方面的考題。即使不考，我們的系統分析員也應該掌握這方面的知識，因為將來從事的系統分析與設計的工作也離不開CMM理論和知識，因為即使我們所在的公司不去進行CMM評估，CMM理論知識對于我們不斷的進行公司的軟件過程改進有一定的借鑒意義，從而有助于軟件質量的提高，進而提升公司產品的市場競爭力。

摘要

　　本文是根據這兩年試題中涉及CMM知識而特為廣大考友搜集整理的關于CMM的基礎知識的文章。主要內容是有關CMM的基本概念、CMM的基本框架和對CMM的正確態度等。希望這篇文章對你有所幫助，謝謝。

　　CMM（Capability Marurity Model，軟件能力成熟度模型）是于1984年美國國會與美國主要的公司和研究中心合作創立的一個由聯邦資助的非盈利組織——軟件工程研究所（Software Engineering Institute,SEI）的一個早期研究成果。該模型提供了軟件工程成果和管理方法的框架，自90年代提出以來，已在北美、歐洲和日本成功地應用。現在該模型已成為事實上的軟件過程改進的工業標準。下面我們來一起學習有關CMM的一些基礎知識。

一、 CMM基本概念

　　過程（Process）：為實現既定目標的一系列操作步驟[IEEE-STD-610].
軟件過程（Software Process）：指人們用于開發和維護軟件及其相關產品的一系列活動、方法、時間和革新。其中相關產品是指項目計劃、設計文檔、編碼、測試和用戶手冊。當一個企業逐步走向成熟，軟件過程的定義也會日趨完善，其企業內部的過程實施將更具有一致性。

　　軟件過程能力（Software Process Capability）：描述了在遵循一個軟件過程后能夠得到的預期結果的界限范圍。該指標是對能力的一種衡量，用它可以預測一個組織（企業）在承接下一個軟件項目時，所能期望得到的最可能的結果。

　　軟件過程性能（Software Process Performance）：表示遵循一個軟件過程后所得到的實際結果。（與軟件過程能力有區別，軟件過程能力關注的是實際得到的結果，而軟件過程性能關注的是期望得到的結果。由于項目要求和客觀環境的差異，軟件過程性能不可能充分反應軟件過程整體能力，即軟件過程能立受限于它的環境。）

　　軟件過程成熟度（Software Process Maturity）：是指一個具體的軟件過程被明確地定義、管理、評價、控制和產生實效的程度。所謂成熟度包含著能力的一種增長潛力，同時也表明了組織（企業）實施軟件過程的實際水平。隨著組織軟件過程成熟度能力的不斷提高，組織內部通過對過程的規范化和對成員的技術培訓，軟件過程也將會被他的使用者關注和不斷修改完善。從而使軟件的質量、生產率和生產周期的到改善。

　　CMM是軟件過程能力成熟度模型（Capacity Maturity Model）的簡稱，是卡內基－梅隆大學軟件工程研究院為了滿足美國聯邦政府評估軟件供應商能力的要求，于1986年開始研究的模型，并于1991年正式推出了CMM 1.0 版。CMM自問世以來備受關注，在一些發達國家和地區得到了廣泛應用，成為衡量軟件公司軟件開發管理水平的重要參考因素和軟件過程改進事實上的工業標準。

　　CMMI（Capability Maturity Model Integration）即能力成熟度模型集成，這也是美國國防部的一個設想，他們想把現在所有的以及將被發展出來的各種能力成熟度模型，集成到一個框架中去。這個框架有兩個功能，第一，軟件獲取方法的改革；第二，建立一種從集成產品與過程發展的角度出發、包含健全的系統開發原則的過程改進。

　　關鍵過程（區）域（Key Process Area）是指一系列相互關聯的操作活動，這些活動反映了一個軟件組織改進軟件過程時所必須滿足的條件。也就是說，關鍵過程域標識了達到某個成熟程度級別時所必須滿足的條件。在CMM中一共有18個關鍵過程域，分布在第二至五級中。

　　關鍵實踐（Key Practices）：是指關鍵過程域種的一些主要實踐活動。每個關鍵過程域最終由關鍵實踐所組成，通過實現這些關鍵實踐達到關鍵過程域的目標。一般情況下，關鍵實踐描述了該“做什么”，但沒有規定“如何”去達到這些目標。

　　軟件過程評估（Software Process Assessment）是用來判斷一個組織當前所涉及的軟件過程的能力狀態，判斷下一個組織所面向得更高層次上的與軟件過程相關的課題，以及利用組織的鼎力支持來對該組織的軟件過程進行有效的改進。

　　軟件能力評價是（Software Capability Appraisal）用來判斷有意承擔某個軟件項目的軟件組織的軟件過程能力，或是判斷已進行的軟件過程所處的狀態是否正確或是否正常。

　　軟件工程組（Software Engineering Group）：負責一個項目的軟件開發和維護活動的團體。活動包括需求分析、設計、編碼和測試等。

　　軟件相關組（Software Related Groups）：代表一種軟件工程科目的團體，它支持但不直接負責軟件開發或維護工作，如軟件質量保證組、軟件配置管理組合軟件工程過程組等等。在CMM的關鍵實踐中，軟件相關組通常應該根據關鍵過程域和組織的上下文來理解。

　　軟件工程過程組（Software Engineering Process Group）：是由專家組成的組，他們推進組織采用的軟件過程的定義、維護和改進工作。在關鍵實踐中，這個組織通常指“負責組織軟件過程活動的組”。

　　系統工程組（System Engineering Group）：是負責下列工作的個人的團體：分析系統需求；將系統需求分配給硬件、軟件和其他成分；規定硬件、軟件和其他成分的界面；監控這些成分的設計和開發以保證它們符合其規格說明。

　　系統測試組（System Test Group）：是一些負責策劃和完成獨立的軟件系統測試的團體，測試的目的是為了確定軟件產品是否滿足對它的需求。

　　軟件質量保證組（Software Quality Assurance Group）：是一些計劃和實施項目的質量保證的團體，其工作目的是保證軟件過程的步驟和標準是否得到遵守。

　　軟件配置管理組（Software Configuration Management Group）：是一些負責策劃、協調和實施軟件項目的正式配置活動的團體。

　　培訓組（Training Group）：是一些負責協調和安排組織培訓活動的團體。通常這個組織負責準備和講授大多數培訓課程并協調其他培訓方式的使用。

二、 CMM 的基本框架

　　任何一個軟件的開發、維護和軟件組織的發展離不開軟件過程，而軟件過程經歷了不成熟到成熟、不完善到完善的發展過程。它不是一朝一夕就能成功的，需要持續不斷的對軟件過程進行改進，才能取得最終的成效。CMM就是根據這一指導思想設計出來的。該模型為了正確和有序地引導軟件過程活動的開展，建立一個能夠有效地描述和表示的軟件過程的改進框架，使其能夠對各階段軟件過程的任務和管理起指導作用。該模型一產品質量的概念和軟件工程的經驗教訓為基礎，指導企業如何控制開發、維護軟件的生產過程和如何制定一套與之相適應的軟件過程及管理體系。

（一）分級標準

　　CMM模型描述和分析了軟件過程能力的發展程度，確立了一個軟件過程成熟程度的分級標準，如圖1示。一方面軟件組織利用它可以評估自己當前的過程成熟度，并以此提出嚴格的軟件質量標準和過程改進的方法和策略，通過不斷的努力去達到更高的成熟程度。另一方面，該標準也可以作為用戶對軟件組織的一種評價標準，使之在選擇軟件開發商時不再是盲目的和無把握的。

圖 1 軟件過程成熟度的級別

　　CMM的分級結構可以描述為：

　　①、初始級：軟件過程的特點是無秩序的，有時甚至是混亂的。軟件過程定義幾乎處于無章法和步驟可循的狀態，軟件產品所取得的成功往往依賴于極個別人的努力和機遇。

　　②、可重復級：已建立了基本的項目管理過程，可用于對成本、進度和功能特性進行跟蹤。對類似的應用項目，有章可循并能重復以往所取得的成功。

　　③、已定義級：用于管理的和工程的軟件過程均已文檔化、標準化，并形成了整個軟件組織的標準軟件過程。全部項目均采用與實際情況相吻合的、適當修改后的標準軟件過程來進行操作。

　　④、以管理級：軟件過程和產品質量有詳細的度量標準。軟件過程和產品質量得到了定量的認識和控制。

　　⑤、優化級：通過對來自過程、新概念和新技術等方面的各種有用信息的定量分析，能夠不斷地、持續地對促進過程進行改進。

　　除第一級外，每一級都設定了一組目標，如果達到了這組目標，則表明達到了這個成熟級別，自然可以向下一級別邁進。CMM體系不主張跨級別的進化。因為從第二級開始，每一個低級別的實現均是高級別實現的基礎。

（二）CMM的主要內容

　　CMM為軟件企業的過程能力提供了一個階梯式的進化框架，它采用分層的方式來解釋起組成部分，如圖2示。在第二至第五個成熟等級中，每個等級包含一個內部結構的概念，關于內部結構詳細描述將在下面CMM內部結構的一欄中進行。

圖 2 CMM的五個成熟等級

　　每一級向上一級邁進的過程中都有其特定的改進計劃，具體情況如下。

　　初始級的改進方向是：建立項目過程管理，是使規范化管理，保障項目的承諾；艷進行需求管理方面的工作，建立用戶域軟件項目之間的溝通，使項目真正反映用戶的需求；建立各種軟件項目幾乎，如軟件開發計劃、軟件質量保證計劃、軟件配置管理計劃、軟件測試計劃、風險管理計劃及過車改進計劃等；積極開展軟件質量保證活動（SQA）。

　　可重復級的改進方向是：不再按項目制定軟件過程，而是總結各種項目的成功經驗，使之規則化，把具體經驗歸納為權組織的標準軟件過程，把改進軟件組織的整體軟件過程能力的軟件過程活動，作為軟件開發組織的責任；確定全組織的標準軟件過程，把軟件工程及管理活動集成到一個穩固確定的軟件過程中，從而可以跨項目改進軟件過程效果，也可以作為軟件過程剪裁的基礎；建立軟件工程過程小組（SPEG）長期承擔評估域調整軟件過程的任務，以適應未來軟件項目的要求；積累數據，建立組織的軟件過程庫及軟件過程相關的文檔；加強培訓。
已定義級的改進方向是：著手軟件過程的定量分析，已達到定量地控制軟件項目過程的效果；通過軟件的質量管理達到軟件質量的目標。

　　已管理級的改進方向是：防范缺陷，不僅在發現了問題能及時改進，而且應采取特定行動防止將來出現這類缺陷；主動進行技術改革管理、標識、選擇和評價新技術，是有效的新技術能在開發組織中實施；進行過程變更管理，定義過程改進的目的，經常不斷地進行過程改進。

　　優化級的改進目方向是：保持持續不斷的軟件過程改進。

（三）CMM的內部結構

　　CMM為軟件過程能力的提高提供了一條改進的途徑。CMM由5個成熟度等級組成，每個成熟度等級有著各自的功能。除第一級外，CMM的每一級按完全相同的內部結構構成的，如圖3。成熟度等級為頂層，不同的成熟度等級反映了軟件組織的軟件過程能力和該組織可能實現預期結果的程度。

圖3 CMM的內部結構圖

　　在CMM中，每個成熟度等級（第一級除外）規定了不同的關鍵過程域，一個軟件組織如果希望達到某一個成熟度級別，就必須完全滿足關鍵過程域所規定的要求，即滿足關鍵古城域的目標。每一級的關鍵過程域的詳細情況見表1。

表1 關鍵過程域的分類

（四）軟件過程評估和軟件能力評價

　　軟件過程評估所針對的是軟件組織自身內部軟件過程的改進問題，目的在于法子按缺陷，提出改進方向。評估組以CMM模型為指引調查、鑒別軟件過程中的問題，翻過來將這些問題與CMM關鍵實踐活動所提出的指導一起用于確定組織的軟件過程改進策略。

　　軟件能力評價是對接受評價者在一定條件下、規定時間內能否完成特定項目的能力考核，即承擔風險的系數大小。評價包括承包者是否有能力按計劃開發軟件產品，是否能按預算完成等。通過利用CMM模型確定評價結果后，就可以利用這些結果確定選擇某一承包商的風險。也可以用來判斷承包者的工作進程，推動他們愛進軟件過程。
CMM為評估和評價提供了一個參考框架，指出了在評估和評價中通常采用的佛農步驟，如圖4示。

圖 4 軟件過程評估和軟件能力評價的步驟

　　具體來說，評估過程是：選擇一個工作組；完成問卷調查和取樣工作；結果分析；現場訪問；與CMM模型對照分析；依據關鍵過程域的基本情況列出評估提綱。以上步驟在軟件過程評估和軟件能力評價題勾勒很有參考價值的方法，但在具體操作時以下這些特點也值得考慮：

　　①、在現場訪問和考察中，充分運用成熟度問卷和結果分析為依據。

　　②、以CMM模型作為現場調查的路線圖。

　　③、利用CMM中的關鍵過程域定義軟件過程中的優點和缺陷，從中發現差異。

　　④、對關鍵過程域目標是否備滿足的實際情況出發，分析滿意程度，寫出書面報告。

　　盡管軟件過程評估和軟件能力評價有很多相似之處，但由于其目的和結果的不同，它們之間的差異也是必然存在的，如：

　　①、軟件過程評估和軟件能力評價在出發點和目標上的不同，使得會談目的、調查范圍、收集的信息和輸出的表示方式上有著本質的不同。尤其在一些細節規范方面，評估和評價的方法有很大差異。

　　②、軟件過程評估和軟件能力評價的結果和結果所起的作用不同。因為兩者的側重點不一樣，即使是對同一個應用項目，運用相同的方法，也不會得出相同的結果。

　　③、被評估和評價單位的態度對評估和評價活動的影響。評估在某種意義上被評估單位的態度較積極，而評價在某種意義上被評價單位的態度可能比較慎重。軟件過程評估是在一個開放的、互相協作的環境中進行的，而軟件能力評價往往是在有較大的阻力的環境中進行的。

（五）CMM的組織保證

　　當人們面對CMM實施時，首先想到的就是人員的構成和各種小組的劃分。它是實施CMM的組織保證，是一切活動的基礎。CMM在制定軟件過程實施中本著盡量不和具體的組織機構和組織形式相聯系的原則，為的是提供一個獨立于具體企業而又有廣泛指導意義的模型框架。但在實施各種軟件關鍵實踐中，不可避免地要涉及到角色和組織結構。所以為了使CMM能夠使用域各種級別和各種規模的企業，SEI提出了一個相對抽象的組織結構，它與組織、項目、人員（角色）相關聯，具有自己特定的術語，而且可能不同于其他組織所用的名詞。例如基本概念中提到的主要的軟件工作組的概念。

三、 正確的態度看待CMM

　　SEI的CMM并不是軟件開發的方法學，也不是產品模板，更不是過程法律。CMM是過程改進的途徑，是一套指南，幫助你通過持續的重復、測量和提煉，穩步創造與凈化開發環境。CMM的假定是：如果你實施一個不斷重復、測量和提煉的大綱，作為環境改進的副產物，質量便會自然的提高。不要把CMM設想為一套規則，而應將它理解為一個學科，做事的一般方法。在這套指南下運作，你會發現這里有著廣闊的空間，讓你剪裁和塑造自己的大綱，以適應組織的特定要求。

　　CMM不采用“用這種方法做這類事”的風格，它也不對由問題的IT組織提供快速的糾正方案。CMM是一個指南針，指導你如何逃離暴風雪。CMM是一個大綱，要求你對整個IT組織的有關部分，從高層領導到軟件生產的第一次線工作者，都做出堅定的、長期的實施承諾。成熟的過程不可能在已也之間實現。

　　在如何解釋CMM建議時，它允許極大的靈活性。CMM意識到，IT組織之間存在著很大的差別。他們的客戶不同，使用的工具不同，人員智力和專業背景不同，從事的項目屬于不同的類型，規模大小不同，要求也各不相同。因而，他們應當以自己的方式走向成熟。在一處活用的東西，在另一處未必適用。這一點非常重要，中國部分軟件公司的前車之鑒也從某種程度上給了我們建議和經驗教訓，那就是，要靈活應用CMM，不要幻想一夜就有成效。

小結

　　本文只是根據這兩年的試題和自己的預測向廣大系分考友提供一些CMM方面的知識。CMM不是重點，但也有可能會考到一些知識，如基本概念等。在搜集資料和整理著篇文章時，遇到了一個矛盾，那就是：我要提供足夠的資料以使讀者不必花費金錢再去買一本書就可以復習有關CMM的知識，而同時又不能放太多的內容使讀者浪費太多的時間在這上面。最后采取了一個折衷的辦法，那就是盡量滿足考試需求的情況下減少篇幅。在此聲明，本文所涉及的內容只是本人的預測，并不是說考試范圍不會超過本文的內容。所以有時間的朋友還是盡可能的擴大這方面知識面。希望這篇文章對你有幫助，謝謝。