20年研發管理經驗談（八）

本文繼20年研發管理經驗談（七）。

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

1、 CMM基本概念
　　過程（Process）：爲實現既定目標的一系列操做步驟[IEEE-STD-610].
　　軟件過程（Software Process）：指人們用於開發和維護軟件及其相關產品的一系列活動、方法、時間和革新。其中相關產品是指項目計劃、設計文檔、編碼、測試和用戶手冊。當一個企業逐步走向成熟，軟件過程的定義也會日趨完善，其企業內部的過程實施將更具備一致性。
　　軟件過程能力（Software Process Capability）：描述了在遵循一個軟件過程後可以獲得的預期結果的界限範圍。該指標是對能力的一種衡量，用它能夠預測一個組織（企業）在承接下一個軟件項目時，所能指望獲得的最可能的結果。

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

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

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

　　關鍵過程（區）域（Key Process Area）是指一系列相互關聯的操做活動，這些活動反映了一個軟件組織改進軟件過程時所必須知足的條件。也就是說，關鍵過程域標識了達到某個成熟程度級別時所必須知足的條件。在CMM中一共有18個關鍵過程域，分佈在第二至五級中。
　　關鍵實踐（Key Practices）：是指關鍵過程域中的一些主要實踐活動。每一個關鍵過程域最終由關鍵實踐所組成，經過實現這些關鍵實踐達到關鍵過程域的目標。

　　軟件過程評估（Software Process Assessment）是用來判斷一個組織當前所涉及的軟件過程的能力狀態，判斷下一個組織所面向得更高層次上的與軟件過程相關的課題，以及利用組織的鼎力支持來對該組織的軟件過程進行有效的改進。
　　軟件能力評價是（Software Capability Appraisal）用來判斷有意承擔某個軟件項目的軟件組織的軟件過程能力，或是判斷已進行的軟件過程所處的狀態是否正確或是否正常。

　　軟件工程組（Software Engineering Group）：負責一個項目的軟件開發和維護活動的團體。活動包括需求分析、設計、編碼和測試等。
　　軟件相關組（Software Related Groups）：表明一種軟件工程科目的團體，它支持但不直接負責軟件開發或維護工做，如軟件質量保證組、軟件配置管理組合軟件工程過程組等等。在CMM的關鍵實踐中，軟件相關組一般應該根據關鍵過程域和組織的上下文來理解。

　　軟件工程過程組（Software Engineering Process Group）：是由專家組成的組，他們推動組織採用的軟件過程的定義、維護和改進工做。在關鍵實踐中，這個組織一般指「負責組織軟件過程活動的組」。
　　系統工程組（System Engineering Group）：是負責下列工做的我的的團體：分析系統需求；將系統需求分配給硬件、軟件和其餘成分；規定硬件、軟件和其餘成分的界面；監控這些成分的設計和開發以保證它們符合其規格說明。

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

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

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

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

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

（一）、分級標準
　　CMM模型描述和分析了軟件過程能力的發展程度，確立了一個軟件過程成熟程度的分級標準。一方面軟件組織利用它能夠評估本身當前的過程成熟度，並以此提出嚴格的軟件質量標準和過程改進的方法和策略，經過不斷的努力去達到更高的成熟程度。另外一方面，該標準也能夠做爲用戶對軟件組織的一種評價標準，使之在選擇軟件開發商時再也不是盲目的和無把握的。

CMM的分級結構能夠描述爲：
①、初始級：軟件過程的特色是無秩序的，有時甚至是混亂的。軟件過程定義幾乎處於無章法和步驟可循的狀態，軟件產品所取得的成功每每依賴於極個別人的努力和機遇。
②、可重複級：已創建了基本的項目管理過程，可用於對成本、進度和功能特性進行跟蹤。對相似的應用項目，有章可循並能重複以往所取得的成功。
③、已定義級：用於管理的和工程的軟件過程均已文檔化、標準化，並造成了整個軟件組織的標準軟件過程。所有項目均採用與實際狀況相吻合的、適當修改後的標準軟件過程來進行操做。

