對大多數國內軟件企業來說，CMM的實施還處于起步階段，準備實施CMM2級的企業占絕大多數，因此，分析CMM2級實施過程中的問題，將有助于這些企業盡快找到適合本企業的實施方式。
一些正在實施CMM2級的企業發現有大量的重復性工作要做，原因何在？沒有做好需求開發是產生這一問題的主要原因！
1 需求管理與需求工程
需求開發和需求管理是需求工程的兩部分，如果沒有做好需求開發，那么從需求管理的角度看就會出現重復性的工作。導致需求開發欠佳的主要原因有以下幾點：
◆ 缺乏良好的需求規格說明編寫模板
分析一些企業的CMM實施過程，從表面上看，它們的確遵循了先推薦方案再進行評審的基本選擇原則，但由于缺乏經驗，實際選定的方案常常缺乏客觀性，同時在企業的工程和管理機制里又缺乏實踐反饋的方法和過程來不斷地改進原有的方案。一般來說，大家在一起工作的時間長了，就會形成一種“默契”，而這很可能給以后的工程和管理工作埋下很多隱患，一旦出現意見分歧時，這種默契就不復存在。如果按CMM的要求去做，大量類似的重復工作就會因此出現。改進的方法之一是在整個工程和管理過程中，既保持文檔和產品的一致性，又反向追蹤需求規格說明更改的程度，并持續改進需求規格說明編寫模板。
◆ 較嚴重地忽略了非功能性需求
目前，國內的軟件客戶很少主動提出非功能性需求，但隨著客戶的逐漸成熟，軟件客戶對軟件的非功能性需求也會越來越高，這就對軟件開發商提出了更高的要求。不做好非功能性需求的規格說明編寫工作，同樣會陷入大量重復工作的包圍之中。
如果缺乏非功能性需求的規格說明，將會使一些基礎問題直到軟件生命的中期才被發現，這將導致大量的文檔和產品需要更改，由此帶來嚴重的工程和管理難題。改進的方法之一是調用有相當軟件調試和維護背景的資深人員參與需求規格說明的編寫，他們的豐富經驗往往可以較好地彌補設計開發人員在這方面存在的不足。
◆ 缺乏對需求文檔的配置管理
采用兩個需求規格說明編寫模板是一種不錯的做法：一份給軟件客戶看，一份留給軟件開發小組內部使用，前者的目標是讓客戶較容易理解，后者則更加專業化。在這種情況下，兩個需求規格說明都應納入配置管理的范疇以便從管理的角度保持其一致性。這還不夠，從工程角度考慮，企業還應該形成一套從前者到后者的轉化規則。盡管這兩個模板的表現形式可能是自然語言，但一個盡可能嚴謹的規則將大大縮小轉化過程中人為自由發揮的空間。需要注意的是，這套規則的建立應從一個項目開始，從基礎做起，逐漸完善。例如，首先確定項目的基本名詞和動詞集合，并規定語句書寫規則。
◆ 需求規格說明缺乏可測性
在需求說明應具備的幾個特性里，為什么單單挑出可測性呢？在需求說明編寫階段，主觀性對其他特性的影響較大，而一個獨立且有經驗的測試組對可測性的掌握是從獨立于需求規格說明的測試文檔出發的。從測試的角度看，很多需求說明是不可測的，這就要求重寫這些需求說明，直到可測性得到保證。測試組要求的往往是簡潔且準確的說明，而這恰恰是開發人員做得不夠好的幾個方面之一；另一方面，目前無論是國內的市場還是企業，對測試人員都不夠重視，軟件企業很少招聘測試人員。實際上，優秀的軟件測試人員對保證軟件質量非常重要，一般來說，測試部門的經理應該由具有軟件開發經驗、做過軟件開發管理且有相當測試經驗的資深人員擔任。處理好設計和測試人員的關系是眾多國內軟件企業應該進一步重視的問題。
◆ 缺乏較好的需求規格說明轉化規范
需求規格說明轉化的目的是把用自然語言書寫的需求說明轉化為更準確的中間形式，這一轉化過程也被稱為“軟件建�！�。一般來說，建�？梢允剐枨笳f明的某些方面更形式化一些，并使設計更加清晰地保持需求繼承。通常，不做需求規格說明轉化或缺乏較好的需求規格說明轉化規范，將造成不同程度的需求說明丟失，從而增加后續管理工作的難度。
需求管理的根本目的是為其后的工程和管理建立基線并保持相關及衍生文檔和產品與需求的一致性，因此需求工程完成得好壞對需求管理實施的工作量有很大影響。
2 配置管理與工作產品的轉化
軟件配置管理的目的是保證項目生成的產品在軟件生命周期中的完整性，它需要一個較好的工具，當找不到較好的商用軟件工具覆蓋該關鍵域的實踐時，許多國外軟件企業會自行開發一些工具來彌補不足，并且取得了很好的效果。國內軟件企業在實施該關鍵域時也會使用一些工具，但存在的典型問題是：有太多的SCCB（軟件配置控制委員會）活動。
配置管理是在軟件生命周期中建立和標識軟件工作產品并控制基線的更改，這將保證軟件工作產品的完整性和一致性。但是，作為配置項/單元標識的軟件工作產品通常為典型的軟件生命周期中的工作產品，這些產品具有一個共同特點：一個產品通常是由另一個產品轉化而來。從一些企業配置管理下的工作產品來看，存在的主要問題是缺乏較好的可轉化性。在這里，“較好的可轉化性”是指把一個產品轉化為另一個產品時有較規范的轉化規則可循，其目的是最大程度地保證一種工作產品能被忠實地轉化為另一種工作產品形式，從而最大限度地降低最初的軟件需求在轉化過程中出現遺漏和被錯誤解釋的可能性。企業在實施這個關鍵過程域時，應由SCCB記錄工作產品的更改以及引發這些更改的原因，這些數據能很好地幫助企業找出問題的癥結。一般來說，引發類似問題的原因主要有以下3點：
需求規格說明書編寫不好或不全；
工作產品模板定義不好；
工作產品之間轉化缺乏規范定義。
3 項目計劃與數據收集和分析
項目計劃是CMM實施一開始就涉及且最后才能相對完善的關鍵過程域，它主要包括軟件規模估計、工作模塊計劃、人力資源計劃、進度安排和其他資源計劃。在其他關鍵過程域的實踐相對穩定之前，項目計劃的實踐總是處于需要改動的狀態。
一般來說，期望在CMM實施之初就有一個可靠的項目計劃是不現實的，因為這需要經歷若干項目的實施才能獲得有效數據并據此制定未來項目的計劃。我們知道，配置管理可以保證項目生成的產品在軟件生命周期中的完整性，因此，為了更好地實施項目計劃，我們可以把用于項目計劃的大部分數據放在對應的工作產品配置管理之下，必要時，還可將工作產品進一步細化，以保證對應的項目計劃數據的準確性。項目完成后，我們還應該對項目計劃的數據進行收集和分析，在此基礎上制定下一個項目計劃時，準確性就能大大提高。通過對若干項目進行同樣的實踐，項目經理就有了比較可靠的數據用于制定未來的項目計劃。通常，項目跟蹤和監督實施不好的原因很大程度上是由于項目計劃的頻繁更動，同時缺乏良好的項目跟蹤工具，使項目管理人員逐漸失去跟蹤項目的興趣。
文章來源于領測軟件測試網 http://www.kjueaiud.com/