軟件開發各階段的質量控制[1] 軟件質量保證
關鍵字：軟件開發 質量控制
提到軟件開發，我們的腦海里總是浮現出這樣的情景：開發組的每一位成員都在辛苦的工作，有的加班加點，甚至通宵達旦是常有的事，雖然項目經理修改了一次又一次的進度計劃，而實際的開發情況卻總是很令人擔憂，以至于每次向領導匯報工作的時候總是覺得以前制定的計劃沒有很好的完成，總是覺得人力資源不夠，總是覺得我們沒有太多的時間。等到代碼終于開發完成了，測試進度卻又非常令人擔憂，每一個小BUG都要花很長的時間去查找，改了某一個小錯誤卻又引起了很多錯誤，結果產品發布遙遙無期，而項目組里的每一位成員已經筋疲力盡。
怎樣擺脫這樣的困境呢?為何軟件開發項目管理這么困難呢?為何我們做的計劃總是不能按時完成呢?為何軟件開發不能像硬件開發那樣可以控制呢?原因在于軟件開發完全靠人的大腦思維產生出產品，而每個人的大腦思維是不一樣的，因此在軟件開發過程中有太多不確定的、可以變化的因素，我們怎樣把握住這些變化因素呢?就像我們題目所說的一樣，軟件開各階段的成果質量管理，如果我們能夠很好的控制軟件生命周期每一個階段的質量，也就很好的控制了整個軟件開發的整個過程。
軟件產品的質量是個很大的概念，因為軟件產品完全是人們大腦思維的產物，就是將大腦里無形的看不見摸不著的思維變成一個可以看到的，可以解決實際問題的一組界面或者組件。這樣的一個復雜的過程，質量應該如何保證呢?有人想到了ISO9000、CMM，也有人很反對，說應該用敏捷開發。其實，不管用什么樣的開發過程，關鍵是找到這些過程的真諦，有些人說，ISO和CMM到中國來就變了味了，為什么變味兒了呢?其實我們只學到了該做什么，卻不知道怎樣去做，為什么要這樣做?大家都知道做軟件開發需要寫需求規格說明書和設計文檔，為什么要寫，文檔的重要性有多高?沒有資深開發和管理經驗的人員可能很難理解其重要性，如果只是簡單的形式上去寫一篇這樣的文檔，對后面的編碼和測試沒有實際的指導作用，甚至起了“ 誤導”作用，同樣會引起大量返工，那么這些文檔除了負擔之外就沒有其他用途了，要知道寫這些文檔是需要消耗項目組資源的(進度、成本……)。
很多人又想到了測試，覺得是我們測試的力度不夠，所以我們產品質量不過關，其實，軟件開發的質量保證從開發最初就應該開始了，如果到了測試階段才重視就已經晚了。軟件產品開發過程，不管采用瀑布式還是迭代式，都離不開需求、設計、編碼、測試這幾個階段，在迭代式開發中，這幾個階段也是周期性出現的。怎樣把握好每個階段的質量，確實不是一件容易的事，本期重點介紹一下需求、設計和編碼階段的成果質量，當然以后會共享一些過程質量方面的知識。
1、需求
我們知道人與人的交流總是會存在一些誤會，同樣一句話，心情不好與心情好的時候聽起來的感覺可能會截然相反，正是因為人們之間存在著理解上的偏差，在描述需求的語言上就應該注意盡量避免歧義的產生。如果對UML比較熟悉的話，需求分析可以利用UML工具進行，這樣可以減少一些自然語言引起的歧義，但是UML可能與用戶溝通起來有一些障礙，因為并不是所有的用戶都了解 UML各種圖形的意思。除了工具之外，我們可以從以下幾個方面來保證需求描述的質量。
文章來源于領測軟件測試網 http://www.kjueaiud.com/