④、已管理級：軟件過程和產品質量有詳細的度量標準。軟件過程和產品質量獲得了定量的認識和控制。
⑤、優化級：經過對來自過程、新概念和新技術等方面的各類有用信息的定量分析，可以不斷地、持續地對促進過程進行改進。
除第一級外，每一級都設定了一組目標，若是達到了這組目標，則代表達到了這個成熟級別，天然能夠向下一級別邁進。CMM體系不主張跨級別的進化。由於從第二級開始，每個低級別的實現均是高級別實現的基礎。

（二）CMM的主要內容
　　CMM爲軟件企業的過程能力提供了一個階梯式的進化框架，它採用分層的方式來解釋其組成部分，如圖示。在第二至第五個成熟等級中，每一個等級包含一個內部結構的概念。 每一級向上一級邁進的過程當中都有其特定的改進計劃，具體狀況以下。

　　初始級的改進方向是：創建項目過程管理，是使規範化管理，保障項目的承諾；豔進行需求管理方面的工做，創建用戶域軟件項目之間的溝通，使項目真正反映用戶的需求；創建各類軟件項目幾乎，如軟件開發計劃、軟件質量保證計劃、軟件配置管理計劃、軟件測試計劃、風險管理計劃及過程改進計劃等；積極開展軟件質量保證活動（SQA）。
　　可重複級的改進方向是：再也不按項目制定軟件過程，而是總結各類項目的成功經驗，使之規則化，把具體經驗概括爲權利組織的標準軟件過程，把改進軟件組織的總體軟件過程能力的軟件過程活動，做爲軟件開發組織的責任；肯定全組織的標準軟件過程，把軟件工程及管理活動集成到一個穩固肯定的軟件過程當中，從而能夠跨項目改進軟件過程效果，也能夠做爲軟件過程剪裁的基礎；創建軟件工程過程小組（SPEG）長期承擔評估域調整軟件過程的任務，以適應將來軟件項目的要求；積累數據，創建組織的軟件過程庫及軟件過程相關的文檔；增強培訓。

　　已定義級的改進方向是：着手軟件過程的定量分析，已達到定量地控制軟件項目過程的效果；經過軟件的質量管理達到軟件質量的目標。

　　已管理級的改進方向是：防範缺陷，不只在發現了問題能及時改進，並且應採起特定行動防止未來出現這類缺陷；主動進行技術改革管理、標識、選擇和評價新技術，是有效的新技術能在開發組織中實施；進行過程變動管理，定義過程改進的目的，常常不斷地進行過程改進。
　　優化級的改進目標方向是：保持持續不斷的軟件過程改進。

（三）CMM的內部結構
　　CMM爲軟件過程能力的提升提供了一條改進的途徑。CMM由5個成熟度等級組成，每一個成熟度等級有着各自的功能。除第一級外，CMM的每一級按徹底相同的內部結構構成的。成熟度等級爲頂層，不一樣的成熟度等級反映了軟件組織的軟件過程能力和該組織可能實現預期結果的程度。 在CMM中，每一個成熟度等級（第一級除外）規定了不一樣的關鍵過程域，一個軟件組織若是但願達到某一個成熟度級別，就必須徹底知足關鍵過程域所規定的要求，即知足關鍵過程域的目標。

（四）軟件過程評估和軟件能力評價
　　軟件過程評估所針對的是軟件組織自身內部軟件過程的改進問題，目的在於發現缺陷，提出改進方向。評估組以CMM模型爲指引調查、鑑別軟件過程當中的問題，翻過來將這些問題與CMM關鍵實踐活動所提出的指導一塊兒用於肯定組織的軟件過程改進策略。
軟件能力評價是對接受評價者在必定條件下、規定時間內可否完成特定項目的能力考覈，即承擔風險的係數大小。評價包括承包者是否有能力按計劃開發軟件產品，是否能按預算完成等。經過利用CMM模型肯定評價結果後，就能夠利用這些結果肯定選擇某一承包商的風險。也能夠用來判斷承包者的工做進程，推進他們解決軟件過程。

