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