質(zhì)量管理：軟件開發(fā)各階段的質(zhì)量管理

申請免費(fèi)試用、咨詢電話：400-8352-114

提到軟件開發(fā)，我們的腦海里總是浮現(xiàn)出這樣的情景：開發(fā)組的每一位成員都在辛苦的工作，有的加班加點，甚至通宵達(dá)旦是常有的事，雖然項目經(jīng)理修改了一次又一次的進(jìn)度計劃，而實際的開發(fā)情況卻總是很令人擔(dān)憂，以至于每次向領(lǐng)導(dǎo)匯報工作的時候總是覺得以前制定的計劃沒有很好的完成，總是覺得人力資源不夠，總是覺得我們沒有太多的時間。等到代碼終于開發(fā)完成了，測試進(jìn)度卻又非常令人擔(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)之外就沒有其他用途了，要知道寫這些文檔是需要消耗項目組資源的（進(jì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工具進(jìn)行，這樣可以減少一些自然語言引起的歧義，但是UML可能與用戶溝通起來有一些障礙，因為并不是所有的用戶都了解 UML各種圖形的意思。除了工具之外，我們可以從以下幾個方面來保證需求描述的質(zhì)量。
　　1、看句子和段落是否簡短，一個很長的句子，看起來會非常困難，因此無法弄懂真正的需求，另外過長的句子和段落容易讓人忽視一些需求，所以如果一個句子不能完全描述清楚需求，應(yīng)該將其拆分成多個小句子。2、句子是否有語法錯誤，還要注意標(biāo)點符號，有時，標(biāo)點符號點錯了，就完全成了另外一個意思了。 3、是否存在模糊不清的需求，出現(xiàn)類似于可能，大概，或者等詞匯表述的需求。4、另外注意引用的術(shù)語和詞匯是否前后一致。5、是否存在一些形容詞、比較性詞語，比如：容易的、快速的、方便的、有效的、許多、很少、簡單、復(fù)雜、最新的，界面友好的，減少、擴(kuò)大，不小于等等，需要將描述性詞語進(jìn)行量化，并且給出具體值或者范圍，要不然不同的人根據(jù)不同的理解就會得出不同的結(jié)果，最終可能跟用戶最初的要求有偏差，那“炒回鍋肉”的事情就不可避免地會發(fā)生。
　　另外保證需求質(zhì)量的一個很重要的因素就是需求是否細(xì)化，如果需求不細(xì)化也會很容易造成代碼的返工，于是就出現(xiàn)了我們的程序員盡管總是加班加點卻總是不能如期的完成任務(wù)的情景。那么我們怎樣才能判斷需求細(xì)化的程度呢？需求細(xì)化程度確實很難把握，什么樣的需求可以算是比較細(xì)了，不用再進(jìn)行細(xì)化了呢？哪些需求又太粗了呢？答案是需求是否可以寫出相應(yīng)的測試用例，如果寫不出來，就說明需求還不是很細(xì)，還需要再進(jìn)行細(xì)化。
　　2、設(shè)計
　　軟件架構(gòu)設(shè)計在軟件產(chǎn)品開發(fā)周期中占有很重要的位置，我們開發(fā)出來的軟件產(chǎn)品在開發(fā)伊始到產(chǎn)品發(fā)布會涉及到方方面面的角色，例如：用戶、項目管理人員、程序員、測試員、維護(hù)人員等等。不同的角色對架構(gòu)設(shè)計的要求也不相同。例如用戶關(guān)心的是需求，因此我們的設(shè)計對需求的覆蓋率是多少？對于程序員來說模塊是否清晰，類的功能是否單一等等，對于測試人員來說系統(tǒng)的是系統(tǒng)的可測試性。對于維護(hù)人員來講系統(tǒng)的擴(kuò)展性、可維護(hù)性如何？一個高質(zhì)量的軟件架構(gòu)，應(yīng)該最大限度的考慮并滿足不同角色的不同要求。正是因為有這些要求，我們在進(jìn)行軟件設(shè)計的時候，應(yīng)該進(jìn)行全面的考慮。一般用來衡量軟件設(shè)計質(zhì)量的標(biāo)準(zhǔn)可以從以下幾個方面來考慮：
　　1)、功能性：包括完全性、正確性、安全性、兼容性、互用性。完全性包括功能點覆蓋率，重點功能點覆蓋率，優(yōu)先功能覆蓋率。正確性包括需求一致度。安全性根據(jù)軟件需求的不同有不同的安全性要求。來源于考試大
　　2)、效率：包括產(chǎn)品運(yùn)行的時間效率和利用的硬件資源兩方面來考慮。
　　3)、維護(hù)性：包括架構(gòu)的可改正性，可擴(kuò)充性以及可測試性。如果用戶的一個很小的需求變更會引起架構(gòu)設(shè)計很大的變化，那么這樣的架構(gòu)設(shè)計的可改正性和可擴(kuò)充性就比較差。
　　4)、可移植性：包括硬件的獨(dú)立性、軟件獨(dú)立性、可安裝性、可重用性。軟件設(shè)計是否模塊化、每個模塊的可復(fù)用性如何都是應(yīng)該考慮的因素。
　　5)、可靠性：包括缺陷數(shù)量、容錯性、可用性。
　　6)、使用性：包括可理解性、易學(xué)習(xí)性、可操作性、易溝通性。我們軟件的最終目的是讓用戶來使用的，如果易用性不好，可操作性不好都會影響用戶對軟件的接納程度。因此在軟件的可使用性也是非常重要的。
　　3、編碼
　　代碼質(zhì)量的一個很重要的標(biāo)準(zhǔn)就是代碼的可讀性及規(guī)范性，可讀性不一定是簡單的代碼，而是容易理解的代碼，因為過于復(fù)雜的代碼難以測試和維護(hù)，同時出錯的幾率也會更高。如果一個方法內(nèi)部的代碼很長，而且使用了很多令人難以理解的數(shù)據(jù)集，這樣就會帶來代碼維護(hù)的困難，因為很少有人能夠有效地分析它們，因此也就是最容易出現(xiàn)缺陷和錯誤的地方。類之間的耦合度會造成類與類之間的相互關(guān)聯(lián)，當(dāng)一個類發(fā)生改變時會使其他的類發(fā)生意想不到的變化，一般從導(dǎo)入類的個數(shù)判斷類之間的耦合度，如果導(dǎo)入類的個數(shù)很多，每一個導(dǎo)入類發(fā)生變化都會影響到該類本身，另外如果該類的public方法太多也會導(dǎo)致類之間的高耦合性增加。
　　也許有的程序員會認(rèn)為寫出可讀、規(guī)范的代碼會影響工作進(jìn)度。的確，對于程序員個體短時間來說為代碼寫上注釋是要花費(fèi)些時間，但如今軟件開發(fā)是多人協(xié)作
　　周期很長的過程，寫過程序的人都知道，如果自己寫了不規(guī)范的代碼，隨著自己所寫的代碼越來越多，到后來需要修改某個前期寫的模塊時都不知道自己當(dāng)初是怎么想的了，讀自己的代碼也需要花很長時間才讀懂。況且如果隨著人員的調(diào)動等其他原因，往往維護(hù)代碼的程序員已不是當(dāng)初寫代碼的人，很多情況就是讀懂了一段糟糕的代碼還比重新寫出一段代碼花費(fèi)的時間還長，嚴(yán)重影響工作效率(有些時候還影響維護(hù)人員的心情)，反過來，如果大家都講究把代碼寫成規(guī)范可讀的，無疑對于整個組織來說提高總體工作效率是非常有用的。
　　代碼質(zhì)量另一個非常重要的衡量手段就是測試，通過統(tǒng)計測試代碼所產(chǎn)生的缺陷情況，如嚴(yán)重等級分布、缺陷曲線的變化等可以從一個方面來簡單地評估代碼質(zhì)量。