軟件測試中CMM評估中存在的若干問題
前言：本文部分內容參考了2000年2月IEEE雜志上的一篇文章。該文作者從采購方和軟件企業方分析了SCE中存在的若干問題，最后發問：“CMM評估還可信嗎？” 中國軟件企業的CMM評估，一開始就充滿了浮躁、做秀和功利的氣息。整個CMM評估的過程，我們看到的是好大喜功的政府行業主管部門、一貫愛湊熱鬧的新聞媒體、有賺白不賺的中介機構、證書隨身帶的主任評估師和愿意花錢買吆喝的軟件企業。CMM評估的這種濃厚的功利性，使得“Gaming the Assessment”成為軟件企業上上下下的共識和“不宣之秘”。希望本文對國內軟件業界正確對待CMM起到應有作用，不要像某些軟件企業一樣找個“證書隨身帶”、“一手交錢，一手交證”的主任評估師。畢竟，提高企業的核心競爭力是最重要的。
1 評估人員的資質SEI對主任評估師的資質要求比較嚴格，但是評估是由一個評估小組來進行的。
問題1：評估組員的資質很難滿足。
通常，評估組員很難達到SEI所要求的軟件工程的技術和管理背景。
問題2：評估人員多是管理人員，技術素質普遍較弱。
這個問題也包括主任評估師，由于多年脫離軟件開發實踐工作，主任評估師甚至在提問時有意回避技術問題，而是反復詢問管理問題。因為評估人員的技術素質普遍較弱，因此對于CMM中涉及工程部分的關鍵實踐解釋能力很差。甚至在對企業員工面試時，當員工提到技術方面問題時，評估人員會將話題岔開，又轉到管理問題上。
2 評估的時間壓力一般評估的時間都在一周左右，要執行的工作相當多，時間壓力很大。原來的評估方法中要求單個面試的方式，后來迫于時間壓力，新版本中增加了“Group Interview”（團體面試）。
問題3：團體面試本來是為了節省時間，實際上往往掩蓋了問題，不能發現真實情況。
聯想測試部門的面試，就是團體面試的方式。
對于評估小組而言，由于時間緊張，他們往往不愿意運用自己的洞察力和專業判斷力，而是滿足于在檢查清單上一項一項劃勾，也就是俗稱的“Checklist強迫癥”。
問題4：“Checklist強迫癥”也給了軟件企業一個鉆空子的機會。
軟件企業可以努力使文檔做得更加“方便評估小組的工作”。
3 CMM問卷在CMM評估中，用到的是同一套問卷。連美國人都批評到，“不可想像對于醫生、建筑師或者律師采用同一套試卷來考察，而對于軟件企業的評估使用的確實一套不變的問卷。想想看，這些軟件企業可能是在為我們的國防系統進行開發！”
問題5：同一套成熟度問卷。
CMM評估允許企業在評估前對員工作出培訓，而這個培訓的作用往往被扭曲了。很多軟件企業甚至“教唆”員工在成熟度問卷上如何回答的“更成熟”一點。
4 文檔因為CMM評估要求文檔應該有在線版本（這樣才可以被配置管理軟件所管理和控制），所以企業在將文檔轉換為在線版本時，就可以對文檔作出修飾。因為知道評估小組的時間很緊張，軟件企業可以把文檔弄得故意非常復雜，評估小組有時候看到復雜得文檔，會不愿意去深究，認為既然寫了這么多，看在頁數得份上，也應該滿足要求。
問題6：過分依賴文檔。
5 項目的選擇選擇什么項目給評估小組看，這里大有學問。軟件企業可以把自己最“成熟”的項目、最優秀的員工組成一個“Goldern Project”來供評估小組檢查。那么，這樣的評估可信性就大打折扣。比如，國內某軟件企業明明是自己一個20多人的“中央研究院”過了CMM某個級別，在媒體宣傳時卻故意混淆視聽，有意無意造成整個企業通過某個級別的錯覺。
問題7：選擇什么項目，選擇什么部門，這其中太多貓膩。
6 事先“培訓”員工甚至有這樣的現象，員工在接受面試之前，塞給他一本企業的CMM指導手冊，甚至要求他故意在手冊上作點筆記、把手冊弄得臟一點，以顯得認真閱讀過了。
問題8：“培訓”員工作假。
這里最嚴重的問題，實際上是主任評估師的技術素質。計算機技術領域日新月異的發展，很多主任評估師是只知道“管理”，對于技術的理解可能僅僅限于5－10年前的技術。IEEE雜志文章的作者建議，在評估時應該同時“Conduct on-site technical evaluations”，觀察企業的開發人員實際完成技術工作的方式。作者特別舉了一個企業的例子，紙面上的同行評審與實際中的同行評審的天淵之別。
Paul在給聯想評估時，竟然沒有向測試部門提問，這個事實太令我失望了。其他領域不論，我真的不信對于測試領域竟然無話可問！
文章來源于領測軟件測試網 http://www.k11sc111.com/