软件能力成熟度模型CMM
軟件能力成熟度模型是一種對軟件組織在定義、實施、度量、控制和改善其軟件過程的實踐中各個發展階段的描述形成的標準。
軟件簡介
CMM:其英文全稱為Capability Maturity Model ，英文縮寫為SW-CMM，簡稱CMM。它是對于軟件組織在定義、實施、度量、控制和改善其軟件過程的實踐中各個發展階段的描述。CMM的核心是把軟件開發視為一個過程，并根據這一原則對軟件開發和維護進行過程監控和研究，以使其更加科學化、標準化、使企業能夠更好地實現商業目標。
分級
CMM是一種用于評價軟件承包能力并幫助其改善軟件質量的方法，側重于軟件開發過程的管理及工程能力的提高與評估。CMM分為五個等級：一級為初始級，二級為可重復級，三級為已定義級，四級為已管理級，五級為優化級。
CMM/CMMI將軟件過程的成熟度分為5個等級,以下是5個等級的基本特征：
(1)初始級(initial)。工作無序，項目進行過程中常放棄當初的計劃。管理無章法，缺乏健全的管理制度。開發項目成效不穩定，項目成功主要依靠項目負責人的經驗和能力，他一但離去，工作秩序面目全非。
(2)可重復級(Repeatable)。管理制度化，建立了基本的管理制度和規程，管理工作有章可循。 初步實現標準化，開發工作比較好地按標準實施。 變更依法進行，做到基線化，穩定可跟蹤，新項目的計劃和管理基于過去的實踐經驗，具有重復以前成功項目的環境和條件。
(3)已定義級(Defined)。開發過程，包括技術工作和管理工作，均已實現標準化、文檔化。建立了完善的培訓制度和專家評審制度，全部技術活動和管理活動均可控制，對項目進行中的過程、崗位和職責均有共同的理解 。
(4)已管理級(Managed)。產品和過程已建立了定量的質量目標。開發活動中的生產率和質量是可量度的。已建立過程數據庫。已實現項目產品和過程的控制。可預測過程和產品質量趨勢，如預測偏差，實現及時糾正。
(5)優化級(Optimizing)。可集中精力改進過程，采用新技術、新方法。擁有防止出現缺陷、識別薄弱環節以及加以改進的手段。可取得過程有效性的統計數據，并可據進行分析，從而得出最佳方法。
歷史來源
CMM是由美國卡內基梅隆大學軟件工程研究所1987年研制成功的，是國際上最流行最實用的軟件生產過程標準和軟件企業成熟度等級認證標準。我國已有軟件企業通過了CMM標準認證 。
SW-CMM(Capability Maturity Model For Software 軟件生產能力成熟度模型,以下簡稱"CMM"),是87年由美國卡內基梅隆大學軟件工程研究所（CMU SEI）研究出的一種用于評價軟件承包商能力并幫助改善軟件質量的方法，其目的是幫助軟件企業對軟件工程過程進行管理和改進，增強開發與改進能力，從而能按時地、不超預算地開發出高質量的軟件。
其所依據的想法是：只要集中精力持續努力去建立有效的軟件工程過程的基礎結構，不斷進行管理的實踐和過程的改進，就可以克服軟件生產中的困難。CMM它是國際上最流行、最實用的一種軟件生產過程標準，已經得到了眾多國家以及國際軟件產業界的認可，成為當今企業從事規模軟件生產不可缺少的一項內容。
CMM通用流行的版本是1．1（Version1．1）。《按照軟件工程研究所（SEI）的原來計劃，CMM的改進版版本2．0（V2．0）是要在1997年的11月完成的。但是，美國國防部辦公室要求軟件工程研究所（SEI）延遲發放公布CMM版本2．0，直至他們完成另一個更為緊迫的項目-CMMI。
CMMI(Capability Maturity Model Integration能力成熟度模型集成)，是美國國防部的一個設想。他們希望把所有現存的與將被發展出來的各種能力成熟度模型，集成到一個框架中去。這個框架用于解決兩個問題：第一，軟件獲取辦法的改革；第二，從集成產品與過程發展的角度出發,建立一種包含健全的系統開發原則的過程改進。
CMM為軟件企業的過程能力提供了一個階梯式的改進框架，它基于過去所有軟件工程過程改進的成果，吸取了以往軟件工程的經驗教訓，提供了一個基于過程改進的框架；它指明了一個軟件組織在軟件開發方面需要管理哪些主要工作、這些工作之間的關系、以及以怎樣的先后次序，一步一步的做好這些工作而使軟件組織走向成熟。
CMM的誕生
信息時代，軟件質量的重要性越來越為人們所認識。軟件是產品、是裝備、是工具，其質量使得顧客滿意，是產品市場開拓、事業得以發展的關鍵。而軟件工程領域在1992年至1997年取得了前所未有的進展,其成果超過軟件工程領域過去15年來的成就總和。
軟件管理工程引起廣泛注意源于20世紀70年代中期。當時美國國防部曾立題專門研究軟件項目做不好的原因，發現70%的項目是因為管理不善而引起，而并不是因為技術實力不夠，進而得出一個結論，即管理是影響軟件研發項目全局的因素，而技術只影響局部。到了20世紀90年代中期，軟件管理工程不善的問題仍然存在，大約只有10%的項目能夠在預定的費用和進度下交付。軟件項目失敗的主要原因有：需求定義不明確；缺乏一個好的軟件開發過程；沒有一個統一領導的產品研發小組；子合同管理不嚴格；沒有經常注意改善軟件過程；對軟件構架很不重視；軟件界面定義不善且缺乏合適的控制；軟件升級暴露了硬件的缺點；關心創新而不關心費用和風險；軍用標準太少且不夠完善等等。在關系到軟件項目成功與否的眾多因素中，軟件度量、工作量估計、項目規劃、進展控制、需求變化和風險管理等都是與工程管理直接相關的因素。由此可見，軟件管理工程的意義至關重要。
軟件管理工程和其它工程管理相比有其特殊性。首先，軟件是知識產品，進度和質量都難以度量，生產效率也難以保證。其次，軟件系統復雜程度也是超乎想象的。因為軟件復雜和難以度量，軟件管理工程的發展還很不成熟。
軟件管理工程的發展，在經歷了從70年代開始以結構化分析與設計、結構化評審、結構化程序設計以及結構化測試為特征的結構化生產時代，到90年代中期，以CMM模型的成熟模型和日益為市場接受為標志，已經進入以過程成熟模型CMM、個體軟件過程PSP和群組軟件過程TSP為標志的以過程為中心的時代，而軟件發展第三個時代，及軟件工業化生產時代，從90年代中期軟件過程技術的成熟和面向對象技術、構件技術的發展為基礎，已經漸露端倪，估計到2005年，可以實現真正的軟件工業化生產，這個趨勢應該引起軟件企業界和有關部門的高度重視，及早采取措施，跟上世界軟件發展的腳步。軟件生產轉向以改善軟件過程為中心，是世界各國軟件產業或遲或早都要走的道路。
軟件過程改善是當前軟件管理工程的核心問題。50多年來計算事業的發展使人們認識到要高效率、高質量和低成本地開發軟件，必須改善軟件生產過程。軟件管理工程走過了一條從70年代開始以結構化分析與設計、結構化評審、結構化程序設計以及結構化測試到90年代中期以過程成熟模型CMM、個體軟件過程PSP和群組軟件過程TSP為標志的以過程為中心向著軟件過程技術的成熟和面向對象技術、構件技術的發展為基礎的真正軟件工業化生產的道路。軟件生產轉向以改善軟件過程為中心，是世界各國軟件產業或遲或早都要走的道路。軟件工業已經或正在經歷著"軟件過程的成熟化"，并向"軟件的工業化"漸進過渡。規范的軟件過程是軟件工業化的必要條件。
軟件過程研究的是如何將人員、技術和工具等組織起來，通過有效的管理手段，提高軟件生產的效率，保證軟件產品的質量。由此誕生了軟件過程的三個流派：CMU-SEI的CMM/PSP/TSP；ISO 9000質量標準體系；ISO/IEC 15504（SPICE）。
CMM/PSP/TSP即軟件能力成熟度模型/ 個體軟件過程/群組軟件過程，是1987年美國 Carnegie Mellon 大學軟件工程研究所(CMU/SEI)以W.S.Humphrey為首的研究組發表的研究成果"承制方軟件工程能力的評估方法"；SO 9000質量標準體系是在70年代由歐洲首先采用的，其后在美國和世界其他地區也迅速地發展起來。歐洲聯合會積極促進軟件質量的制度化，提出了如下ISO9000軟件標準系列：ISO9001、ISO9000-3、ISO9004-2、ISO9004-4、ISO9002；ISO/IEC 15504（SPICE）是1991年國際標準化組織采納了一項動議，開展調查研究，按照CMU-SEI的基本思路，產生的技術報告ISO/IEC 15504–信息技術軟件過程評估。
學術界和工業界公認美國 Carnegie Mellon 大學軟件工程研究所(CMU/SEI) 以W.S.Humphrey為首主持研究與開發的軟件能力成熟度模型CMM是當前最好的軟件過程，已成為業界事實上的軟件過程的工業標準。
CMM的發展
1987年美國 Carnegie Mellon 大學軟件工程研究所(CMU/SEI)以W.S.Humphrey為首的研究組發表了CMM/PSP/TSP 技術，為軟件管理工程開辟了一條新的途經。
CMM框架用5個不斷進化的層次來評定軟件生產的歷史與現狀：其中初始層是混沌的過程，可重復層是經過訓練的軟件過程，定義層是標準一致的軟件過程，管理層是可預測的軟件過程，優化層是能持續改善的軟件過程。任何單位所實施的軟件過程，都可能在某一方面比較成熟，在另一方面不夠成熟，但總體上必然屬于這5個層次中的某一個層次。而在某個層次內部，也有成熟程度的區別。在CMM框架的不同層次中，需要解決帶有不同層次特征的軟件過程問題。因此，一個軟件開發單位首先需要了解自己正處于哪一個層次，然后才能夠對癥下藥地針對該層次的特殊要求解決相關問題，這樣才能收到事半功倍的軟件過程改善效果。任何軟件開發單位在致力于軟件過程改善時，只能由所處的層次向緊鄰的上一層次進化。而且在由某一成熟層次向上一更成熟層次進化時，在原有層次中的那些已經具備的能力還必須得到保持與發揚。
軟件產品質量在很大程度上取決于構筑軟件時所使用的軟件開發和維護過程的質量。軟件過程是人員密集和設計密集的作業過程：若缺乏有素訓練，就難以建立起支持實現成功是軟件過程的基礎，改進工作亦將難以取得成效。CMM描述的這個框架正是勾列出從無定規的混沌過程向訓練有素的成熟過程演進的途徑。
CMM包括兩部分"軟件能力成熟度模型"和"能力成熟度模型的關鍵慣例"。“軟件能力成熟度模型"主要是描述此模型的結構，并且給出該模型的基本構件的定義。“能力成熟度模型的關鍵慣例"詳細描述了每個"關鍵過程方面"涉及的"關鍵慣例”。這里"關鍵過程方面"是指一組相關聯的活動；每個軟件能力成熟度等級包含若干個對該成熟度等級至關重要的過程方面，它們的實施對達到該成熟度等級的目標起到保證作用。這些過程域就稱為該成熟度等級的關鍵過程域，反之有非關鍵過程域是指對達到相應軟件成熟度等級的目標不起關鍵作用。歸納為：互相關聯的若干軟件實踐活動和有關基礎設施的一個集合。而"關鍵慣例"是指使關鍵過程方面得以有效實現和制度化的作用最大的基礎設施和活動,對關鍵過程的實踐起關鍵作用的方針、規程、措施、活動以及相關基礎設施的建立。關鍵實踐一般只描述"做什么"而不強制規定"如何做”。各個關鍵慣例按每個關鍵過程方面的5個"公共特性"（對執行該過程的承諾，執行該過程的能力，該過程中要執行的活動，對該過程執行情況的度量和分析，及證實所執行的活動符合該過程）歸類，逐一詳細描述。當作到了某個關鍵過程的的全部關鍵慣例就認為實現了該關鍵過程，實現了某成熟度級及其以低級所含的全部關鍵過程就認為達到到了了該級。
上面提到了CMM把軟件開發組織的能力成熟度分為5個的等級。除了第1級外，其他每一級由幾個關鍵過程方面組成。每一個關鍵過程方面都由上述5種公共特性予以表征。CMM給每個關鍵過程了一些具體目標。每個公共特性歸類的關鍵慣例是按該關鍵過程的具體目標選擇和確定的。如果恰當地處理了某個關鍵過程涉及的全部關鍵慣例，這個關鍵過程的各項目標就達到了，也就表明該關鍵過程實現了。這種成熟度分級的優點在于，這些級別明確而清楚地反映了過程改進活動的輕重緩急和先后順序。
已剪輯自: https://zhuanlan.zhihu.com/p/86441160
本系列文章為筆記，內容根據北京大學《軟件工程》MOOC
CMM概念及發展
認識軟件質量
- 軟件系統的質量取決于用來開發和改進它的過程和質量
- 要進行過程的改進，必須對現有的過程有所了解，特別是已存在問題有客觀的認識
- 軟件過程改進不是目的，是一個持續的過程
CMM（the Capability Maturity Model for software）軟件能力成熟度模型
過程是生產產品的機制。不論是過程改善還是能力確定，均需要過程評估，而過程評估通常基于已提出的一些評估模型。
CMM是什么
- CMM指的是軟件過程能力成熟度模型，按軟件過程的不同成熟度劃分了5個等級，1級被認為成熟度最低，5級成熟度最高
- CMM給出了從混亂、個人的過程到成熟的規范化過程的一個框架
- CMM項目的主要負責人指出“軟件組織可以通過CMM去定義、實施、度量、控制和改進自己的軟件過程”。人們可以利用該框架進行可靠且統一的評估，實現對軟件過程的度量。
- CMM體現了軟件工程和軟件管理的優秀實踐
- CMM不是銀彈，并沒有涉及的是項目成功的所有重要問題
CMM族
有多種基于CMM的模型，例如：
注：通常把SW-CMM和CMM通用
CMMI的發展
SEI在SW-CMM2.0版本形成過程中，轉為了一個新項目，CMMI，目標是集成已有的CMM模型，實現一個組織的集成化過程和改進
2002年發布的CMMI集成了三個CMM：SW-CMM，SE-CMM，IPD-CMM
CMMI1.1集成的目標是通過以下方法降低實現基于多學科模型的過程改進成本：
- 消除不一致
- 減少重復
- 增加清晰度和理解
- 提供公共術語
- 提供一致的風格
- 建立統一的構造規則
- 維護公共組件
- 確保與ISO/IEC 15504一致
CMM的基本內容
基本思想
整個軟件任務可以看作是一個過程，該過程可以予以控制、測量和改進
基本概念
過程
過程是一種手段，通過該手段可以把人、規程、方法、設備以及工具進行集成，以產生一種所期望的結果
過程能力
一個組織的軟件過程能力，是未來項目結果的指示器，給出了一種預測該組織承擔下一個軟件項目可能結果的方法。是不同等級過程能力的基本指標。
- 非常依賴當前的參與人員
- 軟件過程與管理均是臨時準備
- 沒有嚴格的下一步
- 復審和測試常常不足
- 交付的“東西”不符合要求
- 冒險使用新技術
- 產品的質量很難預測
- 進度延遲和預算超額
- 高過程能力的特征
- 定義了過程，建立了使用技術的基礎
- 開發和管理遵循一個確定的途徑
- 過程得到了很好地控制，并得到各方面的支持
- 實現了過程制度化，并不斷改進
具有成熟過程的組織特征：
過程性能
準尋一個過程所能達到實際結果的一個測度，過程能力和過程性能之間的關系
軟件過程能力與軟件過程性能之間的關系：
過程成熟度
一個特定軟件過程被明確和有效地定義、管理、測量和控制的程度
軟件過程成熟度指明：
- 一個軟件開發組織軟件過程能力的增長潛力——能力提高的基礎性
- 一個開發組織軟件過程的豐富多樣性——能力提高的可能性
- 在各開發項目中運用軟件過程的一致性——能力提高的持續性
由于開發組織通過運用軟件過程，使各項目執行軟件過程的紀律性一致地增強，導致軟件生產率和質量可以得到不斷地改進
組織成熟度
-
組織成熟度是由一組過程的組合能力來表達的，其中包括支持它們的制度因素
-
高的組織成熟度，是將組織的一組過程看作為一個整體，該整體是高的過程能力。主要表現為：
-
- 不論是開發還是管理，均有明確、嚴格的途徑
- 定義了組織過程并不斷改善之
- 得到了管理人員和其他人員的支持
- 實施了很好的控制
能力成熟度等級
- 軟件開發組織在走向成熟的過程中，幾個具有明確定義的、可以表征其軟件過程能力成熟程度的等級
- 每一級包含一組過程目標。當一個軟件開發組織達到其中一個目標時，則表明軟件過程的一個（或幾個）重要成分得到了實現，從而導致該組織軟件過程能力的增長
- 每一個成熟度等級為到達下一個等級提供了基礎
CMM五級標準
五級框架
成熟度框架
初始級、可重復級、已定義級、已管理、持續優化級
- 描述：一條從無序的、混亂的過程達到成熟的、有紀律的軟件過程的進化途徑
- 用途：以軟件過程成熟度框架，可以導出過程改進策略，為軟件過程的不斷改進的歷程提供了一份導引圖；
- 基礎：軟件過程成熟度框架的基礎是等級內部結構
各等級的基本特征
-
初始級
-
- 組織：組織通常沒有提供開發和維護軟件的穩定的環境
- 項目：當發生危機時，項目通常放棄計劃的過程，回復到編碼和測試
- 過程能力：不可預測，由于：
-
結果：項目的成敗完全取決于個人的能力和努力；軟件性能隨個人具有的技能、知識和動機的不同而變化；并只能通過個人的能力進行預測
-
可重復級
-
- 組織：將軟件項目的有效管理過程制度化，這使得組織能夠重復以前項目中的成功實踐。
- 項目：配備了基本的軟件管理控制
- 過程能力：
可重復的：即對當前項目的需求分析后制定的，能重復以前的成功實踐，盡管在具體過程中可能有所不同，這是該級的一個顯著特征
基本可控的：即對軟件項目的管理過程是制度化的。
軟件項目過程基本上是可視的
項目的過程基本是可特征化的
新項目的策劃和管理是基于成功項目經驗的
總之，2級的過程是可視的，即可以獲取項目運行狀態。
實現關鍵過程域：
軟件配置管理、軟件質量保證、軟件子合同管理、軟件項目跟蹤和監督、軟件項目規劃、需求管理。
其中：
-
過程域：互相關聯的若干個軟件實施活動和有關基礎設施的集合
-
關鍵過程域：對某一成熟等級將起到至關重要的過程域即它們的實施將對達到該成熟度等級的目標起保證作用，這些過程域被稱為關鍵過程域
-
每一軟件過程成熟度等級均包含一組特定的關鍵過程域
-
已定義級
-
- 實現了可重復級（2級）的關鍵過程域
- 實現了關鍵過程域：
組織過程焦點、組織過程定義、培訓大綱、集成軟件管理、軟件產品工程、組間協調以及同行評審
-
主要特征：
-
- 組織：在組織范圍內開發和維護軟件的標準過程被文檔化，其中包括軟件工程過程和管理過程，它們集成為一個一致的整體
- 項目：對組織的標準軟件過程進行裁剪，來開發它們自己項目的軟件過程
-
過程能力：是標準的和一致的。
- 關注的焦點轉向組織的體系和管理
- 全組織建立了軟件開發和維護的標準過程
- 軟件工程過程和軟件管理過程，被綜合為一個有機的整體，并且已經文檔化
- 建立了負責組織的軟件過程活動的機構：
在軟件組織中存在負責軟件過程活動的機構，并具體實施全組織的過程制定、維護和改進
其中包括全組織的人員培訓，使之具備必須的技能和知識，能高效地履行其職責。
項目能夠依據其環境和需求等，通過剪裁組織的標準過程，使用組織的過程財富，自定義項目的軟件過程。其中，允許有一定的自由度，但任務間的不匹配情況，應在過程規劃階段得到標識，并進行組間協調和控制。
由于項目自定義的軟件過程將開發活動和管理活動綜合為一個協調的、合理定義的軟件過程，并明確規定了每一活動的輸入、輸出、標準、規程和驗證判據
管理者或軟件項目負責人能夠洞察所有項目的技術進展、費用和進度
- 整個組織范圍內的軟件開發和維護過程已經標準化；
- 軟件工程技術活動和軟件管理活動都實現文檔化的規范管理；
- 組織和項目的軟件過程都是穩定的、可重復的
- 這種過程能力是建立在整個組織范圍內對已定義過程中的活動、作用和職責的共同理解基礎之上。
在整個組織范圍內軟件能力是均衡、一致的
- 定量管理級
實現了關鍵過程域：定量過程管理和軟件質量管理
- 項目：項目減小過程性能的變化性，使其進入可接受的量化邊界，從而達到對產品和過程的控制
- 組織：為軟件產品和過程都設定了量化的質量目標
- 過程能力：可預言的
設置了定量的質量目標：
可以定量地評價項目的軟件過程和產品質量
可以將項目的過程性能變化限制在一個定量的、可接受的范圍之內。產品質量和過程是受控和穩定的
由于組織的軟件過程能力是已知的，從而可以利用全組織的軟件過程數據庫，分析并定量地估計出開發新領域軟件的風險。
過程是經測量的并能在可預測的范圍內運行，一旦發現過程和產品質量偏離所限制的范圍時，能夠立即采取措施予以糾正
- 持續優化級
實現了關鍵過程域：缺陷預防、技術變化管理、過程變化管理
- 組織：關注于持續的過程改進；
- 項目：軟件過程被評價，以防過失重復發生，從中獲得的教訓散布給其它項目。
- 過程能力：持續的改進
- 組織有辦法識別出過程的弱點，并及時地予以克服；
- 能夠利用關于軟件過程有效性的數據，識別最佳軟件工程實踐的技術創新，并推廣到整個組織。
- 缺陷能有效預防
軟件項目組能分析并確定缺陷的發生原因，認真評價軟件過程，以防止同類缺陷再現，并且能將經驗告知其他項目組。
組織既能在現有的基礎上以漸進的方式，又能以技術創新等手段，不斷努力地改善過程性能。
關于級別的三點說明
匯總
ISO9000標準
定義
質量保證體系：用于實現質量管理的組織結構、責任、規程、過程和資源；
創建質量保證體系的目的是幫助組織以符合規格說明的方式，保證組織的產品和服務滿足客戶的期望；
應用
ISO 9000質量管理系統——基本原則和術語
ISO 9001質量管理系統——需求
ISO 9004質量管理系統——性能改善指南
ISO 19011質量和環境管理系統審計指南
ISO 9001核心過程
為了服從ISO 9001標準，公司必須記錄他們的過程與這9個過程相對應
-
產品交付過程
-
- 業務獲取
- 設計和開發
- 測試
- 生產和交付
- 服務和支持
-
支持過程
-
- 業務管理
- 供應商管理
- 庫存管理
- 配置管理
已剪輯自: https://blog.csdn.net/delphizhou/article/details/3035629?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522166376418116800182168635%2522%252C%2522scm%2522%253A%252220140713.130102334…%2522%257D&request_id=166376418116800182168635&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2allsobaiduend~default-1-3035629-null-null.142v49control,201v3control_2&utm_term=cmm%E6%98%AF%E4%BB%80%E4%B9%88&spm=1018.2226.3001.4187
CMM(Capability Maturity Model能力成熟度模型)的本質是軟件管理工程的一個部分。它是對于軟件組織在定義，實現，度量，控制和改善其軟件過程的進程中各個發展階段的描述。他通過5個不斷進化的層次來評定軟件生產的歷史與現狀。CMM的誕生信息時代，軟件質量的重要性越來越為人們所認識。軟件是產品、是裝備、是工具，其質量使得顧客滿意，是產品市場開拓、事業得以發展的關鍵。而軟件工程領域在1992年至1997年取得了前所未有的進展,其成果超過軟件工程領域過去15年來的成就總和。軟件管理工程引起廣泛注意源于20世紀70年代中期。當時美國國防部曾立題專門研究軟件項目做不好的原因，發現70%的項目是因為管理不善而引起，而并不是因為技術實力不夠，進而得出一個結論，即管理是影響軟件研發項目全局的因素，而技術只影響局部。到了20世紀90年代中期，軟件管理工程不善的問題仍然存在，大約只有10%的項目能夠在預定的費用和進度下交付。軟件項目失敗的主要原因有：需求定義不明確；缺乏一個好的軟件開發過程；沒有一個統一領導的產品研發小組；子合同管理不嚴格；沒有經常注意改善軟件過程；對軟件構架很不重視；軟件界面定義不善且缺乏合適的控制；軟件升級暴露了硬件的缺點；關心創新而不關心費用和風險；軍用標準太少且不夠完善等等。在關系到軟件項目成功與否的眾多因素中，軟件度量、工作量估計、項目規劃、進展控制、需求變化和風險管理等都是與工程管理直接相關的因素。由此可見，軟件管理工程的意義至關重要。軟件管理工程和其它工程管理相比有其特殊性。首先，軟件是知識產品，進度和質量都難以度量，生產效率也難以保證。其次，軟件系統復雜程度也是超乎想象的。因為軟件復雜和難以度量，軟件管理工程的發展還很不成熟。軟件管理工程的發展，在經歷了從70年代開始以結構化分析與設計、結構化評審、結構化程序設計以及結構化測試為特征的結構化生產時代，到90年代中期，以CMM模型的成熟模型和日益為市場接受為標志，已經進入以過程成熟模型CMM、個體軟件過程PSP和群組軟件過程TSP為標志的以過程為中心的時代，而軟件發展第三個時代，及軟件工業化生產時代，從90年代中期軟件過程技術的成熟和面向對象技術、構件技術的發展為基礎，已經漸露端倪，估計到2005年，可以實現真正的軟件工業化生產，這個趨勢應該引起軟件企業界和有關部門的高度重視，及早采取措施，跟上世界軟件發展的腳步。軟件生產轉向以改善軟件過程為中心，是世界各國軟件產業或遲或早都要走的道路。軟件過程改善是當前軟件管理工程的核心問題。50多年來計算事業的發展使人們認識到要高效率、高質量和低成本地開發軟件，必須改善軟件生產過程。軟件管理工程走過了一條從70年代開始以結構化分析與設計、結構化評審、結構化程序設計以及結構化測試到90年代中期以過程成熟模型CMM、個體軟件過程PSP和群組軟件過程TSP為標志的以過程為中心向著軟件過程技術的成熟和面向對象技術、構件技術的發展為基礎的真正軟件工業化生產的道路。軟件生產轉向以改善軟件過程為中心，是世界各國軟件產業或遲或早都要走的道路。軟件工業已經或正在經歷著"軟件過程的成熟化"，并向"軟件的工業化"漸進過渡。規范的軟件過程是軟件工業化的必要條件。軟件過程研究的是如何將人員、技術和工具等組織起來，通過有效的管理手段，提高軟件生產的效率，保證軟件產品的質量。由此誕生了軟件過程的三個流派：CMU-SEI的CMM/PSP/TSP；ISO 9000質量標準體系；ISO/IEC 15504（SPICE）。CMM/PSP/TSP即軟件能力成熟度模型/ 個體軟件過程/群組軟件過程，是1987年美國 Carnegie Mellon 大學軟件工程研究所(CMU/SEI)以W.S.Humphrey為首的研究組發表的研究成果"承制方軟件工程能力的評估方法"；SO 9000質量標準體系是在70年代由歐洲首先采用的，其后在美國和世界其他地區也迅速地發展起來。目前，歐洲聯合會積極促進軟件質量的制度化，提出了如下ISO9000軟件標準系列：ISO9001、ISO9000-3、ISO9004-2、ISO9004-4、ISO9002；ISO/IEC 15504（SPICE）是1991年國際標準化組織采納了一項動議，開展調查研究，按照CMU-SEI的基本思路，產生的技術報告ISO/IEC 15504–信息技術軟件過程評估目前，學術界和工業界公認美國 Carnegie Mellon 大學軟件工程研究所(CMU/SEI) 以W.S.Humphrey為首主持研究與開發的軟件能力成熟度模型CMM是當前最好的軟件過程，已成為業界事實上的軟件過程的工業標準。CMM的發展1987年美國 Carnegie Mellon 大學軟件工程研究所(CMU/SEI)以W.S.Humphrey為首的研究組發表了CMM/PSP/TSP 技術，為軟件管理工程開辟了一條新的途經。CMM框架用5個不斷進化的層次來評定軟件生產的歷史與現狀：其中初始層是混沌的過程，可重復層是經過訓練的軟件過程，定義層是標準一致的軟件過程，管理層是可預測的軟件過程，優化層是能持續改善的軟件過程。任何單位所實施的軟件過程，都可能在某一方面比較成熟，在另一方面不夠成熟，但總體上必然屬于這5個層次中的某一個層次。而在某個層次內部，也有成熟程度的區別。在CMM框架的不同層次中，需要解決帶有不同層次特征的軟件過程問題。因此，一個軟件開發單位首先需要了解自己正處于哪一個層次，然后才能夠對癥下藥地針對該層次的特殊要求解決相關問題，這樣才能收到事半功倍的軟件過程改善效果。任何軟件開發單位在致力于軟件過程改善時，只能由所處的層次向緊鄰的上一層次進化。而且在由某一成熟層次向上一更成熟層次進化時，在原有層次中的那些已經具備的能力還必須得到保持與發揚。軟件產品質量在很大程度上取決于構筑軟件時所使用的軟件開發和維護過程的質量。軟件過程是人員密集和設計密集的作業過程：若缺乏有素訓練，就難以建立起支持實現成功是軟件過程的基礎，改進工作亦將難以取得成效。CMM描述的這個框架正是勾列出從無定規的混沌過程向訓練有素的成熟過程演進的途徑。CMM包括兩部分"軟件能力成熟度模型"和"能力成熟度模型的關鍵慣例"。“軟件能力成熟度模型"主要是描述此模型的結構，并且給出該模型的基本構件的定義。“能力成熟度模型的關鍵慣例"詳細描述了每個"關鍵過程方面"涉及的"關鍵慣例”。這里"關鍵過程方面"是指一組相關聯的活動；每個軟件能力成熟度等級包含若干個對該成熟度等級至關重要的過程方面，它們的實施對達到該成熟度等級的目標起到保證作用。這些過程域就稱為該成熟度等級的關鍵過程域，反之有非關鍵過程域是指對達到相應軟件成熟度等級的目標不起關鍵作用。歸納為：互相關聯的若干軟件實踐活動和有關基礎設施的一個集合。而"關鍵慣例"是指使關鍵過程方面得以有效實現和制度化的作用最大的基礎設施和活動,對關鍵過程的實踐起關鍵作用的方針、規程、措施、活動以及相關基礎設施的建立。關鍵實踐一般只描述"做什么"而不強制規定"如何做”。各個關鍵慣例按每個關鍵過程方面的5個"公共特性"（對執行該過程的承諾，執行該過程的能力，該過程中要執行的活動，對該過程執行情況的度量和分析，及證實所執行的活動符合該過程）歸類，逐一詳細描述。當作到了某個關鍵過程的的全部關鍵慣例就認為實現了該關鍵過程，實現了某成熟度級及其以低級所含的全部關鍵過程就認為達到到了了該級。圖一 CMM關系描述圖
上面提到了CMM把軟件開發組織的能力成熟度分為5個的等級。除了第1級外，其他每一級由幾個關鍵過程方面組成。每一個關鍵過程方面都由上述5種公共特性予以表征。CMM給每個關鍵過程了一些具體目標。按每個公共特性歸類的關鍵慣例是按該關鍵過程的具體目標選擇和確定的。如果恰當地處理了某個關鍵過程涉及的全部關鍵慣例，這個關鍵過程的各項目標就達到了，也就表明該關鍵過程實現了。這種成熟度分級的優點在于，這些級別明確而清楚地反映了過程改進活動的輕重緩急和先后順序。圖二 CMM等級模型圖對于CMM的作用歸納兩個主要方面: 科學地評價軟件開發單位的軟件能力成熟等級; 幫助軟件開發單位進行自檢，了解自己的強項和弱項，從而不斷完善和改進單位的軟件開發過程，確保軟件質量，提高軟件開發能效率。由于CMM并未提供有關實現CMM關鍵過程域所需的具體知識和技能，因此，美國 Carnegie Mellon 大學軟件工程研究所(CMU/SEI) 以W.S.Humphrey為首主持研究與開發了個體軟件過程PSP（Personal software process）和群組軟件過程TSP(Team Software Process)，形成CMM/PSP/TSP體系。PSP 個體軟件過程（Personal Software Process）是由美國Carnegie Mellon大學軟件工程研究所(CMU/SEI)的Watts s. Humphrey領導開發的，于1995年它的推出，在軟件工程界引起了極大的轟動，可以說是由定向軟件工程走向定量軟件工程的一個標志。PSP是一種可用于控制、管理和改進個人工作方式的自我改善過程，是一個包括軟件開發表格、指南和規程的結構化框架。 PSP為基于個體和小型群組軟件過程的優化提供了具體而有效的途徑，例如如何制訂計劃，如何控制質量，如何與其他人相互協作等等。在軟件設計階段， PSP的著眼點在于軟件缺陷的預防，其具體辦法是強化設計結束準則，而不是設計方法的選擇。PSP保障軟件產品質量的一個重要途徑是提高設計質量。PSP能夠說明個體軟件過程的原則；幫助軟件工程師作出準確的計劃；確定軟件工程師為改善產品質量要采取的步驟；建立度量個體軟件過程改善的基準；確定過程的改變對軟件工程師能力的影響。TSP 群組軟件過程TSP(Team Software Process)指導項目組中的成員如何有效地規劃和管理所面臨的項目開發任務，并且告訴管理人員如何指導軟件開發隊伍。始終以最佳狀態來完成工作。TSP實施集體管理與自己管理自己相結合的原則，最終目的在于指導開發人員如何在最少的時間內，以預定的費用生產出高質量的軟件產品，所采用的方法是對群組開發過程的定義、度量和改進。TSP致力于開發高質量的產品，建立、管理和授權項目小組，并且指導他們如何在滿足計劃費用的前提下，在承諾的期限范圍內，不斷生產并交付高質量的產品。圖三 CMM、PSP和TSP框架圖CMM是過程改善的第一步，它提供了評價組織的能力、識別優先改善需求和追蹤改善進展的管理方式。企業只有開始CMM改善后，才能接受需要規劃的事實，認識到質量的重要性，才能注重對員工經常進行培訓,合理分配項目人員,并且建立起有效的項目小組。然而，它實現的成功與否與組織內部有關人員的積極參加和創造性活動密不可分。PSP能夠指導軟件工程師如何保證自己的工作質量，估計和規劃自身的工作，度量和追蹤個人的表現，管理自身的軟件過程和產品質量。經過PSP學習和實踐的正規訓練，軟件工程師們能夠在他們參與的項目工作之中充分運用PSP，從而有助于CMM目標的實現。TSP結合了CMM的管理方法和PSP的工程技能，通過告訴軟件工程師如何將個體過程結合進小組軟件過程，并將后者與 組織進而整個管理系統相聯系；通過告訴管理層如何支持和授權項目小組，堅持高質量的工作，并且依據數據進行項 目的管理，向組織展示如何應用CMM的原則和PSP的技能去生產高質量的產品。總之，單純實施CMM，永遠不能真正做到能力成熟度的升級，只有將實施CMM與實施PSP和TSP有機地結合起來，才能發揮最大的效力。因此，軟件過程框架應該是CMM/PSP/TSP的有機集成。實施CMM的必要性軟件開發的風險之所以大，是由于軟件過程能力低，其中最關鍵的問題在于軟件開發組織不能很好地管理其軟件過程，從而使一些好的開發方法和技術起不到預期的作用。而且項目的成功也是通過工作組的杰出努力，所以僅僅建立在可得到特定人員上的成功不能為全組織的生產和質量的長期提高打下基礎，必須在建立有效的軟件如管理工程實踐和管理實踐的基礎設施方面，堅持不懈地努力，才能不斷改進，才能持續地成功。軟件質量是一模糊的、捉摸不定的概念。我們常常聽說：某某軟件好用, 某某軟件不好用；某某某軟件功能全、結構合理, 某某某軟件功能單一、操作困難……這些模模糊糊的語言不能算作是軟件質量評價，更不能算作是軟件質量科學的定量的評價。軟件質量，乃至于任何產品質量，都是一個很復雜的事物性質和行為。產品質量，包括軟件質量，是人們實踐產物的屬性和行為，是可以認識，可以科學地描述的。可以通過一些方法和人類活動，來改進質量。實施CMM是改進軟件質量的有效方法:控制軟件生產過程、提高軟件生產者組織性和軟件生產者個人能力的有效合理的方法軟件工程和很多研究領域及實際問題有關，主要相關領域和因素有：需求工程(RE：REQUIREMENTS ENGINEERING)。理論上，需求工程是應用已被證明的原理、技術和工具，幫助系統分析人員理解問題或描述產品的外在行為。軟件復用(SR：SOFTWARE REUSE)。定義為利用工程知識或方法，由一已存在的系統，來建造一新系統。這種技術，可改進軟件產品質量和生產率。還有軟件檢查、軟件計量、軟件可靠性、軟件可維修性、軟件工具評估和選擇等。CMM與ISO 9001的比較前面提到軟件過程的三個流派：CMU-SEI的CMM/PSP/TSP；ISO 9000質量標準體系；ISO/IEC 15504（SPICE）。這里主要比較一下CMM和ISO 9000質量標準體系中的9001的異同。ISO 9000族國際標準是在總結了英國的國家標準基礎之上產生的，因此，歐洲通過ISO 9000認證的企業數量最多，約占全世界的一半以上。受此影響，相當多的歐洲軟件企業選擇了ISO 9001認證。在基本原理方面，ISO 9001和CMM都十分關注軟件產品質量和過程改進。尤其是ISO 9000:2000版標準增加持續改進、質量目標的量化等方面的要求后，在基本思路上和CMM更加接近。它們之間的主要的差別是狀態上的差別。ISO 9001側重于"機構保證在設計、開發、生產、安裝及服務過程中與指定的要求一致"。而CMM側重于"支持一個機構評估及改進他們的系統的工程能力"及"指出機構選擇的模型的不足之處"。CMM和ISO 9001闡述了一個機構應該將他們如何做的觀點寫下來，然后去做，最后檢查他們是否按照他們說的去做了。ISO 9001所關注意的是確保合格的人員所作的過程記錄是有效的，并且開發生產出滿足質量要求的產品。CMM在能力層次概念之間切開，作一件事情是第1級層次的概念，寫下所做的事情是第2級層次的概念，有一定組織水平的寫作是第三級層次的概念，等等。SE-CMM同樣衡量管理能力，如第四級層次，連續處理問題的能力，第五級層次的概念。這兩個標準都涉及了產品的開發和產品的質量，但CMM在產品的設計和開發的細節作了較多要求，而ISO 9001在產品的開發過程和產品本身的質量細節作了較多要求。CMM 建立了系統工程能力模型第三級模型，而ISO 9001則無此內容。CMM沒有對產品存儲設備的測試作出要求，而ISO 9001則有此要求。ISO 9001要求與質量管理體系相關的所有工作人員的經過授權并簽字的質量記錄（見條款4.1.2.1）。它還要求足夠的資源，包括提供必要的員工培訓等（見條款4.1.2.2）。第四節要求對機構的每個過程都要有記錄。這是SE-CMM第2級的基本要求。從ISO 9001的角度來看SE-CMM，至少SE-CMM的第二級及以上級別才能和ISO 9001相提并論。由以上可以得出ISO 9001和CMM既有區別又相互聯系，兩者不可簡單的互相替代;取得ISO 9001認證并不意味著完全滿足CMM某個等級的要求 ;取得CMM第2級(或第3級)不能籠統的談可以滿足ISO 9001的要求 。 CMM在中國的現狀中國生產力促進協會、北航SEI、中科院研究SEI等科研機構已于近幾年在北京、上海、廣州和深圳等地先后舉辦過多次報告會和研討會，組織過課程學習和應用實驗，開展了軟件過程方面的研究與開發工作，并發表了多篇的研究成果和學術論文，在軟件質量保障平臺支撐環境也取得了一定的成果。近兩年來，CMM在我國獲得了各界越來越多關注，業界有過多次關于CMM的討論，2000年6月國務院頒發的《鼓勵軟件產業和集成電路產業發展的若干政策》對中國軟件企業申請CMM認證給予了積極的支持和推動作用,第17條規定"對軟件出口型企業CMM認證費用予以適當支持。"2000年中國村電腦節上還有CMM專題論壇，吸引了眾多業內人士。鼎新、東大阿爾派、聯想、方正、金蝶、用友、浪潮、創智、華為、東大阿爾派等大型集團或企業等都從1997—2000年起批企業都在進行研究、實驗或實施預評估。其中鼎新公司從1997年著手進行CMM認證工作。1999年7月通過第三方認證機構的CMM2認證。東大阿爾派公司于2000年10月通過第三方認證機構的CMM2認證。2001年1月，聯想軟件經過英國路透集團的嚴格評估，順利通過CMM2認證。2001年6月26日，沈陽東軟軟件股份有限公司（原沈陽東大阿爾派軟件股份有限公司）正式通過了CMM3級認證，成為中國首家通過CMM3級的軟件企業。總體上講，國內對軟件過程理論的討論與實踐正在展開，目標是使軟件的質量管理和控制達到國際先進水平，中國的軟件產業獲得可持續發展的能力。專家分析，在未來兩三年內，國內軟件業勢必將出現實施CMM的高潮。從這一趨勢看，中國的軟件企業已經開始走上標準化、規范化、國際化的發展道路，中國軟件業已經面臨一個整體突破的時代。但是我們應該看到目前國內對軟件管理工程存在的最大問題是認識不足。管理實際上是一把手工程，需要高層管理人員的足夠重視。而且軟件過程的重大修改也必須由高層管理部門啟動，這是軟件過程改善能否進行到底的關鍵。此外，軟件過程的改善還有待于全體有關人員的積極參與。除了要認識到過程改善工作是一把手工程這個關鍵因素外，還應認識到軟件過程成熟度的升級本身就是一個過程，且有一個生命周期。過程改善工作需要循序漸進，不能一蹴而就，需要持續改善，不能停滯不前；需要聯系實際，不能照本宣科；需要適應變革，不能凝固不變。一個有效的途徑是自頂向下的課程培訓，即從高層主管依次普及到下面的工程師。CMM實施的思考上面重點介紹了CMM,但是提醒注意的是，并不是實施了CMM，軟件項目的質量就能有所保障。CMM是一種資質認證，它可以證明一個軟件企業對整個軟件開發過程的控制能力。按照CMM的思想進行管理與通過CMM認證并不能劃等號。CMM認證并不僅僅是在評估軟件企業的生產能力，整個評估過程同時還在幫助企業完善已經按照CMM建立的科學工作流程，發現企業在軟件質量、生產進度以及成本控制等方面可能存在的問題，并且及時予以糾正。認證的過程是糾正企業偏差的過程，一定不能把CMM認證當作一種考試、一種文憑，而是要看成一項有利于企業今后發展的投資，借此來改變中國軟件業長久以來形成的積弊。實施CMM對軟件企業的發展起著至關重要的作用，CMM過程本身就是對軟件企業發展歷程的一個完整而準確的描述，企業通過實施CMM，可以更好地規范軟件生產和管理流程，使企業組織規范化。企業通過CMM不是為了滿足其他公司的要求，而是為了讓企業更好地發展，為企業進一步擴大規模打下堅實的基礎。如果企業只是為了獲得一紙證書而通過CMM，那么就已經本末倒置了，對企業的長久發展反而有害。試想如果企業的態度不夠端正，即使通過CMM認證，企業又怎么能夠保證它在以后的操作過程當中繼續堅持CMM規范呢？CMM只是一個讓企業更好發展的規范，不應該成為企業炒作自己的工具，企業需要的是優化自己的管理、提高產品的質量，而非一張CMM證書。CMM不是萬能的，它的成功與否，與一個組織內部有關人員的積極參與和創造性活動是密不可分的，而且CMM并未提供實現有關子過程域所需要的具體知識和技能。在國內要想取得過程改進成功，必須做好以下的幾點:軟件過程改進必須有高級主管的支持與委托，并積極地管理過程改進的進展;中層管理的積極支持;責任分明，過程改進小組的威望高;基層的支持與參與極端重要;利用定量的可觀察數據，盡快使過程改進成果可見，從而激勵參與者的興趣;將實施CMM與實施PSP和TSP有機地結合起來;為企業的商業利益服務，并要求同時相符的企業文化變革。應該看到,過程改善工作必然具有一切過程所具有的固有特征，即需要循序漸進，不能一蹴而就需要持續改善，不能停滯不前；需要聯系實際，不能照本宣讀需要適應變革，不能凝固不變。將CMM／PSP／TSP引人軟件企業最有效的途徑首先要對單位主管和主要開發人員進行系統的培訓。另外一個有效的途徑是自頂向下的課程培訓，即從高層主管依次普及到下面的工程師。培訓包括最基本的軟件工程和CMM培訓知識；專業領域知識等方面的培訓；軟件過程方面的培訓。不過強調一點，我們必須根據自身的實際制定可行的方案。不深入研究就照搬別的企業的模式是很難起到提高軟件產品質量水平的真正目的的。CMM模型劃分為5個級別，共計18個關鍵過程域，52個目標，300多個關鍵實踐。每一個CMM等級的評估周期（從準備到完成）約需12-30個月。此期間應抽調企業中有管理能力、組織能力和軟件開發能力的骨干人員,成立專門的CMM實施領導小組或專門的機構。同時設立軟件工程過程組、軟件工程組、系統工程組、系統測試組、需求管理組、軟件項目計劃組、軟件項目跟蹤與監督、軟件配置管理組、軟件質量保證組、培訓組。各個小組完成自己的任務同時協調其他小組的工作。然后制定和完善軟件過程, 按照CMM規范評估這個過程。CMM正式評估由CMU/SEI授權的主任評估師領導一個評審小組進行，評估過程包括員工培訓、問卷調查和統計、文檔審查、數據分析、與企業的高層領導討論和撰寫評估報告等，評估結束時由主任評估師簽字生效。此后最關鍵的就是根據評估結果改進軟件過程,使CMM評估對于軟件過程改進所應具有的作用得到最好的發揮。現在國內軟件產業的發展可以說已經具有一定規模了，但除了北大方正、東大阿爾派、用友等大企業外，做軟件工程項目更多的是一些規模在數十人左右的中小企業, 目前處于CMM的初級階段，沒有基礎和經驗。也許有人會問，像這樣一些人力物力資源匱乏的企業，如何進行軟件開發項目的管理呢？我建議這些中小企業可以以CMM為框架，先從PSP做起，然后在些基礎上逐漸過渡到TSP，以保證CMM/PSP/TSP確實在企業中生根開花。總之，我們必須從軟件過程、過程工程的角度來看待CMM的發展，從經濟學的觀點來分析這個過程的價值。我相信在實施CMM/PSP/TSP的過程中，只要堅持改善軟件工程的管理，并在實踐中注意總結適合自身的經驗，一定能取得很好的效果。
===================================================================================
一、CMM的產生軟件能力成熟度（the Capability Maturity Model for Software, 簡稱CMM）是美國軟件工程研究所（Software Engineering Institute, 縮寫為SEI）首先提出的。SEI是美國國防部設立，SEI的任務是提供一系列技術管理方法來提高軟件工程水平，保證美國防部能夠通過成本、進度和質量的預估和改進獲得并且支持其精準的軟件系統。任務包含四個目標：1、 通過對實踐和技術（或為未充分應用的技術和實踐）的定義、評估和成熟預測，以加快導入和推廣高成效的軟件工程的實踐和技術。2、 在軟件工程和技術轉型方面維護一個長期有效的資格認證工作3、 使工業和政府組織通過自己的直接努力實現軟件工程的有規劃的改進4、 促進軟件工程持續不斷的應用所采納的優秀標準二、CMM的管理思想基礎CMM的基本思想是基于已有60多年歷史的產品質量原理。休哈特（Walter Shewart）在30年代發表了統計質量控制原理，戴明（W.Edwards）和朱蘭（Joseph Juran）的關于質量的著作又進一步發展和論證了該原理。實際上，將質量原理變為成熟度框架的思想是克勞斯比(Philip Crosby)，他在著作《質量免費》（Quality is Free）中首先提出，他的質量管理成熟度網絡描繪了采用質量實踐時的5個進化階段，而該框架后來又由IBM的拉迪斯（Rom Radice）和他的同事們在漢弗萊(Watts Humphrey)指導下進一步改進以適應軟件過程的需要。1986年，漢弗萊將此成熟框架帶到了SEI并增加了成熟度等級的概念，將這些原理應用于軟件開發，發展成為軟件過程成熟度框架，形成了當前軟件產業界正在使用的框架。漢弗萊的成熟度框架早期版本發表在1987年的SEI技術報告。該報告中還發表了初步的成熟度提問單，這個提問單作為工具給軟件組織提供了軟件過程評估的一種方法。1987年又進一步研制了軟件過程評估和軟件能力評價兩種方法，以便估計軟件過程成熟度。自1990年以來，SEI基于幾年來將框架運用到軟件過程改進方面的經驗，進一步擴展和精煉了該模型，目前，軟件能力成熟度模型2.0版已經修訂問世。然而企業最終目的是把自己的產品或服務提供給顧客，讓顧客滿意，盡力使這個過程不斷反復、且能夠不斷壯大，才能源源不斷創造利潤。所以，我們應該明白：第一、企業的使命是為顧客創造價值，努力地為顧客創造價值就是企業的成功之路。第二、能為顧客帶來價值的是企業的各種作業。而一個作業是由一系列能為顧客創造價值的活動組成的，構成一個作業的各種活動是由員工完成的，但是各種活動本身對顧客來說毫無意義，顧客關心的是這些活動的結果。也就是說，只有各種活動組合在一起構成一個完整的作業才能創造價值，顧客并不關心怎樣組合這些活動。因此，出于對顧客利益的考慮，作業的構造要努力做到“復雜其中，簡便其表”。第三、企業事業的成功來自優異的作業績效。盡管優質的產品或服務、杰出的人才和優秀的戰略對企業來說必不可少，但并不能保證企業的成功。因為，產品或服務、人才和戰略只有存在于能為顧客帶來價值的各種作業之中，才能對企業事業的成功有所貢獻。也就是說，只有通過作業把這些高質量的要素結合在一起，它們才具有實質性的意義。這種高績效的作業，則是企業優勢的集中體現。第四，優異的作業績效是通過科學的作業設計、適當的人員配置和良好的工作環境的共同作用達到的。因為，科學的作業設計能夠靈敏地對顧客的需求變化做出反應，它是作業本身有效性的根本保證；適當的人員組合能獲得集體智慧和戰斗力；良好的環境則能激發員工的工作熱情，促使員工它們不斷超越自己。對于軟件企業來說，它的成功來自優異的軟件開發過程，要想取得優異的軟件開發過程，就得按照以上四點要求進行管理和改進軟件企業過程。所以，可以認為CMM模型其實質就是一種新興的管理思想和方法，它蘊涵的是當今歐美乃至日本日趨盛行的“Continuos Improvement”管理哲學，現已滲透到各行各業的具體管理中去，是現代企業管理發展方向之一。連續改進（Continuos Improvement）的含義是：以超前的視野預見過程執行實施中可能的引起要素（包括特定的設計、作業方式及其與之相聯系的成本要素），籍先期規范制約的各種手段作出最大可能效果創出（最優成本/效益比）的預期調整，并以相應的效果計量和評估方法相配合，以確保實際過程以預期的低成本運作的先導式控制。我個人認為，著眼于軟件過程的CMM是連續改進的表現，而著重于軟件過程評估和軟件能力評價與改進相呼應，CMM模型中蘊涵的思想就是防止項目失敗的思想，也就是我們所說的連續改進的思想所在。三、連續改進（Continuos Improvement）雖然軟件工程師和管理人員通常詳盡地知道他們的問題所在，但是哪些改進是當前最重要的問題，他們可能彼此有不同的意見。而且缺乏一個組織的改進策略，管理人員和專業人員之間在首先采取什么改進措施上很難達成一致意見。經過深入的調查和研究，終于認識到軟件過程的改進不可能一朝一夕就能成功，需要持續不斷的進行軟件過程改進，軟件過程改進是在一系列微小、不斷發展的，而不是革命性的創新步驟中實現的。這正是連續改進思想的體現。當同類事物之間存在著微少差異時就會產生變異性。當一個過程或系統的資源存在著變異性時，相應的系統輸出也會有變異性。例如，當原材料或所制造的部件質量有偏差時，最終產品的質量也會發生變化。正所謂“進廢品，出廢品”。所以，研究連續改進，就需要關注系統所使用資源的變異性及所采用生產過程的變異性。任何系統都會表現出變異性。一定程度的變異是自然的，這種變異并不一定意味著系統不穩定或質量低劣或成本偏高，但是太多的或反常的變異則表明系統不穩定——其輸出的質量是不一致或不可預知的。這對于任何一個公司都是一種危險的情況，因為不穩定的質量將會影響顧客的滿意度。要保持客戶的滿意，必須改進產品質量、降低產品的成本、增強產品的營銷水平。要改進產品質量、降低產品的成本、增強產品的營銷水平，必須減少系統的變異。研究連續改進過程就是明確系統中的變異在哪里發生，為什么發生。一旦了解到引起變異的原因，就可以尋找一些方法去減少這種變異，以穩定企業運行過程，使企業得到改進。1、連續改進循環如果只解決一個小問題，只稍微改變一下具體過程，而后就置之不理直到問題出現，這是遠遠不夠的。正如“連續改進”這一名稱所暗示的：必須不斷進行。連續改進意味著時常對系統進行分析，一絲不茍地收集數據并加以研究，一絲不茍地測試偏差，每位公司員工都把連續改進作為其工作的一部分看待。持續改進應該視為一個循環。參與持續改進的各團隊需要長期連續地在這個循環中活動。也就是說，當一個問題看來已經解決之時，而員工的參與并沒有終結，仍然有另一個改進要實施，有另一個系統要分析，或有另一個創意要專題研究。2、強化過程改進面臨的下一步是使實施的變革成為系統的一個標準部分。團隊應該著手出一份簡單的報告，說明測試過程中的新規則以及所做改進對系統的影響。報告要列出變革后的優點，包括新系統實施和維護的計劃，以確定新系統達到新的績效水平。如果團隊的建議被管理者接受并付諸實施，以后，團隊需要按照計劃監視系統。你將能指出存在的問題，發現在什么地方工作人員又回到了舊的工作方式。這一步的目標是使新過程變成標準的操作規則。切記，在實施變革過程中，認真地培訓和支持是必要的。3、繼續連續改進循環當你確信新的過程得到強化并成為工作過程的一個自然組成部分時，就要準備開始下一個持續改進循環。你將要從分析系統開始，因為上一循環的變革可能已經改變。4、總結企業的管理者一定明白企業的生存取決于你比其它企業給顧客提供更好服務的能力。通過更快地響應顧客的需要，提供更高質量的服務就可以達到生存的目標。一旦你和你的員工進入持續改進循環，你將擁有更好的信息、更新鮮的創意、更好的過程和質量控制，你將達到夢想的“意想不到的高水平的績效”。
============================================================================
CMM是指“能力成熟度模型”，其英文全稱為Capability Maturity Model for Software，英文縮寫為SW-CMM，簡稱CMM。它是對于軟件組織在定義、實施、度量、控制和改善其軟件過程的實踐中各個發展階段的描述。CMM的核心是把軟件開發視為一個過程，并根據這一原則對軟件開發和維護進行過程監控和研究，以使其更加科學化、標準化、使企業能夠更好地實現商業目標。 CMM是是一種用于評價軟件承包能力并幫助其改善軟件質量的方法，側重于軟件開發過程的管理及工程能力的提高與評估。CMM分為五個等級：一級為初始級，二級為可重復級，三級為已定義級，四級為已管理級，五級為優化級。 CMM是由美國卡內基梅隆大學軟件工程研究所1987年研制成功的，是目前國際上最流行最實用的軟件生產過程標準和軟件企業成熟度等級認證標準。目前，我國已有軟件企業通過了CMM標準認證 。 SW-CMM(Capability Maturity Model For Software 軟件生產能力成熟度模型,以下簡稱"CMM"),是87年由美國卡內基梅隆大學軟件工程研究所（CMU SEI）研究出的一種一種用于評價軟件承包商能力并幫助改善軟件質量的方法，其目的是幫助軟件企業對軟件工程過程進行管理和改進，增強開發與改進能力，從而能按時地、不超預算地開發出高質量的軟件。 其所依據的想法是：只要集中精力持續努力去建立有效的軟件工程過程的基礎結構，不斷進行管理的實踐和過程的改進，就可以克服軟件生產中的困難。CMM它是目前國際上最流行、最實用的一種軟件生產過程標準，已經得到了眾多國家以及國際軟件產業界的認可，成為當今企業從事規模軟件生產不可缺少的一項內容。CMM目前通用流行的版本是1．1（Version1．1）。《按照軟件工程研究所（SEI）的原來計劃，CMM的改進版版本2．0（V2．0）是要在1997年的11月完成的。但是，美國國防部辦公室要求軟件工程研究所（SEI）延遲發放公布CMM版本2．0，直至他們完成另一個更為緊迫的項目-CMMI。 CMMI(Capability Maturity Model Integration能力成熟度模型集成)，是美國國防部的一個設想。他們希望把所有現存的與將被發展出來的各種能力成熟度模型，集成到一個框架中去。這個框架用于解決兩個問題：第一，軟件獲取辦法的改革；第二，從集成產品與過程發展的角度出發,建立一種包含健全的系統開發原則的過程改進。CMM為軟件企業的過程能力提供了一個階梯式的改進框架，它基于過去所有軟件工程過程改進的成果，吸取了以往軟件工程的經驗教訓，提供了一個基于過程改進的框架；它指明了一個軟件組織在軟件開發方面需要管理哪些主要工作、這些工作之間的關系、以及以怎樣的先后次序，一步一步的做好這些工作而使軟件組織走向成熟。一、CMM的誕生 信息時代，軟件質量的重要性越來越為人們所認識。軟件是產品、是裝備、是工具，其質量使得顧客滿意，是產品市場開拓、事業得以發展的關鍵。而軟件工程領域在1992年至1997年取得了前所未有的進展,其成果超過軟件工程領域過去15年來的成就總和。 軟件管理工程引起廣泛注意源于20世紀70年代中期。當時美國國防部曾立題專門研究軟件項目做不好的原因，發現70%的項目是因為管理不善而引起，而并不是因為技術實力不夠，進而得出一個結論，即管理是影響軟件研發項目全局的因素，而技術只影響局部。到了20世紀90年代中期，軟件管理工程不善的問題仍然存在，大約只有10%的項目能夠在預定的費用和進度下交付。軟件項目失敗的主要原因有：需求定義不明確；缺乏一個好的軟件開發過程；沒有一個統一領導的產品研發小組；子合同管理不嚴格；沒有經常注意改善軟件過程；對軟件構架很不重視；軟件界面定義不善且缺乏合適的控制；軟件升級暴露了硬件的缺點；關心創新而不關心費用和風險；軍用標準太少且不夠完善等等。在關系到軟件項目成功與否的眾多因素中，軟件度量、工作量估計、項目規劃、進展控制、需求變化和風險管理等都是與工程管理直接相關的因素。由此可見，軟件管理工程的意義至關重要。 軟件管理工程和其它工程管理相比有其特殊性。首先，軟件是知識產品，進度和質量都難以度量，生產效率也難以保證。其次，軟件系統復雜程度也是超乎想象的。因為軟件復雜和難以度量，軟件管理工程的發展還很不成熟。 軟件管理工程的發展，在經歷了從70年代開始以結構化分析與設計、結構化評審、結構化程序設計以及結構化測試為特征的結構化生產時代，到90年代中期，以CMM模型的成熟模型和日益為市場接受為標志，已經進入以過程成熟模型CMM、個體軟件過程PSP和群組軟件過程TSP為標志的以過程為中心的時代，而軟件發展第三個時代，及軟件工業化生產時代，從90年代中期軟件過程技術的成熟和面向對象技術、構件技術的發展為基礎，已經漸露端倪，估計到2005年，可以實現真正的軟件工業化生產，這個趨勢應該引起軟件企業界和有關部門的高度重視，及早采取措施，跟上世界軟件發展的腳步。軟件生產轉向以改善軟件過程為中心，是世界各國軟件產業或遲或早都要走的道路。 軟件過程改善是當前軟件管理工程的核心問題。50多年來計算事業的發展使人們認識到要高效率、高質量和低成本地開發軟件，必須改善軟件生產過程。軟件管理工程走過了一條從70年代開始以結構化分析與設計、結構化評審、結構化程序設計以及結構化測試到90年代中期以過程成熟模型CMM、個體軟件過程PSP和群組軟件過程TSP為標志的以過程為中心向著軟件過程技術的成熟和面向對象技術、構件技術的發展為基礎的真正軟件工業化生產的道路。軟件生產轉向以改善軟件過程為中心，是世界各國軟件產業或遲或早都要走的道路。軟件工業已經或正在經歷著"軟件過程的成熟化"，并向"軟件的工業化"漸進過渡。規范的軟件過程是軟件工業化的必要條件。 軟件過程研究的是如何將人員、技術和工具等組織起來，通過有效的管理手段，提高軟件生產的效率，保證軟件產品的質量。由此誕生了軟件過程的三個流派：CMU-SEI的CMM/PSP/TSP；ISO 9000質量標準體系；ISO/IEC 15504（SPICE）。 CMM/PSP/TSP即軟件能力成熟度模型/ 個體軟件過程/群組軟件過程，是1987年美國 Carnegie Mellon 大學軟件工程研究所(CMU/SEI)以W.S.Humphrey為首的研究組發表的研究成果"承制方軟件工程能力的評估方法"；SO 9000質量標準體系是在70年代由歐洲首先采用的，其后在美國和世界其他地區也迅速地發展起來。目前，歐洲聯合會積極促進軟件質量的制度化，提出了如下ISO9000軟件標準系列：ISO9001、ISO9000-3、ISO9004-2、ISO9004-4、ISO9002；ISO/IEC 15504（SPICE）是1991年國際標準化組織采納了一項動議，開展調查研究，按照CMU-SEI的基本思路，產生的技術報告ISO/IEC 15504–信息技術軟件過程評估 目前，學術界和工業界公認美國 Carnegie Mellon 大學軟件工程研究所(CMU/SEI) 以W.S.Humphrey為首主持研究與開發的軟件能力成熟度模型CMM是當前最好的軟件過程，已成為業界事實上的軟件過程的工業標準。二、CMM的發展 1987年美國 Carnegie Mellon 大學軟件工程研究所(CMU/SEI)以W.S.Humphrey為首的研究組發表了CMM/PSP/TSP 技術，為軟件管理工程開辟了一條新的途經。 CMM框架用5個不斷進化的層次來評定軟件生產的歷史與現狀：其中初始層是混沌的過程，可重復層是經過訓練的軟件過程，定義層是標準一致的軟件過程，管理層是可預測的軟件過程，優化層是能持續改善的軟件過程。任何單位所實施的軟件過程，都可能在某一方面比較成熟，在另一方面不夠成熟，但總體上必然屬于這5個層次中的某一個層次。而在某個層次內部，也有成熟程度的區別。在CMM框架的不同層次中，需要解決帶有不同層次特征的軟件過程問題。因此，一個軟件開發單位首先需要了解自己正處于哪一個層次，然后才能夠對癥下藥地針對該層次的特殊要求解決相關問題，這樣才能收到事半功倍的軟件過程改善效果。任何軟件開發單位在致力于軟件過程改善時，只能由所處的層次向緊鄰的上一層次進化。而且在由某一成熟層次向上一更成熟層次進化時，在原有層次中的那些已經具備的能力還必須得到保持與發揚。 軟件產品質量在很大程度上取決于構筑軟件時所使用的軟件開發和維護過程的質量。軟件過程是人員密集和設計密集的作業過程：若缺乏有素訓練，就難以建立起支持實現成功是軟件過程的基礎，改進工作亦將難以取得成效。CMM描述的這個框架正是勾列出從無定規的混沌過程向訓練有素的成熟過程演進的途徑。 CMM包括兩部分"軟件能力成熟度模型"和"能力成熟度模型的關鍵慣例"。“軟件能力成熟度模型"主要是描述此模型的結構，并且給出該模型的基本構件的定義。“能力成熟度模型的關鍵慣例"詳細描述了每個"關鍵過程方面"涉及的"關鍵慣例”。這里"關鍵過程方面"是指一組相關聯的活動；每個軟件能力成熟度等級包含若干個對該成熟度等級至關重要的過程方面，它們的實施對達到該成熟度等級的目標起到保證作用。這些過程域就稱為該成熟度等級的關鍵過程域，反之有非關鍵過程域是指對達到相應軟件成熟度等級的目標不起關鍵作用。歸納為：互相關聯的若干軟件實踐活動和有關基礎設施的一個集合。而"關鍵慣例"是指使關鍵過程方面得以有效實現和制度化的作用最大的基礎設施和活動,對關鍵過程的實踐起關鍵作用的方針、規程、措施、活動以及相關基礎設施的建立。關鍵實踐一般只描述"做什么"而不強制規定"如何做”。各個關鍵慣例按每個關鍵過程方面的5個"公共特性"（對執行該過程的承諾，執行該過程的能力，該過程中要執行的活動，對該過程執行情況的度量和分析，及證實所執行的活動符合該過程）歸類，逐一詳細描述。當作到了某個關鍵過程的的全部關鍵慣例就認為實現了該關鍵過程，實現了某成熟度級及其以低級所含的全部關鍵過程就認為達到到了了該級。
上面提到了CMM把軟件開發組織的能力成熟度分為5個的等級。除了第1級外，其他每一級由幾個關鍵過程方面組成。每一個關鍵過程方面都由上述5種公共特性予以表征。CMM給每個關鍵過程了一些具體目標。按每個公共特性歸類的關鍵慣例是按該關鍵過程的具體目標選擇和確定的。如果恰當地處理了某個關鍵過程涉及的全部關鍵慣例，這個關鍵過程的各項目標就達到了，也就表明該關鍵過程實現了。這種成熟度分級的優點在于，這些級別明確而清楚地反映了過程改進活動的輕重緩急和先后順序。能力等級特點關鍵過程第一級 基本級軟件過程是混亂無序的,對過程幾乎沒有定義,成功依靠的是個人的才能和經驗,管理方式屬于反應式 第二級 重復級建立了基本的項目管理來跟蹤進度.費用和功能特征,制定了必要的項目管理,能夠利用以前類似的項目應用取得成功需求管理,項目計劃,項目跟蹤和監控,軟件子合同管理,軟件配置管理,軟件質量保障第三級 確定級已經將軟件管理和過程文檔化,標準化,同時綜合成該組織的標準軟件過程,所有的軟件開發都使用該標準軟件過程組織過程定義,組織過程焦點,培訓大綱,軟機集成管理,軟件產品工程,組織協調,專家審評第四級 管理級收集軟件過程和產品質量的詳細度量,對軟件過程和產品質量有定量的理解和控制定量的軟件過程管理和產品質量管理第五級 優化級軟件過程的量化反饋和新的思想和技術促進過程的不斷改進缺陷預防,過程變更管理和技術變更管理 對于CMM的作用歸納兩個主要方面: 科學地評價軟件開發單位的軟件能力成熟等級; 幫助軟件開發單位進行自檢，了解自己的強項和弱項，從而不斷完善和改進單位的軟件開發過程，確保軟件質量，提高軟件開發能效率。 由于CMM并未提供有關實現CMM關鍵過程域所需的具體知識和技能，因此，美國 Carnegie Mellon 大學軟件工程研究所(CMU/SEI) 以W.S.Humphrey為首主持研究與開發了個體軟件過程PSP（Personal software process）和群組軟件過程TSP(Team Software Process)，形成CMM/PSP/TSP體系。 PSP 個體軟件過程（Personal Software Process）是由美國Carnegie Mellon大學軟件工程研究所(CMU/SEI)的Watts s. Humphrey領導開發的，于1995年它的推出，在軟件工程界引起了極大的轟動，可以說是由定向軟件工程走向定量軟件工程的一個標志。PSP是一種可用于控制、管理和改進個人工作方式的自我改善過程，是一個包括軟件開發表格、指南和規程的結構化框架。 PSP為基于個體和小型群組軟件過程的優化提供了具體而有效的途徑，例如如何制訂計劃，如何控制質量，如何與其他人相互協作等等。在軟件設計階段， PSP的著眼點在于軟件缺陷的預防，其具體辦法是強化設計結束準則，而不是設計方法的選擇。PSP保障軟件產品質量的一個重要途徑是提高設計質量。 PSP能夠說明個體軟件過程的原則；幫助軟件工程師作出準確的計劃；確定軟件工程師為改善產品質量要采取的步驟；建立度量個體軟件過程改善的基準；確定過程的改變對軟件工程師能力的影響。 TSP 群組軟件過程TSP(Team Software Process)指導項目組中的成員如何有效地規劃和管理所面臨的項目開發任務，并且告訴管理人員如何指導軟件開發隊伍。始終以最佳狀態來完成工作。TSP實施集體管理與自己管理自己相結合的原則，最終目的在于指導開發人員如何在最少的時間內，以預定的費用生產出高質量的軟件產品，所采用的方法是對群組開發過程的定義、度量和改進。 TSP致力于開發高質量的產品，建立、管理和授權項目小組，并且指導他們如何在滿足計劃費用的前提下，在承諾的期限范圍內，不斷生產并交付高質量的產品。 CMM是過程改善的第一步，它提供了評價組織的能力、識別優先改善需求和追蹤改善進展的管理方式。企業只有開始CMM改善后，才能接受需要規劃的事實，認識到質量的重要性，才能注重對員工經常進行培訓,合理分配項目人員,并且建立起有效的項目小組。然而，它實現的成功與否與組織內部有關人員的積極參加和創造性活動密不可分。 PSP能夠指導軟件工程師如何保證自己的工作質量，估計和規劃自身的工作，度量和追蹤個人的表現，管理自身的軟件過程和產品質量。經過PSP學習和實踐的正規訓練，軟件工程師們能夠在他們參與的項目工作之中充分運用PSP，從而有助于CMM目標的實現。 TSP結合了CMM的管理方法和PSP的工程技能，通過告訴軟件工程師如何將個體過程結合進小組軟件過程，并將后者與 組織進而整個管理系統相聯系；通過告訴管理層如何支持和授權項目小組，堅持高質量的工作，并且依據數據進行項 目的管理，向組織展示如何應用CMM的原則和PSP的技能去生產高質量的產品。 總之，單純實施CMM，永遠不能真正做到能力成熟度的升級，只有將實施CMM與實施PSP和TSP有機地結合起來，才能發揮最大的效力。因此，軟件過程框架應該是CMM/PSP/TSP的有機集成。三、實施CMM的必要性 軟件開發的風險之所以大，是由于軟件過程能力低，其中最關鍵的問題在于軟件開發組織不能很好地管理其軟件過程，從而使一些好的開發方法和技術起不到預期的作用。而且項目的成功也是通過工作組的杰出努力，所以僅僅建立在可得到特定人員上的成功不能為全組織的生產和質量的長期提高打下基礎，必須在建立有效的軟件如管理工程實踐和管理實踐的基礎設施方面，堅持不懈地努力，才能不斷改進，才能持續地成功。 軟件質量是一模糊的、捉摸不定的概念。我們常常聽說：某某軟件好用, 某某軟件不好用；某某某軟件功能全、結構合理, 某某某軟件功能單一、操作困難……這些模模糊糊的語言不能算作是軟件質量評價，更不能算作是軟件質量科學的定量的評價。軟件質量，乃至于任何產品質量，都是一個很復雜的事物性質和行為。產品質量，包括軟件質量，是人們實踐產物的屬性和行為，是可以認識，可以科學地描述的。可以通過一些方法和人類活動，來改進質量。 實施CMM是改進軟件質量的有效方法:控制軟件生產過程、提高軟件生產者組織性和軟件生產者個人能力的有效合理的方法軟件工程和很多研究領域及實際問題有關，主要相關領域和因素有：需求工程(RE：REQUIREMENTS ENGINEERING)。理論上，需求工程是應用已被證明的原理、技術和工具，幫助系統分析人員理解問題或描述產品的外在行為。軟件復用(SR：SOFTWARE REUSE)。定義為利用工程知識或方法，由一已存在的系統，來建造一新系統。這種技術，可改進軟件產品質量和生產率。還有軟件檢查、軟件計量、軟件可靠性、軟件可維修性、軟件工具評估和選擇等。四、CMM在中國的現狀 中國生產力促進協會、北航SEI、中科院研究SEI等科研機構已于近幾年在北京、上海、廣州和深圳等地先后舉辦過多次報告會和研討會，組織過課程學習和應用實驗，開展了軟件過程方面的研究與開發工作，并發表了多篇的研究成果和學術論文，在軟件質量保障平臺支撐環境也取得了一定的成果。 近兩年來，CMM在我國獲得了各界越來越多關注，業界有過多次關于CMM的討論，2000年6月國務院頒發的《鼓勵軟件產業和集成電路產業發展的若干政策》對中國軟件企業申請CMM認證給予了積極的支持和推動作用,第17條規定"對軟件出口型企業CMM認證費用予以適當支持。"2000年中國村電腦節上還有CMM專題論壇，吸引了眾多業內人士。鼎新、東大阿爾派、聯想、方正、金蝶、用友、浪潮、創智、華為、東大阿爾派等大型集團或企業等都從1997—2000年起批企業都在進行研究、實驗或實施預評估。其中鼎新公司從1997年著手進行CMM認證工作。1999年7月通過第三方認證機構的CMM2認證。東大阿爾派公司于2000年10月通過第三方認證機構的CMM2認證。2001年1月，聯想軟件經過英國路透集團的嚴格評估，順利通過CMM2認證。 2001 年 6 月 26 日 ，沈陽東軟軟件股份有限公司（原沈陽東大阿爾派軟件股份有限公司）正式通過了CMM3級認證，成為中國首家通過CMM3級的軟件企業。 總體上講，國內對軟件過程理論的討論與實踐正在展開，目標是使軟件的質量管理和控制達到國際先進水平，中國的軟件產業獲得可持續發展的能力。專家分析，在未來兩三年內，國內軟件業勢必將出現實施CMM的高潮。從這一趨勢看，中國的軟件企業已經開始走上標準化、規范化、國際化的發展道路，中國軟件業已經面臨一個整體突破的時代。 但是我們應該看到目前國內對軟件管理工程存在的最大問題是認識不足。管理實際上是一把手工程，需要高層管理人員的足夠重視。而且軟件過程的重大修改也必須由高層管理部門啟動，這是軟件過程改善能否進行到底的關鍵。此外，軟件過程的改善還有待于全體有關人員的積極參與。 除了要認識到過程改善工作是一把手工程這個關鍵因素外，還應認識到軟件過程成熟度的升級本身就是一個過程，且有一個生命周期。過程改善工作需要循序漸進，不能一蹴而就，需要持續改善，不能停滯不前；需要聯系實際，不能照本宣科；需要適應變革，不能凝固不變。一個有效的途徑是自頂向下的課程培訓，即從高層主管依次普及到下面的工程師。五、CMM****體系結構 一個企業軟件能力類似于一個人在一個特定領域的能力，是逐步獲得和增長的。如果一個人在其領域的發展過程中能得到一個很好的指南，那么他或她就會不斷達到一個個設定的目標，并變得成熟起來，否則可能會盲目發展，離自己的目標越來越遠，甚至南轅北轍。一個企業的軟件能力發展也同樣需要一個良好的指南，SW-CMM正是這樣一個指南，它以幾十年產品質量概念和軟件工業的經驗及教訓為基礎，為企業軟件能力不斷走向成熟提供了有效的步驟和框架。 框架 SW-CMM為軟件企業的過程能力提供了一個階梯式的進化框架，階梯共有五級。第一級實際上是一個起點，任何準備按CMM體系進化的企業都自然處于這個起點上，并通過這個起點向第二級邁進。除第一級外，每一級都設定了一組目標，如果達到了這組目標，則表明達到了這個成熟級別，可以向下一個級別邁進。CMM體系不主張跨越級別的進化，因為從第二級起，每一個低的級別實現均是高的級別實現的基礎。1.初始級
初始級的軟件過程是未加定義的隨意過程，項目的執行是隨意甚至是混亂的。也許，有些企業制定了一些軟件工程規范，但若這些規范未能覆蓋基本的關鍵過程要求，且執行沒有政策、資源等方面的保證時，那么它仍然被視為初始級。2.可重復級
根據多年的經驗和教訓，人們總結出軟件開發的首要問題不是技術問題而是管理問題。因此，第二級的焦點集中在軟件管理過程上。一個可管理的過程則是一個可重復的過程，一個可重復的過程則能逐漸進化和成熟。第二級的管理過程包括了需求管理、項目管理、質量管理、配置管理和子合同管理五個方面。其中項目管理分為計劃過程和跟蹤與監控過程兩個過程。通過實施這些過程，從管理角度可以看到一個按計劃執行的且階段可控的軟件開發過程。3.定義級
在第二級僅定義了管理的基本過程，而沒有定義執行的步驟標準。在第三級則要求制定企業范圍的工程化標準，而且無論是管理還是工程開發都需要一套文檔化的標準，并將這些標準集成到企業軟件開發標準過程中去。所有開發的項目需根據這個標準過程，剪裁出與項目適宜的過程，并執行這些過程。過程的剪裁不是隨意的，在使用前需經過企業有關人員的批準。4.管理級
第四級的管理是量化的管理。所有過程需建立相應的度量方式，所有產品的質量(包括工作產品和提交給用戶的產品)需有明確的度量指標。這些度量應是詳盡的，且可用于理解和控制軟件過程和產品。量化控制將使軟件開發真正變成為一種工業生產活動。5.優化級
第五級的目標是達到一個持續改善的境界。所謂持續改善是指可根據過程執行的反饋信息來改善下一步的執行過程，即優化執行步驟。如果一個企業達到了這一級，那么表明該企業能夠根據實際的項目性質、技術等因素，不斷調整軟件生產過程以求達到最佳。 結構 除第一級外，SW-CMM的每一級是按完全相同的結構構成的。每一級包含了實現這一級目標的若干關鍵過程域(KPA)，每個KPA進一步包含若干關鍵實施活動(KP)，無論哪個KPA，它們的實施活動都統一按五個公共屬性進行組織，即每一個KPA都包含五類KP。1.目標
每一個KPA都確定了一組目標。若這組目標在每一個項目都能實現，則說明企業滿足了該KPA的要求。若滿足了一個級別的所有KPA要求，則表明達到了這個級別所要求的能力。2.實施保證
實施保證是企業為了建立和實施相應KPA所必須采取的活動，這些活動主要包括制定企業范圍的政策和高層管理的責任。3.實施能力
實施能力是企業實施KPA的前提條件。企業必須采取措施，在滿足了這些條件后，才有可能執行KPA的執行活動。實施能力一般包括資源保證、人員培訓等內容。4.執行活動
執行過程描述了執行KPA所需求的必要角色和步驟。在五個公共屬性中，執行活動是唯一與項目執行相關的屬性，其余四個屬性則涉及企業CMM能力基礎設施的建立。執行活動一般包括計劃、執行的任務、任務執行的跟蹤等。5.度量分析
度量分析描述了過程的度量和度量分析要求。典型的度量和度量分析的要求是確定執行活動的狀態和執行活動的有效性。6.實施驗證
實施驗證是驗證執行活動是否與所建立的過程一致。實施驗證涉及到管理方面的評審和審計以及質量保證活動。
在實施CMM時，可以根據企業軟件過程存在問題的不同程度確定實現KPA的次序，然后按所確定次序逐步建立、實施相應過程。在執行某一個KPA時，對其目標組也可采用逐步滿足的方式。過程進化和逐步走向成熟是CMM體系的宗旨。六、CMM實施的思考 上面重點介紹了CMM,但是提醒注意的是，并不是實施了CMM，軟件項目的質量就能有所保障。CMM是一種資質認證，它可以證明一個軟件企業對整個軟件開發過程的控制能力。按照CMM的思想進行管理與通過CMM認證并不能劃等號。CMM認證并不僅僅是在評估軟件企業的生產能力，整個評估過程同時還在幫助企業完善已經按照CMM建立的科學工作流程，發現企業在軟件質量、生產進度以及成本控制等方面可能存在的問題，并且及時予以糾正。認證的過程是糾正企業偏差的過程，一定不能把CMM認證當作一種考試、一種文憑，而是要看成一項有利于企業今后發展的投資，借此來改變中國軟件業長久以來形成的積弊。 實施CMM對軟件企業的發展起著至關重要的作用，CMM過程本身就是對軟件企業發展歷程的一個完整而準確的描述，企業通過實施CMM，可以更好地規范軟件生產和管理流程，使企業組織規范化。企業通過CMM不是為了滿足其他公司的要求，而是為了讓企業更好地發展，為企業進一步擴大規模打下堅實的基礎。如果企業只是為了獲得一紙證書而通過CMM，那么就已經本末倒置了，對企業的長久發展反而有害。試想如果企業的態度不夠端正，即使通過CMM認證，企業又怎么能夠保證它在以后的操作過程當中繼續堅持CMM規范呢？CMM只是一個讓企業更好發展的規范，不應該成為企業炒作自己的工具，企業需要的是優化自己的管理、提高產品的質量，而非一張CMM證書。 CMM不是萬能的，它的成功與否，與一個組織內部有關人員的積極參與和創造性活動是密不可分的，而且CMM并未提供實現有關子過程域所需要的具體知識和技能。在國內要想取得過程改進成功，必須做好以下的幾點:軟件過程改進必須有高級主管的支持與委托，并積極地管理過程改進的進展;中層管理的積極支持;責任分明，過程改進小組的威望高;基層的支持與參與極端重要;利用定量的可觀察數據，盡快使過程改進成果可見，從而激勵參與者的興趣;將實施CMM與實施PSP和TSP有機地結合起來;為企業的商業利益服務，并要求同時相符的企業文化變革。 應該看到,過程改善工作必然具有一切過程所具有的固有特征，即需要循序漸進，不能一蹴而就需要持續改善，不能停滯不前；需要聯系實際，不能照本宣讀需要適應變革，不能凝固不變。將CMM／PSP／TSP引人軟件企業最有效的途徑首先要對單位主管和主要開發人員進行系統的培訓。另外一個有效的途徑是自頂向下的課程培訓，即從高層主管依次普及到下面的工程師。培訓包括最基本的軟件工程和CMM培訓知識；專業領域知識等方面的培訓；軟件過程方面的培訓。不過強調一點，我們必須根據自身的實際制定可行的方案。不深入研究就照搬別的企業的模式是很難起到提高軟件產品質量水平的真正目的的。 CMM模型劃分為5個級別，共計18個關鍵過程域，52個目標，300多個關鍵實踐。每一個CMM等級的評估周期（從準備到完成）約需12-30個月。此期間應抽調企業中有管理能力、組織能力和軟件開發能力的骨干人員,成立專門的CMM實施領導小組或專門的機構。同時設立軟件工程過程組、軟件工程組、系統工程組、系統測試組、需求管理組、軟件項目計劃組、軟件項目跟蹤與監督、軟件配置管理組、軟件質量保證組、培訓組。各個小組完成自己的任務同時協調其他小組的工作。然后制定和完善軟件過程, 按照CMM規范評估這個過程。CMM正式評估由CMU/SEI授權的主任評估師領導一個評審小組進行，評估過程包括員工培訓、問卷調查和統計、文檔審查、數據分析、與企業的高層領導討論和撰寫評估報告等，評估結束時由主任評估師簽字生效。此后最關鍵的就是根據評估結果改進軟件過程,使CMM評估對于軟件過程改進所應具有的作用得到最好的發揮。 現在國內軟件產業的發展可以說已經具有一定規模了，但除了北大方正、東大阿爾派、用友等大企業外，做軟件工程項目更多的是一些規模在數十人左右的中小企業, 目前處于CMM的初級階段，沒有基礎和經驗。也許有人會問，像這樣一些人力物力資源匱乏的企業，如何進行軟件開發項目的管理呢？我建議這些中小企業可以以CMM為框架，先從PSP做起，然后在些基礎上逐漸過渡到TSP，以保證CMM/PSP/TSP確實在企業中生根開花。總之，我們必須從軟件過程、過程工程的角度來看待CMM的發展，從經濟學的觀點來分析這個過程的價值。我相信在實施CMM/PSP/TSP的過程中，只要堅持改善軟件工程的管理，并在實踐中注意總結適合自身的經驗，一定能取得很好的效果。
============================================================================
隨著我國計算機軟件產業的形成和發展，軟件產品質量保證這一課題逐漸受到各個軟件開發組織和政府有關管理機構的重視。一些規模較大的軟件開發組織各自在本單位運用質量管理理論指導開展了軟件產品質量保證活動；有些軟件開發公司引入了國際通行的質量管理體系質量保證模式——ISO9001（或ISO9002）。鑒于軟件產品本身及其開發和生產的特殊性，不少軟件開發組織在實施ISO9001的同時亦不同程度地感到ISO9001（加上ISO9000-3）與他們的實際活動不是那么相適應。于是，一種專門針對軟件開發組織的軟件質量保證模型悄然進入我國一些軟件開發組織和有關研究單位的研討日程，這就是CMM。
近幾年來，我國一些單位有組織地或自發地開展了對CMM的研究，有的還在本單位內進行了嘗試性的CMM實施。特別是自1998年以來，我國計算機軟件業界對CMM的研究熱迅速升溫；“采用ISO9001還是CMM?”的問題也悄然出現。無論是實施ISO9001，還是尋求運用其他軟件產品質量保證渠道，這些對保證軟件產品質量的熱情正是我國軟件產業正在走向成熟的標志。恰當地選擇軟件開發組織的產品質量保證途徑不僅將有助于各個軟件開發組織提高軟件產品開發和生產能力，亦將為加快我國軟件產業的成熟作出貢獻。鑒于CMM在其“原產國”實際應用中的有效表現，引起包括我國在內的許多國家軟件業界的興趣，國際標準化組織（ISO）也順應各國的興趣而開展了與CMM密切相關的標準課題研究。本文將對CMM作簡要介紹，并且把CMM與ISO9001加以比較，最后談談CMM的應用問題。
一CMM簡介
我國目前談及的CMM是指“軟件能力成熟度模型”，其英文全稱為Capability Maturity Model for Software （英文縮寫名是SM-CMM），更確切地說，是指“軟件能力成熟度模型.1.1版”和“能力成熟度模型的關鍵慣例.1.1版”（Capability Maturity Model for software,Version1.1和Key Practices of the Capability Maturity Model,Version1.1簡稱CMM1.1版}。CMM是美國卡內基—梅隆大學軟件工程研究所（以下簡稱SEI）的研究成果；CMM1.1版發表于1993年。SEI是美國國防部出資于1984年設立。從1986年開始，SEI針對軟件組織改善其軟件過程，特別是美國國防部對軟件承包商的能力評價問題，研究“過程成熟度框架”。1987年9月，SEI發表了關于過程成熟度框架的簡要說明和成熟度調查問卷。以這一過程成熟度框架為藍本，在美國聯邦政府促進下，從1987年到1991年在美國的一些大公司的軟件組織進行了軟件過程能力成熟度模型的評估實踐。根據這4年的實踐經驗，特別是從美國政府和工業界反饋的關于軟件過程評估的信息，SEI在原過程成熟度框架的基礎上開發出了“軟件能力成熟度模型（CMM）0.0版”。在CMM0.0版發表后的兩年里，先后產生了30多稿草案，于1993年2月發表了“軟件能力成熟度模型1.1版”和“能力成熟度模型的關鍵慣例1.1版”（統稱SM-CMM1.1版，有時干脆簡稱為CMM）。
大家都知道，軟件產品的質量在很大程度上取決于構筑軟件時所使用的軟件開發和維護過程的質量。軟件過程是人員密集和設計密集的作業過程；若缺乏有素的訓練，就難以建立起支持實現成功改進軟件過程的基礎，改進工作亦將難以取得成效。CMM描述的這個框架正是勾列出從無定規的混沌過程向訓練有素的成熟過程演進的途徑。
迄今為止，CMM既不是政府標準也不是行業協會標準，而是美國卡內基—梅隆大學軟件工程研究所（SEI）發表的一份技術報告；不過，它在美國已成為事實上的標準。鑒于CMM的巨大應用前景，SEI已在美國注冊了CMM, Capability Maturity Model和Capability Maturity Modeling的專利和商標。與此同時，圍繞以CMM為基礎的軟件過程評估和軟件能力評價建立了從審核員培訓到提供評估和評價的一整套服務體系。
SEI給CMM下的定義是：對于軟件組織在定義，實現，度量，控制和改善其軟件過程的進程中各個發展階段的描述。這個模型便于確定軟件組織的現有過程能力和查找出軟件質量及過程改進方面的最關鍵的問題，從而為選擇過程改進戰略提供指南。
如前所述CMM1.1版包括兩部分：“軟件能力成熟度模型”和“能力成熟度模型的關鍵慣例”。“軟件能力成熟度模型”主要是描述這種模型的結構，并且給出該模型的基本構件的定義；為便于讀者理解，還進一步對成熟度模型及其構件做了大量解釋。“能力成熟度模型的關鍵慣例”除了重復敘述能力成熟度模型結構及其構件外，以大量篇幅詳細描述了每個“關鍵過程方面”涉及的“關鍵慣例”。“關鍵過程方面”是指：一組相關聯的活動；通過執行這些活動可以實現既定的過程能力。所謂“關鍵慣例”是指：使關鍵過程方面得以有效實現和制度化的作用最大的基礎設施和活動。各個關鍵慣例按每個關鍵過程方面的5個“公共特性”（對執行該過程的承諾，執行該過程的能力，該過程中要執行的活動，對該過程執行情況的度量和分析，及證實所執行的活動符合該過程）歸類，逐一詳細描述。按CMM的規定，作到了某個關鍵過程的全部關鍵慣例就認為實現了該關鍵過程，實現了某成熟度級及其以低各級所含的全部關鍵過程就認為達到了該級。
CMM把軟件開發組織的能力成熟度分為5個可能的等級。除了第1級外，其他每一級由幾個關鍵過程方面組成。每一個關鍵過程方面都由上述5種公共特性予以表征。CMM給每個關鍵過程規定了一些具體目標。按每個公共特性歸類的關鍵慣例是按該關鍵過程的具體目標選擇和確定的。如果恰當地處理了某個關鍵過程涉及的全部關鍵慣例，這個關鍵過程的各項目標就達到了，也就表明該關鍵過程實現了。這種分級的思路在于把一個組織執行軟件過程的成熟程度分成循序漸進的幾個階段，這與軟件組織提高自身能力的實際推進過程相吻合。這種成熟度分級的優點在于，這些級別明確而清楚地反映了過程改進活動的輕重緩急和先后順序。這一點很重要，因為大多數軟件組織只能在某一段時間里集中開展少數幾項過程改進活動。
CMM總體結構圖示說明參見圖1。
圖1能力成熟度模型的結構
CMM的開發者們結合他們的軟件產業環境和軟件產品質量保證的需要，在CMM1.1版中把具有最高能力成熟度的組織設定為處于這樣一種情況下的組織：整個組織都持續致力于過程改進；這個組織具備足夠的手段用于事先發現過程的長處及短處和防止發生缺陷；它擁有豐富的軟件過程成功經驗的數據并且可用于對新技術進行“費/效”分析和提出對本組織軟件過程的更改建議；它能發現那些可能發掘出最佳軟件工程慣例的合理化建議并使之在整個組織里實現轉化。這種能力成熟度被定義為CMM的第5級，稱之為“（持續）優化級”。
另一方面，現實的軟件業里尚有不少組織還不具備穩定的環境用于軟件開發和維護,它們缺乏健全的管理慣例，其軟件過程能力無法預計；它們的軟件過程是一片混沌；并且它們的軟件過程總是隨著軟件開發工作的推進而處于變更和調整之中。這種情況被CMM定義為第1級能力成熟度，稱之為“初始級”。
第2級為可重復級。在處于可重復級的組織里，顧客的需求和本組織的工作產物是受控的并且建立起了基本的項目管理慣例。藉以產生軟件產品的一系列過程有如一連串“黑盒子”；盡管管理者可能不知道在“黑盒子”里具體發生了什么，但是，他能掌握過程的產物和那些確認過程是否正常的校驗點，從而在發生問題時作出反應。這一級有6個關鍵過程方面，共含121個關鍵慣例：
——需求管理（12，這是關鍵慣例數，以下同）
——軟件項目策劃（25）
——軟件項目追蹤和監督（24）
——軟件分包方管理（22）
——軟件質量保證（17）
——軟件配置管理。（21）
第3級是（明確）定義級。在這一級，對于在整個組織里用于軟件開發和維護的標準過程以文件形式被固定下來。針對各個基本過程建立起文件化的“標準軟件過程”，這是第3級能力成熟度的突出特點。這些標準軟件過程（包括工程過程和管理過程）被集成為一個相關的整體；這些標準軟件過程有助于軟件經理和技術人員更有效地履行他們的職責。實踐表明，對軟件過程加以標準化的過程，也就是發掘高效軟件工程慣例的過程。而標準軟件過程的建立和實施則為本組織軟件項目的實施提供了公共的工程環境。較普遍的看法是，只有當達到了第3級能力成熟度時，才表明這個組織的軟件能力“成熟”了。因為，在到達這一級后，表明上述的“黑盒子”被打開了。在第2級的基礎上，第3級包括7個關鍵過程方面，共含108個關鍵慣例：
——組織過程定焦（16）
——組織過程定義（11）
——培訓（16）
——集成式軟件管理（19）
——軟件產品工程（20）
——組間協調（17）
——對等審查。（9）
第4級是定量管理級。處于這一級的組織已經能夠為軟件產品和軟件過程設定定量的質量目標，并且能對跨項目的重要軟件過程活動的效率和質量予以度量；可以利用本組織的軟件過程數據庫匯集各項目軟件過程產生的數據并加以分析。處于第4級是，該組織的各個軟件過程是用各種確切定義并且一致地尺度來說明的；這些尺度是用以評價項目的軟件過程和產物的定量基礎。在第2，3級的基礎上，第4級包括兩個關鍵過程方面，共含32個關鍵慣例：
——定量過程管理（19）
——軟件質量管理。（13）
如前所述，第5級叫持續優化級。在前幾級的基礎上，第5級包括3個關鍵過程方面，共含59個關鍵慣例：
——缺陷預防（18）
——技術變更管理（22）
——過程變更管理。（19）
CMM1.1版總計18個關鍵過程方面，320個關鍵慣例。
這18個關鍵過程方面可以劃分為3大類：管理類，組織類和工程類。其中有的關鍵過程方面是跨類的，見圖2。
軟件組織的成熟度等級只能逐級遞進，不可能越級。成熟度級別的提高也就意味著實現的關鍵慣例大幅度增加；其間關系見圖3。
圖2關鍵過程方面分類
圖3成熟度等級遞進與關鍵慣例含量
二CMM與ISO
CMM和ISO9001都涉及質量管理和過程管理，并且都受到類似的厲害關系驅動，兩者之間有著相似之處。因此，往往產生這樣的問題：
——符合ISO9001的軟件組織達到CMM的哪一級？
——達到CMM的第2或3級的軟件組織是否符合ISO9001？
——一個組織打算推進質量管理或改進軟件過程時是采用ISO9001還是采用CMM？
ISO9001被認為是適用于所有各類專業領域的一種質量保證模式；但是，對于軟件組織來說，盡管加上了ISO9000-3作為實施指南，ISO9001似乎仍然不夠貼切，留給審核員作解釋的回旋余地相當大。于是就軟件能力評定而言，按ISO9001進行認證時，不確定性很大；換言之，同是通過了ISO9001認證的組織，其間的軟件能力可能有很大差別。
CMM是專門針對軟件組織設計的一種描述軟件過程能力的模型。CMM研制的主要目的有二：一是用于幫助事先確定承包商的軟件能力；二是用于軟件組織的過程改進。考慮到按ISO9001對軟件組織進行認證審核時存在的較大不確定性，在設計CMM時，注意了盡量縮小審核員解釋的回旋余地，因此，不僅對每個關鍵過程方面給出了明確的目標和體現這些目標的各個關鍵慣例，而且對各個關鍵慣例都給出了明確的定義和詳細的說明，以期按CMM進行評估時能有較大的一致性和可靠性。結果，CMM成了一個“龐然大物”——長達500余頁。
如上所述，CMM與ISO9001的設計思路不同，并且一個是“專用”，一個是“泛用”，因此，盡管兩者都由于涉及質量管理和過程而有著相似之處，但也存在很大差別。下面依次按ISO9001的20個要素對CMM作一些簡單比較。
1.管理職責
ISO9001要求確定質量方針并且加以文件化，理解，執行和維護；要求確定所有員工在規定，達到和監控質量方面的責任和權限；要求確定自有的驗證資源，進行培訓和給予財政支持。由一名指定的經理保證質量計劃的實現和維護。
在CMM中，管理層在質量方針和驗證活動方面的責任主要反映在“軟件質量保證”中，在“軟件項目策劃”和“軟件項目跟蹤和監督”中只是指出履行所有項目角色時的責任。
高級管理層和項目管理層的軟件項目管理責任是在確認實現中反映。一般，領導問題反映在公共特性的“承諾”方面，組織和資源問題反映在公共特性的“能力”方面。雖然CMM在第4級的“軟件質量管理”中也描述了質量方針，不過，第4級的質量方針是定量的。此外，ISO9001中關于度量在質量管理體系中的作用也有點含糊，ISO9001第4.20條要求確定質量目標并且形成文件，而沒有要求量化。
2.質量體系
ISO9001要求建立文件化的質量體系，包括程序和指導書。ISO9000-3以質量體系作為整個軟件生存周期的綜合過程。
CMM主要在“軟件質量保證”中涉及質量體系活動。各項程序分布在“關鍵過程方面”的各項“要執行的活動”中。
軟件項目將用到的特定程序和標準在“軟件項目策劃”中描述的軟件開發計劃中規定。通過“軟件質量保證”和執行“確認實現”中的審核活動來確保符合這些標準和程序。
“軟件產品工程”要求確定各項軟件工程任務，加以綜合并且統一執行；這一點與ISO9000-3關于此條的指南對應。
CMM第3級“組織過程定義”這一關鍵過程方面描述了一組組織一級的軟件過程財富，包括標準，程序和過程說明。運用“組織過程定義”肯定有助于達到此條要求，但是在ISO9001的這一條里，標準和程序可能直接在項目級處理。ISO9001討論供方的質量體系，而不討論組織支持與項目實現的關系；CMM作了討論。另一方面，在ISO9000-3中，關于質量策劃的指南有兩節：4.2.3節討論跨項目的質量策劃；5.5節討論具體開發工作中的質量策劃。
3.合同評審
ISO9001要求評審合同，以確定各項要求是否充分規定，是否與標書一致，是否能實現。
在CMM中，對顧客軟件需求的審查在“需求管理”中敘述。軟件組織（供方）確保分配給軟件的（系統）要求形成文件并且予以審查，確保那些可能引起誤解的或含混的要求得以澄清。因為CMM僅限于軟件方面，所以顧客需求作為一個整體歸于“需求管理”這個關鍵過程方面里。
CMM中的“軟件項目策劃”描述了為簽定合同而要提出的軟件開發計劃建議和工作陳述，并且要求軟件工程組和高級管理層加以審查。
CMM還就軟件組織通過分包獲得軟件的情況作了規定（在“軟件分包方管理”中敘述）。合同可以是與某個外部顧客的，也可以是與分包方的；雖然這一點在ISO9001的這一節中沒有明確規定，但也可以意識到。
4.設計控制
ISO9001要求建立控制和證實設計的程序。這包括策劃設計活動，標識輸入和輸出，證實設計和控制設計變更。ISO9000-3用了幾條來詳細描述了這一條：購方需求規范（5.3），開發策劃（5.4），質量策劃（5.5），設計和實現（5.6），測試和驗證（5.7）和配置管理（6.1）。
CMM中，需求分析，設計，編碼和測試等生存周期活動在“軟件產品工程”中描述。這些活動的策劃是在“軟件項目策劃”中描述。“軟件項目跟蹤和監督”描述這些活動的控制，而“軟件配置管理”描述的是這些活動產生的軟件工作產物的配置管理。
ISO9001要求進行諸如記錄并且保存設計審查和鑒定測試之類的設計控制手段。ISO9000-3指出，供方應該進行審查，以保證需求得到滿足和設計方法得到正確執行。雖然對設計控制手段有要求，但是使用了“shoud”（最好）之類短語則為具體控制手段的使用賦予了靈活性。相反，CMM要求專門的質量控制機制：對等審查。“對等審查”這一關鍵過程方面支持生存周期從需求分析到測試的各個過程。
“軟件質量管理”中描述的定量的設計過程方面更為正規，但ISO9001不一定要求這種正規程度。
5.文件控制
ISO9001要求對文件的分發和修改予以控制。
在CMM中，反映文件控制的配置管理慣例在“軟件配置管理”中描述。在CMM中，可以置于配置管理下的具體程序，標準和其他文件分布在各個關鍵過程方面的各種“要執行的活動”慣例中。為運行和維護質量體系所要求的文件在“軟件產品工程”的“活動8”中作了具體規定。
6.采購
ISO9001要求采購的產品符合它們的規定要求。這包括評估潛在的分包方和驗證采購的產品。
在CMM中，這個要求反映在“軟件分包管理”中。分包方的評估在“活動2”中描述，分包軟件的驗收測試在“活動12”中處理。
7.顧客提供的產品
ISO9001要求任何由顧客提供的物資都要經過驗證和予以維護。ISO9000-3是在包含軟件產品（包括商業現貨軟件）的條文（6.8）中討論這一條。
在“綜合軟件管理”中的“活動6.3”是CMM中描述外購軟件使用的唯一慣例。它把標示現貨軟件或可再用軟件的條款作為項目策劃的一部分。現貨軟件和可再用軟件的綜合是CMM中的薄弱方面。這一條在ISO9000-3中專門做了擴展，而CMM考慮得不夠。雖然不夠，不過，“軟件分包管理”的“活動12”中分包軟件的驗收測試慣例可用之于任何所包含的軟件產品，算是一點彌補。
8.產品標識和溯源
ISO9001要求在產品生產，交付和安裝的所有階段都要給產品加標識并且可追溯。
CMM覆蓋這一條的主要是“軟件配置管理”，不過“軟件產品工程”的“活動10”指出了對軟件工作產物之間的一致性和可追溯性的特定要求。
9.過程控制
ISO9001要求確定各項生產過程并進行策劃。這包括在受控條件下按照文件化的作業指導書進行生產。對于未能充分驗證的專用過程要持續監控。ISO9000-3有幾條包含了此條內容：設計和實現（5.6）；規則，慣例和約定（6.5）；以及工具和技術（6.6）。
CMM中規定軟件生產過程的程序分布在各個關鍵過程方面的各項“要執行的活動”慣例中。將用到的具體慣例和標準，按“軟件項目策劃”的“活動7”所述，在軟件開發計劃中規定。軟件生產過程的定義和集成在“軟件產品工程”中描述。過程保證在“軟件質量保證”的“活動4”中描述（產品保證在“活動5”中規定）。
在CMM中，“定量過程管理”涉及到定量控制，并且要求給出統計過程控制的例證，而按ISO9001的審核中一般不要求滿足這一條。
值得注意的是，ISO9000-3第6.6條指出，供方在必要時應改善這些工具和技術，以便把新技術引入本組織（與CMM中“技術變更管理”討論的內容相近）。
10.檢驗和測試
ISO9001要求對進貨在使用前檢驗或驗證，要求進行過程中檢驗和測試。在成品予以放行前執行最終檢驗和測試。檢驗和測試記錄予以保存。
CMM是在“軟件產品工程”中的第5，6和7項活動里描述測試問題。關于軟件方面的過程中檢驗是在“對等審查”中處理。
11.檢驗，測量和測試設備
ISO9001要求對用于證明符合性的設備于以控制，校準和維護。在使用測試硬件和測試軟件時，要在使用之前檢查并且按預定的時間間隔復檢。ISO9000-3在以下幾條中對這一條作了澄清：測試和確認（5.7）；規則，慣例和約定（6.5）；以及工具和技術（6.6）。
在CMM中，此條是在“軟件產品工程”的測試慣例中做了一般性處理。在“能力1.2”（描述支持測試的工具）中特別提到了測試軟件。
12.檢驗和測試狀態
ISO9001要求，隨著軟件項經由各個處理步驟推進時，其檢驗和測試狀態得以維護。
在CMM中，用“軟件產品工程”的測試慣例和“軟件配置管理”中的“活動5”（問題報告）和“活動8”（配置狀態）處理這一條的要求。
13.不合格品的控制
9000-3把這個概念映射到以下幾條：設計和實現（5.6）；測試和確認（5.7）；復制，交貨和安裝（5.9）以及配置管理（6.1）。
在CMM中，設計，實現，測試和確認是在“軟件產品工程”中處理。在“軟件配置管理”中，“活動8”涉及軟件配置項的狀態，包括已知有缺陷（但尚未定位）的軟件項的狀態。ISO9001第4.15條所述的安裝在CMM中未涉及。
在制造業里，這一條很重要，因為有時有必要使用未符合全部要求的構件建造產品。在做這種決策后，必須小心控制不合格品。
與之類似，在軟件業，有時系統可能使用的工具或復用軟件沒有滿足全部相關的標準。例如，如果已在以前的應用中證明FORTRAN碼的價值，在Ada程序中復用FORTRAN碼也許有良好“費/效”比。然而，這個碼可能給Ada系統帶來很大風險，必須充分掌握這種風險。
CMM中沒有專門談及不合格品。ISO9000-3中，有關不合格品的要求基本上隱含在軟件生存周期的許多有關過程中：設計和實施（5.6）；測試和確認（5.7）；復制，交付和安裝（5.9）和配置管理(6.1)。
14.糾正措施
ISO9001要求找出造成不合格品的原因，消除造成不合格品的潛在原因，根據糾正結果改變程序。
這一段的文字隱含著CMM中“缺陷預防”里的許多慣例。這一段中討論的糾正措施往往是顧客投訴引發的。因此往往是由軟件工程組查找現場缺陷，分析其發生原因，并且采取糾正措施。這種情況常常發生在對現場軟件的修補或升級過程中。按CMM的思路，是在報告問題之后對基線工作產品的維護加以控制。問題報告是在CMM的“軟件配置管理”中描述。
從審核角度看，糾正措施是要處理審核中發現的不符合項，無論是內部還是外部審核中發現的。這一點是在CMM的“軟件質量保證”中處理。
在ISO9001運用于軟件領域時，這是個有爭論的問題。有的認為軟件領域的缺陷預防過程與制造業環境的類似，有的認為只要求涉及用戶問題報告即可。在CMM中，此點亦尚無定論——究竟“缺陷預防”中要描述多少過程中因果分析和缺陷預防才能滿足ISO9001中這一段的要求，還有爭論。
15.搬運，儲存，包裝和交付
ISO9001要求建立并維護關于搬運，儲存，包裝和交付的程序。
ISO9000-3中與這段對應的是接受（5.8）和復制，交付和安裝（5.9）。
CMM中沒有覆蓋復制，交付和安裝。在“軟件產品工程”的”活動7”涉及驗收測試，而“軟件配置管理”的“活動7”描述了軟件產品的創建和釋放。不過CMM中沒有描述交付和安裝產品。
從CMM的修訂版情況看，可能將在“軟件產品工程”這個關鍵過程方面中增加一個關于軟件產品交付和安裝的慣例。
16.質量記錄
ISO9001要求收集，維護和處置質量記錄。
在CMM中，對需要維護的質量記錄加以定義的慣例是以“要執行的活動”的形式分布在各個關鍵過程方面。在“軟件產品工程”中的測試和對等審查慣例，特別是“活動9”中關于缺陷數據的收集和分析反映了這一段的內容。問題報告是在“軟件配置管理”的“活動5”中描述，而對等審查數據的收集是“對等審查”的“活動3”中描述。
17.內部質量審核
ISO9001要求策劃并執行質量審核。審核結果要通知管理層，發現的缺陷要予以糾正。
在CMM中，質量審核過程由“軟件質量保證”描述；具體的審核要求反映在“確認實現”這一公共特性的審核慣例中。
18.培訓
ISO9001要求確定并提供必要的培訓，因為所選擇的任務可能要求有相應資格的人員。培訓記錄要維護。
CMM中，是在“執行能力”這一公共特性的培訓和定向慣例中反映具體的培訓需要。
一般性的培訓設施是在“培訓大綱”（包括“活動6”中的維護培訓記錄）中描述。
19.服務
ISO9001要求按規定執行服務活動。ISO9000-3把這一段的要求作為維護（5.10）來處理。
雖然CMM的意圖是既適用于軟件開發也適用于維護環境，但CMM中的慣例并不直接處理屬于維護環境的獨特特性。維護被鑲嵌在CMM的各個慣例中，并且必須按開發或維護的前因后果作相應解釋。
因此，在CMM中，維護不是一個獨立的過程。從CMM的修改情況看，有可能在措辭上更明確地涉及維護環境，以便清楚地表達CMM在維護項目方面的應用。
20.統計技術
ISO9001指出，適用時，應確定適當的統計技術并且用于驗證過程能力和產品特性的可接受性。ISO9000-3簡單地在度量（6.4）中表述了這一段的特性。
CMM中描述度量的慣例分布在各個關鍵過程方面。產品度量一般是包含在各個“要執行的活動”慣例中，而過程度量是在“度量和分析”這一公共特性中描述。
“組織過程定義”的“活動5”描述了建立組織級數據庫，以便本組織用于收集過程和產品數據。這種數據庫是在組織一級維護。在CMM中，項目級的統計數據是在第2級里各個項目管理關鍵過程方面描述。
如果說這一條指的是統計過程控制，那么，在CMM中是通過“定量過程管理”和“軟件質量管理”予以滿足。不過，要注意是在“適用時”使用統計技術。
由上述的大致比較可以看出，盡管ISO9001中的一些內容在CMM中沒有覆蓋，CMM中的一些內容在ISO9001沒有涉及，但是，ISO9001與CMM之間有著很強的相關性。不過，細節上的差別很大：ISO9001第4章大約有5頁；（ISO9000-3的第5，6和7節大約11頁；）而CMM長達500多頁。不過，這兩分文件間的最大差別在于，CMM強調的是持續的過程改進；而ISO9001涉及的是質量體系的最低可接受標準。此外，CMM專門針對軟件領域，而ISO9001適用范圍很廣（硬件，軟件，流程性材料和服務）。
CMM和ISO9001這兩者的最大相似之點在于它們都是“說你要做的，做你要說的”。ISO9001的基本要求在于，在整個質量控制活動中每個重要過程都應該文件化并且每個交付件都接受質量檢查。
ISO9001要求編制出指導書或指南之類文件，用以說明應該做什么或應該如何做。在CMM中，同樣強調過程和慣例要“文件化”。
CMM強調要求記錄信息以便供該過程以后使用或供改善該過程用。這相當于ISO9001中的質量記錄——證明所要求的質量是否達到和質量體系是否有效運行。
若僅從上述ISO9001和CMM中的基本概念比較看，似乎可以得出結論：獲得ISO9001認證的組織應該處于CMM的第3或第4級。但是，有資料表明，有的組織雖然尚處于第1級，也取得了ISO9001認證。原因之一是由于ISO9001的高度概括性而造成的對文件解釋的多樣性。
那么，一個符合ISO9001的軟件組織，如果它完全沒有實現ISO9001中未包含的管理或工程慣例，它處于CMM的哪個成熟度等級？這是一個極端情況，不過它給出了一個符合ISO9001的組織的成熟度的下邊界。圖4示出這個組織的關鍵過程方面的輪廓。圖中，黑影表示ISO9001或ISO9000-3直接談到的關鍵慣例；灰影表示按照對ISO9001的解釋可能涉及的關鍵慣例；無陰影表示ISO9001未涉及的關鍵慣例。因此，就各個關鍵過程方面而言，根據不同解釋，可以得出部分滿足或全部滿足或不滿足的結論。陰影條的長度表示ISO9001或ISO9000-3中涉及到的關鍵慣例的百分比。
圖4一個符合ISO9001的組織的關鍵過程輪廓
由此輪廓可看出，處于CMM第1級的組織的確有可能通過符合ISO9001的認證；同時，該組織又可能具有很強的第2級的過程實力和明顯的第3級的過程實力。在美國的有關業界里普遍認為，一個得到并且維持ISO9001認證的組織，它應該是接近第2級的。
如果一個組織遵循ISO9001的精神，而不止于符合其書面條款，這個組織有可能接近或超過了第2級。一個軟件組織可以得到ISO9001證書但卻處于第1級，這種情況反映出ISO9001的精神與字面的差別。
是否可以把處于第3級的組織看成是符合ISO9001的呢？不行，因為即使這個組織處于第3級，它還需要確保ISO9001的（4.15）條中描述的交付和安裝要求得到滿足，并且應該考慮ISO9000-3中（6.8）條描述的“所包含的軟件產品的使用”。當然，這些要求對處于第3級的組織來說是微不足道的，即使是處于第2級的組織也不難通過ISO9001認證審核。
從上述分析不難得出這一結論：在CMM中，雖然有的問題談的還不夠充分，但大體上包容了ISO9001，ISO9001卻不能包容CMM。
那么，軟件過程改進應該以CMM為基礎（也許再補充一些ISO9001的內容），還是致力于ISO9001認證？對于一個軟件組織來說，市場可能要求它擁有ISO9001證書。無疑，瞄準CMM的要求進行軟件過程改進將有助于本組織通過ISO9001認證審核。就軟件過程改進而言，雖然這兩份文件都可用，不過CMM給出的指南更詳細并且視野更寬闊，因此CMM應該是較好的選擇。
從本質上說，在構筑競爭優勢時應該致力于改進，而不是只為得到ISO9001證書或達到某個CMM成熟度級。
三CMM的應用
設計CMM的初衷是為了用以支持美國國防部對軟件組織的能力進行評定。因此，從1987年SEI拿出CMM的雛形（“軟件成熟度框架”）后，美國國防部便把它用于軟件組織評估，以支持選擇承包商時的決策。后來，隨著CMM研制和試用工作的推進，設計者，參與者和支持者們發現了它的巨大應用潛力，于是，CMM的研制目標擴大為：
——以實踐為基礎，
——反映最好的實踐經驗，
——反映那些從事軟件過程改進，軟件過程評價和軟件能力評估的人士的需要，
——形成書面文件，
——供大眾使用。
由于接受并且通過了CMM評估給公司在合同競爭中帶來的好處，使CMM很快在美國和美國以外那些希望得到美國的軟件開發項目合同的公司傳播開。由于CMM評估需求大大增加，1994年，在美國國防部的支持下，設立了“軟件過程改進（SPI）服務部”，明碼市價對外提供各種CMM相關服務。現在，美國已有多家咨詢或服務機構獲得授權開展此項服務業務，以應付日益增多的CMM應用需要。對CMM趨之若騖的現象，一些軟件界資深管理人士認為，這是因為“今天，在軟件開發中的最大問題不是技術問題，而是管理問題。”
正式發表的CMM建立了一套準則，供大眾用于描述成熟軟件組織的特性。這些準則可以由軟件組織用于改進它們的開發和維護軟件的過程，也可以由政府或商業組織用來對它們在打算與某公司簽定軟件項目合同時涉及的風險進行評價。簡言之，CMM主要用途有兩大類：
——過程改進；
——能力評估。
CMM用之于軟件過程改進時，是通過按CMM給出的準則對軟件過程實施評價，從而為作出改進決策和實施改進提供支持；所以，往往又把CMM在過程改進方面的應用看成是過程評價。于是，上述CMM的兩種主要用途又歸結為兩種評定方法：
·軟件過程評價；用于確定組織目前的軟件過程狀態，確定組織面臨的突出軟件過程問題，從而求得組織的軟件過程改進的支持。
·軟件能力評估。用于識別合格的軟件工作承包商，或用于監控現行軟件工作項目上用的軟件過程的狀態。
CMM是軟件過程評價和軟件能力評估的公共基礎。不過，兩種用法的目的不同，而且具體用法也有很大差異。軟件過程評價側重于確定本組織軟件過程改進的輕重緩急；軟件能力評估側重于確定在選擇軟件項目承包商時可能碰到的風險，或者說是確定軟件組織在軟件能力方面的置信程度。后面這一點正是許多軟件組織看好按CMM評定等級的原因。軟件過程評價與軟件能力評估在動機，目標，范圍以及審核結果所有權等方面都有所不同。
按CMM進行軟件過程評價或軟件能力評估的幾個大步驟基本相同，從選定評估組后：
——以成熟度調查問卷作為現場訪問的出發點；
——用CMM作為指導現場調查研究的路線圖；
——針對CMM中的關鍵過程方面指出反映該組織軟件過程的強，弱之點；
——根據所了解到的該組織達到CMM關鍵過程方面目標的情況描繪出該組織的軟件過程的概貌；
——向被審核者說明評估結果。
參見圖5。
圖5軟件過程評價和軟件能力評估的共同步驟
CMM僅僅是模型，為了保證可靠且一致地使用它，美國卡內基-梅隆大學軟件工程研究所圍繞CMM擬制了一系列支持性文件（包括相應的評價框架，方法描述和實施指南）以及各種工具。使用CMM的大致思路是：1）圍繞CMM擬制出CMM評估框架（CAF），從CAF中歸類出各類要求，（CAF已由SEI擬出并發表）；2）針對各類要求進行相應準備；3）按對象及其需求采用適當的方法進行評定。以CMM為基礎實施評定的概念見圖6。
圖6以CMM為基礎實施評定的概念圖
（圖中CAF=CMM評估框架IPI=綜合過程改進SCE=軟件能力評估）
如前面所述，CMM是由美國國防部斥資啟動研究的。原定用途是為了確保所選的承包商確有開發重大軟件項目的能力。因此，CMM涉及了軟件組織軟件能力的方方面面并且詳細非常。實施CMM評定將牽涉大量人力，財力和時間。例如，美國的CMM評審機構為進行一次評估（或評價）開出的價碼是710萬美圓。從接受評估申請到完成評估跨時2到3個月；如果涉及過程改進，將可能需時1824個月。為了適應中，小組織的需要，人們已開始探討CMM的裁剪和壓縮問題。不過，對于軟件組織來說，能力的不斷增強是根本所在，所以，美國的一些規模不大的軟件公司也早已開始尋求CMM評估，而沒有等待“小型CMM”出現。
CMM這個模型把軟件組織的能力成熟度分成5個等級。從1987年發表CMM的最初框架到1993年發布CMM1.1版的這6年試運行，除了一些過去已經通過TQM或其他質量管理活動而達到高成熟度的大型公司外，經過評估并達到的成熟度等級大多數是第2或第3級。原因在于，CMM勾畫出的這個分級遞進式框架雖然描述了第4和第5級成熟度的特征，但是，究竟應該用什么樣的實際表現來定位第4和第5級，尚有爭論。就成熟度升級而言，美國CMM評估業界和軟件業界認為，從擬訂出軟件過程改進大綱算起，至少要18~24個月才能真正完成改進，并且隨著軟件項目開發的啟動往往要“凍結”各項相關的軟件過程，也就是說，在軟件開發過程中一般不會去更改該項目開發涉及的軟件過程；此外，所處水平越高升級亦越難——CMM的設計也融入了這種思想。因此，盡管從CMM1.1版發布之日算也已過去了6年，即使在美國本土接受并通過CMM第4或第5級評估的主要還是那些在制定出CMM之前就有很強軟件能力的公司（如IBM,波音，洛克希德，休斯，莫托羅拉等）里的軟件組織。從1995年，即CMM1.1發布后的第3年起，CMM又進入了另一個修改的高峰期。美國政府和軟件業界大力支持和積極參與下，SEI先后發表了CMM2.0版的A版，B版和C版草案；1997年，應美國國防部之請，CMM2.0?版草案停止推進。SEI宣布，CMM1.1版和CMM2.0版的C版草案都有效并且SEI及其授權的機構為這兩種版本提供相應的服務。與此同時，名為“綜合能力成熟度模型”（英文縮寫為CMMI）的一個綜合性模型投入研制。自CMM1.1發布起，為與之配合，在以后幾年里SEI相繼研制并發布了“人員能力成熟度模型”（P-CMM），“軟件采辦能力成熟度模型”（SA-CMM）和“系統工程能力成熟度模型”（SE-CMM）及其支持文件。經過試運行，產生了把SM-CMM, P-CMM, SA-CMM和SE-CMM合并在一起的想法和行動，于是開始了上述的CMMI研制工作。
受CMM思路的影響，國際標準化組織（ISO）開始了圍繞SPICE（軟件過程改進和能力確定）的大題目展開了有關軟件過程評估的成套標準制定活動。SPICE包含的過程管理參考模型與SM-CMM類似，不過，SM-CMM著眼于過程能力，SPICE著眼點是組織能力，而且SPICE提出的一套通用慣例適用于任何過程的過程管理，而不僅僅是軟件過程。目前，ISO將作為技術報告發布的ISO15504（軟件過程評估）包括9個部分：
第1部分概念與導論
第2部分過程和過程能力的參考模型
第3部分評估
第4部分評估指南
第5部分用于評估模型和指針的指南
第6部分審核員資格審定指南
第7部分在過程改進中參考模型使用指南
第8部分在確定供方過程能力中參考模型使用指南
第9部分詞匯。
CMM雖然已在美國成為事實上的標準，但它畢竟只是美國一個研究所的一份技術報告，而且還一直處于修改和變更的過程中。因此，CMM盡管引起不少國家軟件業界的關注，但是，除了因合同需要而尋求CMM評估之外，大多處于分析和研究階段；相比之下，國際標準化組織的步子更大些。如前所述，由于軟件產業發展的需要，CMM所表達的思路也引起了我國一些軟件組織和其他機構的興趣，幾年前即已開展了相應的探討和研究工作。現在有的軟件組織開始談論“是尋求ISO9001認證，還是CMM評估”的現實問題，有的軟件組織正在摸索本組織實施CMM的可能性，有的已經在嘗試準備按CMM評估。對于這些現象，有人歸結為“CMM在我國的應用問題”。筆者認為，除了那些因接受軟件出口合同的要求而不得不接受CMM評估的情況之外，在考慮“CMM在我國的應用”這一問題時，特別是在行業或政府一級考慮這個問題時至少要注意以下三點：
·CMM和Capability Maturity Model已經由美國卡內基-梅隆大學軟件工程研究所在美國注冊了專利和商標；
·CMM產生于美國的軟件產業那個環境；在那個環境里，有的公司的軟件組織在CMM產生之前就有相當成熟的軟件能力。這種能力不是單靠評估或認證能達得到的，應該說，這主要是得益于大量軟件項目實踐以及充分尊重，積累和運用實踐經驗的結果。此環境非彼環境。
·從比較ISO9001與CMM中可以看出，ISO9001和CMM的精神是一致的，兩者都強調“說的要做到，做的要說到”，都強調“文件化（制度化）”；我國許多軟件組織結合ISO9001做了大量實施準備工作或接受并通過了審核認證。在我們引入更好的軟件質量保證途徑時，應充分利用這些質量保證方面的努力。CMM的思路較好地反映了軟件和軟件開發工作的特點，圍繞CMM而設計和擬制的大量支持文件和工具又為實施一致且可靠的評估提供了保證；但是，CMM至少存在一個不足之處——它只強調“關鍵過程方面”和“關鍵慣例”，因此，接受CMM評估的組織往往容易忽視那些“非關鍵”的過程和（或）慣例，而這些“非關鍵”的過程和慣例仍是必須執行的。按ISO9001的精神去理解，軟件組織倒不一定忽視這些必須執行的“非關鍵”。此外，正在修訂之中的ISO9000系列標準和ISO15504（軟件過程評估）亦應關注。
當然，對于企業來說，在本組織內利用CMM或其思路進行軟件過程改進嘗試當屬例外。其實，這種摸索嘗試將有益于我國軟件行業探求推進軟件開發能力的最佳途徑。希望這些寶貴的實踐經驗能在我國軟件行業或政府有關部門的相應工作中發揮作用，既不要藏之高閣，亦不要置之不理。
從CMM本身的發展歷程可以看出，并不是一蹴而就，而是邊擬制邊實踐，不厭其煩地發布一版又一版修改稿，不斷調整，不斷完善。此外，提出CMM者并未止步于這個“標準”文本，同時還拿出了與之配套的文件和工具，并且進一步展開了拓展研究。在我們開展類似工作時，這些經驗是值得借鑒的。操之過急或一哄而起是不可取的。
============================================================================
什么是CMM
剛才在網站上看到關于CMM的說法,現整理一些資料,以便更全面的了解CMM,里面不是本人寫的.只是整理的.
軟件開發能力的成熟度模型(capability manurity model for software,cmm)是軟件 工程協會sei(software engineering institution)在卡內基.梅隆大學開發完成的對一個 組織軟件開發能力進行評價的標準,它側重于對軟件開發過程和開發方法論的考察。cmm包 括五個成熟等級,開發的能力越強,開發組織的成熟度越高,等級越高。目前,大多數公司處 于第一級和第二級,只有很少的公司可以達到第五級。五級的具體定義如下:
初級(initial)：軟件開發過程中偶爾會出現混亂的現象,只有很少的工作過程是經 過嚴格定義的,開發成功往往依靠的是某個人的智慧和努力。
可重復的(repeatable)：建立了基本的項目管理過程。按部就班地設計功能、跟蹤 費用 ,根據項目進度表進行開發。對于相似的項目,可以重用以前已經開發成功的部分。
被定義的(defined.)：軟件開發的工程活動和管理活動都是文檔化、標準化的,它 被集成為一個組織的標準的開發過程。所有項目的開發和維護都在這個標準基礎上進行定 制。
被管理的(managed.)：對于軟件開發過程和產品質量的測試細節都有很好的歸納, 產品和開發過程都可以定量地分解和控制。
優化的(optimizing)：通過建立開發過程的定量反饋機制,不斷產生新的思想,采用 新的技術來優化開發過程。
除了第一級,其它每一級都有幾個特別值得注意的關鍵過程。第二級的關鍵之處是建 立基本的項目管理控制。他們是需求管理、軟件項目計劃、軟件項目的跟蹤和監督、軟件 轉包管理、軟件質量保證和軟件組態管理。
第三級的關鍵之處是既關注項目問題,也關注組織問題,因為組織建立起了使高效率軟 件工程制度化的基本架構和跨項目的管理過程。它們包括組織過程關注程度、組織過程定 義、培訓項目、集成化的軟件管理、軟件產品化機制、項目組的內部協調和對出現錯誤的 復查。
第四級的關鍵之處是對軟件開發過程和軟件產品都有一個定量的理解。它強調的是定 量的過程管理和軟件質量管理。
第五級的關鍵點強調,不論組織還是項目必須追求持續的、可度量的過程改進。包括 缺陷預防、技術更新管理和流程改造管理。
cmm和iso9001的出發點都是通過對生產過程進行管理,來確保產品的質量。雖然它們 之間有很多區別,但也有相似之處。比如,通過iso9001認證的組織,可以基本滿足cmm二級 的標準和很多cmm三級的要求。因為cmm中的很多要求并沒有列入iso9000標準之中,所 以,cmm一級的組織也可能獲得iso9001的登記,defined.同樣,有些iso9001規定的內容并沒 有列入cmm標準。一個cmm三級組織獲得iso9001認證幾乎沒有困難,cmm二級組織申請 iso9001認證也有明顯優勢。
===========================================================================================
第一級：初始級
在初始級，企業一般不具備穩定的軟件開發與維護的環境。常常在遇到問題的時候，就放棄原定的計劃而只專注于編程與測試。
第二級：可重復級
在這一級，建立了管理軟件項目的政策以及為貫徹執行這些政策而定的措施。基于過往的項目的經驗來計劃與管理新的項目。
第三級：定義級
在這一級，有關軟件工程與管理工程的一個特定的、面對整個企業的軟件開發與維護的過程的文件將被制訂出來。同時，這些過程是集成到一個協調的整體。這就稱為企業的標準軟件過程。
第四級：定量管理級
在這一級，企業對產品與過程建立起定量的質量目標，同時在過程中加入規定得很清楚的連續的度量。作為企業的度量方案，要對所有項目的重要的過程活動進行生產率和質量的度量。軟件 產品因此具有可預期的高質量。
第五級：（不斷）優化級
在這個等級，整個企業將會把重點放在對過程進行不斷的優化。企業會采取主動去找出過程的弱點與長處，以達到預防缺陷的目標。同時，分析有關過程的有效性的資料，作出對新技術的 成本與收益的分析，以及提出對過程進行修改的建議。
CMM第一級：初始級
◆ 特征
(1)軟件過程的特點是雜亂無章，有時甚至混亂，幾乎沒有定義過程的規則或步驟。
(2)過分的承諾，常作出良好的承諾：如“按照軟件工程方式，有序的工程來工作”；或達到高目標的許諾。但實際上卻出現一系列問題。
(3)遇到危機就放棄原計劃過程，反復編碼和測試。
(4)成功完全依賴個人努力和杰出的專業人才，取決于超常的管理人員和杰出有效的軟件開發開發人員。具體的表現和成果都源于或者說是決定于個人的能力和他們先前的經驗、知識以及他們的進取心和積極程度。
(5)能力只是個人的特性，而不是開發組織的特性。依靠著個人的品質或承受著巨大的壓力；或找竅門取得成果。但此類人一旦離去，對組織的穩定作用也消失。
(6)軟件過程是不可確定的和不可預見的。軟件成熟性程度處于第一級軟件組織的軟件過程在實際的工作過程中被經常的改變（過程是隨意的）。這類組織也在開發產品，但其成果是不穩定的，不可預見的，不可重復的。也就是說，軟件的計劃、預算、功能和產品的質量都是不可確定和不可預見的。
◆ 過程
(1)極少存在或使用穩定的過程
(2)所謂“過程”，往往是“就這么干”而言。
(3)各種條例，規章制度互不協調，甚至互相矛盾。
◆ 人員
(1)依賴個人努力和杰出人物。一旦優秀人物離去，項目就無法繼續。
(2)人們的工作方式如同“救火”，就是在開發過程中不斷地出現危機，以及不斷的“救火”。
◆ 技術
引進新技術是極大風險。
◆ 度量
不收集數據或分析數據。
◆ 改進方向
(1)建立項目管理過程，實施規范化管理，保障項目的承諾。
(2)首要任務是進行需求管理，建立客戶與軟件項目之間的共同理解，使項目真正反映客戶的要求。
(3)建立各種軟件項目計劃、如軟件開發計劃、軟件質量保證計劃、軟件配置管理計劃、軟件測試計劃、風險管理計劃及過程改進計劃。
(4)開展軟件質量保證活動（SQA）。
CMM第二級：可重復級
◆ 特征
(1)進行較為現實的承諾，可按以前在同類項目上的成功經驗建立的必要過程準則來確保再一次的成功。
(2)主要是逐個項目地建立基本過程管理條例來加強過程能力。
(3)建立了基本的項目管理過程來跟蹤成本、進度和功能。
(4)管理工作主要跟蹤軟件經費支出、進度及功能。識別在承諾方面出現的問題。
(5)采用基線（BASELINE）來標志進展、控制完整性。
(6)定義了軟件項目的標準，并相信它，遵循它。
(7)通過子合同建立有效的供求關系。
◆ 過程
(1)軟件開發和維護的過程是相對穩定的，但過程建立在項目一級。
(2)有規則的軟件過程是在一個有效的工程管理系統的控制之下，先前的成功經驗可以被重復。
(3)問題出現時，有能力識別及糾正。承諾是可實現的。
◆ 人員
(1)項目的成功依賴于個人的能力以及管理層的支持。
(2)理解管理的必要性及對管理的承諾。
(3)注意人員的培訓問題。
◆ 技術
建立技術支持活動，并有穩定的計劃。
◆ 度量
每個項目建立資源計劃。主要是關心成本、產品和進度。有相應的管理數據。
◆ 改進方向
(1)不再按項目制定軟件過程，而是總結各種項目的成功經驗，使之規則化，把具體經驗歸納為全組織的標準軟件過程。把改進組織的整體軟件過程能力的軟件過程活動，作為軟件開發組織的責任。
(2)確定全組織的標準軟件過程，把軟件工程及管理活動集成到一個穩固確定的軟件過程中。從而可以跨項目改進軟件過程效果，也可作為軟件過程剪裁的基礎。
(3)建立軟件工程過程小組（SEPG）長期承擔評估與調整軟件過程的任務，以適應未來軟件項目的要求。
(4)積累數據，建立組織的軟件過程庫及軟件過程相關的文檔庫。
(5)加強培訓。
CMM第三級：確定級
◆ 特征
(1)無論管理方面或工程方面的軟件過程都已文件化、標準化，并綜合成軟件開發組織的標準軟件過程。
(2)軟件過程標準被應用到所有的工程中，用于編制和維護軟件。有的項目也可根據實際情況，對軟件開發組織的標準軟件過程進行剪裁。
(3)在從事一項工程時，產品的生產過程、花費、計劃以及功能都是可以控制的，從而軟件質量也可以控制。
(4)軟件工程過程組（SEPG）負責軟件活動。
(5)在全組織范圍內安排培訓計劃。
◆ 過程
(1)整個組織全面采用綜合性的管理及工程過程來管理。軟件工程和管理活動是穩定的和可重復的，具有連續性的。
(2)軟件過程起了預見及防范問題的作用，能使風險的影響最小化。
◆ 人員
(1)以項目組的方式進行工作。如同綜合產品團隊。
(2)在整個組織內部的所有人對于所定義的軟件過程的活動、任務有深入了解，大大加強了過程能力。
(3)有計劃地按人員的角色進行培訓。
◆ 技術
在定性基礎上建立新的評估技術。
◆ 度量
(1)在全過程中收集使用數據。
(2)在全項目中系統性地共享數據。
◆ 改進方向
(1)開始著手軟件過程的定量分析，以達到定量地控制軟件項目過程的效果。
(2)通過軟件的質量管理達到軟件的質量目標。
CMM第四級：管理級
◆ 特征
(1)制定了軟件過程和產品質量的詳細而具體的度量標準，軟件過程和產品質量都可以被理解和控制。
(2)軟件組織的能力是可預見的，原因是軟件過程是被明確的度量標準所度量和操作。不言而喻，軟件產品的質量就可以預見和得以控制。
(3)組織的度量工程保證所有項目對生產率和質量進行度量、并作為重要的軟件過程活動。
(4)具有良好定義及一致的度量標準來指導軟件過程，并作為評價軟件過程及產品的定量基礎。
(5)在開發組織內已建立軟件過程數據庫，保存收集到的數據，可用于各項目的軟件過程。
◆ 過程
(1)開始定量地認識軟件過程。
(2)軟件過程的變化小，一般在可接受的范圍內。 (3)可以預見軟件過程中和產品質量方面的一些趨勢。一旦質量經度量后超出這些標準或是有所違反，可以采用一些方法去改正，以達到良好的目標。
◆ 人員
每個項目中存在強烈的群體工作意識。因為每人都了解個人的作用與組織的關系，因此能夠產生這種群體意識。
◆ 技術
不斷的在定量基礎上評估新技術。
◆ 度量
(1)在全組織內進行數據收集與確定。
(2)度量標準化。
(3)數據用于定量地理解軟件過程及穩定軟件過程。
◆ 改進方向
(1)缺陷防范，不僅僅在發現了問題時能及時改進，而且應采取特定行動防止將來出現這類缺陷。
(2)主動進行技術變動管理、標識、選擇和評價新技術，使有效的新技術能在開發組織中施行。
(3)進行過程變動管理，定義過程改進的目的，經常不斷地進行過程改進。
CMM第五級：優化級
◆ 特征
(1)整個組織特別關注軟件過程改進的持續性、預見及增強自身，防止缺陷及問題的發生，不斷地提高他們的過程處理能力。
(2)加強定量分析，通過來自過程的質量反饋和吸收新觀念，新科技，使軟件過程能不斷地得到改進。
(3)根據軟件過程的效果，進行成本/利潤分析，從成功的軟件過程中吸取經驗，加以總結。把最好的創新成績迅速向全組織轉移， 對失敗的案例，由軟件過程小組進行分析以找出原因。
(4)組織能找出過程的不足并預先改進，把失敗的教訓告知全體組織以防止重復以前的錯誤。
(5)對軟件過程的評價和對標準軟件過程的改進，都在全組織內推廣。
◆ 過程
(1)不斷地系統地改進軟件過程。
(2)理解并消除產生問題的公共根源，在任何一個系統中都可找到：由于隨機變化造成重復工作、進而導致時間浪費。為了防止浪費人力可能導致的系統變化。要消除“公共”的無效率根源，防止浪費發生。盡管所有級別都存在這些問題，但這是第五級的焦點。
◆ 人員
(1)整個組織都存在自覺的強烈的團隊意識。
(2)每個人都致力過程改進，人們不再以達到里程碑的成就而滿足，而要力求減少錯誤率。
◆ 技術
基于定量的控制和管理，事先主動考慮新技術、追求新技術。可以實現軟件開發中的方法和新技術的革新、以防止出現錯誤，不斷提 高產品的質量和生產率。
◆ 度量
利用數據來評估，選擇過程改進。
◆ 改進方向
保持持續不斷的軟件過程改進。
CMM總結：五層結構圖
我們看到，在第五級上，技術和過程的改進像普通商業活動一樣有計劃、有管理地進行。由于組織不斷的致力于改進過程的能力，所以軟件開發組織的能力可持續改進。這種改進不僅表現在對存在的軟件過程逐步改進，不表現在采用新技術和新方法方面的革新。
畫一個圖吧：（CMM的五層結構圖）
-----------------
/ (5) /
-----------------↑
| 不斷改進的過程|
-----------------
/ 可 管 理 級 /
/ (4) /
-----------------
↑
| 能預見的過程
|
-----------------
/ 確 定 級 /
/ (3) /
-----------------
↑
| 標準一致的過程
|
-----------------
/ 可 重 復 級 /
/ (2) /
-----------------
↑
| 有紀律的過程
|
-----------------
/ 初 始 級 /
/ (1) /
-----------------
==================================================================================================
軟件工程與能力成熟度模型CMM
我們首先討論軟件工程管理的意義。軟件工程管理引起廣泛注意源于20世紀70年代中期。當時美國國防部曾立題專門研究軟件項目做不好的原因，發現70%的項目是因為管理不善而引起，而并不是因為技術實力不夠，進而得出一個結論，即管理是影響軟件研發項目全局的因素，而技術只影響局部。這個結論非常重要。到了20世紀90年代中期，軟件工程管理不善的問題仍然存在。據美國軟件工程實施現狀的調查，軟件研發的情況依然很難預測，大約只有10%的項目能夠在預定的費用和進度下交付。在商用軟件產業中，這一現象尤為嚴重。1995年，美國共取消了810億美元的軟件項目，其中31%的項目未做完就取消了，53%的軟件項目進度通常要延長50%的時間，通常只有9%的軟件項目能夠及時交付并且費用也不超支。軟件項目失敗的主要原因有：需求定義不明確；缺乏一個好的軟件開發過程；沒有一個統一領導的產品研發小組；子合同管理不嚴格；沒有經常注意改善軟件過程；對軟件構架很不重視；軟件界面定義不善且缺乏合適的控制；軟件升級暴露了硬件的缺點；關心創新而不關心費用和風險；軍用標準太少且不夠完善等等。在關系到軟件項目成功與否的眾多因素中，軟件度量、工作量估計、項目規劃、進展控制、需求變化和風險管理等都是與工程管理直接相關的因素。由此可見，軟件工程管理的意義至關重要。
軟件工程管理和其它工程管理相比有其特殊性。首先，軟件是知識產品，進度和質量都難以度量，生產效率也難以保證。其次，軟件系統復雜程度也是超乎想象的。例如，宇宙飛船的軟件系統源程序代碼多達2000萬行，如果按過去的生產效率一個人一年只能寫1萬行代碼的話，那么需要2000人年的工作量，這是非常驚人的。正因為軟件如此復雜和難以度量，軟件工程管理的發展還很不成熟。
美國 Carnegie Mellon 大學軟件工程研究所(CMU/SEI)主持研究與開發的CMM/PSP/TSP 技術，為軟件工程管理開辟了一條新的途經。CMM是英文 Capability Maturity Model 的簡稱，意為能力成熟度模型。CMM的本質是軟件管理工程的一個部分。根據軟件生產的歷史與現狀，CMM框架可用5個不斷進化的層次來表達：其中初始層是混沌的過程，可重復層是經過訓練的軟件過程，定義層是標準一致的軟件過程，管理層是可預測的軟件過程，優化層是能持續改善的軟件過程。任何單位所實施的軟件過程，都可能在某一方面比較成熟，在另一方面不夠成熟，但總體上必然屬于這5個層次中的某一個層次。在某個層次內部，也有成熟程度的區別。在一個較低層次的上沿，很可能與一個較高層次的下沿非常接近，此時由這個較低層次向該較高層次進化也就比較容易。反之，在一個較低層次的下沿向較高層次進化，就比較困難。在CMM框架的不同層次中，需要解決帶有不同層次特征的軟件過程問題。因此，一個軟件開發單位首先需要了解自己處于哪一個層次，然后才能夠對癥下藥地針對該層次的特殊要求解決相關問題，這樣才能收到事半功倍的軟件過程改善效果。任何軟件開發單位在致力于軟件過程改善時，只能由所處的層次向緊鄰的上一層次進化，即軟件過程的進化是漸進的，而不能是跳躍的。而且在由某一成熟層次向上一更成熟層次進化時，在原有層次中的那些已經具備的能力還應該得到保持與發揚。
CMM家族包括CMM集成產品集、SA-CMM(軟件獲取能力成熟度模型)、SE-CMM(系統工程能力成熟度模型)和IDEAL模型。其中CMM集成產品集為工業界和政府部門提供了一系列集成產品，以支持軟件過程和產品的改善；SA-CMM用于單位獲取和采購基于軟件的應用系統的軟件過程，美國國防部、陸軍、海軍和一些商用單位都已采用SA - CMM對他們的獲取能力進行評估；SE-CMM是描述一個單位為保證實現一個好的系統工程的主要元素；而IDEAL模型則是一個單位用于啟動、規劃和實現過程改善措施藍圖的模型，概括了建立一個成功的過程改善項目的必要步驟，其中I代表Initiating(啟動)、D代表Diagnosing(診斷)、E代表Establishing(建造)、A代表Acting(措施)、L代表Learning(學習)。
美國曾在1995年做過軟件產業成熟程度的調查，發現在美國的軟件產業中，CMM成熟度等級為初始級的竟占70%，其特征是軟件開發過程不能預測，風險度高；為可重復級的占15%，其特征是軟件開發過程需小心謹慎方能避免失敗；為定義級的所占比例小于10%，其特征是軟件開發過程相當穩定，進展順利且可以預測；為管理級的所占比例小于5%，其特征是軟件過程預測準確、值得信賴；為優化級的所占比例小于1%，其特征是軟件過程能持續改善。國內在這方面的起步則要晚一些，據我所知，目前只有清華鼎新公司的CMM成熟度等級達到可重復級。盡管CMM已經是一套發展相當成熟的方法，但國內要想完全掌握并廣泛付諸實踐，對絕大多數軟件企業來說，可能還需要3～5年的時間。
需要注意的是，并不是實施了CMM，軟件項目的質量就能有所保障。CMM不是萬能的，它的成功與否，與一個組織內部有關人員的積極參與和創造性活動是密不可分的，而且CMM并未提供實現有關子過程域所需要的具體知識和技能。因此，個體軟件過程PSP(Personal Software Process)也就應運而生。PSP為基于個體和小型群組軟件過程的優化提供了具體而有效的途徑，例如如何制訂計劃，如何控制質量，如何與其他人相互協作等等。在軟件設計階段，PSP的著眼點在于軟件缺陷的預防，其具體辦法是強化設計結束準則，而不是設計方法的選擇。根據對參加培訓的104位軟件人員的統計數據表明，在應用了PSP后，軟件中總的缺陷減少了58.0%，在測試階段發現的缺陷減少了71.9%，生產效率提高了20.8%。PSP的研究結果還表明，絕大多數軟件缺陷是由于對問題的錯誤理解或簡單的失誤所造成的，只有很少一部分是由于技術問題而產生的。而且根據多年來的軟件工程統計數據表明，如果在設計階段注入一個差錯，則這個差錯在編碼階段要引發3～5個新的缺陷，要修復這些缺陷所花的費用要比修復這個設計缺陷所花的費用多一個數量級。因此，PSP保障軟件產品質量的一個重要途徑是提高設計質量。PSP的推出，在軟件工程界引起了極大的轟動，可以說是由定向軟件工程走向定量軟件工程的一個標志。
然而實踐證明，僅有CMM和PSP還是不夠的，因此，CMU/SEI又在此基礎上提出了群組軟件過程TSP(Team Software Process)的方法。TSP指導項目組中的成員如何有效地規劃和管理所面臨的項目開發任務，并且告訴管理人員如何指導軟件開發隊伍始終以最佳狀態來完成工作。TSP實施集體管理與自已管理自己相結合的原則，最終目的在于指導一切人員如何在最少的時間內，以預定的費用生產出高質量的軟件產品；所采用的方法是對群組軟件開發過程的定義、度量和改進。實施TSP的先決條件有3條：首先，需要有高層主管和各級經理的支持，以取得必要的資源；其次，項目組開發人員需要經過PSP的培訓并有按TSP工作的愿望和熱情；第三，整個單位在總體上應處于CMM二級以上。在實施TSP的過程中，首先要有明確的目標，開發人員要努力完成已經接受的委托任務。在每一階段開始，要做好工作計劃。如果發現未能按期按質完成計劃，應分析原因，以判定問題是由于工作內容不合適或工作計劃不實際所引起，還是由于資源不足或主觀努力不夠所引起。開發小組一方面應隨時追蹤項目進展狀態并進行定期匯報，另一方面應經常評審自己是否按PSP的原理工作。開發人員應按自己管理自己的原則管理軟件過程，如發現過程不合適，應及時改進，以保證用高質量的過程來生產高質量的軟件。項目開發小組則按集體管理的原則進行管理，全體成員都要參加和關心小組的規劃、進展的追蹤和決策的制訂等項工作。
總之，單純實施CMM，永遠不能真正做到能力成熟度的升級，只有將實施CMM與實施PSP和TSP有機地結合起來，才能發揮最大的效力。因此，軟件過程框架應該是CMM/PSP/TSP的有機集成，其相互關系可用圖1來表示。
目前國內對軟件工程管理存在的最大問題是認識不足。管理實際上是一把手工程，需要高層管理人員的足夠重視。據國外有些大公司的介紹，他們在軟件工程管理方面的投資一般占軟件開發費用的10%左右，這些都需要得到高層管理人員的支持。而且軟件過程的重大修改也必須由高層管理部門啟動，這是軟件過程改善能否進行到底的關鍵。此外，軟件過程的改善還有待于全體有關人員的積極參與，否則不僅他本人將失去從軟件過程改善中獲得提高的機會，甚至還會成為過程改善的阻力。
除了要認識到過程改善工作是一把手工程這個關鍵因素外，還應認識到軟件過程成熟度的升級本身就是一個過程，且有一個生命周期。因此，過程改善工作必然具有一切過程所具有的固有特征，即需要循序漸進，不能一蹴而就，需要持續改善，不能停滯不前；需要聯系實際，不能照本宣科；需要適應變革，不能凝固不變。而且我認為，要將CMM/PSP/TSP引入軟件企業，最有效的途徑是要對單位主管和主要開發人員進行系統的培訓。美國 Carnegie Mellon 大學軟件工程研究所曾經嘗試讓軟件工程師通過自學的方式來進行，但實際上只有不到20%的人能夠堅持到底。另外一個有效的途徑是自頂向下的課程培訓，即從高層主管依次普及到下面的工程師。 現在國內軟件產業的發展可以說已經具有一定規模了，但除了北大方正、東大阿爾派、用友等大企業外，做軟件工程項目更多的是一些規模在數十人左右的中小企業。也許有人會問，像這樣一些人力物力資源匱乏的企業，如何進行軟件開發項目的管理呢？我建議這些中小企業可以以CMM為框架，先從PSP做起，然后在些基礎上逐漸過渡到TSP，以保證CMM/PSP/TSP確實在企業中生根開花。總之，我們必須從軟件過程、過程工程的角度來看待CMM的發展，從經濟學的觀點來分析這個過程的價值。我相信在實施CMM/PSP/TSP的過程中，只要堅持改善軟件工程的管理，并在實踐中注意總結適合自身的經驗，一定能取得很好的效果。
==============================================================================
總結
以上是生活随笔為你收集整理的软件能力成熟度模型CMM的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 苹果6发布时间_苹果头戴式耳机AirPo
- 下一篇： linux系统使用ps,Linux系统p