CMM綜述

作者：趙熙朝 來源：yesky

CMM(Capability Maturity Model能力成熟度模型)的本質是軟體管理工程的一個部分。它是對于軟體組織在定義，實作，度量，控制和改善其軟體過程的程序中各個發展階段的描述。他通過5個不斷進化的層次來評定軟體生産的曆史與現狀。

　　 

上面提到了CMM把軟體開發組織的能力成熟度分為5個的等級。除了第1級外，其他每一級由幾個關鍵過程方面組成。每一個關鍵過程方面都由上述5種公共特性予以表征。CMM給每個關鍵過程了一些具體目标。按每個公共特性歸類的關鍵慣例是按該關鍵過程的具體目标選擇和确定的。如果恰當地處理了某個關鍵過程涉及的全部關鍵慣例，這個關鍵過程的各項目标就達到了，也就表明該關鍵過程實作了。這種成熟度分級的優點在于，這些級别明确而清楚地反映了過程改進活動的輕重緩急和先後順序。圖二 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關系描述圖 

對于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的過程中，隻要堅持改善軟體工程的管理，并在實踐中注意總結适合自身的經驗，一定能取得很好的效果。