CMM SM是適用于小工程項目和小規模組織的經剪裁的CMM版本。而CMM V1.1是用適宜于那些和政府簽約的大型組織的 標準實踐來表達的，這些實踐必須剪裁才能適合不同于這個樣板的組織的需要。
摘要
由美國軟件工程學會（SEI）開發的軟件能力成熟度模型（CMM, Capability Maturity Model），已經成為軟件過程及質量改進方面的世界主流。盡管CMM被廣泛接受了,但有關如何在商業驅動的軟件 過程改進中有效地使用它，特別是針對小型組織和小型工程項目，仍存在著許多的誤解。有關在小工程或小組織中應用CMM的一些常見問題包括：
什么樣的才算做“小”？標準是根據人？時間？項目大��？還是產品的艱難復雜程度？
什么是CMM的“需求”？是否有不該被應用到小項目/小組織中去的關鍵過程區域或目標？有好的過程“ 不變量”嗎？
造成CMM被濫用的驅動力和動機是什么？
這篇論文以小型組織為例討論了怎樣在各種商業環境中正確而有效地使用CMM。從那些對改進其軟件過程感興趣的任何組織得出的結論是：使用為大組織/大項目所開發的發行版來相應地解釋用于小項目或小組織中的CMM，可能會存在程度上的差異，但它們決不會是本質上的不同。正確有效地使用CMM，要求具有專業性的判斷，并且能夠理解CMM是如何針對不同的用途來進行建構的。
1. 介紹
軟件工程學會(SEI)是由美國國防部1984年設立的一個聯邦資助研發中心，主要通過大范圍承包工程的研究來尋求軟件工程技術的躍遷——即改進軟件工程的實踐。在某種意義上, SEI的存在是“軟件危機”（即習慣性的拖延，超出預算，達不到預期功能，以及不可靠的質量等[Gibbs94]）的結果。硬性地講，危機大多是由軟件自身造成的，一位首席信息官曾說過：“我寧愿讓它有了錯，也不想讓它出得晚，稍后我們總會去修理它的�！痹S多組織要完成預期成本和進度目標的關鍵就在于——經常性地關注質量成本，一再地學習以往20年由美國工業界所推演出的現稱為“全面 質量管理（Total Quality Management，TQM）”的一門課程。
引用DeMarco [DeMarco95], 各種因素綜合造成的如下情形并不令人驚奇：
“人們總是抱怨我們，因為他們知道在抱怨的時候，我們會努力工作�！�
“大多數軟件評估報告是令人沮喪的……但好在他們還不是對評估過程完全不滿�！�
“正確的進度表是絕對不能達成的，只不過還不那么明顯地不能達成�！�
DeMarco繼續觀察到我們的工業界正在疲于奔命,而感覺上唯一真切的選擇就是降低質量以換取速度。
TQM課程聚焦于在質量管理引導下減少開發周期, 提高生產率，增進客戶滿意程度并努力取得商業上的成功。挑戰，當然被定義成“聚焦質量”的實用手段是什么，隨即就要系統地尋求各種質量問題。也許SEI最成功的產品就是軟件能力成熟度模型(CMM)，就是說，它給在全世界軟件社團中已成為主流的軟件過程改進提供了路標[Paulk95]。CMM定義了怎樣使開發組織的軟件過程走向成熟的5個等級的框架結構。這些等級描述了從特別紊亂的混沌過程到成熟的、有紀律的軟件過程的進化路徑。如圖1中的概示，5個等級和18個關鍵過程區域詳細描述了它們。5個成熟度等級指明了對于成功的過程改進（即在許多案例的研究和調查中被文檔化記錄的有效性）的優先順序[Herbsleb97,Lawlis95,Clark97]。
表 1. CMM 概況
盡管CMM的當前發行版本1.1的焦點是在與政府簽約的大型組織和大型工程項目上,但CMM是被設計成了為實現對軟件工程及項目管理的詳細指導及示例而普遍適用并分級細化的抽象模型。CMM的關鍵過程區域，是以能達成被描述為關鍵實踐、子實踐及示例的目標而滿足的。CMM用以評估的構件是成熟度等級、關鍵過程區域和目標。另外的構件則在怎樣解釋模型上提供了信息和指導。18個關鍵過程區域共有52個目標和316個關鍵實踐。雖然CMM的“需求”可以被概括成對52個目標的描述，但它的支持材料卻包括了將近500頁的信息。關鍵實踐和示例描述了好的工程和管理實踐是什么樣，但是沒有說明如何去實現這些過程。
CMM之所以能成為一個指導過程改進的有用工具，是因為它歷史性地成為了通過對軟件社團已開發軟件的廣泛評審而形成的全面質量管理(TQM)概念的一個常規應用。它的五個等級是非常簡單的，但如能將其巧妙運用，就會找到一個激勵人的支點，正如美國國防部的程序經理所坦陳的：“底線是進度表。我的晉升和加薪，就全靠首當其沖地完成進度表了�！�
正當CMM由于對指導軟件過程改進的重要性而令人鼓舞地在全球變得流行起來的時候，它也正被一些人濫用和誤用，并且另外也有人沒能有效地使用它。CMM v1.1提供的指導往往是面向大工程和大組織的，在使用過程中小組織發覺到這方面有問題，盡管我們堅信CMM的基本概念對于任何組織規模、任何商業環境、任何應用領域都是適用的。
難道按時完成進度、預算和需求，對于小項目或小組織來講，真的那么重要嗎？在某些環境下，這確實是值得商榷的，就如同商用小塑膠袋，拿它跟那些市場份額總是占先的裝船出口的頂好產品相比，其成本是極其微不足道的。如果一個組織的雇員十分滿足安于現狀，那么CMM所提供的能導致真實變化的東西將會很少；變化只會出現在那些對現狀非常不滿并且樂于標新求異的經理和員工身上。無論對大組織還是小組織而言，這都是無庸置疑的。
CMM在稱心如意地實施管理及工程實踐方面，都提供了良好的建議，它強調以人為核心的管理、溝通和協調以及能體現軟件開發和維護特性的強化設計的過程。無論如何，把它看成靈活的指南而非生硬的指令吧，還有對于軟件工程和管理，以及應用領域和組織的商業環境等方面，CMM用戶必須能夠在這些方面應用其基于知識和經驗的專業判斷。因為CMM聚焦于軟件，所以TQM的一些重要方面不能直接照搬到模型里，比如系統工程里的“人的問題（people issues）”和“較寬泛的審視（broader perspective）”，這些在商業上可能是至關重要的。CMM應該被看成使用在軟件過程改進系統步驟里的一種上下文工具，比如SEI的IDEAL模型，如圖2所示[McFeeley96]。
在對軟件過程改進的討論中，開始的問題總應該是這樣的：為什么軟件組織會對使用CMM感興趣？如其愿望是以直接依從商業目標以及心甘情愿投身改革而來改進過程，那么CMM確實是效用非凡、功能強大的工具；如果CMM只被當成單純的短期時髦，那可真是把一劑糟糕的藥方拿到了手。如果驅動力是客戶利益，理想情況下客戶利益將導致客戶和供應商之間協作的改進。有時供應商的利益集中在軟件能力評價(Software Capability Evaluations，SCEs)上, 如此則可在那些來源選擇及簽約監督方面是由政府獲取代理的項目上有所表現。國防部在執行軟件能力評價(SCEs)標準的政策上是排斥絕大多數小組織和小項目的[Barbour96]，但也存在它們可以有所作為的機遇。
很多CMM的濫用都對“其他人”可以做什么的擔心置于不顧。如若一個開發組織能在用CMM來導引勝過被需求來牽引上達成共識，那么在模型中要解決問題的很大一部分就化解掉了。有很多這樣的案例。盡管如此，那些對于好的工程和管理實踐的無知仍將成為問題。對于那些只有很少的管理方面的經驗和訓練而只是因技術優秀就被提拔到管理層職位的人來講，問題是顯而易見的。由DOD（美國國防部）特種部隊確認并提出的問題是[DOD87]：
“少數區域在最佳當前實踐和平均當前實踐之間有著如此巨大的缺口�！�
“大問題不在技術方面……現今軍事軟件開發的主要問題不再是技術問題，而是管理問題�！�
2. 小組織和小項目
本篇論文的焦點對準了在小組織正確而有效地使用CMM，因為經常有人問我，“CMM是否能被用在小項目(或小組織)？”然而有關“小”的定義卻是模糊難解的，如表1所示。 在某段時間里我們致力于為小項目和小組織而開發出剪裁適當的CMM，1995年CMM剪裁工作室的結論是我們甚至不能對什么才算“小”的真正含義達成一致意見！這個結果得出了一篇更注重于“如何剪裁CMM”而不是“已為小組織而裁好的CMM”的報告[Ginsberg95]。1998年SEPG會議關注于CMM及小組織上，“小”被定義成“5個或更少的人為期3至4個月的開發”。Brodman和Johnson則定義“小組織”為少于50個軟件開發人員并且“小項目”為少于20個開發人員[Johnson98]。
表2. 定義一個小項目
注意從小到微小的項目是在被Humphrey稱為小組軟件過程（Team Software Process，TSP）的范圍里，而個人的開發努力則在個人軟件過程（Personal Software Process，PSP）的范圍里[Humphrey95]。TSP和PSP闡明了CMM的概念是如何應用到小項目中的�！盎奶啤弊凅w則描述了一個解釋性的問題。在兩種場合里，變體都會被論述，問題是“項目”的定義。兩種情況下它都是個維護環境，而且組織的“項目”將被描述為CMM的任務；更多關于CMM“項目”的精確解釋是一個基線的升級或者維護的發行……但術語的沖突會將其搞亂。
對于那些使用CMM的小組織來說，首要的挑戰就是其主要商業目標要能存活下來！甚至在決定之后，現狀是不能令人滿意的而且過程改進也將有助于發現資源并為過程改進分派職責,接下來通過制定與部署過程所要做的是一項艱難的商務決定。小組織往往相信：
我們全都是勝任的——人們是被雇傭來做工作的，我們可不想負擔那些要在雇傭期間進行培訓所花的任何時間或金錢
我們全都彼此溝通——因我們是如此緊密地在“滲透式”工作
我們全都是英雄好漢——我們無論做任何需要做的事情，規則都不適用于我們（這些恰恰達成了將工作完成的方式），我們承受住了短周期及高壓力
然而對于小組織，也正象大組織一樣，有著非文檔化的需求所帶來的麻煩，以及無經驗的經理人員、資源分配、培訓、同行評審和產品文檔等方面帶來的問題。盡管有著這些挑戰，小組織仍能非同尋常地進行創新和提高生產率。盡管有一大把需要人們去解決的大塊問題，通常小組織比大組織更具生產效率，他們能更敏銳地成形生產要素并且遠遠更少見有溝通方面的問題。無論如何，遺留下來的問題是，小組織也需要過程紀律嗎？回答這些CMM咒語,我們需要考慮到紀律包括了什么? 而那將引入這篇有關CMM指導性課題論文的核心。
即便如此，評估小組織時運用最新式的評估過程是明智可取的。為期兩周的CMM內部過程改進基礎評估(CMM IPI)的形式也許是多余的[Strigel95, Paquin98, Williams98]，甚至會由于缺乏監控而導致某些遺漏，而關鍵是有效地確認重大問題。我建議將注意力集中在建立在企業文化上的制度化實踐方面：如規劃、培訓等等，并確切地將過程改進落實到商業需要上。
3. 解釋CMM
CMM都適用在什么地方呢？CMM是按照在任何環境中為任何項目都能提供良好的軟件工程和管理實踐來塑造的。模型是被分層次描述的：
成熟度等級 (5)
->關鍵過程區域 (18)
->目標 （52）
->關鍵實踐 （316）
->子實踐和例子 (許多)
根據我最近十年來在軟件過程工作方面的經驗，闡述的環境以及CMM的剪裁需要包括：
非常大的程序
虛擬項目或組織
地點上分布式的項目
快速原型法的項目
研究及開發組織
軟件服務組織
小項目和小組織
對于小項目和小組織的解釋性指導也同樣適用于大項目和大組織。在正確有效地使用CMM的過程中，智慧和常識是必要的[Paulk96]。所有（軟件）項目都有所不同，但所有（軟件）項目也都有所相同——這可全都是真的。我們必須平衡現實：相似與唯一，秩序與混亂。那些成功所締造出的持久組織[Collins94]是真正有能力的學習型組織[Senge90]；此外在其他地方也必須得益于其成功。
CMM的標準構件是成熟度等級、關鍵過程區域和目標。CMM的所有實踐都是有益處的。既然那些詳細的實踐都首先支持大型簽約的軟件組織，也就沒必要正好寫成是直接適用于小項目和小組織——然而它們同樣提供了如何達到目標和可重復地實現已定義的、規范的、不斷改進的軟件過程。這樣就會避免了過程評估方式上的簡單武斷——諸如“去問老張吧”。
我最通常的指導性建議是開發出一套適用于組織的置于CMM術語和語言間的映射。特別地,組織結構的期限行為、角色、關系以及過程的形式都需要映射到其組織的相應部分，以防止出現無法理喻的事情，諸如“荒誕的一小時項目”。組織結構的例子包括諸如質量保證、測試及配置管理等“獨立小組”。應該用術語明確地指定適當的組織角色，諸如項目經理及項目軟件經理等。人們可以擔當多重角色，例如，一個人可以同時做項目經理、項目軟件經理、軟件配置管理（SCM）經理等等。明確規劃好這些，將生發出對CMM更生動簡潔也更協調一致的闡明。
一旦術語問題被理解了，我們就得考慮什么是守紀律過程的“不變量”（invariant，一個必須永遠為真的約束）以及哪些實踐依賴于上下文關系。除了軟件轉包合同管理（即若無轉包合同的話就可能成為“不可用的”），一般來說我們總是假定關鍵過程區域及目標關聯到任何環境。我想象不出同行評審被等級3的組織適當剪裁掉的情形。盡管所選擇出的實踐（諸如正式方法）可以替代同行評審，但這還是一個需要足夠專業性判斷的問題。擁有專業性的判斷和訓練、經驗豐富的評估人員是至關重要的，甚至對小組織也一樣！[Abbott97]
我從沒見過下列哪個環節是不必要的(盡管實現方式不同)：
將客戶(系統)的需求記錄成文檔
與客戶(并且最終用戶)溝通
同意承諾并簽約
計劃
文檔化過程
工作細化結構
當然，一些實踐都被處理成了“大項目的實現”。小的項目未必需要軟件配置管理組或者變更控制部門……，然而配置管理及變更控制總還是要有的。一個獨立的軟件質量保證(SQA)組也許不是必要的，但目標的認可始終是需求要被滿足。一個獨立的測試組也許沒必要設立，但測試總是必要的。即使小組織和大組織之間的實現有著根本的不同，但我們看到對于上下文相關的實踐，其意旨是建設性的。如果有人讀到CMM所定義的“組”，它是被陳述為“一個組可以是被分派兼職的單獨個人、從不同部門分派了幾個兼職的個人，也可以是全職的幾個個人”，這里就有意迎合了環境的變化。
除了這些, 一些特殊的問題再三地出現, 尤其是對于小組織，涉及有：
管理資助
度量
軟件工程過程組(SEPGs，Software Engineering Process Groups)
“不保修”過程
文檔化過程
剪裁
培訓
風險管理
計劃
同行評審
獲取高層管理的贊助是構建組織能力的關鍵成分，這看起來固然很陳腐老套。做為個體，我們可以在我們可操控的范圍內磨練自身的專業素養及自制能力�？墒侨粢粋�組織作為一個整體來改善其效能，那么其高層管理就必須積極地支持變革。由下至上地改革，無須贊助和協同，卻能夠導向超過可預期改進的組織能力的勝地，這可真是奇聞了。即便如此，當總裁（或者公司創始人）是主角時，敬重“冠軍”往往是具有撼動整個組織的影響力的——包括總裁本人。
對于大多數組織而言，管理實際上是必須基于一個度量基礎的范例轉換。掌握有用的數據，就是說你必須了解性能數據的含義以及如何有價值地去分析它。從收集簡單的有用數據開始，你也不得不敏感于經由度量而導致紊亂行為的潛在因素[Austin96]。度量活動要確認什么是重要的，但一些事情是難于度量的。管理需要確保注意力傾注在項目的所有可評價方面，包括那些難于度量的，而不僅僅是那些易于度量和跟蹤的。
在大多數組織中，軟件工程過程組(SEPG)或一些類似小組應該成為協調過程定義、改進及部署活動的工作組。把資源奉獻給SEPG的原因之一是要確保完成評估調查。許多改進綱要僅僅因為有著不是從評估所導致的行動而失敗。小組織可能沒有全職的SEPG人員，但改進的職責應該明確地加以指派和監控。
起始于“不保修”（"as is"）過程，而不是“合理”（"should be"）過程——對于有效實施的實踐與對指派任務的抵觸來說，這相當于兩者之間的杠桿，此起彼落。要求自上而下的每個人都遵循的“合理”過程，若其顯著地不是由被授權的工人所參與開發的，則將是一個通用的失敗處方�！安槐Ｐ蕖边^程進化的理由是人們從事工作是希望工作任務能被完成（即使那意味著要整天圍著系統轉）�！昂侠怼边^程或可行，或不可行——只有在特定的文化環境中才能成為可行。伴隨著過程管理和改進的組織焦點，“不保修”和“合理”過程將聚合在一點——即導致有組織地進行學習。
文檔化你的過程。文檔化地記錄一個過程(或產品)的原因是 1)溝通——給別人一個當前的交待以及給自己一個今后的備忘；2)理解——如果你不能寫下它，你就不能真正理解它；以及 3)鼓勵連貫一致性——擁有可重復的優勢。文檔化過程支持有組織地學習以及避免重復地打造解決通用問題的車輪（車輪在任何地方都被置于一個反復重用的過程）。歸檔是如此重要，但有用的文檔最好不要冗長繁雜。我們生活在一個迅速變化的世界里，請保持文檔簡潔吧。過程也不要冗長繁復。CMM關注做事（doing things），而不是成事（having things）。一個1-2頁的過程說明是足夠了，子過程和步驟能按需調用就行。運用好的軟件設計原則，比如在定義過程中使用內存空間的局域性、信息隱藏以及抽象。另外的實用經驗是每周最多跟蹤2-3個任務的工作。其順序應由少量指導性原則或法則所確立，而不是由復雜的控制來確立[Wheatley92, page 11]。
過程需要剪裁到項目所需的程度[Ginsberg95,Ade96]。雖然標準過程提供了一個基礎，但每一個項目也都將有其獨特的要求。剪裁時不切實際的約束可導致執行過程中的重大阻力。正如Hoffman所表述的，“別生造感悟也別強求過程�！盵Hoffman98]
過程所需的形式化程度對大組織和小組織都構成了威脅[Comer98]。對于那些每每提到要“按照文檔化步驟”的等級2的25個關鍵實踐中的每一個，應該存有很個別的步驟嗎？答案正如在CMM書籍《文檔和CMM》(Documentation and the CMM)的4.5.5小節所論述的，是一個響亮的“不！”——文檔的包裝是組織化的必然結果。
文檔化的過程如果沒有加以有效地部署，只會具有很小的價值。要想達成文檔化的大量買進，過程實現必須成為過程定義和改進的一部分。通過多種機制的培訓，對于協調一致和效力非凡的軟件工程及管理將是建設性的。培訓的動機是發展技能。有很多“培訓機制”不同于能有效培養技能的正規課堂培訓。其中應該被認真考慮的是正規的顧問制。在此情形下，形式化意謂著寄希望于沒有經驗的顧問。形式化提示要在如何指導及監督顧問的效力上訓練人們。
在過程或技術的最初部署之后，培訓仍然是一個問題[Abbott97，Williams98]。當人員變動時，培訓所增加的需要可能不會被充分地認識。顧問學徒制能充分地解決這一問題，但是除非能謹慎地加以監督，否則不能設想會有滿意的結果。
管理上的培訓是特別重要的，因為低下的管理會削弱一個好的團隊。那些因其技術技能而被提拔到管理層的人，將不得不重新學習包括人際關系在內的一套新的技能[Mogilensky94, Curtis95,Weinberg94]。
軟件工程管理的部分論題確實是風險管理。感覺上，CMM就是關于管理風險的。我們致力于確立穩定的需求，以便能有效地實施計劃和管理，但商業環境總在迅急而紊亂地變化著。我們嘗試在軟件那混沌的大海里建造秩序的孤島，但是秩序和混沌都自有其位置。Wheatley建議，“為了生存，開放系統維持在一非平衡狀態，保持系統均衡以便它能改變和成長�！盵Wheatley92, page 78]盡管我們能確立幫助我們管理混沌世界里的風險的過程，我們也需要變化和成長。
這意味著你應該使用一個增量的或進化的生存周期。如果你想重心集中到風險管理上，螺旋模型將是首選的生存周期模型。如果重心集中在籠絡客戶上，可能快速原型法或接合應用設計更好一些。少數長期項目對穩定環境的奢求是必要的，對其瀑布生存周期將是首選——可能它仍是最普遍通用的生存周期。注意，無論如何，對于小項目，瀑布生存周期都會是一個極佳的選擇。
成功的過程定義和改進的頭號因素是“全程計劃（planfulness）”[Curtis96]。計劃是每一個主要軟件過程都需要的，但不外乎綁定合理的判斷、由組織決定什么是“主要的”以及怎樣包裝計劃。一個計劃可以駐留在幾個不同的工件或被植入一個大計劃當中。
即使你可以對最好的同行評審有爭議，但簡單的事實是同行評審帶來的好處遠遠超出了其成本。數據表明一些檢測表格應該是慣用的[Ackerman89]，但任何學院式或嚴格的評審表格，諸如結構化預排，都附加了重要價值。不幸地，認可同行評審并不意味著我們在系統地做著這件事。我們需要“走在路上”，而不僅僅是“說在嘴上”。這對技術人員來說是很大的挫折，他們不理解CMM所強調的管理，然而糟糕的管理會導致放棄好的工程實踐，比如同行評審。
另外還有其他被確定為是小組織和小項目的問題，Paquin[ Paquin98 ]認定了下面的5個：
評估
工程焦點
文檔
需求功能
成熟度提問單
我們沒有討論等級2的項目焦點對小組織構成的挑戰。軟件過程改進包括了那些對小項目而言是過度的開銷。一些勸告從組織化觀點來攻擊恰似混合了等級2和等級3而又的確不失為合理途徑的小項目的過程改進[Comer98，Paquin98]。CMM本就是為任何規模的組織或項目而考慮的[Paulk96]。盡管無須過程焦點一個組織也能達到等級2，但極其高效的組織化學習的策略將成為減少項目開銷的組織資產的一個重點。同時，必須認識到項目等級的改變可能會形成多半是基于正當利害關系的阻力，而且探察阻力時需要考慮組織進行學習過程的那部分。
需求功能是一個問題，因為比起人來可能有更多的CMM功能。這個問題是做為技術或角色的映射來討論的。成熟度提問單因使用CMM技術而成為關注焦點，它可能在填寫的過程中被搞亂。以組織的技術來表達提問單，甚至對于非正式的評估及度量也是很需要的先導。
Abbott[Abbott97]指明了對于小組織的軟件過程改進的6個關鍵：
高層管理的支持
正確的用人原則
將項目管理的法則應用到過程改進
與ISO 9001的集成
來自過程改進顧問的協助
聚焦在提供項目上及商業上的價值
如果將好的項目管理應用到軟件項目中是確保成功的最佳途徑，那么應該象對待其他任何項目一樣來對待過程改進就同樣是正確的。ISO 9001是在大組織里比小組織里使用更頻繁的一個評估版本，因而Abbott也有興趣針對他的小公司指出這一點。
Brodman和Johnson[Johnson98]認為針對小組織/小項目的挑戰有7種：
處理需求
生成文檔
管理項目
分配資源
度量過程
促導評審
提供培訓
Brodman和Johnson開發了一個針對小型商業、組織和項目的CMM剪裁版本[Johnson96, Johnson97, Brodman94]。盡管如此，大多數CMM的關鍵實踐還是被剪裁到了《LOGOS剪裁版CMM》里，變化體現在：
已存實踐的凈化
明顯的夸張
選擇性實踐的介紹(特出地作為例子)
伴隨小商業/小組織/小項目的結構及資源的實踐調整
因此針對小組織而剪裁CMM的相關改變是可以根本不予考慮的。
4. 濫用CMM
正確使用CMM意味著要平衡相互沖突的目標�；贑MM的評估要求運用專業性的判斷。盡管如此，CMM在做出這些判斷以及消除對一個明確的、反復的、非設計工作特有的過程的主觀臆斷等方面都提供了大量的指導。CMM有時作為一整套過程需求被提及，但它不能有任何含有“將要”(shall)的語句。這就是在核對（子）實踐一致性時造成CMM濫用的原因。
有些是勉強地、無能地去解釋、剪裁或應用判斷力。這是易于委派到關鍵實踐的，但卻愚笨透頂。此種蠢行常常由客戶意圖及能力的偏執來驅動。我在更多的場合聽說某人要做某些傻事，但他們害怕客戶無知無能到理解不了不能完全生搬硬套CMM的道理的地步。這對于軟件能力評價來說是明顯有疑問的。判斷可能不一致是對的——并且有時只有如此才合理。曾在某一環境中適用的卻可能滿足不了一個新項目。那就是我們推薦把過程成熟度包含在風險評估要比使用成熟度等級來過濾報價者更好的原因。小組織應該較少關心這個問題，因為對小組織的軟件能力評價未必是劃算的。它是從事許多小項目的大組織的一個問題的多個方面。
十分不幸，我沒有此問題的解決方案。象這種CMM能幫助組織改進軟件過程的“標準”，卻是聚焦在達到一個沒有從事潛在的、能導致紊亂行為的過程的能力成熟度等級。成熟度應該成為改進的度量，而不是改進的目標。這就是為何我們強調需要依靠改進來達到商業目的。
5. 結論
底線是軟件過程改進應該有助于達成商業成就——而不是為其自身理由。無論對大組織還是小組織，這都是真真確確的。最好的忠告來自于Bellcore的總裁Sanjiv Ahuja：“讓常識奏效！”
構造軟件是一項設計密集的創造性活動。同時過程的紀律對于能否成功是至關重要的——目標是解決問題——同時要有創造活力。就算軟件本身不是重復的，軟件的過程也應該是可重復的。要在紀律約束和創造活力之間取得均衡是頗具挑戰性的[Glass95]。失去了創造性視野，軟件工作的精密設計的天性將被引入令人窒息的僵化境地。而失去了所需的紀律觀念，也將導致混亂不堪。
CMM描繪了軟件過程改進的一個“常識工程化”路徑。它的成熟度等級、關鍵過程區域、目標及關鍵實踐經受了軟件社團內部的廣泛討論和評審。同時CMM既非完美無缺也不包容一切，它只是表達了軟件社團的一種廣泛一致的意見，并且成為指導改進工作的一個有用工具，它也有助于小型軟件組織改進它們的過程 [Abbott97, Hadden98b, Hoffman98, Pitterman98, Sanders98]。
小組織應該認真地考慮PSP和TSP[Ferguson97,Hayes97]。掌握了PSP課程，我可以高度評價其建立了自我約束的能力。注意看書的效果不能等同于掌握課程及實際操作。CMM所從事的過程改進組織化的一個側面，就是PSP致力于建造個體從業者的能力。PSP確信個人能夠——基于他或她自有的性能數據——遵從紀律尊重價值——以工程化途徑來構建軟件。
參考資料
Abbott97 John J. Abbott, "Software Process Improvement in a Small Commercial Software Company,", Proceedings of the 1997 Software Engineering Process Group Conference, San Jose, CA, 17-20 March 1997.
Ackerman89 A.F. Ackerman, L.S. Buchwald, and F.H. Lewski, "Software Inspections: An Effective Verification Process," IEEE Software, Vol. 6, No. 3, May 1989, pp. 31-36.
Ade96 Randy W. Ade and Joyce P. Bailey, "CMM Lite: SEPG Tailoring Guidance for Applying the Capability Maturity Model for Software to Small Projects," Proceedings of the 1996 Software Engineering Process Group Conference: Wednesday Papers, Atlantic City, NJ, 20-23 May 1996.
Austin96 Robert D. Austin, Measuring and Managing Performance in Organizations, Dorset House Publishing, ISBN: 0-932633-36-6, New York, NY, 1996.
Barbour96 Rick Barbour, "Software Capability Evaluation Version 3.0 Implementation Guide for Supplier Selection," Software Engineering Institute, Carnegie Mellon University, CMU/SEI-95-TR-012, April 1996.
Brodman94 J.G. Brodman and D.L. Johnson, "What Small Businesses and Small Organizations Say About the CMM," Proceedings of the 16th International Conference on Software Engineering, IEEE Computer Society Press, Sorrento, Italy, 16-21 May 1994, pp. 331-340.
Clark97 Bradford K. Clark, "The Effects of Software Process Maturity on Software Development Effort," PhD Dissertation, Computer Science Department, University of Southern California, August 1997.
Collins94 James C. Collins and Jerry I. Porras, Built to Last, HarperCollins Publishers, New York, NY, 1994.
Curtis95 Bill Curtis, William E. Hefley, and Sally Miller, "People Capability Maturity Model," Software Engineering Institute, CMU/SEI-95-MM-02, September 1995.
Curtis96 Bill Curtis, "The Factor Structure of the CMM and Other Latent Issues," Proceedings of the 1996 Software Engineering Process Group Conference: Tuesday Presentations, Atlantic City, NJ, 20-23 May 1996.
DeMarco95 Tom DeMarco, Why Does Software Cost So Much?, ISBN 0-932633-34-X, Dorset House, New York, NY, 1995.
DOD87 Department of Defense, "Report of the Defense Science Board Task Force on Military Software," Office of the Under Secretary of Defense for Acquisition, Washington, D.C., September 1987.
Ferguson97 Pat Ferguson and Jeanie Kitson, "CMM-Based Process Improvement Supplemented by the Personal Software Process in a Small Company Environment,", Proceedings of the 1997 Software Engineering Process Group Conference, San Jose, CA, 17-20 March 1997.
Gibbs94 W. Wayt Gibbs, "Software's Chronic Chrisis," Scientific American, September 1994, pp. 86-95.
Ginsberg95 Mark Ginsberg and Lauren Quinn, "Process Tailoring and the Software Capability Maturity Model," Software Engineering Institute, CMU/SEI-94-TR-024, November 1995.
Glass95 Robert L. Glass, Software Creativity, Prentice Hall, Englewood Cliffs, NJ, 1995.
Hadden98a Rita Hadden, "How Scalable are CMM Key Practices?" Crosstalk: The Journal of Defense Software Engineering, Vol. 11, No. 4, April 1998, pp. 18-20, 23.
Hadden98b Rita Hadden, "Key Practices to the CMM: Inappropriate for Small Projects?" panel, Rita Hadden moderator, Proceedings of the 1998 Software Engineering Process Group Conference, Chicago, IL, 9-12 March 1998.
Hayes97 Will Hayes and James W. Over, "The Personal Software Process (PSP): An Empirical Study of the Impact of PSP on Individual Engineers," Software Engineering Institute, Carnegie Mellon University, CMU/SEI-97-TR-001, December 1997.
Herbsleb97 James Herbsleb, David Zubrow, Dennis Goldenson, Will Hayes, and Mark Paulk, "Software Quality and the Capability Maturity Model," Communications of the ACM, Vol. 40, No. 6, June 1997, pp. 30-40.
Hoffman98 Leo Hoffman, "Small Projects and the CMM," in "Key Practices to the CMM: Inappropriate for Small Projects?" panel, Rita Hadden moderator, Proceedings of the 1998 Software Engineering Process Group Conference , Chicago, IL, 9-12 March 1998.
Humphrey95 Watts S. Humphrey, A Discipline for Software Engineering, ISBN 0-201-54610-8, Addison-Wesley Publishing Company, Reading, MA, 1995.
Johnson96 Donna L. Johnson and Judith G. Brodman, The LOGOS Tailored Version of the CMM for Small Businesses, Small Organizations, and Small Projects, Version 1.0, August 1996.
Johnson97 Donna L. Johnson and Judith G. Brodman, "Tailoring the CMM for Small Businesses, Small Organizations, and Small Projects," Software Process Newsletter, IEEE Computer Society Technical Council on Software Engineering, No. 8, Winter 1997, p. 1-6.
Johnson98 Donna L. Johnson and Judith G. Brodman, "Applying the CMM to Small Organizations and Small Projects," Proceedings of the 1998 Software Engineering Process Group Conference, Chicago, IL, 9-12 March 1998.
Lawlis95 Patricia K. Lawlis, Robert M. Flowe, and James B. Thordahl, "A Correlational Study of the CMM and Software Development Performance," Crosstalk: The Journal of Defense Software Engineering, Vol. 8, No. 9, September 1995, pp. 21-25. Reprinted in Software Process Newsletter, IEEE Computer Society Technical Council on Software Engineering, No. 7, Fall 1996, pp. 1-5.
McFeeley96 Bob McFeeley, "IDEAL: A User's Guide for Software Process Improvement," Software Engineering Institute, CMU/SEI-96-HB-001, February 1996.
Mogilensky94 Judah Mogilensky and Betty L. Deimel, "Where Do People Fit in the CMM?," American Programmer, Vol. 7, No. 9, September 1994, pp. 36-43.
Paquin98 Sherry Paquin, "Struggling with the CMM: Real Life and Small Projects," in "Key Practices to the CMM: Inappropriate for Small Projects?" panel, Rita Hadden moderator, Proceedings of the 1998 Software Engineering Process Group Conference, Chicago, IL, 9-12 March 1998.
Paulk95 Carnegie Mellon University, Software Engineering Institute (Principal Contributors and Editors: Mark C. Paulk, Charles V. Weber, Bill Curtis, and Mary Beth Chrissis), The Capability Maturity Model: Guidelines for Improving the Software Process, ISBN 0-201-54664-7, Addison-Wesley Publishing Company, Reading, MA, 1995.
Paulk96 Mark C. Paulk, "Effective CMM-Based Process Improvement," Proceedings of the 6th International Conference on Software Quality, Ottawa, Canada, 28-31 October 1996, pp. 226-237.
Pitterman98 Bill Pitterman, "Key Practices to the CMM: Inappropriate for Small Projects?" panel, Rita Hadden moderator, Proceedings of the 1998 Software Engineering Process Group Conference, Chicago, IL, 9-12 March 1998.
Sanders98 Marty Sanders, "Small Company Action Training and Enabling," in The CMM and Small Projects, Society for Software Quality Roundtable, Washington, DC, 26 January 1998.
Senge90 Peter M. Senge, The Fifth Discipline: The Art & Practice of the Learning Organization, Doubleday/Currency, New York, NY, 1990.
Strigel95 Wolfgang B. Strigel, "Assessment in Small Software Companies," Proceedings of the 1995 Pacific Northwest Software Quality Conference, 1995, pp. 45-56.
Weinberg94 Gerald M. Weinberg, Quality Software Management, Volume 3: Congruent Action, ISBN 0-932633-28-5, Dorset House, New York, NY, 1994.
Wheatley92 Margaret J. Wheatley, Leadership and the New Science, Berrett-Koehler Publishers, San Francisco, CA, 1992.
Williams98 Louise B. Williams, "SPI Best Practices for 'Small' Projects," in The CMM and Small Projects, Society for Software Quality Roundtable, Washington, DC, 26 January 1998
作者簡介
Mark是美國軟件工程學會（SEI）的一名技術人員。他1987年加入SEI ,最初參與的是軟件能力評價項目的工作。Mark從一開始就工作在軟件能力成熟度模型方面，并且是開發CMM1.1版本時的項目領導人。他也一直活躍在制定有關軟件工程的標準上, 這些標準包括：
ISO 15504 ( 也稱為SPICE--軟件過程改進和能力決斷),一整套軟件過程評估的國際標準
ISO 12207 , 軟件生存周期過程
ISO 15288 , 系統生存周期過程
在加入SEI之前，Mark是系統開發公司（System Development Corporation，即優利國防系統公司Unisys Defense Systems的前身）的位于亞拉巴馬州Huntsville的彈道導彈防護高級研究中心（Ballistic Missile Defense Advanced Research Center）的一名高級系統分析員。
Mark在范德比爾特大學獲得了他的計算機科學碩士學位。在Huntsville的亞拉巴馬州立大學獲得了他的數學和計算機科學學士學位。
專業資格及證明
電子學會高級研究員及電子工程師 (IEEE，美國電氣及電子工程師學會）
美國質量協會高級研究員 (ASQ，美國質量協會)
美國質量協會（ASQ）認證軟件質量工程師
摘要
由美國軟件工程
什么樣的才算做“小”？標準是根據人？時間？項目大��？還是產品的艱難復雜程度？
什么是CMM的“需求”？是否有不該被應用到小項目/小組織中去的關鍵過程區域或目標？有好的過程“ 不變量”嗎？
造成CMM被濫用的驅動力和動機是什么？
這篇論文以小型組織為例討論了怎樣在各種商業環境中正確而有效地使用CMM。從那些對改進其軟件過程感興趣的任何組織得出的結論是：使用為大組織/大項目所開發的發行版來相應地解釋用于小項目或小組織中的CMM，可能會存在程度上的差異，但它們決不會是本質上的不同。正確有效地使用CMM，要求具有專業性的判斷，并且能夠理解CMM是如何針對不同的用途來進行建構的。
1. 介紹
引用DeMarco [DeMarco95], 各種因素綜合造成的如下情形并不令人驚奇：
“大多數軟件評估報告是令人沮喪的……但好在他們還不是對評估過程完全不滿�！�
“正確的進度表是絕對不能達成的，只不過還不那么明顯地不能達成�！�
TQM課程聚焦于在質量管理引導下減少開發周期, 提高生產率，增進客戶滿意程度并努力取得商業上的成功。挑戰，當然被定義成“聚焦質量”的實用手段是什么，隨即就要系統地尋求各種質量問題。也許SEI最成功的產品就是軟件能力成熟度模型(CMM)，就是說，它給在全世界軟件社團中已成為主流的軟件過程改進提供了路標[Paulk95]。CMM定義了怎樣使開發組織的軟件過程走向成熟的5個等級的框架結構。這些等級描述了從特別紊亂的混沌過程到成熟的、有紀律的軟件過程的進化路徑。如圖1中的概示，5個等級和18個關鍵過程區域詳細描述了它們。5個成熟度等級指明了對于成功的過程改進（即在許多案例的研究和調查中被文檔化記錄的有效性）的優先順序[Herbsleb97,Lawlis95,Clark97]。
| 成熟度等級[Level] | 焦點[Focus] | 關鍵過程區域[Key Process Areas] |
| 5--優化級[Optimizing] | 持續不斷的過程改進[Continual process Improvement] | 缺陷預防[Defect Prevention] 技術變更管理[Technology Change Management] 過程變更管理[Process Change Management] |
| 4--已管理級[Managed] | 產品和過程質量[Product and process Quality ] | 定量過程管理[Quantitative Process Management] 軟件質量管理[Software Quality Management] |
| 3--已定義級[Defined ] |
工程化過程及組織支持[Engineering processes and organizational support] | 組織過程焦點[Organization Process Focus] 組織過程定義[Organization Process Definition] 培訓大綱[Training Program] 集成軟件管理[Integrated Software Management] 軟件產品工程[Software Product Engineering] 組間協調[Intergroup Coordination] 同行評審[Peer Reviews] |
| 2--可重復級[Repeatable] |
項目管理過程[Project management processes ] | 需求管理[Requirements Management] 軟件項目計劃[Software Project Planning] 軟件項目跟蹤和監督[Software Project Tracking & Oversight] 軟件轉包合同管理[Software Subcontract Management] 軟件質量保證[Software Quality Assurance] 軟件配置管理[Software Configuration Management] |
| 1--初始級[Initial ] | 能人高手和英雄行為[Competent people and heroics ] | |
表 1. CMM 概況
CMM之所以能成為一個指導過程改進的有用工具，是因為它歷史性地成為了通過對軟件社團已開發軟件的廣泛評審而形成的全面質量管理(TQM)概念的一個常規應用。它的五個等級是非常簡單的，但如能將其巧妙運用，就會找到一個激勵人的支點，正如美國國防部的程序經理所坦陳的：“底線是進度表。我的晉升和加薪，就全靠首當其沖地完成進度表了�！�
正當CMM由于對指導軟件過程改進的重要性而令人鼓舞地在全球變得流行起來的時候，它也正被一些人濫用和誤用，并且另外也有人沒能有效地使用它。CMM v1.1提供的指導往往是面向大工程和大組織的，在使用過程中小組織發覺到這方面有問題，盡管我們堅信CMM的基本概念對于任何組織規模、任何商業環境、任何應用領域都是適用的。
難道按時完成進度、預算和需求，對于小項目或小組織來講，真的那么重要嗎？在某些環境下，這確實是值得商榷的，就如同商用小塑膠袋，拿它跟那些市場份額總是占先的裝船出口的頂好產品相比，其成本是極其微不足道的。如果一個組織的雇員十分滿足安于現狀，那么CMM所提供的能導致真實變化的東西將會很少；變化只會出現在那些對現狀非常不滿并且樂于標新求異的經理和員工身上。無論對大組織還是小組織而言，這都是無庸置疑的。
CMM在稱心如意地實施管理及工程實踐方面，都提供了良好的建議，它強調以人為核心的管理、溝通和協調以及能體現軟件開發和維護特性的強化設計的過程。無論如何，把它看成靈活的指南而非生硬的指令吧，還有對于軟件工程和管理，以及應用領域和組織的商業環境等方面，CMM用戶必須能夠在這些方面應用其基于知識和經驗的專業判斷。因為CMM聚焦于軟件，所以TQM的一些重要方面不能直接照搬到模型里，比如系統工程里的“人的問題（people issues）”和“較寬泛的審視（broader perspective）”，這些在商業上可能是至關重要的。CMM應該被看成使用在軟件過程改進系統步驟里的一種上下文工具，比如SEI的IDEAL模型，如圖2所示[McFeeley96]。
在對軟件過程改進的討論中，開始的問題總應該是這樣的：為什么軟件組織會對使用CMM感興趣？如其愿望是以直接依從商業目標以及心甘情愿投身改革而來改進過程，那么CMM確實是效用非凡、功能強大的工具；如果CMM只被當成單純的短期時髦，那可真是把一劑糟糕的藥方拿到了手。如果驅動力是客戶利益，理想情況下客戶利益將導致客戶和供應商之間協作的改進。有時供應商的利益集中在軟件能力評價(Software Capability Evaluations，SCEs)上, 如此則可在那些來源選擇及簽約監督方面是由政府獲取代理的項目上有所表現。國防部在執行軟件能力評價(SCEs)標準的政策上是排斥絕大多數小組織和小項目的[Barbour96]，但也存在它們可以有所作為的機遇。
很多CMM的濫用都對“其他人”可以做什么的擔心置于不顧。如若一個開發組織能在用CMM來導引勝過被需求來牽引上達成共識，那么在模型中要解決問題的很大一部分就化解掉了。有很多這樣的案例。盡管如此，那些對于好的工程和管理實踐的無知仍將成為問題。對于那些只有很少的管理方面的經驗和訓練而只是因技術優秀就被提拔到管理層職位的人來講，問題是顯而易見的。由DOD（美國國防部）特種部隊確認并提出的問題是[DOD87]：
“少數區域在最佳當前實踐和平均當前實踐之間有著如此巨大的缺口�！�
“大問題不在技術方面……現今軍事軟件開發的主要問題不再是技術問題，而是管理問題�！�
2. 小組織和小項目
本篇論文的焦點對準了在小組織正確而有效地使用CMM，因為經常有人問我，“CMM是否能被用在小項目(或小組織)？”然而有關“小”的定義卻是模糊難解的，如表1所示。 在某段時間里我們致力于為小項目和小組織而開發出剪裁適當的CMM，1995年CMM剪裁工作室的結論是我們甚至不能對什么才算“小”的真正含義達成一致意見！這個結果得出了一篇更注重于“如何剪裁CMM”而不是“已為小組織而裁好的CMM”的報告[Ginsberg95]。1998年SEPG會議關注于CMM及小組織上，“小”被定義成“5個或更少的人為期3至4個月的開發”。Brodman和Johnson則定義“小組織”為少于50個軟件開發人員并且“小項目”為少于20個開發人員[Johnson98]。
表2. 定義一個小項目
| 小的變體 | 人數 | 總的時間 |
| 小 |
3-5 | 6個月 |
| 很小 |
2-3 | 4個月 |
| 微小 |
1-2 | 2個月 |
| 個人 |
1 | 1星期 |
| 荒唐！ | 1 | 1小時 |
注意從小到微小的項目是在被Humphrey稱為小組軟件過程（Team Software Process，TSP）的范圍里，而個人的開發努力則在個人軟件過程（Personal Software Process，PSP）的范圍里[Humphrey95]。TSP和PSP闡明了CMM的概念是如何應用到小項目中的�！盎奶啤弊凅w則描述了一個解釋性的問題。在兩種場合里，變體都會被論述，問題是“項目”的定義。兩種情況下它都是個維護環境，而且組織的“項目”將被描述為CMM的任務；更多關于CMM“項目”的精確解釋是一個基線的升級或者維護的發行……但術語的沖突會將其搞亂。
對于那些使用CMM的小組織來說，首要的挑戰就是其主要商業目標要能存活下來！甚至在決定之后，現狀是不能令人滿意的而且過程改進也將有助于發現資源并為過程改進分派職責,接下來通過制定與部署過程所要做的是一項艱難的商務決定。小組織往往相信：
我們全都彼此溝通——因我們是如此緊密地在“滲透式”工作
我們全都是英雄好漢——我們無論做任何需要做的事情，規則都不適用于我們（這些恰恰達成了將工作完成的方式），我們承受住了短周期及高壓力
然而對于小組織，也正象大組織一樣，有著非文檔化的需求所帶來的麻煩，以及無經驗的經理人員、資源分配、培訓、同行評審和產品文檔等方面帶來的問題。盡管有著這些挑戰，小組織仍能非同尋常地進行創新和提高生產率。盡管有一大把需要人們去解決的大塊問題，通常小組織比大組織更具生產效率，他們能更敏銳地成形生產要素并且遠遠更少見有溝通方面的問題。無論如何，遺留下來的問題是，小組織也需要過程紀律嗎？回答這些CMM咒語,我們需要考慮到紀律包括了什么? 而那將引入這篇有關CMM指導性課題論文的核心。
即便如此，評估小組織時運用最新式的評估過程是明智可取的。為期兩周的CMM內部過程改進基礎評估(CMM IPI)的形式也許是多余的[Strigel95, Paquin98, Williams98]，甚至會由于缺乏監控而導致某些遺漏，而關鍵是有效地確認重大問題。我建議將注意力集中在建立在企業文化上的制度化實踐方面：如規劃、培訓等等，并確切地將過程改進落實到商業需要上。
3. 解釋CMM
CMM都適用在什么地方呢？CMM是按照在任何環境中為任何項目都能提供良好的軟件工程和管理實踐來塑造的。模型是被分層次描述的：
成熟度等級 (5)
->關鍵過程區域 (18)
->目標 （52）
->關鍵實踐 （316）
->子實踐和例子 (許多)
根據我最近十年來在軟件過程工作方面的經驗，闡述的環境以及CMM的剪裁需要包括：
非常大的程序
虛擬項目或組織
地點上分布式的項目
快速原型法的項目
研究及開發組織
軟件服務組織
小項目和小組織
對于小項目和小組織的解釋性指導也同樣適用于大項目和大組織。在正確有效地使用CMM的過程中，智慧和常識是必要的[Paulk96]。所有（軟件）項目都有所不同，但所有（軟件）項目也都有所相同——這可全都是真的。我們必須平衡現實：相似與唯一，秩序與混亂。那些成功所締造出的持久組織[Collins94]是真正有能力的學習型組織[Senge90]；此外在其他地方也必須得益于其成功。
CMM的標準構件是成熟度等級、關鍵過程區域和目標。CMM的所有實踐都是有益處的。既然那些詳細的實踐都首先支持大型簽約的軟件組織，也就沒必要正好寫成是直接適用于小項目和小組織——然而它們同樣提供了如何達到目標和可重復地實現已定義的、規范的、不斷改進的軟件過程。這樣就會避免了過程評估方式上的簡單武斷——諸如“去問老張吧”。
我最通常的指導性建議是開發出一套適用于組織的置于CMM術語和語言間的映射。特別地,組織結構的期限行為、角色、關系以及過程的形式都需要映射到其組織的相應部分，以防止出現無法理喻的事情，諸如“荒誕的一小時項目”。組織結構的例子包括諸如質量保證、測試及配置管理等“獨立小組”。應該用術語明確地指定適當的組織角色，諸如項目經理及項目軟件經理等。人們可以擔當多重角色，例如，一個人可以同時做項目經理、項目軟件經理、軟件配置管理（SCM）經理等等。明確規劃好這些，將生發出對CMM更生動簡潔也更協調一致的闡明。
一旦術語問題被理解了，我們就得考慮什么是守紀律過程的“不變量”（invariant，一個必須永遠為真的約束）以及哪些實踐依賴于上下文關系。除了軟件轉包合同管理（即若無轉包合同的話就可能成為“不可用的”），一般來說我們總是假定關鍵過程區域及目標關聯到任何環境。我想象不出同行評審被等級3的組織適當剪裁掉的情形。盡管所選擇出的實踐（諸如正式方法）可以替代同行評審，但這還是一個需要足夠專業性判斷的問題。擁有專業性的判斷和訓練、經驗豐富的評估人員是至關重要的，甚至對小組織也一樣！[Abbott97]
我從沒見過下列哪個環節是不必要的(盡管實現方式不同)：
將客戶(系統)的需求記錄成文檔
與客戶(并且最終用戶)溝通
同意承諾并簽約
計劃
文檔化過程
工作細化結構
當然，一些實踐都被處理成了“大項目的實現”。小的項目未必需要軟件配置管理組或者變更控制部門……，然而配置管理及變更控制總還是要有的。一個獨立的軟件質量保證(SQA)組也許不是必要的，但目標的認可始終是需求要被滿足。一個獨立的測試組也許沒必要設立，但測試總是必要的。即使小組織和大組織之間的實現有著根本的不同，但我們看到對于上下文相關的實踐，其意旨是建設性的。如果有人讀到CMM所定義的“組”，它是被陳述為“一個組可以是被分派兼職的單獨個人、從不同部門分派了幾個兼職的個人，也可以是全職的幾個個人”，這里就有意迎合了環境的變化。
除了這些, 一些特殊的問題再三地出現, 尤其是對于小組織，涉及有：
管理資助
度量
軟件工程過程組(SEPGs，Software Engineering Process Groups)
“不保修”過程
文檔化過程
剪裁
培訓
風險管理
計劃
同行評審
獲取高層管理的贊助是構建組織能力的關鍵成分，這看起來固然很陳腐老套。做為個體，我們可以在我們可操控的范圍內磨練自身的專業素養及自制能力�？墒侨粢粋�組織作為一個整體來改善其效能，那么其高層管理就必須積極地支持變革。由下至上地改革，無須贊助和協同，卻能夠導向超過可預期改進的組織能力的勝地，這可真是奇聞了。即便如此，當總裁（或者公司創始人）是主角時，敬重“冠軍”往往是具有撼動整個組織的影響力的——包括總裁本人。
對于大多數組織而言，管理實際上是必須基于一個度量基礎的范例轉換。掌握有用的數據，就是說你必須了解性能數據的含義以及如何有價值地去分析它。從收集簡單的有用數據開始，你也不得不敏感于經由度量而導致紊亂行為的潛在因素[Austin96]。度量活動要確認什么是重要的，但一些事情是難于度量的。管理需要確保注意力傾注在項目的所有可評價方面，包括那些難于度量的，而不僅僅是那些易于度量和跟蹤的。
在大多數組織中，軟件工程過程組(SEPG)或一些類似小組應該成為協調過程定義、改進及部署活動的工作組。把資源奉獻給SEPG的原因之一是要確保完成評估調查。許多改進綱要僅僅因為有著不是從評估所導致的行動而失敗。小組織可能沒有全職的SEPG人員，但改進的職責應該明確地加以指派和監控。
起始于“不保修”（"as is"）過程，而不是“合理”（"should be"）過程——對于有效實施的實踐與對指派任務的抵觸來說，這相當于兩者之間的杠桿，此起彼落。要求自上而下的每個人都遵循的“合理”過程，若其顯著地不是由被授權的工人所參與開發的，則將是一個通用的失敗處方�！安槐Ｐ蕖边^程進化的理由是人們從事工作是希望工作任務能被完成（即使那意味著要整天圍著系統轉）�！昂侠怼边^程或可行，或不可行——只有在特定的文化環境中才能成為可行。伴隨著過程管理和改進的組織焦點，“不保修”和“合理”過程將聚合在一點——即導致有組織地進行學習。
過程需要剪裁到項目所需的程度[Ginsberg95,Ade96]。雖然標準過程提供了一個基礎，但每一個項目也都將有其獨特的要求。剪裁時不切實際的約束可導致執行過程中的重大阻力。正如Hoffman所表述的，“別生造感悟也別強求過程�！盵Hoffman98]
過程所需的形式化程度對大組織和小組織都構成了威脅[Comer98]。對于那些每每提到要“按照文檔化步驟”的等級2的25個關鍵實踐中的每一個，應該存有很個別的步驟嗎？答案正如在CMM書籍《文檔和CMM》(Documentation and the CMM)的4.5.5小節所論述的，是一個響亮的“不！”——文檔的包裝是組織化的必然結果。
文檔化的過程如果沒有加以有效地部署，只會具有很小的價值。要想達成文檔化的大量買進，過程實現必須成為過程定義和改進的一部分。通過多種機制的培訓，對于協調一致和效力非凡的軟件工程及管理將是建設性的。培訓的動機是發展技能。有很多“培訓機制”不同于能有效培養技能的正規課堂培訓。其中應該被認真考慮的是正規的顧問制。在此情形下，形式化意謂著寄希望于沒有經驗的顧問。形式化提示要在如何指導及監督顧問的效力上訓練人們。
在過程或技術的最初部署之后，培訓仍然是一個問題[Abbott97，Williams98]。當人員變動時，培訓所增加的需要可能不會被充分地認識。顧問學徒制能充分地解決這一問題，但是除非能謹慎地加以監督，否則不能設想會有滿意的結果。
管理上的培訓是特別重要的，因為低下的管理會削弱一個好的團隊。那些因其技術技能而被提拔到管理層的人，將不得不重新學習包括人際關系在內的一套新的技能[Mogilensky94, Curtis95,Weinberg94]。
軟件工程管理的部分論題確實是風險管理。感覺上，CMM就是關于管理風險的。我們致力于確立穩定的需求，以便能有效地實施計劃和管理，但商業環境總在迅急而紊亂地變化著。我們嘗試在軟件那混沌的大海里建造秩序的孤島，但是秩序和混沌都自有其位置。Wheatley建議，“為了生存，開放系統維持在一非平衡狀態，保持系統均衡以便它能改變和成長�！盵Wheatley92, page 78]盡管我們能確立幫助我們管理混沌世界里的風險的過程，我們也需要變化和成長。
這意味著你應該使用一個增量的或進化的生存周期。如果你想重心集中到風險管理上，螺旋模型將是首選的生存周期模型。如果重心集中在籠絡客戶上，可能快速原型法或接合應用設計更好一些。少數長期項目對穩定環境的奢求是必要的，對其瀑布生存周期將是首選——可能它仍是最普遍通用的生存周期。注意，無論如何，對于小項目，瀑布生存周期都會是一個極佳的選擇。
成功的過程定義和改進的頭號因素是“全程計劃（planfulness）”[Curtis96]。計劃是每一個主要軟件過程都需要的，但不外乎綁定合理的判斷、由組織決定什么是“主要的”以及怎樣包裝計劃。一個計劃可以駐留在幾個不同的工件或被植入一個大計劃當中。
即使你可以對最好的同行評審有爭議，但簡單的事實是同行評審帶來的好處遠遠超出了其成本。數據表明一些檢測表格應該是慣用的[Ackerman89]，但任何學院式或嚴格的評審表格，諸如結構化預排，都附加了重要價值。不幸地，認可同行評審并不意味著我們在系統地做著這件事。我們需要“走在路上”，而不僅僅是“說在嘴上”。這對技術人員來說是很大的挫折，他們不理解CMM所強調的管理，然而糟糕的管理會導致放棄好的工程實踐，比如同行評審。
另外還有其他被確定為是小組織和小項目的問題，Paquin[ Paquin98 ]認定了下面的5個：
評估
工程焦點
文檔
需求功能
成熟度提問單
我們沒有討論等級2的項目焦點對小組織構成的挑戰。軟件過程改進包括了那些對小項目而言是過度的開銷。一些勸告從組織化觀點來攻擊恰似混合了等級2和等級3而又的確不失為合理途徑的小項目的過程改進[Comer98，Paquin98]。CMM本就是為任何規模的組織或項目而考慮的[Paulk96]。盡管無須過程焦點一個組織也能達到等級2，但極其高效的組織化學習的策略將成為減少項目開銷的組織資產的一個重點。同時，必須認識到項目等級的改變可能會形成多半是基于正當利害關系的阻力，而且探察阻力時需要考慮組織進行學習過程的那部分。
需求功能是一個問題，因為比起人來可能有更多的CMM功能。這個問題是做為技術或角色的映射來討論的。成熟度提問單因使用CMM技術而成為關注焦點，它可能在填寫的過程中被搞亂。以組織的技術來表達提問單，甚至對于非正式的評估及度量也是很需要的先導。
Abbott[Abbott97]指明了對于小組織的軟件過程改進的6個關鍵：
高層管理的支持
正確的用人原則
將項目管理的法則應用到過程改進
與ISO 9001的集成
來自過程改進顧問的協助
聚焦在提供項目上及商業上的價值
如果將好的項目管理應用到軟件項目中是確保成功的最佳途徑，那么應該象對待其他任何項目一樣來對待過程改進就同樣是正確的。ISO 9001是在大組織里比小組織里使用更頻繁的一個評估版本，因而Abbott也有興趣針對他的小公司指出這一點。
Brodman和Johnson[Johnson98]認為針對小組織/小項目的挑戰有7種：
處理需求
生成文檔
管理項目
分配資源
度量過程
促導評審
提供培訓
Brodman和Johnson開發了一個針對小型商業、組織和項目的CMM剪裁版本[Johnson96, Johnson97, Brodman94]。盡管如此，大多數CMM的關鍵實踐還是被剪裁到了《LOGOS剪裁版CMM》里，變化體現在：
已存實踐的凈化
明顯的夸張
選擇性實踐的介紹(特出地作為例子)
伴隨小商業/小組織/小項目的結構及資源的實踐調整
因此針對小組織而剪裁CMM的相關改變是可以根本不予考慮的。
4. 濫用CMM
正確使用CMM意味著要平衡相互沖突的目標�；贑MM的評估要求運用專業性的判斷。盡管如此，CMM在做出這些判斷以及消除對一個明確的、反復的、非設計工作特有的過程的主觀臆斷等方面都提供了大量的指導。CMM有時作為一整套過程需求被提及，但它不能有任何含有“將要”(shall)的語句。這就是在核對（子）實踐一致性時造成CMM濫用的原因。
有些是勉強地、無能地去解釋、剪裁或應用判斷力。這是易于委派到關鍵實踐的，但卻愚笨透頂。此種蠢行常常由客戶意圖及能力的偏執來驅動。我在更多的場合聽說某人要做某些傻事，但他們害怕客戶無知無能到理解不了不能完全生搬硬套CMM的道理的地步。這對于軟件能力評價來說是明顯有疑問的。判斷可能不一致是對的——并且有時只有如此才合理。曾在某一環境中適用的卻可能滿足不了一個新項目。那就是我們推薦把過程成熟度包含在風險評估要比使用成熟度等級來過濾報價者更好的原因。小組織應該較少關心這個問題，因為對小組織的軟件能力評價未必是劃算的。它是從事許多小項目的大組織的一個問題的多個方面。
十分不幸，我沒有此問題的解決方案。象這種CMM能幫助組織改進軟件過程的“標準”，卻是聚焦在達到一個沒有從事潛在的、能導致紊亂行為的過程的能力成熟度等級。成熟度應該成為改進的度量，而不是改進的目標。這就是為何我們強調需要依靠改進來達到商業目的。
5. 結論
底線是軟件過程改進應該有助于達成商業成就——而不是為其自身理由。無論對大組織還是小組織，這都是真真確確的。最好的忠告來自于Bellcore的總裁Sanjiv Ahuja：“讓常識奏效！”
構造軟件是一項設計密集的創造性活動。同時過程的紀律對于能否成功是至關重要的——目標是解決問題——同時要有創造活力。就算軟件本身不是重復的，軟件的過程也應該是可重復的。要在紀律約束和創造活力之間取得均衡是頗具挑戰性的[Glass95]。失去了創造性視野，軟件工作的精密設計的天性將被引入令人窒息的僵化境地。而失去了所需的紀律觀念，也將導致混亂不堪。
CMM描繪了軟件過程改進的一個“常識工程化”路徑。它的成熟度等級、關鍵過程區域、目標及關鍵實踐經受了軟件社團內部的廣泛討論和評審。同時CMM既非完美無缺也不包容一切，它只是表達了軟件社團的一種廣泛一致的意見，并且成為指導改進工作的一個有用工具，它也有助于小型軟件組織改進它們的過程 [Abbott97, Hadden98b, Hoffman98, Pitterman98, Sanders98]。
小組織應該認真地考慮PSP和TSP[Ferguson97,Hayes97]。掌握了PSP課程，我可以高度評價其建立了自我約束的能力。注意看書的效果不能等同于掌握課程及實際操作。CMM所從事的過程改進組織化的一個側面，就是PSP致力于建造個體從業者的能力。PSP確信個人能夠——基于他或她自有的性能數據——遵從紀律尊重價值——以工程化途徑來構建軟件。
參考資料
Abbott97 John J. Abbott, "Software Process Improvement in a Small Commercial Software Company,", Proceedings of the 1997 Software Engineering Process Group Conference, San Jose, CA, 17-20 March 1997.
Ackerman89 A.F. Ackerman, L.S. Buchwald, and F.H. Lewski, "Software Inspections: An Effective Verification Process," IEEE Software, Vol. 6, No. 3, May 1989, pp. 31-36.
Ade96 Randy W. Ade and Joyce P. Bailey, "CMM Lite: SEPG Tailoring Guidance for Applying the Capability Maturity Model for Software to Small Projects," Proceedings of the 1996 Software Engineering Process Group Conference: Wednesday Papers, Atlantic City, NJ, 20-23 May 1996.
Austin96 Robert D. Austin, Measuring and Managing Performance in Organizations, Dorset House Publishing, ISBN: 0-932633-36-6, New York, NY, 1996.
Barbour96 Rick Barbour, "Software Capability Evaluation Version 3.0 Implementation Guide for Supplier Selection," Software Engineering Institute, Carnegie Mellon University, CMU/SEI-95-TR-012, April 1996.
Brodman94 J.G. Brodman and D.L. Johnson, "What Small Businesses and Small Organizations Say About the CMM," Proceedings of the 16th International Conference on Software Engineering, IEEE Computer Society Press, Sorrento, Italy, 16-21 May 1994, pp. 331-340.
Clark97 Bradford K. Clark, "The Effects of Software Process Maturity on Software Development Effort," PhD Dissertation, Computer Science Department, University of Southern California, August 1997.
Collins94 James C. Collins and Jerry I. Porras, Built to Last, HarperCollins Publishers, New York, NY, 1994.
Curtis95 Bill Curtis, William E. Hefley, and Sally Miller, "People Capability Maturity Model," Software Engineering Institute, CMU/SEI-95-MM-02, September 1995.
Curtis96 Bill Curtis, "The Factor Structure of the CMM and Other Latent Issues," Proceedings of the 1996 Software Engineering Process Group Conference: Tuesday Presentations, Atlantic City, NJ, 20-23 May 1996.
DeMarco95 Tom DeMarco, Why Does Software Cost So Much?, ISBN 0-932633-34-X, Dorset House, New York, NY, 1995.
DOD87 Department of Defense, "Report of the Defense Science Board Task Force on Military Software," Office of the Under Secretary of Defense for Acquisition, Washington, D.C., September 1987.
Ferguson97 Pat Ferguson and Jeanie Kitson, "CMM-Based Process Improvement Supplemented by the Personal Software Process in a Small Company Environment,", Proceedings of the 1997 Software Engineering Process Group Conference, San Jose, CA, 17-20 March 1997.
Gibbs94 W. Wayt Gibbs, "Software's Chronic Chrisis," Scientific American, September 1994, pp. 86-95.
Ginsberg95 Mark Ginsberg and Lauren Quinn, "Process Tailoring and the Software Capability Maturity Model," Software Engineering Institute, CMU/SEI-94-TR-024, November 1995.
Glass95 Robert L. Glass, Software Creativity, Prentice Hall, Englewood Cliffs, NJ, 1995.
Hadden98a Rita Hadden, "How Scalable are CMM Key Practices?" Crosstalk: The Journal of Defense Software Engineering, Vol. 11, No. 4, April 1998, pp. 18-20, 23.
Hadden98b Rita Hadden, "Key Practices to the CMM: Inappropriate for Small Projects?" panel, Rita Hadden moderator, Proceedings of the 1998 Software Engineering Process Group Conference, Chicago, IL, 9-12 March 1998.
Hayes97 Will Hayes and James W. Over, "The Personal Software Process (PSP): An Empirical Study of the Impact of PSP on Individual Engineers," Software Engineering Institute, Carnegie Mellon University, CMU/SEI-97-TR-001, December 1997.
Herbsleb97 James Herbsleb, David Zubrow, Dennis Goldenson, Will Hayes, and Mark Paulk, "Software Quality and the Capability Maturity Model," Communications of the ACM, Vol. 40, No. 6, June 1997, pp. 30-40.
Hoffman98 Leo Hoffman, "Small Projects and the CMM," in "Key Practices to the CMM: Inappropriate for Small Projects?" panel, Rita Hadden moderator, Proceedings of the 1998 Software Engineering Process Group Conference , Chicago, IL, 9-12 March 1998.
Humphrey95 Watts S. Humphrey, A Discipline for Software Engineering, ISBN 0-201-54610-8, Addison-Wesley Publishing Company, Reading, MA, 1995.
Johnson96 Donna L. Johnson and Judith G. Brodman, The LOGOS Tailored Version of the CMM for Small Businesses, Small Organizations, and Small Projects, Version 1.0, August 1996.
Johnson97 Donna L. Johnson and Judith G. Brodman, "Tailoring the CMM for Small Businesses, Small Organizations, and Small Projects," Software Process Newsletter, IEEE Computer Society Technical Council on Software Engineering, No. 8, Winter 1997, p. 1-6.
Johnson98 Donna L. Johnson and Judith G. Brodman, "Applying the CMM to Small Organizations and Small Projects," Proceedings of the 1998 Software Engineering Process Group Conference, Chicago, IL, 9-12 March 1998.
Lawlis95 Patricia K. Lawlis, Robert M. Flowe, and James B. Thordahl, "A Correlational Study of the CMM and Software Development Performance," Crosstalk: The Journal of Defense Software Engineering, Vol. 8, No. 9, September 1995, pp. 21-25. Reprinted in Software Process Newsletter, IEEE Computer Society Technical Council on Software Engineering, No. 7, Fall 1996, pp. 1-5.
McFeeley96 Bob McFeeley, "IDEAL: A User's Guide for Software Process Improvement," Software Engineering Institute, CMU/SEI-96-HB-001, February 1996.
Mogilensky94 Judah Mogilensky and Betty L. Deimel, "Where Do People Fit in the CMM?," American Programmer, Vol. 7, No. 9, September 1994, pp. 36-43.
Paquin98 Sherry Paquin, "Struggling with the CMM: Real Life and Small Projects," in "Key Practices to the CMM: Inappropriate for Small Projects?" panel, Rita Hadden moderator, Proceedings of the 1998 Software Engineering Process Group Conference, Chicago, IL, 9-12 March 1998.
Paulk95 Carnegie Mellon University, Software Engineering Institute (Principal Contributors and Editors: Mark C. Paulk, Charles V. Weber, Bill Curtis, and Mary Beth Chrissis), The Capability Maturity Model: Guidelines for Improving the Software Process, ISBN 0-201-54664-7, Addison-Wesley Publishing Company, Reading, MA, 1995.
Paulk96 Mark C. Paulk, "Effective CMM-Based Process Improvement," Proceedings of the 6th International Conference on Software Quality, Ottawa, Canada, 28-31 October 1996, pp. 226-237.
Pitterman98 Bill Pitterman, "Key Practices to the CMM: Inappropriate for Small Projects?" panel, Rita Hadden moderator, Proceedings of the 1998 Software Engineering Process Group Conference, Chicago, IL, 9-12 March 1998.
Sanders98 Marty Sanders, "Small Company Action Training and Enabling," in The CMM and Small Projects, Society for Software Quality Roundtable, Washington, DC, 26 January 1998.
Senge90 Peter M. Senge, The Fifth Discipline: The Art & Practice of the Learning Organization, Doubleday/Currency, New York, NY, 1990.
Strigel95 Wolfgang B. Strigel, "Assessment in Small Software Companies," Proceedings of the 1995 Pacific Northwest Software Quality Conference, 1995, pp. 45-56.
Weinberg94 Gerald M. Weinberg, Quality Software Management, Volume 3: Congruent Action, ISBN 0-932633-28-5, Dorset House, New York, NY, 1994.
Wheatley92 Margaret J. Wheatley, Leadership and the New Science, Berrett-Koehler Publishers, San Francisco, CA, 1992.
Williams98 Louise B. Williams, "SPI Best Practices for 'Small' Projects," in The CMM and Small Projects, Society for Software Quality Roundtable, Washington, DC, 26 January 1998
作者簡介
Mark是美國軟件工程學會（SEI）的一名技術人員。他1987年加入SEI ,最初參與的是軟件能力評價項目的工作。Mark從一開始就工作在軟件能力成熟度模型方面，并且是開發CMM1.1版本時的項目領導人。他也一直活躍在制定有關軟件工程的標準上, 這些標準包括：
ISO 15504 ( 也稱為SPICE--軟件過程改進和能力決斷),一整套軟件過程評估的國際標準
ISO 12207 , 軟件生存周期過程
ISO 15288 , 系統生存周期過程
在加入SEI之前，Mark是系統開發公司（System Development Corporation，即優利國防系統公司Unisys Defense Systems的前身）的位于亞拉巴馬州Huntsville的彈道導彈防護高級研究中心（Ballistic Missile Defense Advanced Research Center）的一名高級系統分析員。
Mark在范德比爾特大學獲得了他的計算機科學碩士學位。在Huntsville的亞拉巴馬州立大學獲得了他的數學和計算機科學學士學位。
專業資格及證明
電子學會高級研究員及電子工程師 (IEEE，美國電氣及電子工程師學會）
美國質量協會高級研究員 (ASQ，美國質量協會)
美國質量協會（ASQ）認證軟件質量工程師
文章來源于領測軟件測試網 http://www.kjueaiud.com/
