積極面對 效果加倍——別僅僅把CMM當標準

領測軟件測試網 CMM是一個大家關注已久的話題。然而，知道的人多，懂得的人少。
口頭談論的人多，付諸實施的人少。
認為CMM是用來認證的人多，真正把CMM當成指導“過程開發和改進”的人少。 如果CMM是一個有情緒的人，我想他會深感失落；他也許會說：別僅僅把我當成一個用來認證的標準，請讓我在組織的“過程開發和改進”中起到積極的作用。
本文闡述如何從“過程開發和改進”角度，更加積極地理解CMM，并淺談如何對CMM進行剪裁。本文的基本觀點是：CMM是過程開發和改進的需求和測試方案。寫作倉促，不妥之處敬請斧正。
一、軟件過程也是軟件
軟件工程大師Osterweil在其論文《Software Processes are Software Too》中高屋建瓴地指出：軟件過程也是軟件。
軟件有一個開發的過程，軟件過程也有一個開發的過程。
軟件開發產出軟件產品，軟件過程開發產出過程產品。
軟件開發可以是一個演進過程，使軟件產品不斷更新升級，軟件過程開發也可以是一個演進過程，使過程不斷升級，過程能力成熟度不斷提高。
由此看來，從軟件過程開發角度理解CMM，是非常自然的。
二、從軟件過程開發和改進角度理解CMM
1、 軟件過程的概念模型
開發軟件，先要分析出該軟件的概念模型。要開發軟件過程，也要首先分析其概念模型。筆者用UML類圖的語法描述之（如下圖所示）：

從圖中可以看到，
有3個要素：人，活動，工件。
人執行活動，活動產出工件。
人執行某些活動需要使用先前的工件。
活動由人執行，所以活動對人存在依賴關系，制定軟件過程時，必須考慮員工的素質，另外，對員工進行培訓也是不錯的選擇。
工件由活動產生（或再加工），所以工件對活動存在依賴關系，活動的具體實施情況，直接影響著工件的質量。
人執行某些活動需要使用先前的工件，以產生新的工件或對原工件進行再加工，所以人對工件存在依賴關系，所需工件沒有產生，就會限制下面的其他活動的進行。
由上面所說的依賴關系，演生出了：人對人的依賴，活動對活動的依賴，工件對工件的依賴。
所有這些依賴關系 都是我們制定軟件過程時要考慮的，只有合理處理它們，才能使軟件過程流暢高效。
好了，上面描述了軟件過程的概念模型。不難理解，開發軟件過程就是要依據實際情況，定義出諸如“由誰在何時執行何種活動產出何種工件” 的復雜模型。如果再進一步將其文檔化，在企業內部標準化，它就成為企業級的軟件過程了。
2、 CMM是軟件過程開發的需求
應當指出，軟件過程有以角色為中心、以活動為中心和以工件為中心3種流派。而以活動為中心的過程是比較流行的，比如RUP就是一種以活動為中心的過程（而且還引入工作流來支持并行活動）。
再看CMM，它最基本的概念是關鍵實踐和關鍵過程域（如下圖所示）：
關鍵實踐，對相關活動和設施的描述，僅描述應當“做什么”，而不是強制規定“如何做”。
關鍵過程域，為達到一定目標，相互關聯的若干軟件實踐活動和有關基礎設施的集合。

那么如何理解CMM是軟件過程開發的需求呢？
因為關鍵實踐描述了應當“做什么”，而不是強制規定“如何做”，所以可以認為，關鍵實踐是關鍵活動的需求描述。
關鍵實踐就是過程開發的需求項。
關鍵實踐被分組，成為一些關鍵過程域。相當于需求項的分組，便于管理。
關鍵過程域的實施都是為了達到一定的目的，從需求的層次角度（請參考Wiegers著陸麗娜譯《軟件需求》一書），可將“目的”理解為“業務需求”，將關鍵過程域理解為“用戶需求”，前者由后者來實現。
CMM通過定義的這些關鍵實踐和關鍵過程域，覆蓋了我們要開發的軟件過程的主要目的（比如需求管理、產品工程）。
因此說，CMM是軟件過程開發的需求。
3、 CMM是軟件過程開發的測試方案
再看軟件過程的測試。
從原理上，需求就是測試依據。軟件工程中的一條基本原理就是：依據需求進行測試。
從實施上，我們通常依據需求來編寫測試用例，然后執行這些測試用例。
Brain Marick更是表述了他的具有革命性的觀點：“我并不想寫出一套用于捕捉用戶愿望的需求，取而代之的是，我要寫出一套測試，一旦這些測試能夠通過，產品就能使她滿意�！北M顯大師風范。
CMM提供了大量提問單（如下圖所示），和測試用例的概念對應得很完美，我們通過這些提問單就可以輕松測試出每一個關鍵實踐進行得怎么樣，進一步測試出每個關鍵過程域完成得如何，該組織的軟件過程的能力成熟度有多高。
因此說，CMM是軟件過程開發的測試方案。
其實，“CMM是軟件過程標準”的說法，和“CMM是軟件過程開發的測試方案”的說法頗有幾分神似。

