摘 要： 提出一種基于GQM的目標、信息及屬性共同驅動的GQ（I）M的軟件過程改進度量模型，并且通過統計過程控制方法SPC來進行分析驗證，能夠得到軟件組織過程的一組基線模型，為企業決策者在實施軟件過程改進中提供有效的支持和指導，以降低缺陷率、控制風險以及提高產品質量等，滿足企業希望以較低成本取得良好改進效果的需求，尤其是對中小企業更具有現實意義。

　　關鍵詞： GQ（I）M；SPC；基線；過程改進；度量模型

　　近年來，軟件的規模和復雜度不斷地提高，軟件開發項目也變得越來越復雜和難以管理，軟件項目經常出現質量不高、成本超支、進度滯后以及范圍失控等問題。有關研究和實踐表明，70%的軟件項目失敗不是由于技術實力不夠而是由于管理不善造成的。產品的質量很大程度上取決于生產和維護產品過程的質量，這一結論已在全世界范圍內獲得認可[1-2]。

　　目前，CMM模型發展到CMMI模型，將度量由分散在其他過程域中提升為一個獨立的過程域，由此可見度量在軟件組織過程改進過程中的必要性和重要性。 調研發現，目前采用CMMI度量模型進行改進的企業，尤其是中小企業在實施過程改進中并沒有達到預期的目標。總結原因，大致在于：選取度量元的盲目性，缺乏度量經驗的人員不知從何著手。度量需要考慮成本，過于盲目進行度量不但給軟件過程改進組織帶來成本壓力，而且還會給軟件組織過程改進帶來阻礙；度量過程脫離開發過程實際，將很難按照現有的度量模型去規范項目數據和采集項目信息，或者即使采集了數據卻沒有運用有效的分析技術；最后，許多度量程序由于缺乏一致的度量標準，使得數據高度相似、無效或者缺失，從而導致數據信息分析的延遲和分析結果的可靠性遭到質疑[3]。

　　本文提出一種基于GQM的支持過程改進的目標和信息共同驅動的GQ（I）M軟件過程度量模型，該模型可以在組織的目標和信息驅動下，形成軟件組織的度量模型和相關基線，經實驗驗證，該模型可以保證度量結果的時效性、可靠性以及可操作性。

1 模型概述

　　1.1 GQM模型

　　GQM模型(Goal Question Metric)是由美國馬里蘭大學的Vietor Basili博士及其助手提出的一種面向目標、自上而下、由目標逐步細化到度量的度量方法，具備較強的操作性和靈活性。它基于如下假設：對于一個有目的地進行軟件度量的組織，首先必須指定組織和項目的目標，然后通過目標跟蹤到項目數據，這些數據旨在可量化地定義目標，最后提供一個解釋數據與相關目標的框架。每一個組織、項目均有一系列目標要實現；而要實現每一個目標，均要回答一系列問題才能知道目標是否實現；對于提出的每個問題，都可以找到一個完整、可以量化的滿意解答。他把組織的目標歸納、分解為度量的指標，并把這些指標提煉成可以測量的值，從而能夠更好地預測、控制過程性能，實現軟件開發的定量化管理。GQM三層模型如圖1所示。

　　1.2 改進的度量模型GQ(I)M

　　度量在軟件發展過程中，前人已經摸索出了一些方法和標準，但是，無論是CMM/CMMI模型，PDCA模型，還是IDEAL模型或者GQM模型，要么是因為企業資金原因，要么是因為操作流程繁瑣，都或多或少有一些缺陷。尤其是對于一些中小型企業，資金技術實力不夠雄厚，人員流動大，所能承受的風險小，在這種情況下，提出一種具有可操作性和結論時效性的度量模型顯得頗為重要。在研究前人提出的模型中，結合GQM模型，提出了一種改進的軟件度量模型GQ(I)M，主要思想是在GQM模型的基礎上，引入指示器I。GQIM示意圖如圖2所示。

　　GQIM模型是基于GQM模型，在其基礎上，在問題Q和度量M之間引入指示器I，可以直接反映問題層的問題，是一種目標G和信息共同驅動的度量模型，并且在分析驗證階段，將收集到的相關度量數據采用統計過程控制(SPC)的方法進行分析和驗證，這樣既可以避免單純采用GQM模型造成的度量實施過程中不能及時發現問題和原因的局限性，或者單純采用SPC方法分析造成的不能夠更好地將項目目標、組織過程性能目標與商業目標相聯系起來的缺點，而且能夠最大限度地保證度量結果的時效性、可靠性以及更具實際意義的可操作性[5-8]。相關流程如圖3。

