原帖裡面其他的文章也非常好
有人認為，如果乙個軟體機構在五個開發人員以下，以及開發周期短於六個月，進行基於sw-cmm的軟體過程改進是不划算的。寫這篇文章的乙個目的，就是幫助人力財力不那麼雄厚的中小型企業進行軟體過程改進，讓他們能少花錢，少花時間，並且顯著得益。無論人數多少，開發周期多短，改進必得益！
筆者在「sw-cmm與中國」一文中己提出了對在中國軟體產業中應用cmm的一些建議。
只要乙個軟體企業在開發產品，它就一定有乙個軟體過程（可能只是沒有寫下來）。如果這個過程不能很好地適應開發工作的要求，就需要進行軟體過程改進。
軟體過程改進並不是一件很困難的事。並沒有寫乙個作業系統，或設計乙個微處理器那樣的純技術上的難度。但它面對的是一種含有大量管理成分的工程技術。這也就是為什麼不容易把它做好的原因。
什麼是「改進」？改進所涉及的幾個步驟是：
1.把要想達到的狀態與目前的狀態作比較，找出所有差距；
2.決定要改變哪一些（注意，不一定是全部）差距，要改變到什麼程度（可分階段改）；
3.制定具體的行動計畫；
4.執行計畫，同時在執行過程中對行動計畫按情況進行調整（以最佳效果為目標）；
5.總結這一輪改進的經驗，開始下一輪改進。 下面討論，在進行軟體過程改進時，上述五個步驟中的關鍵內容。
「要想達到的狀態」（目標狀態）：具體是指軟體過程的狀態。如果乙個機構決定採用sw-cmm來作參考籃本的話，就可以基於它的各個關鍵過程域（kpa ），制定出符合自己機構及產品特點的目標狀態。（在這裡，筆者強調「基於」及「符合自己特點」，意思就是不能照抄。）
「目前的狀態」：要找出什麼是目前的狀態，就.要進行對目前軟體過程的評估。評估的方法很多，最簡單的就是一組熟悉本機構的日常開發運作的人員在一起討論，把它列出來。在這裡，可借助sw-cmm的評估問卷辦法。實質上，評估問卷中的問題，就是把各關鍵過程域的各細則內容，加上「有沒有做到」、「有沒有建立」、「有沒有執行」等語句而構成的，並沒有什麼神秘之處。 「決定要改變哪一些差距」：要從多個方面進行考慮決定。例如：「最薄弱的環節」、「最需要改進的環節」，「最易做到而又有顯著收效的改進」，「有人力，財力和時間，即有條件進行」。各機構要按自己的情況作決定。
「要改變到什麼程度」：由於條件的限制，我們不可能做一切希望要做的事，或者不可能百分之百地一步實現目標。許多時候，欲速則不達，反而誤了事。目標與能力，要有個平衡。
「具體的行動計畫」：「具體的」就是：
a. 要有明確的，可以檢驗的目標；
b. 要定出檢驗成功與否的標準；
c. 要有具體的實施行動辦法；
d. 要指定具體執行計畫的人，每人的具體責任與任務；
e. 要指明計畫的主要領導或協調者，以負責解決一切在執行中出現的問題；
f. 要列出所採用的新技術與新工具，怎樣獲得它們；
g. 要定出對新技術和新工具進行對本機構適用性改造的目標；
h. 要有對新技術和新工具的使用進行培訓的計畫；
i. 要列出每一改進對過程的其他部分的關係、影響、和協調的辦法；
j. 要建立與專案相關聯的時間表；
k. 要指出相關的人力、資金與時間的**；
l. 要定出在整個執行過程中，必須在什麼時候提供什麼資料；
m. 要有對執**況進行監察考核的具體辦法及計畫；
n. 要準備很可能發生的，在執行過程中對行動計畫按情況進行調整的行動。
o. 要有對行動計畫執行中可能出現的意外情況有所準備，保證專案仍然能夠順利進行。
p. 必須要有高層領導、管理人員作為推動整個行動計畫的動力。
「在執行過程中對行動計畫按情況進行調整」：一旦發現需要對行動計畫進行調整，以期達到最佳的效果，而實際情況也允許在中途進行調整的話，可以進行經過計畫的、嚴加控制的調整。所有的改變必須預先取得所有有關人員的同意。
「總結這一輪改進的經驗」：過程改進是乙個永不停止的工作。總結經驗使我們能越做越好，越做越有信心。光有未經實踐的知識，還不能有信心。信心是經過運用知識解決了問題之後建立起來的。
sei 建議的做法：
運用sw-cmm進行軟體過程改進，按照sei 的建議是使用他們制定的ideal 模式的做法。
ideal 是個組合字，實際代表：
i initiating（創始）為成功地進行過程改進而打好基礎。
d diagnosing（診斷）找出相對於你要達到的位置，你現在在何處。
e establishing（建立）計畫你如何達到你的目的地。
a acting（行動）按計畫進行工作。
l learning （學習）從經驗中學習和改進你在將來採用新技術的能力。
讀者可詳細學習sei 的出版物：（編號 sei-96-hb-001，共263 頁，可從sei 網頁上找到） 「軟體過程改進使用者指南」（ideal：a user`s guide for software process improvement ）
筆者認為，正規地使用ideal 模式，可能比較適合於大型企業。
下面，就一些問題提出筆者的看法：
是否一定需要外來的諮詢？
企業進行軟體過程改進，是否一定需要外來的諮詢呢？筆者認為，好的諮詢確實能帶來幫助，如果財力上付得起，同時又了解對方是有商業道德和有能力的顧問，則不妨進行一點初步的接觸，然後逐步判斷他的觀點和建議是否符合你們機構的需要，千萬不要被對方說服去投入乙個你們的機構現在不需要的，或在人力、財力、時間上條件不具備的努力。（諮詢服務也是一種商品。不道德的商人會向你推銷你並不需要的商品。）你們要進一步判斷，究竟在哪一些方面，在多大的程度上需要多少外來的幫助，因為過程改進的乙個目的是培養本機構的人才，過份地依賴外來諮詢，會削弱這個努力。
俗語說得好「三個臭皮匠，頂個諸葛亮」。在機構內部組織乙個小組，多討論，通過各種渠道多學習別人的經驗，破除教條迷信，靈活運用自己的專業判斷力，就有能力領導整個過程改進，並且在實踐中成長起來。（至於運用專業判斷力，實際上更多時候是運用常識。一種**，無論來自什麼權威，如果你覺得不合常理的話，就要弄清究竟。）
知道了要做什麼，如何知道怎樣做？
sw-cmm只提出了要做些什麼（關鍵過程域中的關鍵實踐），但並沒有介紹要怎樣做。解決這個問題的方法很多，比如到軟體工程的書中去找、向有經驗的人請教、或者就自己討論出乙個可行的辦法，從來都不要小看自己經過認真思考而想出來的辦法。凡是從書中或別人處學得的辦法，都要經過適當的改變，以適應自己的機構的條件及目前專案的特點。世界上沒有適合一切人穿的鞋。 怎樣知道過程改進帶來了什麼效果呢？
一般來說，你知道了目前的缺點是什麼，就應當知道怎樣去判斷過程改進的效果。當然，效果可以分別從質和量的角度去量度。對於不同的改進，效果的檢驗方法就不同，比如對於專案的計畫中的軟體規模大小的估算，就可以從最終產品的大小中得知估算的準確度；比如進行早期缺陷預防，就可以看看在開發的各個階段所發現的缺陷數目的分布（記得在行動計畫中要有記錄統計的一項）；又比如進行軟體配置的版本控制改進，就可以看看是否對不同的版本有了完全及方便的控制。因此，可以看出，這些都是按常理進行的事。 找差距時，應對照哪些關鍵過程域？
sw-cmm的能力成熟度分等級，是人為的。它是基於sei 對成熟度的由底到高的理解來劃分的。有人就覺得劃分得不大合理，然而，使用者是活著的人，可以按自己需要作改變。 筆者認為，對於初開始軟體過程改進的機構，不妨對照全部或部分的sw-cmm第二級的各個關鍵過程域，外加第**的「交換審核」，及第五級的「缺陷預防」。（有點象從選單上點菜）
為什麼要把「交換審核」及「缺陷預防」從高的成熟度等級中「往下拉」呢？原因是，按筆者的實際經驗，「交換審核」是乙個簡單易行而且非常有效的找出缺陷的方法，也是一種促進開發人員注重預防缺陷的好方法。至於「缺陷預防」，這是整個軟體過程的核心與靈魂，從一開始就必須全力以赴。
在每個對照的關鍵過程域中，原原本本地對照每一項關鍵實踐嗎？
絕對不是。這裡就牽涉到對sw-cmm進行裁剪及解釋的間題。「裁剪」是指對範圍及程度的改變；「解釋」是指把實際軟體專案中的實踐工作，解釋理解為（等同為）某個關鍵實踐。基本上，不要去裁剪那些屬於目標（goals ）的關鍵實踐。裁剪及解釋，是中小企業能否成功地應用sw-cmm的乙個關鍵。在不影響效果的前提下，剪裁到越簡單越好。要慢慢地把自己培養成裁剪高手。
（sei 有專門討論裁剪（tailoring ）的技術報告，檔案編號是94-tr-024 。）
把機構目前的一切推倒，按sw-cmm重建，是否會更好？
千萬不要這樣做。基於目前的過程進行改進，證明是最有成效的方法。
是否起碼要滿足sw-cmm第二級的所有關鍵過程域呢？ 筆者認為不必。任何方面，任何程度的改進都是有益的。要按照你機構的擔負能力及要求來決定進行軟體過程改進的廣度與深度。
軟體過程改進中，應注意些什麼呢？
應該注意的事情很多，但筆者認為最重要的一點是要注重執行、做實事，千萬不要定出了行動計畫之後就丟進抽屜中，束之高閣。另外乙個要注意的問題是，要有對行動計畫執行中可能出現的意外情況有所準備，保證專案仍然能夠順利進行。
如何進行軟體過程改進
rel file list href file c 5cdocume 7e1 5ccn1ww2g0 5clocals 7e1 5ctemp 5cmsohtml1 5c01 5cclip filelist.xml 比爾蓋茨在 70年代就意識到了軟體的重要性。相比硬體，軟體是無限制的，軟體提供的服務也是...
軟體工程過程及過程改進
軟體過程主要指的是軟體工程過程，即在軟體開發的過程中組織內發生的各開發階段 各項開發活動的先後順序及其關係。這些活動有機的運轉即可以完成軟體開發過程。有人將軟體生命週期當作軟體工程過程，這個觀點是有偏差的。軟體生命週期指的是軟體從無到有再到消亡的過程，是軟體本身的特性。軟體工程過程是建立軟體或者修改...
軟體小開發團體運用CMM思想進行過程改進
目前很多有一定規模的軟體公司都熱衷於cmm認證，他們不僅想藉此提高公司的聲譽，拉開和競爭對手的距離並且在業務競標中取得有利位置，也更想藉此機會從本質上使本公司的軟體開發實力達到乙個質的飛躍。但是對於小公司或者小的開發團體呢？他們由於資金，資源和規模等方面的原因，不可能花費鉅額的投資去請好的諮詢公司來...