目前很多有一定規模的軟體公司都熱衷於cmm認證，他們不僅想藉此提高公司的聲譽，拉開和競爭對手的距離並且在業務競標中取得有利位置，也更想藉此機會從本質上使本公司的軟體開發實力達到乙個質的飛躍。但是對於小公司或者小的開發團體呢？他們由於資金，資源和規模等方面的原因，不可能花費鉅額的投資去請好的諮詢公司來做cmm認證，因此也造成也一些小公司，小開發團體覺得沒有認識和運用cmm的必要，但事實真的如此嗎？
在學習了《軟體過程改進與管理》這門課程後，並且結合自己工作中碰到的實際問題，我覺得即使是小公司，小開發團體，如果能夠適當抽取cmm的部分思想精髓來對日常軟體開發工作進行過程改進也是十分必要的，目的不是為了認證而認證，也不是為了接工程而進行所謂的cmm認證，關鍵在於真的達到「改進」這個目的。
我公司雖然是香港的乙個上市it公司，但主要業務做系統整合和解決方案為主，而軟體部分佔的比重並不大，只做技術支援，軟體整合和必要的軟體開發，因此和一般專業的軟體開發公司確實有很多不同的地方，因此我們部門的軟體開發只能屬於小的開發團體。雖然也過了iso9001，但是這個認證主要是針對系統整合專案為主的，我們公司一直以來在軟體開發部分並沒有形成十分規範的管理流程，特別是文擋管理也只是遵循著公司自己制定的文擋模板而已。在學習了《軟體過程改進與管理》之後，我覺得其實cmm中的很多思想在以前的開發工作中也有用到，只是沒有十分系統的整理或者說上公升到一定的層次去做乙個提高而已。學習了課本的理論，再回想工作的情況，恰好可以做到理論指導實踐，實踐檢驗理論的作用，有些思想在日後的工作中如果可以運用起來的話，確實可以促進象我們這種小團體的開發效率的。無論做什麼樣規模的軟體開發，重用性是任何程式設計師和程式開發團體的終極追求目標。從以前結構化開發過程的時候，大家都絞盡腦汁去歸納出公共函式，到現在流行的物件導向開發過程時提出的各種設計模式；從以前的公共程式庫到現在流行的元件技術…這些都是程式設計師在技術方面對重用性的乙個追求的軌跡…有人說軟體開發成功重要因素就是技術，人和管理，重用性在技術方面的追求一直都沒有間斷過，而人本身也是重用性的努力追求者，在管理方面呢？雖然各種的管理方式層出不窮，從適合大團隊開發的rup迭代開發到適合小團隊的敏捷開發模式xp，這些開發方式或者說是太具體了，對於國內的開發團體，完全地生搬硬套似乎都遇到這樣或者那樣的困難，或者是中途夭折，又或者尋尋覓覓，在各種的開發模式中猶豫不決，而cmm的層次和它們又有所不同，它沒有提出乙個具體的操作指南，但卻從效果的角度提出了它的要求，並且制定了5個不同的級別：初始級，可重複級，已定義級，已管理級和優化級。這幾個級別當然是級別越高越好，但是對於不同的規模的團體卻可以根據自己的實際情況去制定自己的近期目標，而不需要去追求不切實際的級別。對於可重複級別，其實已經可以在一定程度上實現程式設計師一直追求的終極目標--可重用性了。
結合自身的開發過程，像我們這種小的開發團體，並沒有必要一定要完全遵循或者達到這些級別的每項要求，然後自詡自己達到了什麼級別，這些並沒有任何實際的效果，倒不如從中抽取幾個精髓加以實現，從而可以達到過程改進的目的。
任何專案的執行過程中都需要指定必要的計畫，這個道理即使沒有學習過cmm，只要做過專案都是應該知道的。而學習了cmm後，從理論上知道在專案執行過程中需要制定計畫，這是cmm二級中spp(software project planning)的核心內容，並且還是spto(software project tracking and oversight)的依據。由此可見專案計畫這個活動的實施好壞直接影響到2個kpa的效果，而且這個還是cmm二級的難點之一。在以前的專案實施，雖然都可以意識到專案計畫的重要性，但在實際執行過程中，對於計畫的跟蹤和進度記錄的工作也往往做得不夠充分，特別是任務比較緊的時候，跟蹤和記錄有時就成了專案經理給領導做的一些門面工夫了，並沒有真正起到應有的作用。由於這些記錄的並不真實，又往往不能使這些資料對後來的專案起參考的作用，到下乙個類似專案，一切又由專案經理根據自身的主觀經驗來對新專案的進度和資源的分配進行估計，因此專案計畫的制定並沒有達到乙個不斷改進的效果。如果專案人員接受了cmm的思想，並且能夠真實地跟蹤專案程序，真實資料的積累對於日後過程的改進是十分有效的。
以往的開發中，我們也有用到一些版本控制工具，例如cvs或者vss，但是都只是為了從技術上同步大家的**而使用的。在學習了cmm後，才認識到配置管理制度的重用性，而版本控制也是配置管理的其中一部分。對於小的開發團體，設立sccb機構是完全沒有必要的，但是確定受控產品和做版本管理，專案組建立基線，里程碑，版本一致性的概念和更加規範版本操作的check-in和check-out等動作確實十分必要的。理解了cmm的配置管理機制，可以讓我們在開發過程中，從更高更全面的角度來完成以前版本控制的工作，這個過程改進也是十分明顯的。
由於人手的原因，對於小開發團體，在某種程度上在以往的開發過程中對於質量保證方面是粗線條的，往往開發人員完成了unit test就整合起來做了幾次整合測試後就直接去到使用者那裡做使用者測試了，往往造成的結果是開發人員經常被使用者叫到現場去修正程式錯誤。這雖然不可避免，但是次數多了，往往對於整個專案的進度的影響很大，而且對於**的版本管理和整體監控等方面都十分不利的。在cmm的思想指導下，質量控制管理體系不能夠因為人手的原因而減低對其的要求，寧可適當加長專案時間也必須將質量保證下來。
監督體系不僅是管理的需要，也是專案組中成員和專案經理溝通的需要。專案組成員應該定期給專案經理做進度的匯報，而專案經理也有義務定期做專案週報和專案進度總結。監督還包括測試人員對工作產品的審核，包括需求文件，使用者說明書，**和產品質量等環節。雖然這點看起來似乎對於小開發團體，由於因為人手和資源的原因在實施上有一定的困難，但也應該在cmm的思想上對其重視，不應該為了趕進度而將這些必要的事情忽略了，最終又去返工補救。這樣只會得不償失，也使整個開發過程得不到乙個持續改進的效果。
總的來說，cmm的思想不僅適合大公司，對於小開發團體一樣可以起到過程改進的效果，關鍵是要把有限的資源用到「點子」上，使得整個開發過程朝乙個健康的，持續改進的方向發展。
軟體開發管理CMM等級劃分
cmm軟體開發流程試圖將幾十年來風險比較不可控的軟體開發用乙個規範的流程控制起來，變成乙個類似傳統工業化生產流程的工業。cmm理念 cmm主要理念之一就是加強過程控制，認為只要開發的過程按照規定動作執行，就可以很大程度上降低軟體開發的質量 進度風險。而過程質量控制的主要手段就是檢視。cmm的理念之二...
解印度CMM模式困境 提供中國軟體發展新思路
2008 09 18 14 51 cmm成就了印度軟體業今天的輝煌，但cmm無法適應軟體需求的快速變化，又限制了印度軟體業進一步發展，近年來興起的精益管理模式下的敏捷開發過程為中國軟體業提供了乙個發展思路。cmm成就了印度軟體業今天的輝煌，但cmm無法適應軟體需求的快速變化，又限制了印度軟體業進一步...
CMM的級別就是軟體開發管理的「段位」
cmm的級別就是軟體開發管理的 段位 cmm 英文wiki 是什麼 包括cmmi，因為本文不涉及細節 有人把它理解成 規範 有人把它理解成 標準 一般人對cmm的理解是 1 cmm是一堆規範的集合，包括5個等級，共計18個過程域，52個目標，300多個關鍵實踐。2 如果按照這些規範執行就需要寫很多文...