軟體品質的度量
摘要:隨著軟體的複雜性日益增長, 軟體開發的周期以及費用也日益增長,軟體品質的保證與提高越來越成為了人們高度重視的問題。軟體品質的度量的理論和研究也隨之發展起來,好的度量模型和標準能夠有效地提高軟體開發效率和軟體品質。本文主要介紹軟體品質的概念和度量模型以及軟體品質度量的方法,並對未來的發展趨勢做一些展望。
關鍵詞:軟體品質、度量模型、發展趨勢、軟體品質度量 0. 引言
在過去幾十年裡,因為軟體的品質問題而導致整個系統發生失效的案例屢見不鮮,進而給人類生命安全和環境造成了巨大的損失。美國IBM公司於1963年~1966年開發的IBM360系列機的作業系統。該軟體系統花了大約5 000人一年的工作量,最多時,有 1000人投入開發工作,寫出近100萬行的來源程式。儘管投入了這麼多的人力和物力,得到的結果卻極其糟糕。而在1996年6月,在阿麗亞娜5號火箭首次發射後不到一分鐘的時間內,就因為軟體故障問題致使火箭發生了爆炸,導致了巨大的經濟損失和相應計劃的延遲。因此軟體的品質問題已引起了人們的極度重視,軟體品質的度量問題自然也得到重視。
由於電腦技術、資料融合技術、網路技術和通訊技術的飛速發展,人們對軟體效能及功能提出的要求也越來越高,度量軟體品質已成為一個迫切需要解決的問題。如何通過選擇合適的軟體品質指標體系、確定軟體品質的量化過程和方法來進行客觀性地度量,對於評價軟體的品質是關鍵的一步,進而對於減少軟體失效的發生和提升軟體的總體品質也是具有極其重要的意義。 1. 軟體品質的理論基礎 1. 1 軟體品質的定義
至今為止,軟體品質還沒有一個統一的、惟一的定義,不同的組織或應用可能會有不同的定義。ANSI/IEEE Std 729—1983定義軟體品質為:與軟體產品滿足規定的和隱含的需求的能力有關的特徵或特性的全體;M.J.Fisher給出的定義為:表徵電腦軟體卓越程度的所有屬性的集合。不同的人從不同的角度來看軟體品質問題,會有不同的理解。從使用者的角度看,品質就是滿足客戶的需求;從開發人員的角度看,品質 就是與需求說明保持一致;從產品的角度看,品質就是產品的內在特點;從價值的角度看,品質就是客戶是否願意購買。概括地說,軟體品質就是“軟體與明確的和隱含的定義的需求相一致的程度”。具體地說,軟體品質是軟體符合明確敘述的功能和效能需求、文檔中明確描述的開發標準、以及所有專業開發的軟體都應具有的隱含特徵的程度。 1. 2 軟體品質引出的問題
M.J.Fisher定義軟體品質為“所有描述電腦軟體優秀程度的特性的組合”。也就是說,為滿足軟體的各項精確定義的功能、效能需求,符合文檔化的開發標準,需要相應地給出或設計一些品質特性及其組合,作為在軟體開發與維護中的重要考慮因素。如果這些品質特性及其組合都能在產品中得到滿足,則這個軟體產品品質就是高的。
軟體品質反映了以下三方面的問題:
(1)軟體需求是度量軟體品質的基礎 ,不符合需求的軟體就不具備品質。
(2)正常化的標準定義了一組開發準則,用來指導軟體人員用工程化的方法來開發軟體。如果不遵守這些開發準則,軟體品質就得不到保證。
(3)往往會有一些隱含的需求沒有顯式地提出來。如軟體應具備良好的可維護性。如果軟體只滿足那些精確定義了的需求而沒有滿足這些隱含的需求,軟體品質也不能保證。
軟體品質是各種特性的複雜組合。它隨著應用的不同而不同,隨著使用者提出的品質要求不同而不同。因此,有必要討論各種品質特性,以及評價品質的準則,還要介紹為保證品質所進行的各種活動。 1. 3 軟體品質度量模型
軟體的品質由一系列品質要素組成,每一個品質要素又由一些衡量標準組成,每個衡量標準又由一些量度標準加以定量刻劃。品質度量貫穿於軟體工程的全過程以及軟體交付之後,在軟體交付之前的度量主要包括程式複雜性、模組的有效性和總的程式規模,在軟體交付之後的度量則主要包括殘存的缺陷數和系統的可維護性方面。
勃姆 (Barry W. Boehm) 在《軟體風險管理》 (Software Risk Management) 中第一次提出了軟體品質度量的層次模型。而麥考爾 (McCall) 等人將軟體品質分解至能夠度量的層次,提出 FCM 3 層模型 ( 參見下表 ) :軟體品質要素 (factor) 、衡量標準 (criteria) 和量度標準 (metrics) ,包括 11 個標準,分為產品操作 (product operation) 、產品修正 (product revision) 和產品轉移 (product transition) 。
| 層級 |
名稱 |
內容 |
| 第一層 |
品質要素:描述性和評價軟體品質的一組屬性。 |
功能性、易用性、可靠性、可維護性、可移植性等品質特性以及將品質特性細化產生的副特性 |
| 第二層 |
衡量標準:衡量標準的組合,反應某一軟體品質要素。 |
精確性、穩健性、安全性、通訊有效性、處理有效性、裝置有效性、可操作性、培訓性、完備性、一致性、可追蹤性、可見度、硬體系統無關性、軟體系統無關性、可擴充性、公用性、模組性、清晰性、自描述性、簡單性、結構性、檔案完備性等 |
| 第三層 |
量度標準:可由各使用單位自訂 |
根據軟體的需求分析、概要設計、詳細設計、編碼、測試、確認、維護與使用等階段,針對每一個階段制定問卷表,以此實現軟體開發過程的品質度量。 |
表1 軟體品質度量FCM模型
其中,可以簡單地描述使用缺陷密度(缺陷數量/軟體規模)、缺陷檢出率(某階段當時發現的缺陷/該階段的全部缺陷 100%)、發布前缺陷去除率(發布前發現的缺陷/(發布前發現的缺陷 軟體啟動並執行前3個月發現的缺陷) 100%)、潛在缺陷數((100% 發布前缺陷去除率) 缺陷密度)、平均失效時間(軟體持續已耗用時間/缺陷數量)、平均修複時間(∑缺陷修複時間/缺陷數量)等作為產品品質的指標。
在軟體品質度量活動中,同樣需要建立一條效能基準,作為軟體產品的品質、軟體測試效能評估的起點,並作為對系統評估是否通過的標準。缺陷評測的基準是對某一類或某一組織的結果的一種度量,這種結果可能是常見的或典型的,如10 000行來源程式(LOC)是程式規模的一個基準,每一千行代碼有3個錯誤是測試中錯誤發現率的基準。基準對期望值的管理有很大協助,目標就是相對基準而存在,也就是定義可接受行為的基準,如表3所示。
| 條目 |
目標 |
低水平 |
| 缺陷清除率 |
>95% |
<70% |
| 缺陷密度 |
每個功能點<4 |
每個功能點>7 |
| 超出風險之外的成本 |
0% |
>=70% |
| 全部需求功能點 |
<1% 每月平均值 |
>=50% |
| 全部程式文檔 |
每個功能點頁數<3 |
每個功能點頁數>6 |
表3 某個軟體項目品質的基準和目標
ISO 9126將軟體品質總結為6大特性每個特性包括一系列副特性其軟體品質模型包括3層,即高層:軟體品質需求評價準則(QSRC);中層:軟體品質設計評價準則(SQDC);低層:軟體品質度量評價準則(SMQC)。
凱悅(Lawrence E.Hyatt)和羅森貝克(Linda H. Rosenberg)在《識別項目風險以及評價軟體品質的軟體品質模型與度量》(A Software Quality Model and Metrics for Identifying Project Risks and Assessing Software Quality)中比較了這3種最常用的軟體品質模型,其基本情況如下表所示。
| 度量標準/目標 |
麥考爾 |
勃姆 |
ISO 9126,1993 |
| 正確性(Correctness) |
X |
X |
可維護性 |
| 可靠性(Reliability) |
X |
X |
X |
| 完整性(Integrity) |
X |
X |
|
| 可用性(Usability) |
X |
X |
X |
| 效率性(Efficiency) |
X |
X |
X |
| 可維護性(Maintainability) |
X |
X |
X |
| 可測試性(Testability) |
X |
X |
可維護性 |
| 互通性(Interoperability) |
X |
|
|
| 適應性(Flexibility) |
X |
X |
|
| 可重用性(Reusable) |
X |
X |
|
| 可移植性(Portability) |
X |
X |
X |
| 明確性(Clarity) |
|
X |
|
| 可變更性(Modifiability) |
|
X |
可維護性 |
| 文檔化(Documentation) |
|
X |
|
| 恢複力(Resilience) |
|
X |
|
| 易懂行(Understandability) |
|
X |
|
| 有效性(Validity) |
|
X |
可維護 |
| 功能性(Functionality) |
|
|
X |
| 普遍性(Generality) |
|
X |
|
| 經濟性(Economy) |
|
X |
|
表2 三種軟體品質模型之比較 2. 軟體品質的度量 2. 1 軟體品質度量過程
軟體的度量過程主要可以分為五個步驟進行:
(1)確定軟體的品質度量需求。這一步是軟體品質度量最為前提和基礎的一步,主要活動包括設計可能的品質因素集合,最佳化並確定這一因素集合和建立軟體品質模型。
(2)確定軟體品質度量元。這是軟體度量過程較為關鍵的一步,度量元選取的好壞直接影響著品質評估的結果。首先在基於軟體品質度量架構的基礎之上,將品質特性分解成度量元;繼而執行度量元的成本效益分析,根據其結果調整最佳化已選度量元集合。
(3)執行軟體品質度量。包括定義度量資料收集過程並且收集資料、根據已有資料導出量值等環節。需要注意的是,採集的資料應該基於正確定義的度量和模型,從而保證資料的正確性、準確性和精度;因此,在收集資料之前,應當設定資料擷取的目標,並且定義有意義的問題。
(4)分析軟體品質度量結果。通過分析比較收集的度量資料與目標值,發現兩者之間的區別。確定那些不可接受的度量值,詳細分析那些數值偏離關索引值的度量元並依據分析結果重新設計軟體品質度量。
(5)軟體品質度量的驗證。驗證的目的就是為了證明通過軟體產品和過程度量可以預測具體的軟體品質因素值。驗證的過程中,在運用相關的驗證方法和標準的前提下,必須確定軟體品質因素樣本和度量樣本,然後執行對度量的統計分析,檢驗度量的作用是否實現。整個具體過程如圖1所示。
圖1 軟體品質度量過程示意圖 2. 2 軟體度量的驗證與預測
在軟體開發和維護的過程中,定量地評價軟體的品質,必須對軟體品質特性進行度量,以測定軟體具有要求品質特性的程度。
軟體品質特性度量有兩類:預測型和驗收型。
預測度量是利用定量的或定性的方法,對軟體品質的評價值進行估計,以得到軟體品質的比較精確的估算值。它是用在軟體開發過程中的。而驗收度量則是在軟體開發各階段的檢查點,對軟體的要求品質進行確認性檢查的具體評價值,它可以看成是對預測度量的一種確認,是對開發過程中的預測進行評價。
預測度量有兩種。第一種叫做尺度度量,這是一種定量度量。它適用於一些能夠直接度量的特性,例如,出錯率定義為:錯誤數/KLOC/單位時間。一般它作為相對量進行度量。第二種叫做二元度量,這是一種定性度量。它適用於一些只能間接度量的特性,例如,可使用性、靈活性等等。通常,對品質特性制定檢查表,通過對照檢查項目,確定一種品質特性的有無。例如,在設計和編碼階段的複雜性度量,利用尺度度量方法來做。而對模組複雜性的度量採用Mc—Cabe環路度量。基本思想是基於程式的分支、迴圈、順序等摔制結構來估算模組中的結構上的複雜性,其檢查表;給出了評價設計文檔是否完備的檢查表,這是二元度量的例子。我們對檢查表中每一項都應給以記分,指定資訊存在時記“1”,否則記“0”。表中所有各項的分數相加,即得度量結果。 2. 3 軟體品質度量的方法
(1)面向結構度量方法
較早出現的度量是建立在結構化程式設計和模組化思想基礎上的,分析的對象包括程式的控制流程圖,實現中的操作複雜性,方法間的傳遞耦合和流程耦合等。其中影響比較大的有McCabe 提出的迴圈計數複雜度度量,直到今天曆經改進,仍然被實踐者所採納。McCabe 1976年提出了環形複雜度(cyclomatic complexity)理論,該理論以圖論為基礎,通過剖析器的控制流程圖來獲得程式的複雜度,為度配量序邏輯複雜性提供了一種很好的方法。
(2)面向軟體複用的度量
20世紀90年代後期,軟體複用的研究興起。複用的度量主要包括可複用性度量和複用度量。可複用性度量主要用來判定一個構件的可複用性和品質,複用度量主要用於判定複用對生產率、品質和開發時間的作用,它可以在不同層級上進行度量,包括構件級、產品族級、項目級和機構級。目前面向複用的度量大致可分為以下4大類:經濟模型類、成熟度等級模型、複用比率模型以及複用潛力度量模型。
(3)物件導向度量方法
軟體度量進一步作的開展主要在80、90年代,尤其是在90年代,軟體度量的研究獲得了空前的發展。1989年,Morris研究討論了物件導向應用程式的度量,Bieman討論了在物件導向條件下軟體重用的度量問題。1993年中國台灣學者J-Y Chen和J-F Liu提出chen liu方法,從操作性、複雜性、重用性、類的屬性等八個方面去度量物件導向軟體。1994 年Chidamber和Kemerer發表論文對物件導向度量提出了基於繼承樹的一套物件導向度量方法被稱為C K度量方法,主要用來量度與對外部品質屬性的影響有關的物件導向設計的複雜性。1995年,brito等人針對物件導向屬性提出的一套稱之為MOOD的度量演算法集,它從封裝性、繼承性、耦合性和多態性等四個方面給出了物件導向軟體六個度量指標。1998年,Nesi和Querci提出了一種新的軟體複雜度和大小度量方法。
到了2000年,Arlene F提出一種預測點度量方法,這種方法基於對象和他們的特徵,建立一種適合預測工作量和跟蹤生產力的方法,核心是每類加權方法數(Weighted Methods per Class WMC)。2001年,Victor和Daily提出了一種基於構件點的度量方法叫SPECTRE的方法,用於預測開發工作單位時間和模組規模。2003年,Washizaki等提出了一種可重用組件的度量方法,用於度量物件導向組件的易理解性和可重用性。同年,Hastings和Sajeev 介紹了一種新的Vector Size Measure(VSM)方法,用於在軟體生命週期的早期度量軟體規模,軟體分類,軟體開發結果等。2005年Gyimothy等提出一種基於經驗的物件導向度量方法,該方法能有效地實現對源碼的bug預測度量。同年,Del Bianco 等採用經驗斷言的方法,擴充了功能點度量方法,並將其應用到物件導向度量中。 3. 總結
| 學號 |
姓名 |
學習心得 |
| 08212155103 |
王雲 |
在此次的小論文書寫中,我學習到了軟體品質的度量對於軟體工程這門學科是一個關鍵的部分。一個軟體的品質好與壞由許多因素決定,缺陷是肯定會有的。我們要做的是怎麼使得軟體的缺陷的最少化,讓軟體的運行效率最大化。這就要求我們對軟體開發和維護的每個過程都要熟悉,不斷的做評估和修改,然後及時的做出決策。而軟體品質的度量的發展使得我們有模型和度量方法對軟體品質的評估有了一個量化。這樣我們可以根據標準進行決策,使得軟體開發和維護的效率提高,及時發現軟體存在的缺陷。同時在這一次小論文的書寫過程中,也讓我對軟體工程有了更深的認識。軟體工程在介紹軟體開發和維護過程中,也在灌輸著我們一種設計的理念和團隊合作的意識。我會在以後的生活和學習中,好好地培養自己的設計理念和團隊合作的意識。 |
| 08212155101 |
畢娜娜 |
| 082121551 |
熊非非 |
| 082121551 |
潘旭東 |
| 08212155129 |
餘宗紅 |
隨著資訊化產業的發展,人們對軟體品質的要求越來越高。這樣軟體品質的度量就越來越重要了, 在這次論文討論過程中,我學習到了許多關於軟體品質度量方面的知識,也知道了軟體品質的度量對軟體開發的重要性,對軟體工程這門課有了一個深的認識,認識到軟體品質度量在軟體開發過程中是一個不可或缺的部分,它能提高軟體開發及其維護的效率,以及發現一些軟體BUG等。我們組在合作的情況下完成了這篇論文,讓我們認識到團隊合作的重要性,任何時候都離不開團隊的合作,偶爾的一些討論能讓我們收穫很大,今後的學習中我們仍然離不開團隊合作。 |
4. 參考文獻
[1]. 程諾,萬琳,張威.基於量化指標分析的軟體品質度量方法[J].北京化工大學學報,2007,34.
[2]. 郭英軍,曾一,程全良,封衛.一種軟體過程品質的度量方法[J].電腦工程與應用,2008(9).
[3]. 梅宏,謝濤,袁望洪,等.青鳥構件庫的構件度量[J].軟體學報,2000(11).
[4]. 段雲亭.介紹一種軟體品質度量方法[J].資訊系統工程,1991(1).
[5]. 羅建軍.C++程式設計教程.北京:清華大學出版社,2002.