 討論區主頁 軟體流程改善
CMMI 評鑑存在若干問題，大家不妨一起思考如何改善 ! | 無發表權 |
| 全部展開 | 前一個主題 | 下一個主題 |
| 發表者 | 討論內容 |
|---|---|
| tyrone | 發表時間: 2005-03-20 10:42 |
網站管理員   註冊日: 2003-04-19 來自: CSQA 發表數: 342 |
CMMI 評鑑存在若干問題，大家不妨一起思考如何改善 ! 以下是在中國大陸賽迪網所發表的一篇文章, 僅供大家參考 !
*********************************************** [ CMM 評估的各環節分析及其存在的若干問題 ] 作者： http://image.ccidnet.com/ad_files/home/images/blank.gif 來源： http://www.csdn.net 前言：本文部分內容參考了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在給聯想評估時，竟然沒有向測試部門提問，這個事實太令我失望了。其他領域不論，我真的不信對於測試領域竟然無話可問！
凡所有相皆是虛妄。見諸相非相。即見如來。 |
| 全部展開 | 前一個主題 | 下一個主題 |
| 主旨: | 發表者 | 日期 |
|---|---|---|
»  CMMI 評鑑存在若干問題，大家不妨一起思考如何改善 ! |
tyrone | 2005-03-20 10:42 |
| Re: CMMI 評鑑存在著若干問題，大家不妨一起思考如何改善 ! |
cheng | 2005-03-23 11:37 |
| Re: CMMI 評鑑存在著若干問題，大家不妨一起思考如何改善 ! |
訪客 | 2005-06-30 09:28 |
| Re: CMMI 評鑑存在著若干問題，大家不妨一起思考如何改善 ! |
Fred | 2005-12-03 00:51 |
| Re: CMMI 評鑑存在若干問題，大家不妨一起思考如何改善 ! |
cheng | 2006-01-06 10:43 |
| Re: CMMI 評鑑存在若干問題，大家不妨一起思考如何改善 ! |
Member | 2006-04-19 09:49 |
| Re: CMMI 評鑑存在若干問題，大家不妨一起思考如何改善 ! |
Terry | 2006-04-24 10:51 |
| 無發表權 | |