　　CMM爲評估和評價提供了一個參考框架，指出了在評估和評價中一般採用的步驟。 具體來講，評估過程是：選擇一個工做組；完成問卷調查和取樣工做；結果分析；現場訪問；與CMM模型對照分析；依據關鍵過程域的基本狀況列出評估提綱。以上步驟在軟件過程評估和軟件能力評價題勾勒頗有參考價值的方法，但在具體操做時如下這些特色也值得考慮：

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

②、以CMM模型做爲現場調查的路線圖。

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

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

　　儘管軟件過程評估和軟件能力評價有不少類似之處，但因爲其目的和結果的不一樣，它們之間的差別也是必然存在的，如：

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

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

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

 

（五）CMM的組織保證

　　當人們面對CMM實施時，首先想到的就是人員的構成和各類小組的劃分。它是實施CMM的組織保證，是一切活動的基礎。CMM在制定軟件過程實施中本着儘可能不和具體的組織機構和組織形式相聯繫的原則，爲的是提供一個獨立於具體企業而又有普遍指導意義的模型框架。但在實施各類軟件關鍵實踐中，不可避免地要涉及到角色和組織結構。因此爲了使CMM可以適用各類級別和各類規模的企業，SEI提出了一個相對抽象的組織結構，它與組織、項目、人員（角色）相關聯，具備本身特定的術語，並且可能不一樣於其餘組織所用的名詞。例如基本概念中提到的主要的軟件工做組的概念。

 

3、 正確的態度看待CMM

　　SEI的CMM並非軟件開發的方法學，也不是產品模板，更不是過程法律。CMM是過程改進的途徑，是一套指南，幫助你經過持續的重複、測量和提煉，穩步創造與淨化開發環境。CMM的假定是：若是你實施一個不斷重複、測量和提煉的大綱，做爲環境改進的副產物，質量便會天然的提升。不要把CMM設想爲一套規則，而應將它理解爲一個學科，作事的通常方法。在這套指南下運做，你會發現這裏有着廣闊的空間，讓你剪裁和塑造本身的大綱，以適應組織的特定要求。

　　CMM不採用「用這種方法作這類事」的風格，它也不對由問題的IT組織提供快速的糾正方案。CMM是一個指南針，指導你如何逃離暴風雪。CMM是一個大綱，要求你對整個IT組織的有關部分，從高層領導到軟件生產的第一次線工做者，都作出堅決的、長期的實施承諾。成熟的過程不可能在它之間實現。
　　在如何解釋CMM建議時，它容許極大的靈活性。CMM意識到，IT組織之間存在着很大的差異。他們的客戶不一樣，使用的工具不一樣，人員智力和專業背景不一樣，從事的項目屬於不一樣的類型，規模大小不一樣，要求也各不相同。於是，他們應當以本身的方式走向成熟。在一處活用的東西，在另外一處未必適用。這一點很是重要，中國部分軟件公司的前車可鑑也從某種程度上給了咱們建議和經驗教訓，那就是，要靈活應用CMM，不要幻想一晚上就有成效。
從 CMM 到 CMMI 的映射
　　CMM 到 CMMI 的映射是一個複雜的體系，它涉及到 KPA 重構， KP 的再組織。圖 1 只是從整體上描述了 CMM 到 CMMI 的映射關係。

映射分析
　　CMMI 雖然是創建在 CMM 基礎之上，二者大部分類似，但仍是有很大差別。從整體上講， CMMI 更加清晰的說明各過程域和類屬實踐（ generic practice ）如何應用實施，並指出如何將工做產品歸入相應等級的配置和數據管理基線，風險管理策略，驗證策略等。 CMMI 包含更多工程活動，如需求開發，產品集成，驗證等過程域；過程內容的定義更加清晰，較少強調文檔化規程。
如圖，在 CMMI2 級中增長了測量和分析 KPA （ Measurement and analysis ），將各測量分析實踐（ KP ）歸結爲一個正式的關鍵過程域，而在 CMM 中測量分析實踐是散落在各等級中的。所以在 CMMI 中更增強調了量化管理，管理的透明度和軟件開發的透明度獲得了升級。

