第2章軟件生命周期質(zhì)量度量

第2章軟件生命周期質(zhì)量度量目錄2.1概述2.2需求分析模型的度量2.3設(shè)計(jì)模型的度量2.4源代碼度量2.5對測試的度量2.6對維護(hù)的度量2.7本章小結(jié)重點(diǎn)了解軟件生命周期中各個(gè)階段度量的重要性了解每個(gè)階段度量的原理和主要的度量計(jì)算方法難點(diǎn)了解每個(gè)階段度量的原理和主要的度量計(jì)算方法度量測量在科學(xué)領(lǐng)域有悠久的歷史[116]。相對早在1889年就定義好了度量單位～米的長度測量，溫度的度量復(fù)雜的多Fahrenheit和Celsius分別在1714年和1742年提出了基于某固定點(diǎn)間隔遞增等級的溫度度量方法。Celsius將100度和0度之間分為100個(gè)等份2.1概述軟件的質(zhì)量由一系列質(zhì)量要素組成，每個(gè)質(zhì)量要素又由一些衡量標(biāo)準(zhǔn)組成，每個(gè)衡量標(biāo)準(zhǔn)又由一些度量標(biāo)準(zhǔn)加以定量刻畫質(zhì)量度量（softwaremeasurement）貫穿于軟件工程的全過程以及軟件交付前后，在軟件交付之前的度量主要包括程序復(fù)雜性、模塊的有效性、總的程序規(guī)模，在軟件交付之后的度量則主要包括殘存的缺陷數(shù)和系統(tǒng)的可維護(hù)性方面軟件度量研究主要分為兩個(gè)陣營：一部分認(rèn)為軟件可以度量，一部分認(rèn)為軟件無法通過度量分析。無論如何，研究主流是關(guān)心軟件的品質(zhì)和認(rèn)為軟件需要定量化度量。目前有超過上千種軟件度量方法被軟件研究人員及從業(yè)人員提出，并且到今天有超過5000份論文出版發(fā)表。軟件度量的重要性如果沒有度量，我們很難想象關(guān)于電子、機(jī)械、及普通工程的定律能得到發(fā)展。但事實(shí)上現(xiàn)在在軟件工程的主流里度量卻被忽略了?，F(xiàn)狀當(dāng)我們在設(shè)計(jì)和開發(fā)軟件產(chǎn)品的時(shí)候，我們并未能制定出度量的目標(biāo)。例如：我們保證說我們將使用戶界面友好、可靠、易于維護(hù)；而并未使用度量的術(shù)語來詳細(xì)說明它們的具體含義。Gilb曾經(jīng)說過：所謂模糊目標(biāo)定理，就是沒有明確目標(biāo)的項(xiàng)目將不能明確地達(dá)到它的目標(biāo)。我們未能對構(gòu)成軟件項(xiàng)目實(shí)際費(fèi)用的各個(gè)不同的部分進(jìn)行有效的度量。譬如：通常我們并不知道，和測試階段相比，設(shè)計(jì)階段花費(fèi)時(shí)間多大。我們并未試圖使我們開發(fā)的產(chǎn)品的各種質(zhì)量合格。因此我們未能使用術(shù)語（如：在一段時(shí)間里使用故障的可能性、把產(chǎn)品安裝到新環(huán)境中需花費(fèi)的工作量等）向潛在的用戶說明產(chǎn)品的可靠性很高。我們總是試圖說服自己使用另一種新的革新的開發(fā)技術(shù)和方法進(jìn)行軟件開發(fā)現(xiàn)狀事實(shí)上，我們在軟件度量方面做的工作很少很少，而且所作的度量方面的工作也與一般科學(xué)意義上的度量相分離。我們經(jīng)常會看到諸如此類的話：“軟件的費(fèi)用有80％花費(fèi)在維護(hù)上?！被颉败浖恳磺谐绦蛑衅骄?5個(gè)Bugs?！?。但是這些話并沒有告訴我們這樣的結(jié)果是怎樣產(chǎn)生的、試驗(yàn)是怎樣設(shè)計(jì)、執(zhí)行的、度量的是那個(gè)實(shí)體、及錯(cuò)誤的框架是什么等等。因此，歸因于度量不充分的問題的產(chǎn)生是由于缺乏嚴(yán)格的度量方法造成的軟件質(zhì)量度量目的軟件度量是對軟件開發(fā)項(xiàng)目、過程及其產(chǎn)品進(jìn)行數(shù)據(jù)定義，收集及分析的持續(xù)性定量化過程目的在于對此加以理解、預(yù)測、評估、控制和改善通過軟件度量，可以改進(jìn)軟件開發(fā)過程，促進(jìn)項(xiàng)目成功，開發(fā)高質(zhì)量的軟件產(chǎn)品度量取向是軟件開發(fā)諸多事項(xiàng)的橫斷面，包括顧客滿意度度量、質(zhì)量度量、項(xiàng)目度量、以及品牌資產(chǎn)度量、知識產(chǎn)權(quán)價(jià)值度量度量取向要依靠事實(shí)、數(shù)據(jù)、原理、法則；其方法是測試、審核、調(diào)查；其工具是統(tǒng)計(jì)、圖表、數(shù)字、模型；其標(biāo)準(zhǔn)是量化的指標(biāo)2.1.1度量的原則度量應(yīng)該基于該應(yīng)用領(lǐng)域正確的理論之上，并在度量的定義中確定測量的目標(biāo)每一個(gè)技術(shù)度量的定義應(yīng)該具有一致性、客觀性、無二義性，任何度量的第三方對其度量的理解是相同的。度量在經(jīng)驗(yàn)和直覺上也應(yīng)該有說服力度量應(yīng)該被剪裁使之適應(yīng)特定的產(chǎn)品和過程，而且任何時(shí)候應(yīng)該盡可能的使得收集和分析自動化應(yīng)該使用正確的統(tǒng)計(jì)技術(shù)來建立內(nèi)部產(chǎn)品屬性和外部帶度量特征的關(guān)系度量結(jié)果是可靠的2.1.2軟件開發(fā)生命周期的度量活動一方面要遵守一般度量的標(biāo)準(zhǔn)和原則另一方面軟件度量很少借助意見設(shè)備和儀器測量，更多的借助一些軟件的方法——軟件工具、數(shù)理統(tǒng)計(jì)的方法和自身特定的方法并不是所有的度量都對軟件工程有實(shí)際意義有些度量太復(fù)雜有些太深奧被人們經(jīng)常使用的軟件度量并不是很多，可以分為產(chǎn)品度量、過程度量、項(xiàng)目度量3大類產(chǎn)品度量主要用來描述軟件產(chǎn)品的特征,用于產(chǎn)品評估和決策包括軟件規(guī)模大小產(chǎn)品復(fù)雜度設(shè)計(jì)特征性能質(zhì)量水平項(xiàng)目度量用來描述項(xiàng)目的特性和執(zhí)行狀態(tài)如項(xiàng)目計(jì)劃的有效性、項(xiàng)目資源使用效率、成本效益、項(xiàng)目風(fēng)險(xiǎn)進(jìn)度和生產(chǎn)力評估項(xiàng)目開發(fā)過程的質(zhì)量預(yù)測項(xiàng)目的進(jìn)度、工作量輔助管理者進(jìn)行質(zhì)量控制和項(xiàng)目控制過程度量用于軟件開發(fā)、維護(hù)過程的優(yōu)化和改進(jìn)，如開發(fā)過程中的缺陷移除效率、測試階段中的缺陷到達(dá)模式以及缺陷修復(fù)過程的效率三種度量活動的比較過程度量是戰(zhàn)略性的項(xiàng)目度量是戰(zhàn)術(shù)性的產(chǎn)品度量是對產(chǎn)品質(zhì)量的度量，用于對產(chǎn)品質(zhì)量的評估和預(yù)測軟件度量的實(shí)施過程度量承諾度量計(jì)劃度量實(shí)施度量評估度量改善2.2需求分析的度量軟件工程的技術(shù)性工作開始于需求分析，所以對這個(gè)階段進(jìn)行度量是很重要的2.2.1基于功能的度量功能點(diǎn)度量可以用來作為預(yù)測從分析模型得到系統(tǒng)大小的手段舉例：safahome軟件，該功能管理用戶交互，接收一個(gè)用戶密碼來啟動和關(guān)閉系統(tǒng)，并且允許對安全區(qū)狀態(tài)和不同安全傳感器進(jìn)行查詢SafaHome分析模型的一部分SafeHomeUserInteractionfunctionUserSensorsUserMonitoring&responsesubsystemSystemconfigurationdataPasswordZoneinquirySensorinquiryPanicbuttonActivate/deactivateTestsensorZonesettingMessagesSensorstatusActivate/deactivateAlarmalertPassword，sensors用戶的輸入數(shù)用戶輸出數(shù)用戶查詢數(shù)文件數(shù)外部接口書2.2.2規(guī)約質(zhì)量的度量需求的功能性有下列的特征確定性（無二義性），完全性，正確性，可理解性，可驗(yàn)證性，內(nèi)部和外部一致性，可完成性，簡潔性，可跟蹤性，可修改性，精確性，可復(fù)用性以上的特性看起來都是定性的，無法度量，但是Davis等人建議每一個(gè)質(zhì)量特性用一個(gè)到多個(gè)度量來表示需求的一致性的度量Q1=n(ui)/n(r)n(ui)是無二義性的需求總數(shù)n(r)是需求總數(shù)n(r)=n(f)+n(nf)n(f)表示功能性需求的數(shù)目，n(nf)為非功能性需求的數(shù)目需求穩(wěn)定性的度量軟件的需求，肯定是一次無法確定的，變化是必然的，但是變化又會引起后面的各個(gè)階段的變化，所以需求穩(wěn)定性度量是關(guān)鍵的度量之一RSI=（所有確定的需求數(shù)-累計(jì)的需求變化請求數(shù)）/所有確定的需求數(shù)

