模板
教程
環境
性能
功能
管理
CMM軟件過程改進前常見問題解答
Q：在實施基于CMM的過程改進時，難度最大的KPA是哪些？ A：根據SEI在2002年8月份發布的統計數據來看，如下圖： 上圖是根據全球496次正式評估得到的統計圖表，其中我們重點關注CMM 2級的6個關鍵過程區域的情況。圖中對于每一個關鍵過程區域都有2個數據，分別
| Q：在實施基于CMM的過程改進時，難度最大的KPA是哪些？ A：根據SEI在2002年8月份發布的統計數據來看，如下圖： 上圖是根據全球496次正式評估得到的統計圖表，其中我們重點關注CMM 2級的6個關鍵過程區域的情況。圖中對于每一個關鍵過程區域都有2個數據，分別表示在這496次評估中完全達到要求的比例和進行了評估的比例。換句話說，在2級的6個KPA中紅色柱最短的應該就是實施難度最大的KPA，這樣看來子合同管理似乎是實施難度最大的KPA。但我們發現產生這種情況的原因是：在絕大多數的軟件企業中沒有需要進行子合同管理的情況，這樣，子合同管理這個KPA在60%以上的評估中被定為“不適用”或者“不評級”。除去這個KPA，在90%以上的評估中，二級中的其他5個KPA都進行了評估，而只有10%多一點的評估中SQA（軟件質量保證組）能夠做到完全達到要求，這足以說明SQA是CMM 2級實施過程中難度最大的KPA，需求管理的實施難度最小。具體分析，原因如下： ★ 和各企業對于不同KPA的重視程度有關系，需求管理幾乎是所有軟件企業都非常重視的內容，畢竟需求管理不好，需求變更頻繁對項目組的工作量、進度和成本等方面影響是巨大的，于是各企業無論是否進行基于CMM的過程改進，都努力在找出使項目組和用戶就將來產品的功能、性能等達成一致理解的方法，并盡一切辦法減少客戶提出需求變更的可能。相對來說，質量保證的工作就不那么引人注意了。 ★ SQA的工作帶有一定的預防性質。大家都知道，在軟件公司里面，評判一個人是不是“高手”的準則是他能不能解決其他人都解決不了的問題，就像給人治病的醫生，能夠治療疑難雜癥的是“神醫”；不知道大家有沒有想過，如果有個醫生在病人剛剛出現輕微癥狀的時候就能把別人的病治好，對于病人來說是莫大的幸事，但這樣的醫生恐怕一般人不會認為他是個好醫生，同樣，SQA也是如此。 ★ 很多國內的軟件企業一邊在抱怨他們的客戶成熟度低，對于軟件什么也不懂，每天都在提出一大堆的需求變更，另一方面卻在充分的利用客戶什么都不懂，在軟件產品的質量上睜一只眼閉一支眼，畢竟高質量的產品需要更高的成本來換取，既然用戶也沒有那么高的質量要求，何必費那么大的力氣呢?？墒撬麤]有想過，這種做法和一些黑作坊里面生產“三無”食品并沒有什么本質上的區別。好在越來越多的軟件企業已經加強了質量意識，也使SQA的地位得到了不少的提升。 ★ SQA要在組織中得到認同。很多CMM 2級實施不到位的組織經常出現的問題就是無論是高層經理還是項目組有關的人員，大家都認為SQA可有可無，沒有必要。如果不是CMM有這樣的KPA，才不會安排專人去做這些事情呢。SQA做得好的企業通常有這樣的特征，組織中的所有人員能夠充分認識到SQA的價值，而項目組中發生的問題都能夠在SQA的幫助下友善的解決。 ★ 根據CMM的要求可以看出，對SQA溝通能力的要求是比較高的?，F在有不少企業的SQA成了“收賬的”，根據公司的規定到什么時候項目組應該出什么文檔，SQA就沖到項目組那里，大喊：“該交XX文檔了！”。項目經理就像老鼠看見貓一樣，求饒著說：“項目組現在太緊張了，能不能過幾天再說？”到底能不能再說就看SQA的心情了。久而久之，所有的文檔都改成了項目結束的時候再統一提交，而到那個時候文檔的質量也沒有人關心了。CMM要求的SQA可不是這樣的，SQA要成為項目組的好朋友，而不是“貓和老鼠”的關系，一方面SQA要執行必要的質量檢查和過程檢查，這是保證公司的整體利益而必須要做的；另一方面，SQA在執行檢查的同時，要通過發現的問題了解項目現在有什么麻煩，在項目組的級別上能不能解決，是否需要向高層經理匯報。要想做好這些事情，要求SQA對上面的高層經理，對下面的項目組反復的溝通，必要的時候還需要請一些技術經驗豐富的專家協助執行技術檢查，沒有相當的溝通技巧是很難做好這些事情的。 對于SQA能否有效的發現問題也是一個不小的考驗。如果SQA沒有比較豐富的軟件開發和項目管理方面的經驗，又不具備足夠的威望邀請一些有這些經驗的人員來協助進行檢查的話，項目組就可以隨心所欲的“蒙”SQA了。有的公司舍不得讓經驗豐富的人員來做SQA，結果可想而知；有的公司在實施CMM以后，充分認識到了SQA的價值，將這個崗位采取輪崗制，要求每個項目經理在正式上崗以前都必須先做半年的SQA，以便充分理解這個崗位的難處和重要性，以后可以更好的配合他們的工作，這真是一個很好的想法，值得推薦。 |
| ■ 實施企業是否可以使用階段式的演進路線： 如果企業只希望單方面的提高自己在項目管理、工程活動、支持活動或者過程管理四個方面中的某些方面的能力，那么就只能應用CMMI的連續表示方法。如果實施企業可以接受成熟度級別的思路（目前看國內大多數企業還是比較習慣于成熟度級別的），那么就不一定必須選擇CMMI了。 ■ 實施CMM與CMMI可以平滑的轉換。 一來，CMMI并不要求一家企業必須先做CMMI的2級然后再向更高的成熟級別演進，評估的時候也沒有這樣的要求。 另外， CMMI的評估都會根據被評估的成熟度級別，檢查所有不高于該級別的過程區域。換句話說，一個企業在CMM正式評估中達到了2級的成熟度，將來改為基于CMMI進行過程改進。在CMMI 3級的正式評估時，CMMI 2級的內容同樣要進行檢查。如果我們能夠在做CMM 2級的時候就按照CMMI的要求實施，效果沒有任何的折扣，但對于實施企業來說，會節省很多在培訓和評估方面的“額外”費用。（此處的“額外”費用是指CMMI收費比CMM高出的部分） Q：聽說SEI到2003年底將不再繼續支持SW-CMM 1.1版，那我們是不是到時候必須要改為使用CMMI？ A：到目前為止了解到的消息確實如此，不過軟件CMM并不像大家想象的那樣到今年年底就不復存在了。 SEI為了讓CMMI有更多的用戶，已經宣布到2003年底，不再繼續對軟件CMM提供支持。這種現象就像是微軟公司在推出新版本的Windows后，一段時間后就不再對過去版本的產品提供技術支持是一樣的道理。 但為什么可以說CMM并不會到了2003年底就不復存在了呢？這要從SEI對于CMM的支持都包括哪些內容說起，其中主要包括提供CMM相關知識的培訓，公開世界上一些軟件組織實施CMM后發表的論文，解答來自全球軟件組織關于CMM的問題，為主任評估師提供授權證書，管理CMM正式評估相關的信息數據庫等等。除此以外，大家還要知道每位主任評估師的資格證書是有2年的有效期的。這樣我們就可以作出下面的結論了：如果主任評估師在2003年拿到了資格證書，他們可以在2004年和2005年繼續為軟件企業提供培訓和CMM正式評估的服務，而此時SEI對這樣的結果是認可的，只不過SEI不會在進入2004年以后再頒發新的CMM主任評估師的資格證書了。按照這樣的思路，我們可以說CMM可以一直使用到2005年12月。在那之后，恐怕大家只能使用CMMI了。不過，現在在主任評估師當中，仍然存在著大量的爭論，很多人仍然堅信CMMI不能完全替代CMM?？陀^地講，CMMI確實比CMM要先進，質量也高出不少。但CMM已經被應用了10年多了，有些人對它的感情還是很深的，所以有的主任評估師猜想SEI可能會延長對CMM的支持時間。但目前我們還沒有收到任何這方面的消息。 Q：聽說軟件CMM 要出3.0版了，這是真的么？ A：在2002年12月份，我們聽說了這樣的消息。這似乎和SEI宣布到2003年底就不再支持軟件CMM有些矛盾。其實是這樣的：CMM 3.0版本的研發并不是SEI宣布要進行的項目，而是卡內基·梅隆大學宣布要研發的。不過有不少堅持支持CMM的主任評估師對此表示極大的興趣和歡迎，也有不少主任評估師對此事表示擔憂，因為CMMI的研發是得到了美國國防部大力支持的，這樣擅自決定開發軟件CMM的新版本恐怕很難得到“老東家”的支持。果然不出所料，在我們大家充滿好奇期盼新版本的軟件CMM的時候，我們在2003年4月上旬接到了這個項目被取消的消息，雖然不是官方宣布的，但消息來源非?？煽?。作為實施的企業，大可不必為此擔憂。只要認真地實施過程改進，目前的軟件CMM 和CMMI都可以幫助我們取得很好的效果。 結束語 以上十八個問題是對實施CMM前，軟件企業各級管理人員通常要考慮的幾個方面進行的一個簡單的概括說明。當然，對實施CMM的探討決不僅限于此。我希望通過這十八個問題，使將要進行過程改進的企業能對CMM有一個正確的認識，找到一個簡單有效的途徑來幫助企業實施CMM。本文若有不正之處，希望讀者能夠通過.net提出意見、建議，進行討論，以便能有進一步的改進和提高。">yuanqingping@263.net提出意見、建議，進行討論，以便能有進一步的改進和提高。 |
