軟件開發(fā)為何不能像硬件開發(fā)那樣可控？軟件質(zhì)量之旅將帶給我們一些啟示。

　　提到軟件產(chǎn)品開發(fā)，我們的腦海里總是浮現(xiàn)出這樣的情景：開發(fā)組的每一位成員都在辛苦地工作，加班加點(diǎn)，甚至通宵達(dá)旦。雖然項(xiàng)目經(jīng)理一次又一次地修改了進(jìn)度計(jì)劃，而實(shí)際的開發(fā)情況卻總是令人擔(dān)憂，以至于每次向領(lǐng)導(dǎo)匯報(bào)工作的時(shí)候，總是覺得以前制定的計(jì)劃沒有很好完成，總是覺得人力資源不夠，總是覺得沒有太多的時(shí)間。等到代碼終于開發(fā)完成了，測(cè)試進(jìn)度同樣非常令人擔(dān)憂，每一個(gè)小BUG都要花很長(zhǎng)的時(shí)間去查找，改了某一個(gè)小錯(cuò)誤卻又引起了很多新的錯(cuò)誤，結(jié)果產(chǎn)品發(fā)布無(wú)期，而項(xiàng)目組里的每一位成員已經(jīng)筋疲力盡。

　　怎樣擺脫這樣的困境？為何軟件開發(fā)項(xiàng)目管理這么困難？為何我們做的計(jì)劃總是不能按時(shí)完成？為何軟件開發(fā)不能像硬件開發(fā)那樣可以控制？

　　軟件開發(fā)是完全依靠人的大腦思維產(chǎn)生出產(chǎn)品，而每個(gè)人的大腦思維是不一樣的，因此在軟件開發(fā)過程中有太多不確定、可變化的因素。那么我們?cè)鯓影盐兆∵@些變化因素呢？

　　軟件項(xiàng)目管理——質(zhì)量先行，如果我們能夠控制軟件生命周期每一個(gè)階段的質(zhì)量，能很好地控制了軟件開發(fā)的整個(gè)過程。

　　軟件產(chǎn)品的質(zhì)量是個(gè)很大的概念，因?yàn)檐浖�產(chǎn)品完全是人們大腦思維的產(chǎn)物，是將大腦里無(wú)形的思維變成可以解決實(shí)際問題的一組界面或者組件。在這樣一個(gè)復(fù)雜的過程中，應(yīng)該如何保證質(zhì)量呢？有人想到了ISO9000、CMM，也有人提出反對(duì)意見，認(rèn)為應(yīng)該用敏捷開發(fā)。其實(shí)，不管用什么樣的開發(fā)過程，關(guān)鍵是找到這些過程的本質(zhì)。

　　有人說，ISO和CMM到中國(guó)來(lái)怎么變了味了？其實(shí)，我們只學(xué)到了怎樣去做，但是不知道為什么要這樣做。大家都知道在產(chǎn)品立項(xiàng)之前要寫市場(chǎng)分析報(bào)告，但不了解為什么要寫，市場(chǎng)分析報(bào)告的重要性有多高？不是開發(fā)人員很難理解其重要性，如果是簡(jiǎn)單地去寫一篇形式上的文檔，那么，除了負(fù)擔(dān)之外沒有其它用途了。

　　有些人又想到了測(cè)試，覺得是我們測(cè)試的力度不夠，所以產(chǎn)品質(zhì)量不過關(guān)。

　　其實(shí)，軟件開發(fā)的質(zhì)量保證從初應(yīng)該開始了，如果到了測(cè)試階段才重視已經(jīng)晚了。軟件產(chǎn)品開發(fā)過程，不管采用瀑布式模型還是迭代式模型，都離不開需求、設(shè)計(jì)、編碼、測(cè)試這幾個(gè)階段。在迭代式開發(fā)中，這幾個(gè)階段也是周期性出現(xiàn)的。

　　怎樣把握好每個(gè)階段的質(zhì)量，確實(shí)不是一件容易的事。對(duì)于軟件產(chǎn)品的測(cè)試，不管是單元測(cè)試還是集成、系統(tǒng)測(cè)試，這方面的介紹已經(jīng)很多了，因此筆者重點(diǎn)介紹一下需求、設(shè)計(jì)和編碼階段的質(zhì)量保證。

　　讓我們開始一次質(zhì)量之旅吧，第一站是需求分析。

　　在需求分析過程中，如何進(jìn)行質(zhì)量保證呢？我們平時(shí)可能更多地關(guān)注需求本身，卻忽視了一個(gè)很重要的因素，那是市場(chǎng)。因?yàn)槲覀冮_發(fā)出來(lái)的產(chǎn)品是直接面向市場(chǎng)的，如果費(fèi)了很多的人力物力開發(fā)出來(lái)一個(gè)沒有市場(chǎng)前景，缺乏競(jìng)爭(zhēng)力的產(chǎn)品，那么所有的努力都是白費(fèi)。如何充分考慮市場(chǎng)因素，具體可以從以下幾個(gè)方面進(jìn)行。

