第2章軟件生命周期質量度量

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

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

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

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

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