CMM綜述
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與品質管理
一、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簡介二
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的過程中，隻要堅持改善軟體工程的管理，并在實踐中注意總結适合自身的經驗，一定能取得很好的效果。 ============================================================================ CMM及其應用
随着我國計算機軟體産業的形成和發展，軟體産品品質保證這一課題逐漸受到各個軟體開發組織和政府有關管理機構的重視。一些規模較大的軟體開發組織各自在本機關運用品質管理理論指導開展了軟體産品品質保證活動；有些軟體開發公司引入了國際通行的品質管理體系品質保證模式——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評審機構為進行一次評估（或評價）開出的價碼是7~10萬美圓。從接受評估申請到完成評估跨時2到3個月；如果涉及過程改進，将可能需時18~24個月。為了适應中，小組織的需要，人們已開始探讨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(C)版草案停止推進。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五級标準
第一級：初始級
在初始級，企業一般不具備穩定的軟體開發與維護的環境。常常在遇到問題的時候，就放棄原定的計劃而隻專注于程式設計與測試。
第二級：可重複級
在這一級，建立了管理軟體項目的政策以及為貫徹執行這些政策而定的措施。基于過往的項目的經驗來計劃與管理新的項目。
第三級：定義級
在這一級，有關軟體工程與管理工程的一個特定的、面對整個企業的軟體開發與維護的過程的檔案将被制訂出來。同時，這些過程是內建到一個協調的整體。這就稱為企業的标準軟體過程。
第四級：定量管理級
在這一級，企業對産品與過程建立起定量的品質目标，同時在過程中加入規定得很清楚的連續的度量。作為企業的度量方案，要對所有項目的重要的過程活動進行生産率和品質的度量。軟體 産品是以具有可預期的高品質。
第五級：（不斷）優化級
在這個等級，整個企業将會把重點放在對過程進行不斷的優化。企業會采取主動去找出過程的弱點與長處，以達到預防缺陷的目标。同時，分析有關過程的有效性的資料，作出對新技術的 成本與收益的分析，以及提出對過程進行修改的建議。
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的過程中，隻要堅持改善軟體工程的管理，并在實踐中注意總結适合自身的經驗，一定能取得很好的效果。 ==============================================================================
![寫在工作13周年[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)