　　首先，判斷需求是否符合愿景目標(biāo)，所謂愿景目標(biāo)是我們開發(fā)出來(lái)的產(chǎn)品能夠給我們的用戶帶來(lái)什么樣的好處？如果有些需求沒有被包含在愿景目標(biāo)里，那么這樣的需求其實(shí)背離了我們開發(fā)產(chǎn)品的初衷。其次，判斷產(chǎn)品需求能夠給企業(yè)帶來(lái)多大的利潤(rùn)，如果某個(gè)需求只是代表個(gè)別用戶的需求，并不能給企業(yè)帶來(lái)較大的利潤(rùn)，但又花費(fèi)甚高，可以考慮刪除。后，與競(jìng)爭(zhēng)對(duì)手相比核心競(jìng)爭(zhēng)力有哪些？如果核心競(jìng)爭(zhēng)力不夠，應(yīng)該考慮重新進(jìn)行需求分析，因?yàn)槿绻麤]有核心競(jìng)爭(zhēng)力，開發(fā)出來(lái)的產(chǎn)品沒有市場(chǎng)。

　　在排除了市場(chǎng)因素產(chǎn)生的風(fēng)險(xiǎn)之后，我們應(yīng)該保證需求描述的質(zhì)量。人與人的交流總會(huì)存在一些誤會(huì)，同樣一句話，心情不好與心情好的時(shí)候聽起來(lái)可能會(huì)截然相反，正是因?yàn)槿藗冎�間存在著理解上的偏差，在描述需求的語(yǔ)言上應(yīng)該注意盡量避免歧義的產(chǎn)生。如果對(duì)UML比較熟悉的話，需求分析可以利用UML工具進(jìn)行，這樣可以減少一些自然語(yǔ)言引起的歧義，但是并不是所有的用戶都了解UML各種圖形的意思，與用戶溝通起來(lái)存在障礙，除了工具之外，我們可以從以下幾個(gè)方面來(lái)保證需求描述的質(zhì)量。

　　首先，看句子和段落是否簡(jiǎn)短。長(zhǎng)句子看起來(lái)會(huì)非常困難，很難弄懂真正的需求：另外，過長(zhǎng)的句子和段落容易讓人忽視一些需求。所以，如果一個(gè)句子不能完全描述清楚需求，應(yīng)該將其拆分成多個(gè)小句子。

　　其次，句子是否有語(yǔ)法錯(cuò)誤，還要注意標(biāo)點(diǎn)符號(hào)，有時(shí)，標(biāo)點(diǎn)符號(hào)點(diǎn)錯(cuò)了完全成了另外一個(gè)意思。再次，是否存在模糊不清的需求，出現(xiàn)“可能，大概，或者”等詞匯表述。

　　后，注意是否存在形容詞及比較性詞語(yǔ)，比如：容易的、快速的、方便的、有效的、許多、很少、簡(jiǎn)單、復(fù)雜、新的、界面友好的、減少、擴(kuò)大，不小于等等，需要將描述性詞語(yǔ)進(jìn)行量化，并且給出具體值或者范圍。

　　另外，保證需求質(zhì)量的一個(gè)很重要的因素是需求是否細(xì)化，如果需求不細(xì)化很容易造成代碼的返工，出現(xiàn)程序員盡管加班加點(diǎn)卻總是不能如期完成任務(wù)的情景。怎樣才能判斷需求細(xì)化的程度呢？需求細(xì)化程度確實(shí)很難把握，什么樣的需求可以算是比較細(xì)了，不用再進(jìn)行細(xì)化了呢？

　　答案是：是否可以將需求寫出相應(yīng)的測(cè)試用例，如果寫不出來(lái)，說明需求還不是很細(xì)，還需要進(jìn)一步進(jìn)行細(xì)化。

　　把握住了需求分析這一關(guān)，下一站我們可以進(jìn)行設(shè)計(jì)了。

　　軟件架構(gòu)設(shè)計(jì)在軟件產(chǎn)品開發(fā)周期中占有很重要的位置，我們開發(fā)出來(lái)的軟件產(chǎn)品在開發(fā)伊始到產(chǎn)品發(fā)布會(huì)涉及到方方面面的角色。

　　例如：用戶、項(xiàng)目管理人員、程序員、測(cè)試員、維護(hù)人員等等。不同的角色對(duì)架構(gòu)設(shè)計(jì)的要求也不相同。對(duì)于程序員來(lái)說更關(guān)注模塊是否清晰，類的功能是否單一等等，對(duì)于測(cè)試人員來(lái)說，關(guān)注的是系統(tǒng)的可測(cè)試性。對(duì)于維護(hù)人員來(lái)講，系統(tǒng)的擴(kuò)展性、可維護(hù)性如何？