　　在項目和組織的特定需要的基礎上，GQ（I）M模型的工作原理就是提供一種模式來幫助軟件管理者為了達到管理上的目標而設計一整套軟件度量體系，運用系統的方法來對軟件過程和產品模型中的各個目標進行裁剪和整合。GQ(I)M可以有效回答正在收集的數據目的是“為什么”這個問題。“為什么”的問題是重要的，因為基于它可以確定如何解釋所獲得的數據，而且，該問題的答案也可以為后續項目活動中變更相關度量計劃和過程提供基礎。軟件開發中運用基于GQ（I）M改進度量模型的方法力求形式化表達這個特殊的過程，通過定義目標和測量指標，使之便于理解，易于培訓，方便知識的重用和計算機管理，以及適應于復雜、多變的應用環境等。

2 實施GQIM度量模型的過程

　　2.1 模型實施原則

　　⑴度量目標的選取。度量目標取決于企業商業目標。度量的目的是為了達成某個目標，而不僅僅是為了度量去度量。它既可以是看作為了加強對軟件過程的理解，也可以是為了組織過程改進。然而，不論是何種目標，均是為了公司的商業目標服務的，因此，在選取組織度量目標時，一定要結合公司的商業目標，并確保度量目標與商業目標的可跟蹤性[4]。商業目標、過程目標與度量目標的映射關系如圖4所示。

　　⑵用發展的思想來提供度量環境和聚焦目標。在軟件度量過程實施中，度量目標的選擇多種多樣。面對大量的數據，可能會感到迷茫不知所措，因此必須運用發散的思維確定所關注的重點過程和目標，明確度量目標先后順序。為了能夠達到這些目標，還需要建立起達到這些目標的支撐環境，比如度量過程中的輔助工具Minitab、SPC分析方法以及各種控制圖等。

　　⑶通過GQIM模型把非形式化的目標分解為可以執行的度量單元。明確了度量目標后，通過這些目標分解出具體的問題，問題解決實際上就是達到了度量目標。每一類問題都和特定的指示器相對應，根據問題，可以派生出相對應指示器或者清晰的度量項，由此，可以得到度量目標與度量數據項之間的映射聯系。

　　2.2 實施步驟

　　采用基于GQ（I）M模型改進的度量活動有4個階段[5]。

　　⑴計劃階段：確定一個度量項目，通過定義、特征化，制訂出項目度量計劃。

　　⑵定義階段：定義度量步驟（確定假設、目標、問題、度量）并文檔化。

　　⑶收集數據階段：收集、確認、分析數據，得到結果集合，并采取相應的措施。

　　⑷解釋階段：按照度量定義將收集的原始數據轉換為可量化的測量結果，解答前面的相關問題，評價所要達到的目標。通過事后剖析的方式分析數據以評估是否與目標一致，建立軟件組織的性能基線模型，并為其后的改善提供建議，為測量結果利益相關者提供反饋信息。

3 基于GQIM模型建立軟件組織性能基線實例

　　M公司是一家從事軟件開發的中小型企業，在資金和技術上均有一定的制約，為了節約成本，提高產品質量，為公司贏得信譽，項目組決定采取基于GQIM的度量方法對項目進行全程追蹤。項目組共有30人，其中開發人員15人。

　　3.1 度量計劃確定

　　圖5是銀行信貸監管系統項目編碼階段的甘特圖，其為度量數據的收集設置了一定的頻度，按此計劃，可以在一定的頻度下，收集到項目的度量數據。

　　3.2 度量目標獲取

　　以下通過選取軟件開發缺陷為例來說明度量目標和指標的分解過程和確定過程。度量目標和指標的結構化描述如下。

　　⑴度量目標：降低開發缺陷，提高產品質量。

　　⑵度量對象：銀行信貸監管系統項目開發過程。

　　⑶度量目的：評價組織過程的性能，缺陷是影響軟件質量的重要因素，控制缺陷是提高軟件質量的重要手段。因此，在軟件開發過程中需要對缺陷進行跟蹤和監控，利用缺陷數據來協助管理項目。