N3R=初始需求請求列表數(shù)+接受的需求變化請求數(shù)而接受的需求變化請求數(shù)是累計(jì)的需求變化請求數(shù)與待定的需求變化請求數(shù)之差，是動態(tài)的，越到后面，需求越趨于穩(wěn)定RSI越大，需求越穩(wěn)定，其值越接近于12.4源代碼度量最簡單的度量程序復(fù)雜性的方法就是：統(tǒng)計(jì)源代碼的行數(shù)前提：程序復(fù)雜性隨著程序規(guī)模的增加不均衡地增長； 控制程序規(guī)模的方法最好是采用分而治之的方法，將大程序分解成若干個(gè)簡單的可理解的程序段出錯(cuò)率：每100行源程序中可能有的錯(cuò)誤數(shù)目，如1%Thayer指出，程序出錯(cuò)率的估算范圍是0.04%~7%之間，并且每行代碼的出錯(cuò)率與源代碼行數(shù)之間不是簡單的線性關(guān)系小于100行的程序，出錯(cuò)率為1.3%~1.8%，是線性的大于100行的大程序，出錯(cuò)率增加到2.7%~3.2%，出錯(cuò)率以非線性的方式增長2.4.1Halstead度量法Halstead的軟件科學(xué)理論是“最著名的赫研究最完全的（軟件）復(fù)雜度的復(fù)合度量之一”代碼長度N的公式P43代碼的體積V公式P43McCabe度量法McCabe是一種基于程序控制流的復(fù)雜性度量方法，又稱為環(huán)路復(fù)雜度，是基于程序模塊的程序圖中環(huán)路的個(gè)數(shù)V(G)=m-n+2m是圖G中的有向弧個(gè)數(shù)；n是圖G中的節(jié)點(diǎn)個(gè)數(shù)A開始BC輸入DEFGH輸入JK輸出L結(jié)束當(dāng)分支或循環(huán)的數(shù)目增加時(shí)，程序中的環(huán)路也隨之增加，因此這種度量值為軟件測試的難易程序提供了一個(gè)度量度量的方法，同時(shí)也間接的表示了軟件的可靠性說明環(huán)路復(fù)雜度與程序中覆蓋的路徑條數(shù)有關(guān)環(huán)路復(fù)雜度是可累加的復(fù)雜度超過10的程序，建議分成幾個(gè)小程序2.5對測試的度量測試廣度：是指在某一個(gè)時(shí)刻測量提供的需求有多少已經(jīng)被測試，它用來度量測試計(jì)劃的執(zhí)行、測試進(jìn)度等狀態(tài)測試深度：對被測試覆蓋的獨(dú)立基本路徑占程序中的基本路徑的總數(shù)的百分比的策略，可用McCabe環(huán)形來計(jì)算過程中收集的缺陷數(shù)度量，發(fā)現(xiàn)的、修正的和關(guān)閉的缺陷數(shù)量在過程中的差異、發(fā)展趨勢等測試階段主要過程質(zhì)量度量缺陷度量或缺陷分布度量測試用例的深度、質(zhì)量、覆蓋率和有效性測試執(zhí)行的效率和質(zhì)量缺陷報(bào)告的質(zhì)量測試覆蓋率測試環(huán)境的穩(wěn)定性或有效性測試用例的深度、質(zhì)量和有效性測試用例的度量包含測試用例的深度、質(zhì)量、有效性和自動化程度的度量測試用例的深度（TestCaseDepth)可以表示為每千行代碼（kloc）的測試用例數(shù)或每個(gè)功能點(diǎn)/對象點(diǎn)的測試用例數(shù)測試用例的效率可以用每100或1000個(gè)測試用例所發(fā)現(xiàn)的缺陷數(shù)來衡量不同階段是不一樣的，測試用例的質(zhì)量（TestCaseQuality）TCQ=測試用例發(fā)現(xiàn)的缺陷數(shù)量/總的缺陷數(shù)量問題：為什么測試發(fā)現(xiàn)的缺陷數(shù)量不等于宗的缺陷數(shù)量？因?yàn)橛幸徊糠秩毕菔峭ㄟ^其他手段和階段發(fā)現(xiàn)的，比如壓力測試，還有軟件發(fā)布后還是會發(fā)現(xiàn)缺陷測試執(zhí)行的效率和質(zhì)量測試執(zhí)行的質(zhì)量=軟件發(fā)布后遺留的缺陷/總的缺陷數(shù)一般要求小于0.5%測試執(zhí)行的效率可以用如下的方法來綜合度量