　　CMMI3 級中增長了需求開發（ Requirements Development ）、技術解決方案（ Technical Solution ）、產品集成（ Product Integration ）、驗證（ Verification ）、確認（ Validation ）、風險管理（ Risk Management ）、決策分析和決定（ Decision Analysis and Resolution ） KPAs 。 CMM 中的軟件產品工程 KPA 被需求開發，技術解決方案，產品集成，驗證，確認 KPAs 所取代；同行評審 KPA 被融入到驗證 KPA 中； CMM 中集成軟件管理 KPA 所闡述的風險管理在 CMMI3 中造成了一個獨立風險管理 KPA 。同時集成軟件管理和組間協調 KPAs 合併成集成項目管理 KPA 。合成團隊、決定分析和解決方案、組織的一體化環境 KPAs 是全新的，其過程內容在 CMM 中沒有說起。
CMMI4 中沒有新的過程域，只是對原來的定量過程管理，軟件質量管理 KPAs 從新構建爲定量項目管理和組織過程性能 KPAs 。
CMMI5 中的技術變動管理和過程變動管理 KPAs 合併爲組織革新與技術推廣 KPA ，缺陷防範 KPA 從新構建爲緣由分析和解決方案 KPA 。
CMM 到 CMMI 的升級
升級前的準備工做

（ 1 ） 回顧 CMMI 模型和其餘的 CMMI 信息，肯定如何使 CMMI 最好的知足組織須要

（ 2 ）擬訂升級策略。

（ 3 ） 在升級過程當中確保之前用於 CMM 改進的投資獲得維持和運用

（ 4 ）將升級事項通告客戶

（ 5 ）將對現有過程域和新增過程域的改進費用編入預算，並提供有關改進須要的培訓。

（ 6 ）肯定組織升級計劃的風險表並管理這些風險，關鍵要識別 CMM 和 CMMI 之間的差別以及這些差別如何獲得支持。

升級的方法：

　　一旦作好了升級前的準備工做，弄清了升級可帶來的利益和成本，可執行下列活動進行升級，這些活動是迭代的。

（ 1 ） 選擇適合組織最好的 CMMI 模型。 CMMI 覆蓋各類知識體，包括項目管理，軟件工程，系統工程，集成產品，過程開發供應商來源。按組織的商業目標選擇模型。

（ 2 ）選擇最適合組織的表示法。 CMMI 有階段式表示法和連續式表示法，因爲 CMM 採用的是階段式的表示法，許多組織都採起 CMMI 階段式表示法，若組織對連續式表示法較熟悉，也能夠採起連續式表示法。

（ 3 ）將選擇的 CMMI 模型與 CMM 對比，肯定須要變動的範疇。具體的對比見上文。 變動的主要活動是對 CMMI 中重組的 KPA 及 CMMI 中新增的 KPA 進行更新。

（ 4 ） 肯定升級會帶來的影響。

（ 5 ）向 CMMI 升級因該報高級管理層的承認。

（ 6 ）變動組織目前的過程改進計劃以支持 CMMI 升級。過程改進計劃要反映出工做的優先級、組織所需增長的新部門。將該計劃送交評審，獲得關鍵儲金保管者（ key stakeholders ）的許諾和承認，計劃要說明升級可能帶來的管理風險和進度風險，所需的培訓，工具，和服務支持。傳達這個計劃並保持更新。

（ 7 ）確保對工程過程組，技術工做組及其餘相關的員工進行 CMMI 的培訓。

（ 8 ）獲取 SCAMPI 評估支持。

（ 9 ） 修改每一個項目已定義的過程使其與項目改進計劃一致。
（ 10 ）給每一個項目制定升級進度表 不一樣的項目升級進度表可能不一樣，若是有的升級工做已經完成則該工做能夠拋棄。

（ 11 ）執行 SCAMPI 評估，看是否全部的目標過程域和目標獲得支持。

處於 CMM 不一樣成熟等級的組織所作的具體工做

（ 1 ） CMM1 級：
　　若是組織正使用 CMM 模型致力於過程改進而並處於 CMM1 級，那麼組織應該繼續用 CMM 模型。在改進的同時，組織將 CMM2 與 CMMI2 進行對比和差別確認，分析這些差別中哪些是對組織有價值的。當組織剛達到 CMM2 級時其主要工做時當即從 CMM2 向 CMMI2 升級。
（ 2 ） CMM2 級，
　　組織應該把其當前的過程改進向 CMMI2 級映射，填補二者之間的差距，從 CMM2 升級到 CMMI2 完成後，在下一步的工做中採用 CMMI 模型進行過程改進。主要有一下幾方面