　　⑷度量環境：新開發的銀行信貸監管系統項目，項目規模30人，其中開發人員15人。

　　結合GQ(I)M模型，可以得出如下度量目標與指示器的映射如表1所示。

　　3.3 建立軟件組織過程性能基線

　　（1）統計過程控制SPC原理

　　根據中心極限定律，子組（每次采樣中進行的n次實驗稱為一個子組）樣本均值missing image file將隨著樣本數量的增大而近似的服從正態分布missing image file。由3σ原理可知,missing image file，如圖6所示。這說明軟件產品的性能特性落在missing image file內的概率為99.73%，在此范圍之外兩邊的概率均為0.135%。當落到missing image file范圍之外時，即為小概率事件發生，可判定此過程處于失控狀態，此過程中有不穩定因素發生或存在[6]。

　　（2）控制圖

　　SPC常用控制圖來反映，用來區分軟件組織活動過程的異常是由偶然因素引起的還是由固有因素引起的。控制圖與SPC對應關系如圖6所示。

　　控制圖與控制線：

　　右轉90°

4 過程基線模型的建立

　　根據項目度量計劃設置一定頻度，在項目執行的不同階段為組織過程性能分析收集原始數據(結合圖3說明)。在軟件組織中，根據項目規模大小、用戶需求、技術復雜性、項目范圍、活動類型等分為不同種類。這樣就可以得到可能是唯一的只適用于一種類型的項目度量數據。收集數據之后，按照一定的規則歸類，并且根據這些規則依次運用統計過程控制(SPC)的方法建立組織的性能基線。如果某些類型的項目的數據較少，則將選取類似的項目數據類型組合在一起使用[7]。

　　4.1 基線樣本數據的分析技術

　　所有基線采用XmR控制圖方式，采集到的樣本數據基于以下公式計算如下。

　　X為樣本值，mR為移動極值差；

　　樣本均值：

　　注：其中σ為樣本標準差，對于控制范圍為2σ，A=2；3σ，A=3…以此類推。

　　4.2 樣本數據的采集

　　在項目中收集到的參數如表2所示，n表示樣本數據的樣本點數,即樣本容量，d2,d3是隨樣本容量變化的常數。

　　根據4.1公式可以得出項目的一組相關基線,如表3所示，其中類型是根據相關過程在具體項目中采取不同的類型建立的不同基線。

　　4.3 異常點的判異準則

　　剔除異點判異準則[6]：

　　1個點距離中心大于3個標準差；

　　連續9個點在中心線同一側；

　　連續6個點全部遞增或者全部遞減；

　　連續14個點上下交錯；

　　3個點中有兩個點距離中心線同一側大于兩個標準差；

　　5個點中有4個點距離中心線同一側大于1個標準差；

　　連續15個點距離中心線任一側1個標準差以內；

　　連續8個點距離中心線任一側大于1個標準差。

　　剔除異點后重新計算均值和上下限，要保證所有采集到的數據都落在正常值域范圍，這時的數據即為過程最終的基線。注意應保持至少3個有效的數據，對踢出的異點應分析原因，必要時應針對該原因提出改進計劃措施。

5 度量結果分析

　　5.1 I-MR控制圖建立

　　選擇Minitab統計分析工具來模擬仿真，確定過程性能的基線值，評估度量過程的穩定性，注意計算過程性能基線值只適用于穩定過程[7]。例如：通過單點值和移動值域(I-mR)圖法建立軟件組織過程性能基線。其中I是隨著時間順序觀察得到的單點值，mR值是將后一個觀察值和前一個觀察值比較的差值，即移動極差值。當以單個觀測值收集數據時，就沒有辦法計算出每個子樣組的標準方差，所以可采用移動極差代替，過程變異可通過計算兩個或者多個連續觀測值的極差來反映。圖7為編碼缺陷率的I-MR控制圖：

　　5.2 根據指示器分析度量結果

　　本文引入的指示器，就是能夠在發現問題時，及時有效的找到問題出現的根源，讓管理者及時做決策，掌控全局[8-10]。對于類似軟件項目來說，若開發過程是穩定的，則開發過程中的缺陷率也是穩定的，因此缺陷率可以很好反映編碼過程狀態。若某一段時間缺陷率持續偏高或者偏低，偏離組織的性能基線，則需要對該階段活動進行分析，找出原因并及時采取有效措施。項目結束時，可以總結經驗教訓，并將其納入到組織財富庫，調整組織性能基線，為后續項目作參考。

