過程改進是否一定提高軟件質量

領測軟件測試網 對于實施CMMI，對軟件過程進行改進，我原來一直觀點是CMMI實施不一定能夠提高軟件的質量，因為過程和人始終是兩個重要因素，軟件項目團隊和人往往起到重要作用。
 
當我們持這種觀點的時候往往就表明了我們的成熟度比較低，沒有上升到項目級和組織級，整個項目的成功往往取決于項目中的幾個關鍵人員，這樣對項目和組織的危險性都是很大的。實施CMMI的一個重要目的就是要盡量的減少人對項目的影響，形成組織級的過程和規范。因此我現在觀點是實施CMMI一定可以改進軟件質量，如果你實施了CMMI沒有改進質量，只能夠說明你某些重要的KPA沒有達到CMMI的要求。
 
需求的不穩定或需求范圍的蔓延往往是我們經常都要分析到的軟件項目的關鍵風險，出現頻繁需求變更的一個關鍵其實是需求開發RD這個過程域沒有做好，如果我們前期需求收集，需求開發，與用戶有足夠多的溝通，交互和原型的演示，原則上不應該出現過多的需求變更。
 
GG通用實踐里面有兩個重要的實踐，一個是提供相應的資源，當資源技能不足的時候組織應該保證充足的技能培訓。但我們項目一啟動的時候，一般這兩點都很難滿足要求，及時資源能夠滿足，但人員的知識和技能水平往往也不能馬上得到滿足，而往往這個時候項目根本不可能說等著組織把你的人員培訓來技能滿足要求了，再給你，再開始項目，所以往往你知道人員技能有問題，還是得開始你得項目。所以經常出現這種情況往往是我們得GG根本沒有達到要求，而CMMI很簡單給你一個實踐在需要時候可以得到充足滿足技能得資源，及時不滿足組織級可以通過技能培訓讓資源滿足要求。所以這看似簡單一句話，就包含了諸多需求我們進行過程改進得地方，需要考慮人得因素得地方，你做不到不能說CMMI不好或者沒有要求，只有說你成熟度沒有夠。
 
有些項目往往一開始就注定失敗，一個重要得是技術方案得選擇，對于決定著項目重要成敗得技術方案CMMI推薦要采用DAR過程域進行決策分析和解決方案得選擇，而往往做一個復雜得DAR需要1-2個月甚至更長得時間，一個大中型項目周期一般也就半年，時間決定金錢，市場決定研發項目要第一時間盡快交付，而這個時候不知道有多少人會等待這漫長時間去做一個DAR，而理直氣壯得說這是按照CMMI得要求在做。 CMMI針對很多過程和問題都給出得實踐得方案和標準，而由于資源限制，項目時間進度限制，往往我們很難達到這些目標和標準，這時候你可以說CMMI沒有考慮這些，也可以說我們得過程確實還需要進一步改進。
 
CMMI一個重要假設就是人員技能能夠達到項目要求。同時CMMI也通過組織級技能評估，培訓效果評估等多個子實踐來驗證這點，但往往我們是很難達到這個目標。項目往往考慮得是有人總比沒人強。CMMI另外一個重要假設是假設制度和規范可以規范所有人員得活動，而這點往往又是很難做到得，CMMI強調你這些你過程沒有做到，只能說明你能力成熟度不夠。
 
CMM的VER和VAL兩個過程域是保障軟件質量的重要KPA,評審一直是我們提前發現缺陷和防止缺陷泄漏的重要手段，而評審一般要提前熟悉相關內容，提前預審，評審會議召開后還需要對評審文檔進行修改，修改完成后還要相關人員逐一驗證，基線后才能夠開始后續的相關活動，而這個過程耗時至少一周以上，對于項目周期短的軟件項目來說，這個時間對進度的影響是致命的。還有CMMI假設評審成員都會認真評審和發現問題，但往往這點要做到又很難，問題出在我們預審時間留的不夠，或者規范根本很難去控制個人的預審過程。及時我們修改規范和標準，做到能夠根據規范去檢查也不一定最優，反而是適得其反。
 
RSKM風險管理也是CMMI三級的一個重要過程域，這個過程域對軟件項目成功至關重要，很多項目最好導致延期或失敗，關鍵還是我們沒有提前發現不確定性和風險，而采取相關的緩解和應對措施。
 
軟件能力成熟度也高一個直接的體現就是組織過程，個人對整個軟件項目的影響降到最低。整個軟件項目成功不依賴于項目幾個人單打獨斗。而是整個項目共同分工協助來完成。
 
CMMI一定可以改進軟件質量，如果沒有改進應該首先檢查自己的各個KPA是否都達到要求了，而且現在CMMI過級本來就存在較大水平，只有我們真正按著以改進我們的軟件過程目標為導向來過級的時候，才能夠體會到CMMI對軟件質量改進的好處。

文章來源于領測軟件測試網 http://www.kjueaiud.com/