|
對大多數國內軟件企業來說，CMM的實施還處於起步階段，準備實施CMM2級的企業佔絕大多數，因此，分析CMM2級實施過程中的問題，將有助於這些企業儘快找到適合本企業的實施方式。
一些正在實施CMM2級的企業發現有大量的重複性工作要做，原因何在？沒有做好需求開發是產生這一問題的主要原因！
1. 需求管理與需求工程
需求開發和需求管理是需求工程的兩部分，如果沒有做好需求開發，那麼從需求管理的角度看就會出現重複性的工作。導致需求開發欠佳的主要原因有以下幾點：
缺乏良好的需求規格說明編寫模板
分析一些企業的CMM實施過程，從表面上看，它們的確遵循了先推薦方案再進行評審的基本選擇原則，但由於缺乏經驗，實際選定的方案常常缺乏客觀性，同時在企業的工程和管理機制裏又缺乏實踐反饋的方法和過程來不斷地改進原有的方案。一般來說，大家在一起工作的時間長了，就會形成一種“默契”，而這很可能給以後的工程和管理工作埋下很多隱患，一旦出現意見分歧時，這種默契就不復存在。如果按CMM的要求去做，大量類似的重複工作就會因此出現。改進的方法之一是在整個工程和管理過程中，既保持文檔和產品的一致性，又反向追蹤需求規格說明更改的程度，並持續改進需求規格說明編寫模板。
缺乏良好的需求規格說明編寫模板
分析一些企業的CMM實施過程，從表面上看，它們的確遵循了先推薦方案再進行評審的基本選擇原則，但由於缺乏經驗，實際選定的方案常常缺乏客觀性，同時在企業的工程和管理機制裏又缺乏實踐反饋的方法和過程來不斷地改進原有的方案。一般來說，大家在一起工作的時間長了，就會形成一種“默契”，而這很可能給以後的工程和管理工作埋下很多隱患，一旦出現意見分歧時，這種默契就不復存在。如果按CMM的要求去做，大量類似的重複工作就會因此出現。改進的方法之一是在整個工程和管理過程中，既保持文檔和產品的一致性，又反向追蹤需求規格說明更改的程度，並持續改進需求規格說明編寫模板。
比較嚴重地忽略了非功能性需求
目前，國內的軟件客戶很少主動提出非功能性需求，但隨着客戶的逐漸成熟，軟件客戶對軟件的非功能性需求也會越來越高，這就對軟件開發商提出了更高的要求。不做好非功能性需求的規格說明編寫工作，同樣會陷入大量重複工作的包圍之中。
如果缺乏非功能性需求的規格說明，將會使一些基礎問題直到軟件生命的中期才被發現，這將導致大量的文檔和產品需要更改，由此帶來嚴重的工程和管理難題。改進的方法之一是調用有相當軟件調試和維護背景的資深人員參與需求規格說明的編寫，他們的豐富經驗往往可以較好地彌補設計開發人員在這方面存在的不足。
缺乏對需求文檔的配置管理
採用兩個需求規格說明編寫模板是一種不錯的做法：一份給軟件客戶看，一份留給軟件開發小組內部使用，前者的目標是讓客戶較容易理解，後者則更加專業化。在這種情況下，兩個需求規格說明都應納入配置管理的範疇以便從管理的角度保持其一致性。這還不夠，從工程角度考慮，企業還應該形成一套從前者到後者的轉化規則。儘管這兩個模板的表現形式可能是自然語言，但一個儘可能嚴謹的規則將大大縮小轉化過程中人爲自由發揮的空間。需要注意的是，這套規則的建立應從一個項目開始，從基礎做起，逐漸完善。例如，首先確定項目的基本名詞和動詞集合，並規定語句書寫規則。
需求規格說明缺乏可測性
在需求說明應具備的幾個特性裏，爲什麼單單挑出可測性呢？在需求說明編寫階段，主觀性對其他特性的影響較大，而一個獨立且有經驗的測試組對可測性的掌握是從獨立於需求規格說明的測試文檔出發的。從測試的角度看，很多需求說明是不可測的，這就要求重寫這些需求說明，直到可測性得到保證。測試組要求的往往是簡潔且準確的說明，而這恰恰是開發人員做得不夠好的幾個方面之一；另一方面，目前無論是國內的市場還是企業，對測試人員都不夠重視，軟件企業很少招聘測試人員。實際上，優秀的軟件測試人員對保證軟件質量非常重要，一般來說，測試部門的經理應該由具有軟件開發經驗、做過軟件開發管理且有相當測試經驗的資深人員擔任。處理好設計和測試人員的關係是衆多國內軟件企業應該進一步重視的問題。
缺乏較好的需求規格說明轉化規範
需求規格說明轉化的目的是把用自然語言書寫的需求說明轉化爲更準確的中間形式，這一轉化過程也被稱爲“軟件建模”。一般來說，建模可以使需求說明的某些方面更形式化一些，並使設計更加清晰地保持需求繼承。通常，不做需求規格說明轉化或缺乏較好的需求規格說明轉化規範，將造成不同程度的需求說明丟失，從而增加後續管理工作的難度。
需求管理的根本目的是爲其後的工程和管理建立基線並保持相關及衍生文檔和產品與需求的一致性，因此需求工程完成得的好壞，對需求管理實施的工作量有很大影響。
2. 配置管理與工作產品的轉化
軟件配置管理的目的是保證項目生成的產品在軟件生命週期中的完整性，它需要一個較好的工具，當找不到較好的商用軟件工具覆蓋該關鍵域的實踐時，許多國外軟件企業會自行開發一些工具來彌補不足，並且取得了很好的效果。國內軟件企業在實施該關鍵域時也會使用一些工具，但存在的典型問題是：有太多的SCCB（軟件配置控制委員會）活動。
配置管理是在軟件生命週期中建立和標識軟件工作產品並控制基線的更改，這將保證軟件工作產品的完整性和一致性。但是，作爲配置項/單元標識的軟件工作產品通常爲典型的軟件生命週期中的工作產品，這些產品具有一個共同特點：一個產品通常是由另一個產品轉化而來。從一些企業配置管理下的工作產品來看，存在的主要問題是缺乏較好的可轉化性。在這裏，較好的可轉化性摻蝦玫目勺詳是指把一個產品轉化爲另一個產品時有較規範的轉化規則可循，其目的是最大程度地保證一種工作產品能被忠實地轉化爲另一種工作產品形式，從而最大限度地降低最初的軟件需求在轉化過程中出現遺漏和被錯誤解釋的可能性。企業在實施這個關鍵過程域時，應由SCCB記錄工作產品的更改以及引發這些更改的原因，這些數據能很好地幫助企業找出問題的癥結。一般來說，引發類似問題的原因主要有以下3點：
需求規格說明書編寫不好或不全；
工作產品模板定義不好；
工作產品之間轉化缺乏規範定義。
3. 項目計劃與數據收集和分析
項目計劃是CMM實施一開始就涉及且最後才能相對完善的關鍵過程域，它主要包括軟件規模估計、工作模塊計劃、人力資源計劃、進度安排和其他其它資源計劃。在其他它關鍵過程域的實踐相對穩定之前，項目計劃的實踐總是處於需要改動的狀態。
一般來說，期望在CMM實施之初就有一個可靠的項目計劃是不現實的，因爲這需要經歷若干項目的實施才能獲得有效數據並據此制定未來項目的計劃。我們知道，配置管理可以保證項目生成的產品在軟件生命週期中的完整性，因此，爲了更好地實施項目計劃，我們可以把用於項目計劃的大部分數據放在對應的工作產品配置管理之下，必要時，還可將工作產品進一步細化，以保證對應的項目計劃數據的準確性。項目完成後，我們還應該對項目計劃的數據進行收集和分析，在此基礎上制定下一個項目計劃時，準確性就能大大提高。通過對若干項目進行同樣的實踐，項目經理就有了比較可靠的數據用於制定未來的項目計劃。通常，項目跟蹤和監督實施不好的原因很大程度上是由於項目計劃的頻繁更動，同時缺乏良好的項目跟蹤工具，使項目管理人員逐漸失去跟蹤項目的興趣。
4. 質量保證與實踐反饋
實踐反饋是質量保證體系得以有效運作的驅動力，企業應該爲所有項目建立一條從SQA到項目經理以及更高層經理的反饋渠道。實踐反饋是SQA組與高層經理相互溝通的過程，SQA組定期向高層經理彙報SQA的活動，並及時與項目組溝通，使項目組能儘早改進工作；當溝通不暢、發現項目組運作不力或發現組間協調困難時，應及時報告高層經理，通過高層經理的協調及時進行修正。
有些項目經理認爲自己心裏有一套計劃，只要按計劃進行就可以按時保質完成項目，但事實並非如此，在項目組之間的協調問題上，高層經理的作用是非常明顯的。如果僅僅爲滿足CMM的要求而虛設高層經理，這種做法是不可取的，因爲如此一來，實踐反饋是不完全的。
SQA組在CMM實踐中猶如一個司法機構，但這還不夠，它還應該爲改進過程管理提供資源。SQA組不一定完全由專職人員組成，也可調配一些擅長軟件開發方法和軟件過程管理的人員參與主要的SQA活動。
5 .同行評審
從理論上講，同行評審這個關鍵域的實施並不難，但實際上大多數企業都掌握得不夠好，主要表現在以下方面：
評審時組間爭論過多或過少
這一問題在不同企業的表現也不同。調查表明，爭論較多的情況是工作產品的輸入/輸出不清楚，組間缺乏溝通的公共平臺，因此組間只有通過較多的討論甚至爭論才能弄清其他組的需求。遺憾的是，事後大家並沒有坐下來認真討論如何改進原工作產品的模板形式或表現形式，因而也就無法從根本上解決問題。另一種較極端的情況是，評審一個組的工作產品時，其他組很少發表意見，儘管有些問題是十分明顯的。通過調研發現，這實際上是企業文化的問題。一種普遍的想法是“等我們實際做的時侯自然就清楚了”，但實際情況往往事與願違，這使企業的工作效率大打折扣，但又不易被管理層意識到。無論是哪種情況，最終的原因是：“項目甚至企業缺乏持續改進過程管理的意識。”
缺乏心理訓練
做好同行評審的最大挑戰是克服心理障礙。簡單地說，同行評審就是被別人挑錯或挑別人的錯。因此，評審會就像是答辯會，必須做好充分的準備。當角色互換，自己成了挑錯方時，則應該把被評審的工作產品看成是自己在較早前完成的，現在再做一次修改，且修改完成後，自己要拿它去參加評審答辯。經歷幾次這種心理角色換位，就會逐漸適應。如果大家都這麼做，同行評審就會形成良好的氛圍，這對形成健康的企業文化將起促進作用。
競爭與合作意識不充分
從另一個角度看，同行評審又是競爭與合作的最佳表現場所和形式，凡在這種場合講話有理且意見中肯的人逐漸會成爲團隊的核心人物。在這種競爭的環境中，合作是基礎，同行評審的目的就是在合作的前提下儘早且有效地排除工作產品中的缺陷。把握好競爭與合作的尺度，將有益於企業文化的發展，否則有可能出現惡性循環。如何把握呢？從大量的案例看，多數消化少數是較好的方法，因爲文化是不可創造的。
考慮不全面
同行評審存在的另一個問題是評審時僅注意工作產品內容本身，大家面對面地弄清內容後，卻忽略瞭如何改進工作產品的表現形式，使新表現形式下的工作產品可更好地用書面形式表示，進而可減少面對面溝通的需求。當然，面對面的溝通並不是不好，但如果一個工作產品需要太多的口頭表達才能被理解，則原因只有兩個：書寫不清楚或模板定義不好，如果是後者則情況更糟。 6. 缺陷預防與度量
缺陷預防的目的是爲了識別產生缺陷的原因並防止其再次發生。一些實施低級別CMM的企業通常都採用一些度量（metrics）來預防缺陷，包括軟件大小、軟件設計錯誤、編碼錯誤、測試錯誤、設計評審覆蓋、編碼評審覆蓋、產生測試覆蓋、與過程原因相關的缺陷、與項目原因相關的缺陷等。
個別企業選用了一些難度更大的度量。大多數情況下，這些企業並非要達到更高級別的CMM，而是從產品需求的特性出發，對工作產品進行缺陷分析和預防。其過程通常是：獲取數據、數據整理、度量、發現原因並確定過程的改進措施，其典型例子包括設計複雜性與測試覆蓋及測試深度、模塊複雜性與測試覆蓋及測試深度等。這類企業的軟件產品一般具有以下特點：軟件產品規模較大，通常在軟件產品交付給用戶後，通過相當長時間的不斷維護，穩定性才能達到滿意程度。如果在早期對可能產生較多錯誤的軟件模塊進行識別，加強對這些模塊的早期關注和測試，就可較早地使系統達到穩定。這種方法常常用在大型軟件開發中，但真正用好的並不多，主要原因有以下幾點：
忽略了使用度量的環境
大多數工作產品的度量都是爲某一種特定的設計方法或編程語言設計的，忽略了這個因素，度量就容易失去準確性。此外，軟件產品不同的行業特性往往也是造成度量產生偏差的原因。
忽略了對度量參數的修改
一些度量參數是在原來的實踐環境下確定的，當在新環境下使用時，其中的參數很可能需要進行修改，才能使度量的準確性得到保證。
忽略了對相關性的研究
使用的度量與缺陷在本地的相關性越高，度量的價值就越大。獲取這種相關性的方法一般是對本地的歷史數據進行相關性研究，企業只有在確認滿意的相關性後纔可將度量用於缺陷預防。
|