　　根據上文度量目標與指示器映射表，可及時快速找出問題所出現在的模塊。針對指示器“軟件缺陷密度分布”，如果軟件某個模塊的實際缺陷密度在一個階段突然增加或者降低，其可能原因或者是該項目開發人員的能力欠缺，或者是模塊功能本身較為復雜，需要針對它進行原因分析，以達到將其維護到軟件組織的正常基線范圍內。

　　由圖7可發現，第4個點落在控制線之外，根據4.2節異常點判異準則知該點異常，其余點正常可控。

　　針對第4個點出現的異常，結合表1中的指示器對應部分做了分析，結果發現，新員工參與的模塊缺陷率較高、缺陷密度較大。通過原因分析發現是由于公司最近新招進來一批員工，沒有經過培訓就直接加入到項目組，各自有自己的一套編碼風格，對公司編碼規范不了解，造成了后續代碼缺陷率過高，超出控制線范圍。找到原因之后，可將這些原因歸類，作為組織經驗納入到公司的財富庫中。針對原因，采取一定的改善措施，通過一段時間培訓，項目的缺陷密度基本穩定，及時關閉了相關缺陷，較以往類似項目相比，缺陷的發現和關閉時間均有一定程度的提前，項目如期交付，得到客戶的認可。

　　軟件開發活動在很大程度上受人的主觀意識支配，具有一定的不確定性和盲目性,這對軟件開發的認知造成一定的困擾。本文將改進的GQIM軟件過程改進度量模型引入到軟件項目的管理中，在很大程度上緩解了以往項目管理過程中的盲目性問題。文中給出了模型的度量指示器以及指示器的可視化性表示，并結合了一個項目實例，在此基礎上講述了GQIM模型的構造、實施流程以及結果分析，使得企業軟件管理者對項目的管理有一個清楚的認知，為項目決策提供支持，尤其是對中小型企業具有現實意義。后續工作仍需要繼續完善該模型的理論，并在企業實踐中不斷優化改進，力圖找到一種適合我國軟件企業的軟件過程改進度量模型。

參考文獻

　　[1] 鄭人杰,殷人昆，陶勇雷.實用軟件工程（第二版）[M].北京：清華大學出版社，2005.

　　[2] CMMI Product Team. CMMI for Development.Version1.3[Z].USA: SEI, CMU/SEI_2010_TR_033, 2010.

　　[3] 張鳳景，任愛華．一種目標與信息共同驅動的度量模型[J].計算機應用，2007，27（2）：389-393.

　　[4] 徐丹，黃金貴，曾維橋.基于目標的軟件過程性能定量評價模型[J].計算機工程與應用，2008，44（2）：54-55.

　　[5] 徐丹.基于目標的軟件過程性能定量評價模型[D].長沙：湖南師范大學，2008.

　　[6] 張少崗.基于CMMI的軟件過程度量研究與應用[D].鄭州：鄭州大學，2010.

　　[7] 徐俊，李軍.軟件研發過程性能基線和模型建立方法及應用分析[J].現代計算機（專業版），2013(14):14-17.

　　[8] 錢紅兵，朱麗娟，曹慧民.基于CMM的軟件過程度量系統的設計與實現[J].計算機應用研究，2004，21（6）：49-52.

　　[9] 田麗從，李鐵牛，彭宏.中小型企業軟件過程改進方法研究[J].計算機應用與軟件，2011，28（4）：208-211.

　　[10] 范文峰.軟件過程度量的研究與應用[D].上海：上海大學，2003.

　　[11] 李健，金茂忠.中小型企業軟件過程改善方法研究[J].計算機工程與應用，2001，37（19）：107-111.

　　[12] 程全良.軟件過程缺陷度量的研究與應用[D].重慶：重慶大學，2010.

　　[13] 王海.基于CMMI的軟件度量過程的研究與應用[D].天津：天津大學，2006.

　　[14] 徐俊.軟件過程改進模型研究與應用[D].廣州：中山大學，2008.

　　[15] 孔垂云.基于CMMI的軟件質量度量研究[D].北京：北京交通大學，2009.