　　一個(gè)高質(zhì)量的軟件架構(gòu)，應(yīng)該大限度的考慮并滿足不同角色的不同要求。因此我們?cè)谶M(jìn)行軟件設(shè)計(jì)的時(shí)候，應(yīng)該進(jìn)行全面的考慮。一般用來(lái)衡量軟件設(shè)計(jì)質(zhì)量的標(biāo)準(zhǔn)可以從以下幾個(gè)方面來(lái)考慮：

◆功能性

　　包括完全性、正確性、安全性、兼容性、互用性。

◆效率

　　產(chǎn)品運(yùn)行的時(shí)間效率和利用的硬件資源兩方面。

◆維護(hù)性

　　包括架構(gòu)的可改正性，可擴(kuò)充性以及可測(cè)試性。如果用戶的一個(gè)很小的需求變更會(huì)引起架構(gòu)設(shè)計(jì)很大的變化，那么這樣的架構(gòu)設(shè)計(jì)的可改正性和可擴(kuò)充性比較差。

◆可移植性

　　包括硬件的獨(dú)立性、軟件獨(dú)立性、可安裝性、可重用性。軟件設(shè)計(jì)是否模塊化、可復(fù)用性都是應(yīng)該考慮的因素。

◆可靠性

　　包括無(wú)缺陷性、容錯(cuò)性、可用性。

◆使用性

　　包括可理解性、易學(xué)習(xí)性、可操作性、易溝通性。我們軟件的終目的是讓用戶來(lái)使用的，如果易用性不好，可操作性不好都會(huì)影響用戶對(duì)軟件的接納程度。因此軟件的可用性也是非常重要的。

　　完成了設(shè)計(jì)之后，接下來(lái)要進(jìn)行編碼了。在編碼階段，應(yīng)該怎樣保證我們的編碼質(zhì)量呢？?jī)蓚�(gè)比較有效的方法是代碼走查和單元測(cè)試。

　　代碼走查可以以組為單位進(jìn)行，代碼走查可以發(fā)現(xiàn)代碼是否符合代碼規(guī)范，是否存在拼寫錯(cuò)誤，是否具有可讀性，類和方法是否過于冗長(zhǎng)，類之間是否存在高耦合性。

　　代碼質(zhì)量的一個(gè)很重要的標(biāo)準(zhǔn)是代碼的可讀性，可讀性不一定是簡(jiǎn)單的代碼，而是容易理解的代碼，因?yàn)檫^于復(fù)雜的代碼難以測(cè)試和維護(hù)，同時(shí)出錯(cuò)的幾率也會(huì)更高。

　　如果一個(gè)方法內(nèi)部的代碼很長(zhǎng)，而且使用了很多令人難以理解的數(shù)據(jù)集，會(huì)帶來(lái)代碼維護(hù)的困難，因?yàn)楹苌儆腥四軌蛴行У胤治鏊鼈�，因此也容易出現(xiàn)缺陷和錯(cuò)誤。類之間的耦合度會(huì)造成類與類之間的相互關(guān)聯(lián)，當(dāng)一個(gè)類發(fā)生改變時(shí)會(huì)使其他的類發(fā)生意想不到的變化，一般從導(dǎo)入類的個(gè)數(shù)判斷類之間的耦合度，如果導(dǎo)入類的個(gè)數(shù)很多，或者該類的public方法太多都會(huì)導(dǎo)致類之間的高耦合性增加。

　　編碼階段另一個(gè)非常重要的手段是單元測(cè)試。單元測(cè)試是一個(gè)模塊的功能及常規(guī)錯(cuò)誤測(cè)試，單元測(cè)試是由程序員進(jìn)行的，一般單元測(cè)試能夠捕獲80%的bug。因此單元測(cè)試對(duì)保證代碼質(zhì)量方面占有很重要的地位，由于這方面內(nèi)容比較多，我們這里不做具體闡述了。

　　好了，經(jīng)過了這樣一次質(zhì)量旅行，我們對(duì)軟件開發(fā)是否增加了很多信心呢？當(dāng)然軟件項(xiàng)目管理還有很多其他的因素，但是如果每個(gè)階段都能夠很好的控制質(zhì)量，會(huì)在產(chǎn)品開發(fā)初期減少很多風(fēng)險(xiǎn)，從而使我們的軟件開發(fā)在一個(gè)可以控制的范圍內(nèi)進(jìn)行，這樣我們才能夠避免過多的沒有必要的人力物力的浪費(fèi)，從而使我們的產(chǎn)品更快更好的投入市場(chǎng)。