前言
當學習了軟體過程改進這門課後，我時常在考慮乙個問題，那就是大家一提軟體過程改進，言必是cmm云云，給人的感覺好象軟體過程改進就是cmm是的。其實作為一門學科來講，軟體過程改進所包括的內容是多方面的，cmm只是其中的一分子。就我個人認為：軟體過程改進對我國的軟體質量的提高和開發進度控制還是非常有好處的。為什麼要這麼說呢，我可以舉乙個我們現實生活中的例子來說明一下。不知大家吃過西餐沒有，如果你吃過的話，你有沒有發現不管你來吃多少次，味道似乎都一樣呢。再讓我們來比較一下中餐，你敢說你每次吃的都是乙個味道嗎？特別是當這個餐廳的大廚換人的時候。為什麼中餐廳會因為某個大廚的離開而影響其生意甚至倒閉，而西餐廳卻不會呢。仔細分析其實並不難理解，這是因為西餐廳把自己的每道菜用多少菜，放多少油，鹽，醬，醋都形成了規範，形成了標準的文擋，形成了操作的習慣，它不會因為某個人的離開而無法繼續進行。而我們的中餐廳卻不是這樣的，他呢只會依靠幾個水平很高的大廚來支援他的運作。我們很容易想象當這些人離開後所產生的影響是多麼大，輕則影響生意，重則甚至關門，這種事我們見得還少嗎？再來看我國軟體行業，和中餐廳的運營方式是多像啊，我們難道只有到了關門大吉的時候才會哀嘆自己既知今日，何不當初就。。。，那就晚了。
有人可能會問我，那我們也可以像西餐廳的那樣，採用cmm（很多人長掛在嘴上的話題，顯的自己很智慧型，其實對cmm的主旨也只是一知半解而已）來管理我們的公司，是不是就解決問題了呢？這多像乙個病人充滿希望地問醫生：「你看我的病什麼時候能好？」。在這裡我不想打擊很多準備實施cmm的企業的積極性，我只想說的是「你要看cmm到底適合你的公司嗎？你的公司有實施cmm的能力嗎？」。說到這在讓我們來看看我國中小企業的實際情況吧：管理基礎薄弱，資源不足，生存壓力大，缺乏統一而有力的文化，人員素質良莠不齊。在這種情況下去實施cmm真的能妙手回春，解救你的公司於水火之中嗎？我真的很表示懷疑。
有人會說，你不要那麼悲觀嗎？你看我國iso9000不就實施的很好嗎？不要再豈人憂天了。聽到這話我不禁要反問一句「我們的iso9000真的就實施的很好嗎？」。請允許我再舉乙個我們張老師給我們講的故事「東門外乙個賣油茶的人，很激動的對來往的人說我賣的油茶通過了iso9000，你們快來吃吧。」，我想可能大家都會被他嚇跑，誰還敢去吃他的油茶啊。首先我要申明，在這裡我沒有一點侮辱iso9000的意思，我只是想說iso9000在我國是否氾濫了呢，我記得我曾經工作過的乙個單位，為了通過iso9000所做的一切事情，除了自欺欺人，還能剩下些什麼，我不想再多說什麼，或許這種事情太多都見怪不怪了，麻木了吧。說真心話我可不希望cmm也和iso9000一樣。
其實我們都明白，實施cmm和iso9000的作用是為了什麼呢？還不是希望提高我們的軟體質量嗎？很多時候我們都是為了什麼而什麼，而忘卻了真正的目的是什麼。我認為乙個企業最大的目的是贏利，因為不贏利他就無法生存，都無法生存了，還有必要去考慮一些面子工程嗎？「馬斯洛需求層次理論「我想大家都知道，他闡明了生存是最大的需求，它是其他需求的基礎，離開了生存的一切都是空的。我想這是很好理解的，當你的生存都有問題的時候，你還會去考慮其他什麼問題嗎？我想肯定是不會的。
讓我們把話題在轉回到軟體過程改進上來吧。只要乙個軟體企業在開發產品，它就一定有乙個軟體過程。當這個過程不能很好地適應開發工作的要求時，就必須要進行軟體過程改進，這就像生產力和生產關係，當生產關係不能適應生產力的發展是就必須要進行改革一樣。其實對軟體行業而言，軟體過程改進並不是一件很困難的事。因為它既沒有要求我們寫乙個作業系統，也沒有像設計乙個微處理器那樣的純技術上的難度。因此通過我們自身的努力還是有可能很快實現的。
那麼我們應該如何去進行改進呢？
首先我們把我們要想達到的狀態與目前的狀態作比較，找出其中的差距到底在那裡。其次我們應該決定到底要改變哪一些差距，是全部還是部分，到底要改變到什麼程度。下來我們就必須制定具體的行動計畫，包括如何實施，是分階段還是一次性等等。最後就是執行計畫，同時在執行過程中對行動計畫按實際情況進行調整。因為只要存在發展就始終存在著改進，因而我們還必須總結這一輪改進的經驗，開始下一輪新的改進。
同時乙個軟體開發單位還必須了解自己處於哪乙個層次，然後才能夠對症下藥地針對該層次的特殊要求解決相關問題，這樣才能收到事半功倍的軟體過程改善效果。任何軟體開發單位在致力於軟體過程改善時，只能由所處的層次向緊鄰的上一層次進化，即軟體過程的進化是漸進的，而不能是跳躍的。而且在由某一成熟層次向上一更成熟層次進化時，在原有層次中的那些已經具備的能力還應該得到保持與發揚。
說了這麼多，我必須要表明一點：軟體過程的改進決不是一蹴而就的，它是乙個長期的艱苦的過程，它的實現需要從加強企業的自身管理開始，沒有乙個好的母體，在優秀的東西也就不再優秀。讓我們好好的理解這句話吧「乙個企業軟體工程過程的建立不會一開始就十全十美, 而且企業的內外部環境也是在不斷地變化.所以軟體的管理過程需要不斷地改進。缺少了過程改進，再好的體系也會漸漸的變得過時和不適用，更沒有可能使我們開發軟體的能力逐步地成熟起來。」
總之，乙個企業不論採用iso9000也好，cmm也罷，還是其他的psp，tsp等等，我認為如何能有效地規劃和管理所面臨的專案開發任務，並且能是開發隊伍始終以最佳狀態來完成工作這才是最重要的。
「軟體危機」這把生死之劍依然懸在我們頭上，我們不能有一絲絲的放鬆，而且也容不得我們放鬆。我堅信只要我們堅持改善軟體工程的管理，並在實踐中總結適合自身的經驗，我們就一定能取得很好的效果。
關於CMM CMMI過程改進的思考
讀張維迎先生的 理性思考中國改革 一文，聯想到軟體企業所進行的cmm cmmi過程改進工作，頗有感想。無論相對微觀的過程改進還是巨集觀的改革，其思考方式看來是可以借鑑利用的。張先生一文的內容可以概括為四個短語 換位想 向前看 講可行 重邏輯，這些何尚又不是在軟體過程改進工作中必須遵循的思考方式呢？中...
CMMI時代的軟體過程改進
在這個概念 的時代，cmm cmmi在中國軟體這片特殊的土壤上，曾經創造了並不完美的輝煌，也面對著諸多質疑和否定，一路走來，它會最終將被證明是乙個偉大的經典還是乙個因水土不服而徹底失敗的理論呢？後cmm時代的軟體過程改進又將如何演繹呢？以下，筆者嘗試從cmm cmmi以外的三個方面來 這個問題.有效...
怎樣進行軟體過程改進
原帖裡面其他的文章也非常好 有人認為，如果乙個軟體機構在五個開發人員以下，以及開發周期短於六個月，進行基於sw cmm的軟體過程改進是不划算的。寫這篇文章的乙個目的，就是幫助人力財力不那麼雄厚的中小型企業進行軟體過程改進，讓他們能少花錢，少花時間，並且顯著得益。無論人數多少，開發周期多短，改進必得益...