筆者在“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. 必須要有高層領導、管理人員作為推動整個行動計劃的動力。
“在執行過程中對行動計劃按情況進行調整”：一旦發現需要對行動計劃進行調整，以期達到最佳的效果，而實際情況也允許在中途進行調整的話，可以進行經過計劃的、嚴加控制的調整。所有的改變必須預先取得所有有關人員的同意。
“總結這一輪改進的經驗”：過程改進是一個永不停止的工作�？偨Y經驗使我們能越做越好，越做越有信心。光有未經實踐的知識，還不能有信心。信心是經過運用知識解決了問題之后建立起來的。
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第二級的所有關鍵過程域呢?
筆者認為不必。任何方面，任何程度的改進都是有益的。要按照你機構的擔負能力及要求來決定進行軟件過程改進的廣度與深度。
軟件過程改進中，應注意些什么呢?
應該注意的事情很多，但筆者認為最重要的一點是要注重執行、做實事，千萬不要定出了行動計劃之后就丟進抽屜中，束之高閣。另外一個要注意的問題是，要有對行動計劃執行中可能出現的意外情況有所準備，保證項目仍然能夠順利進行。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