·每個(gè)人日所執(zhí)行的測試用例數(shù)

·每個(gè)人日所發(fā)現(xiàn)的缺陷數(shù)

·每修改KLOC所運(yùn)行的測試用例數(shù)缺陷報(bào)告的質(zhì)量缺陷報(bào)告的有效性：所有修正或關(guān)閉缺陷和測試人員所報(bào)的所有缺陷的比值，越接近1，有效性就越高，正常值在0.92~0.96缺陷報(bào)告的質(zhì)量： 處于中間狀態(tài)的缺陷數(shù)/總的缺陷數(shù) 中間狀態(tài)指的是：需要補(bǔ)充信息 一般占總?cè)毕輸?shù)的3%~5%為正常太高說明缺陷報(bào)告質(zhì)量太低太低說明測試人員缺乏懷疑精神2.6對維護(hù)的度量在完成一個(gè)軟件產(chǎn)品的開發(fā)并將它發(fā)布到市場上，它就進(jìn)入了維護(hù)階段在這個(gè)階段，按時(shí)間區(qū)間的缺陷出現(xiàn)數(shù)和按時(shí)間區(qū)間的顧客問題召回?cái)?shù)都是事實(shí)量缺陷數(shù)或問題的出現(xiàn)數(shù)是由開發(fā)過程決定的在維護(hù)階段對產(chǎn)品質(zhì)量的改變作用不大軟件系統(tǒng)失效嚴(yán)重性度量目的：如何對顧客經(jīng)受的麻煩或損害的嚴(yán)重性使用權(quán)重或維護(hù)人員所需資源的范圍使用權(quán)重軟件系統(tǒng)失效的平均嚴(yán)重性AverageSeverityofSoftwareSystemFailure，ASSSF指一年或半年或一個(gè)季度內(nèi)檢測到的軟件失效數(shù)ASSSF=WYF/NYFWYF指一年內(nèi)的危害服務(wù)期內(nèi)檢測到的軟件失效的加權(quán)數(shù)NYF指一年內(nèi)的維護(hù)服務(wù)期內(nèi)檢測到的軟件失效數(shù)軟件系統(tǒng)失效的密度度量SSFD=NYF/KLMCWSSFD=WYF/KLMCWSSFF=(NYF+WYF)/NMFPKLMC指被維護(hù)軟件的千行代碼數(shù)NMFP是指維護(hù)軟件的功能點(diǎn)數(shù)軟件系統(tǒng)可用性度量完全可用FA=（NYSerH-NYFH）/NYSerH