????????首先介紹一下CMM和CMMI瓮恭。軟件能力成熟度模型（Capability Maturity Model, CMM）是美國卡內(nèi)基梅隆大學(xué)軟件工程研究生（SEI）匯集了世界各地軟件過程管理者的經(jīng)驗和智慧而產(chǎn)生的軟件過程改進的指導(dǎo)性模型。該模型經(jīng)過世界各地軟件組織的實際應(yīng)用臭蚁，證明其對軟件過程改進具有建設(shè)性作用寇蚊。
????????自1991年起第晰，CMM標(biāo)準陸續(xù)發(fā)展應(yīng)用于許多專業(yè)領(lǐng)域谓苟，形成了包含系統(tǒng)工程、軟件工程哗蜈、軟件采購及整合的產(chǎn)品與流程發(fā)展（Integrated Process & Product Development, IPPD）等在內(nèi)的多個模型前标。雖然這些模型已經(jīng)在許多企業(yè)被認可，然而使用多個模型本身也是有問題的距潘。許多組織想要將它們的改善成果擴展到組織中的其他模塊中去炼列，然而每個模塊使用的特定專業(yè)領(lǐng)域模型的差異（包含架構(gòu)、內(nèi)容與方法）音比，在很大程度上限制了這些組織改進成功的能力俭尖。此外，訓(xùn)練洞翩、評鑒和改善活動的成本是昂貴的目溉。CMMI的出現(xiàn)就是為了解上述使用多種能力成熟度模型的問題。
? ? ? ? 之所以需要CMM和CMMI菱农，主要是為了更好的開展軟件過程管理。我們需要積累相關(guān)活動的經(jīng)驗教訓(xùn)柿估，形成了若干可以參考的模型和方法循未，這其中最著名的軟件過程管理參考模型之一可能就是能力成熟度模型CMM以及其后續(xù)的集成模型CMMI。該模型在實踐當(dāng)中被誤解和曲解的若干場景有很多秫舌。
????????首先需要注意的妖，CMM/CMMI并不是一種具體的軟件過程或者軟件開發(fā)方法。在不少文獻中足陨，CMM/CMMI都被視作一種官僚化和教條主義的重型軟件過程嫂粟，并且與當(dāng)前軟件開發(fā)大環(huán)境格格不入。事實上墨缘，按照CMM/CMMI模型的要求星虹，一個軟件組織應(yīng)當(dāng)定義適應(yīng)本軟件組織特點的軟件過程零抬，并且不斷優(yōu)化該過程，來更好的實現(xiàn)軟件組織的商業(yè)目標(biāo)宽涌。然而平夜，實踐中，軟件組織往往為了迎合基于CMM/CMMI模型的“證據(jù)驗證（verification）”評估方法卸亮，可以準備大量文檔化證據(jù)忽妒，導(dǎo)致CMM/CMMI被視作必須在軟件項目管理中必須滿足的某種標(biāo)準（這一點類似于幾乎所有的ISO系列標(biāo)準的貫標(biāo)審核）。顯然兼贸，這是對CMM/CMMI模型意圖和使用方法的曲解段直。
????????其次，CMM/CMMI 并不能作為檢驗軟件過程優(yōu)劣的標(biāo)準溶诞。實踐中鸯檬，很多人會將達到一定成熟度水平視作某個軟件組織的研發(fā)能力，并且試圖進行橫向比較很澄，認為成熟度較高的企業(yè)京闰，其研發(fā)能力應(yīng)該強于成熟度較低的企業(yè)。Leon J. Osterweil 那篇影響極大的論文中也將 CMM/CMMI 視作是檢驗過程優(yōu)劣的標(biāo)準甩苛。而事實上蹂楣，由于企業(yè)所處的環(huán)境以及要實現(xiàn)的目標(biāo)等方面的差異，過程改進對于不同企業(yè)的含義是不一樣的讯蒲。因此痊土，成熟度等級不適宜脫離企業(yè)環(huán)境直接橫向比較，同處于相同的成熟度等級墨林，也并不能說明這些企業(yè)的研發(fā)能力也是相同的赁酝。
????????最后，將 CMM/CMMI 與其他軟件過程或者軟件開發(fā)方法的比較是沒有任何意義的旭等。很多人習(xí)慣于將CMM/CMMI 作為敏捷方法的對立面酌呆，試圖來解釋和說明敏捷方法的優(yōu)勢。事實上搔耕，這種語境之下所謂的“CMM/CMMI 方法”其實已經(jīng)不是一個過程管理的參考模型了隙袁，而是某個特定軟件組織為了迎合或者滿足 CMM/CMMI 評估的需要所定義出來的某個具體軟件過程。顯然弃榨，將這個為了特定目的而定義出來的軟件過程的缺點視作 CMM/CMMI 模型的缺點是不合適的菩收。
????????成功使用CMMI最佳實踐也存在挑戰(zhàn)。沒有發(fā)展方法或方法可以有效地解決所有困難的挑戰(zhàn)或情況[Elm 2007]鲸睛。僅僅因為某個組織已經(jīng)在特定的CMMI成熟度級別進行評估并不能保證組織中的特定項目將成功娜饵。但是，組織使用CMMI可能會失敼俦病（有些失斚湮琛１榉亍）因為他們?yōu)E用模型或追求流程改進以及隨后的誤導(dǎo)動機或不謹慎的領(lǐng)導(dǎo)評估。
????????有時褐缠，在急于達到成熟度的同時政鼠，注重提高組織績效迷路了《游海可能會施加錯誤的標(biāo)準流程和裁剪指南公般。例如，標(biāo)準流程可能過度指定胡桨，從而過度約束項目而不利于項目成功官帘。
????????剪裁指南可能不允許項目具有定制標(biāo)準所需的靈活性解決項目特定需求和優(yōu)先事項的過程[Charette 2004]。特別是這些指南可能不允許有效解決困難項目所需的過程靈巧性挑戰(zhàn)和風(fēng)險昧谊。找到更有效地解決風(fēng)險（和機會）的方法之一就是其中之一開發(fā)產(chǎn)品開發(fā)的迭代和螺旋方法的主要動機 - 和最近的敏捷方法刽虹。在當(dāng)今日益動態(tài)的世界中，基于CMMI組織過程改進方法不能完全依賴傳統(tǒng)方法項目管理方法呢诬，基于瀑布的項目生命周期和重量級分析方法涌哲。
????????相反，標(biāo)準流程可能未明確規(guī)定尚镰，并且省略了經(jīng)過驗證的組織和流程項目實踐阀圾。同樣，標(biāo)準流程的定義可能傾向于處理所有CMMI實踐同等（獲得成熟度）并且不承認某些特定實踐是至關(guān)重要的對業(yè)務(wù)狗唉。適當(dāng)關(guān)注這些做法可能會增加直接價值初烘，但這些做法可能會在收費到成熟度等級的噪音中迷失。
????????許多人太快通過判斷分俯，宣布勝利或宣布失敗肾筐。他們期待即時結(jié)果并經(jīng)常假設(shè)這些結(jié)果將無限期地持續(xù)存在。第一個項目使用敏捷或CMMI必須是成功的缸剪，或者新嘗試的方法被標(biāo)記為失敗;同樣吗铐，一個成功就是假設(shè)代表組織層面的制度化模式。現(xiàn)實是杏节，兩者都不是一般情況下抓歼。
????????“不同的項目需要不同的方法論，一個項目的最佳過程是這個項目所能負擔(dān)的最小過程拢锹。”CMM/CMMI的周期是螺旋模型；核心是過程改進萄喳；范圍是需求嚴格而極少變化的項目卒稳；組織是個人（PSP）、團隊（TSP）和組織的3個層次他巨，組間協(xié)作充坑、培訓(xùn)减江；技術(shù)是傳統(tǒng)結(jié)構(gòu)化方法；管理是側(cè)重于過程的定義捻爷、度量和改進辈灼。一切用數(shù)字和文檔說話；活動是通過過程域來定義活動也榄；實踐是各類級別的關(guān)鍵實踐巡莹，重視關(guān)鍵基礎(chǔ)設(shè)施。雖然CMM/CMMI的通用性比較強甜紫，但是它非常復(fù)雜降宅，成本比較高，而在當(dāng)前軟件開發(fā)過程中囚霸，更傾向于一些簡單腰根、性價比高的軟件過程模型。
????????有句話：所有模型都是錯的（它一定是對某些現(xiàn)實世界的抽象拓型，但并不適用于所有現(xiàn)實）额嘿，但有一些模型是有用的。到20世紀80年代劣挫，全球最大的軟件開發(fā)服務(wù)采購商美國國防部無法按時册养，按預(yù)算和正確的規(guī)格完成項目。盡管與一些最好的和最知名的軟件開發(fā)公司合作揣云，它仍然有近50/50的機會讓項目正確捕儒。擔(dān)心其表現(xiàn)，它與卡內(nèi)基梅隆大學(xué)邓夕，軟件工程學(xué)院一起資助刘莹。該研究所的任務(wù)是編制一套軟件開發(fā)最佳實踐，這些實踐可以提供衡量當(dāng)前供應(yīng)商的基準焚刚，以及當(dāng)前供應(yīng)商為改進其軟件工程實踐而應(yīng)遵循的具體指導(dǎo)点弯。
????????該計劃最終催生了能力成熟度模型集成（CMMI）及其1到5的級別。能力成熟度模型將公司劃分為級別矿咕，從級別1（在未管理的流程或廣告下運營）開始-hoc）到那些達到5級（優(yōu)化）的人抢肛。我們的目的不是要詳細了解每個級別的含義，除非指出在第5級公司必須遵守超過16個軟件和系統(tǒng)開發(fā)過程領(lǐng)域的原則碳柱，包括能力（在級別上）;管理他們的軟件開發(fā)過程（配置管理捡絮，項目監(jiān)控和控制，項目規(guī)劃莲镣，需求管理）;定義他們的軟件開發(fā)方法（決策分析和解決方案福稳，組織培訓(xùn)，風(fēng)險管理瑞侮，驗證的圆，驗證）;定量管理他們的開發(fā)過程（衡量組織過程績效鼓拧，可靠地衡量生產(chǎn)率，錯誤注入和其他關(guān)鍵變量）并優(yōu)化他們的過程越妈，包括不斷審查過程問題的原因并采取措施改進和解決它們季俩。國防部需求的性質(zhì)影響了CMMI的核心。國防部的軟件開發(fā)項目往往很大梅掠，并且經(jīng)常與硬件交互酌住。
????????實質(zhì)上，在CMMI和RUP下宣稱為“最佳實踐”的軟件開發(fā)方法確實在代碼質(zhì)量方面產(chǎn)生了顯著的提高瓤檐。然而赂韵，這在以下方面都付出了巨大的代價：
a）時間（時間更可預(yù)測，但形式顯著增加了軟件開發(fā)的長度與ad-hoc編程）挠蛉；
b）功能相關(guān)性（嚴格的流程不允許應(yīng)用程序輕松適應(yīng)業(yè)務(wù)環(huán)境的變化祭示，因此隨后的應(yīng)用程序通常是“客戶要求的但不是客戶需要的”）；
c）成本令人沮喪（隨后的申請并不便宜谴古，因為該流程的所有形式都有行政管理費用质涛，而且申請的預(yù)計成本仍然與最初的“固定價格”估算不匹配，估計相對于臨時估計而言掰担，其數(shù)量較少汇陆，但仍然顯著偏離）。
????????故我們可以看到带饱，盡管CMM/CMMI是一個比較優(yōu)秀的軟件過程管理參考模型毡代，但是由于其復(fù)雜度、時間勺疼、功能相關(guān)性教寂、成本等方面還有很多不足與欠缺。我們需要的軟件開發(fā)模型要能清晰执庐、直觀地表達軟件開發(fā)全過程酪耕，明確規(guī)定要完成的主要活動和任務(wù)，用來作為軟件項目工作的基礎(chǔ)轨淌。對于不同的軟件系統(tǒng)迂烁，可以采用不同的開發(fā)方法、使用不同的程序設(shè)計語言以及各種不同技能的人員參與工作递鹉、運用不同的管理方法和手段等盟步，以及允許采用不同的軟件開發(fā)工具和不同的軟件工程環(huán)境。
????????綜合考慮躏结，CMM/CMMI的性價比不是非常高址芯，不適用于普遍的軟件開發(fā)當(dāng)中。
參考文獻：
軟件組織與管理方法綜述——榮國平, 張賀, 邵棟, 王青
CMMI or Agile: Why Not Embrace Both!——Hillel Glazer, Entinex, Inc.,Jeff Dalton, Broadsword Solutions Corporation,David Anderson, David J. Anderson & Associates, Inc.,Mike Konrad, SEI,Sandy Shrum, SEI
Traditional software engineering, CMMi and its problems——PSL Corp