4、 CMM是軟件過程改進的框架
軟件開發中，為了降低風險，需求項會被分為不同的優先級，高優先級的需求要先完成，進行演進開發。優先級劃分的依據是：
需求項之間的依賴關系，被其他需求項依賴的需求項的優先級高。
需求項的重要程度，重要的需求項優先級高。
而軟件過程也要根據企業的具體情況，循序漸進地改進，CMM這個過程開發的需求也特別照顧到了這一點：
CMM本身就將作為“需求項分組”的關鍵過程域，依據重要性和相互依賴關系，劃分了優先級。
依據優先級的高低，將所有“需求項分組”進一步劃分為4組，分別命名為可重復級、已定義級、已管理級和優化級。
再加上一個過程混亂的初始級，成為CMM的5級成熟度模型（如下圖所示）。

5、 CMM的剪裁
需要說明的是，軟件過程的改進會涉及到軟件過程的度量等一系列活動，并不屬于本文的討論范圍。在此僅單純討論CMM的剪裁。
框架者，通用的東西也。既然說“CMM是軟件過程改進的框架”，那么可以對其進行剪裁應當是“題中應有之義”。
剪裁之前，當然要先進行需求捕獲，以明確軟件過程的具體需求。比如可以首先明確軟件企業的環境，然后向所有涉及人員收集信息。
軟件企業環境的例子有：開發人員素質，合作單位素質，待開發軟件的類型、規模、重要程度等，這些因素都會影響到將來軟件過程的制定。
涉及的人員的例子有：用戶，開發人員，合同確定者和投標者等，從他們那里收集對軟件過程的要求。
掌握了企業的實際情況之后，就可以對CMM進行剪裁了。筆者認為，至少可以從以下方面對CMM進行剪裁：
既然CMM是依據優先級高低而分組的關鍵過程域的集合，我們根據實際情況的不同，可能對優先級重新劃分。比如學習型企業的理念非常適合以技術為導向公司，將關鍵過程域“培訓活動”提升到更優先的級別，首先加以實施。
顧名思義，有關鍵過程域，就有非關鍵過程域，但依據具體情況，會有可能需要這些“非關鍵過程域”。比如，國內比較重視業績考核，可以增加一個過程域“業績考核”。
關鍵過程域由一組關鍵實踐組成，可以依據具體情況，增加或減少關鍵實踐。比如關鍵過程域“軟件子合同管理”中，可以增加關鍵實踐“律師事務所輔助監督”，以滿足重要的跨國合同的執行需要。
三、 總結
筆者認為，流行的“CMM是軟件過程標準”的說法稍顯被動消極，而從軟件過程開發角度去理解CMM，更加積極，更加有利于實踐中充分利用CMM：
這種理解角度以“軟件過程也是軟件”為理論基礎，非常自然
有利于廣大軟件開發人員對CMM的理解和認同
有建設性，利于啟發人們將CMM做為實踐指導
這種理解角度和“CMM是軟件過程標準”的說法是兼容的
總之，目的只有一個——充分發揮CMM的作用。
參考文獻
Osterweil 《Software Processes are Software Too》
溫昱 《RUP的剪裁原理和剪裁過程》
何新貴等 《軟件能力成熟度模型》
Wiegers著 陸麗娜等譯 《軟件需求》

文章來源于領測軟件測試網 http://www.kjueaiud.com/

TAG: cmm CMM