合理的軟體過程是軟體品質的基礎－論CMM/CMMI的缺點

CMM/CMMI被認為是一種最成熟、最有效地提高軟體工程化水平的方法和標準，用來評估和改進過程，它是一個描述在軟體開發過程中有待改進的關鍵因素的架構，描述了一個能用漸進方式進行改進的途徑。它為軟體流程改善提供一個基礎，將軟體開發從一個相對來說隨意、不成熟的過程變成非常成熟的、有規律的、可管理的過程。

 

然而，CMM/CMMI也有一些與身俱來的缺點不容忽視。比如，CMM/CMMI的評估耗資不菲，一個CMM2級評估就可能達到數百萬之巨，而且耗時很長，過程十分複雜，常常導致效果不太理想。不少企業的認證流於形式，評估完成後就只留下一大堆文檔，而真正的軟體開發過程卻依然故我。而且，CMM/CMMI只告訴我們應該怎麼做，而沒有具體地告訴如何做。比如說，它要求必須改進需求管理，那麼到底該如何做需求管理？CMM/CMMI沒有提供答案。

 

還有最重要的一點是，不少軟體企業陷入了一個誤區，以為單單通過CMM/CMMI評估就可以解決軟體品質不高的問題，而忽略了軟體過程這一真正改善軟體品質的環節。事實上，完全有可能出現這樣的情況: 軟體成熟度等級為CMM 1級或2級的企業開發出的軟體是真正好用的，而有的企業即使通過了CMM 5級認證，也無法保證它交付好的軟體。最糟糕的情形是，如果採用不好的軟體過程，通過CMM/CMMI的成熟度等級層級越高，只會使軟體企業生產差勁軟體的過程變得更加有效率，而不是使企業開發出更好的軟體。

 

Ivar Jacobson認為,好的軟體過程首先一定是基於組件的,在此基礎之上,還要符合反覆式開發法、用例驅動開發和以架構為中心的這三個最佳實務。

合理的軟體過程是軟體品質的基礎

為什麼會是這樣呢，Ivar Jacobson舉了一個非常形象的例子。這是一個農夫和他的奶牛的故事。在奶牛喝水的途中（稱為“牛路”）有一片莊稼地，牛會吃掉很多莊稼。農夫看到這種情況後，意識到必須對奶牛喝水的過程進行改進，所以他就在這條道路上鋪上了瀝青。結果，農夫得到了一個好的“牛路”，牛走得更快了，但是並沒有真正解決牛吃莊稼的問題。它應該有更好的方式，就是為牛喝水尋找一條全新的道路。

 

 

軟體企業利用CMM架構進行軟體品質控制的過程，就像是這個農夫為牛路鋪瀝青。對於軟體企業來說，如果從一個錯誤的軟體過程開始，即使你在這個上面再改進，得到的永遠只是“牛路”。這裡更應該考慮的是要選擇一條更好的路，也就是從一開始時，就採用能夠開發出好的軟體的過程。然後在這個軟體過程的基礎上，對這個軟體進行度量，改進這個軟體的過程,也就是進行CMM/CMMI要求的改進。

 

Ivar Jacobson博士認為，從一個不良的軟體過程出發，在此基礎上進行改進，實際上會把軟體開發變得更糟糕，因為你把軟體開發過程固化了，使日後再想對它進行改造，變得更加困難。正確的方法是，先要有一個好的軟體過程，這是不容易的，但是值得做的事情。Ivar Jacobson 說，“把一個好的軟體過程變得可度量非常容易，但是把一個可度量的軟體過程變成一個好的軟體過程卻很難”。也就是說，只有把一個好的軟體過程，即能夠開發出好的軟體的過程變得可度量才是有益的。而把一個已經經過CMMI改進的、可度量的過程變成一個真正的能夠開發出好軟體的過程，這是幾乎不可能的事情。

 

那麼什麼是一個好的軟體過程？Ivar Jacobson建議從以下幾個方面進行辨別: 第一，壞的過程關注文檔上，而好的過程關注在可執行檔程式或者系統上; 第二，壞的過程延誤了揭露風險的時間，而好的過程一開始就把自己暴露在風險之下，並及時解決它; 第三，壞的過程在項目的最後才能夠驗證這個項目的品質，而好的過程其品質是每時每刻都能夠得到驗證的;第四，壞的過程有一個非常複雜的跟蹤關係矩陣，從需求到代碼需要一個非常複雜的矩陣，而好的過程，卻是一個無縫連結; 第五，在面對變更時，壞的軟體很脆弱，好的軟體會很健壯。

 

Ivar Jacobson提醒軟體開發人員要做聰明的農夫，首先得到一個正確的軟體過程; 然後，再考慮去度量它、定義它。因為軟體專案管理的本質不是能否描述並度量軟體過程以及過程到底怎麼樣，而是首先關注軟體，你是否能很好地開發出合格軟體。重點是得到結果，通過軟體過程得到這個結果，也就是交付的軟體產品。

敏捷開發企圖終結軟體危機(但也是很難的，敏捷開發適合小團隊，不適合需求清楚的大項目、軍工項目、...)