(1) 將 CMM 中分散的測量分析活動集中到 CMMI2 級測量分析 KPA 中，造成一個獨立的過程域，提升開發的透明度。
(2) 重定位測量分析 KPA （ Measurement and Analysis ）的共同特徵（ common feature ）
測量分析 KPA 重組見表 所示。

　　表示符說明： QPM Co 2 Ac1,3,4,5,6 表示定量過程管理（ Quantitative Process Management ）過程域執行的約定（ Commitment to perform ） 2 和執行活動（ Activities to perform ） 1,3,4,5,6 。
Co 表示執行的約定； Ab 表示執行的能力； Ac 表示執行的活動； SG 表示特殊目標（ Special Goal ）； GG 表示通常目標（ Generic Goal ）；其餘可類推。

（ 3 ） CMMI3 級
①將 CMM 軟件產品工程 KPA 分解爲需求開發、技術解決方案、產品集成、認證、確認 KPAs ，並進行擴充。
②瞭解 CMMI3 級中新增的決定分析和解決方案、合成團隊，組織一體化環境 KPAs ，並填補。
③迭代 CMM2 級的工做。
說明
　　卡內基梅隆大學軟件工程研究所推出 CMM Version 2.0 draft C 後就中止了在 CMM 的改進。 CMM 被 CMMI 所取代是大勢所趨。許多正在運用 CMM 模型進行軟件過程改進的組織紛紛向 CMMI 升級。而 CMMI 模型迄今尚未成熟，卡內基梅隆大學軟件工程研究所 推出了 CMMI-SE/SW 1.1 和 CMMI-SE/SW/IPPD ，在目前的產品集中沒有關於軟件採購方面的內容，估計之後還會推出這個科目。並且從 CMM 向 CMMI 升級也只是處於嘗試階段。組織升級的操做過程，運用 CMMI 模型所帶來的效益等信息還很匱乏，這些信息也爲未能及時反饋到卡內基梅隆大學軟件工程研究所，這也給 CMMI 模型的改進及向 CMMI 的升級工做帶來了必定的難度。

關於CMM評估的一些背景資料
　　CMM評估包括5個等級，共計18個關鍵過程域，52個目標，300多個關鍵實踐。每個CMM等級評估週期（從準備到完成）約需12-30個月。每一級別的評估由美國卡內基梅隆大學的軟件工程研究所受權的主任評估師領導一個評審小組進行，其成員大部分來自企業內部。評估過程包括員工培訓（企業的高層領導也要參加）、問卷填寫和統計、文檔審查、數據分析、與企業的高層領導討論和撰寫評估報告等。評估結束由主任評估師簽字生效。國外CMM等級評估生效，只須要主任評估師的簽字，既沒有某主管單位的批准，也沒有蓋上公章的證書。顯然，國外更看重主任評估師及公司的信譽。

　　取得主任評估師的資格的條件： § 首先要有10年以上的軟件開發經驗； § 其次要在美國卡內基梅隆大學的軟件工程研究所接受培訓，培訓費用每人約需數萬美圓，非美國人加倍； § 第三要通過兩次以上CMM評估的全過程實習； § 第四要獲得已有主任評估師資格的人推薦。主任評估師的資格並不是終身制，如要繼續保持，每一年至少要參加兩次CMM評估。 目前全世界一共只有313個主任評估師，大部分在美國，而我國大陸尚未一個主任評估師。因爲我國在CMM評估中要聘請外籍主任評估師，因此費用較高。據估計，要經過一個級別的CMM評估，費用是經過ISO9001認證的十多倍。

做業
一、請用圖表的形式描述CMM的分級結構？
二、軟件過程性能和軟件過程能力的主要區別是什麼？
三、關鍵實踐的主要描述的是什麼？
四、CMM和CMMI的主要區別有哪些？
五、假如你是SQA，你應該具備什麼樣的心態去看待CMM的評定？