基于ＣＭＭＩ的軟件過程度量

摘要：軟件度量已經逐漸成為了軟件工程領域中極其重要的一部分[5]。該文提出了一種軟件過程的度量模型。在該模型中定義了與實施軟件過程度量有關的活動。并在此基礎上，重點闡述和說明了數據收集、認證和分析的目標、任務以及方法。文中還給出了一個把該模型應用于大型軟件公司的實例，以說明該模型能夠有效地評估并改進軟件過程。該文的研究結果對改進軟件過程、增加組織的過程能力成熟度是很有幫助的。

關鍵詞：軟件過程；度量；CMMI

中圖分類號：TP311文獻標識碼：A文章編號：1009-3044(2009)34-1647-03

CMMI Based Software Process Measurement

HE Yun

(School of Software Engineering， Shanghai Tongji University， Shanghai 200092， China)

Abstract: Software measurement is becoming more and more important for the software engineering. This paper raises a model in which some activities related to the software process measurement are defined. Based on this， the paper put more focus on the objectives， tasks and methods of data collection， validation and analysis. This paper also includes an example of applying the model to a large-scale software company so as to illustrate the effectiveness of the model. This paper is very useful for the software process improvement and the enhancement of the process capability maturity within the organization.

Key words: software process; measurement; CMMI

1 介紹

過程管理已經逐漸成為了現代軟件質量管理的核心，從二十世紀七十年代開始，就不斷涌現出了各種軟件過程質量模型和軟件質量標準[1]，包括CMM[2]、CMMI[9]、ISO9001[3]、SPICE[4]等。雖然，上述各大模型和標準都不盡相同，但它們都不約而同地把關注點放在了基于度量的軟件過程改進之上。也正因為如此，目前，過程度量已經成為了軟件過程能力度評估和管理的重要組成部分。

然而，CMM、CMMI等模型都沒有精確定義實施軟件過程度量以及收集并分析軟件過程數據的方法，也沒有指明應該使用何種工具及方法完成相關的度量操作。因此到目前為止，各企業只是按照自己的理解來進行軟件過程度量，仍未有一種操作標準和指南來幫助企業有效地實施相關的度量活動。

基于已有的CMMI模型，本文將提出一個用于軟件過程度量的過程模型，并對其相關的活動、方法等內容進行定義。本文還將介紹與常用數據收集、認證和分析過程有關的目標、任務和方法，以便更好地使用過程度量模型實施軟件過程度量。之后，還會給出一個使用該模型進行實際評估和改進的實例。

文本的組織結構如下：

第二部分將描述針對軟件過程度量的過程模型，定義相關的內容、主要活動以及方法等；

第三部分將介紹在數據捕捉（收集和驗證）及分析時的目標、任務和方法；

第四部分將給出一個基于提出模型的過程評估及改進實例；

最后第五部分將對全文做出總結并給出今后擬進行的研究工作。

2 軟件過程度量

所謂過程度量，是指在某種限制條件下由多個角色根據（過程）計劃所進行的一系列（度量）活動[3]。因此，過程度量本身也便成了一種“過程”。圖1是在CMMI的基礎上給出的一個軟件度量過程模型。該圖中包含了每一個過程度量活動中的輸入、輸出、限制條件、必備的支持工具及方法等。這當中，每一個活動的輸入指的是來自于前一個活動的數據輸出或其它相關的外部輸入，正是由于這些輸入，使得度量的分析結果可以很好地反映出過程的執行情況，從而確定出在過程執行期間是否滿足了那些關于過程評估、過程控制和過程改進的既定目標[8]。

2.1 過程度量的輸入和輸出

軟件過程度量的對象是軟件過程的活動和相關的工作產品，因此，軟件過程度量的輸入就應該是軟件項目小組每天的生產活動和對應于每一個階段的有關產品。另一個可以作為輸入的是軟件過程度量計劃，該計劃是軟件項目小組根據組織及項目目標并在GQM（Goal-Question-Metrics）度量模型[6]的指導下按照項目實際環境建立起來的。軟件過程度量必須與其要度量的軟件過程相聯系，相關的度量活動則經常與相應的軟件過程并行展開，因此，過程度量計劃往往會被視作為一個項目計劃的一部分。

2.2 過程度量的主要活動

軟件過程度量包括了數據捕捉和度量分析兩部分。其中，數據捕捉包含了兩個活動：數據收集和數據驗證，而度量分析則由三個活動組成：數據轉換、度量分析和決策制定。

2.3 過程度量的體系結構

軟件過程度量的體系結構包括一些核心的業務模塊、支持工具、度量數據庫以及一些相關的規則、方法、指導、模版等。核心的業務模塊可以完成一些如數據收集、數據分析、數據存儲以及信息反饋等的核心功能，各類支持工具則可以向各業務模塊提供必要的原始過程及產品數據。如圖2所示，是一個簡化的軟件過程度量體系結構。

根據度量請求，度量規劃模塊會按照GQM的標準格式生成一張與該項目相對應的度量進度表。在制定進度表的時候，該模塊會采用已知的度量模型并選取以往的項目經驗進行參考。在度量進度表中，針對最終信息產品的的進度信息會根據在請求中包含的相關需求信息（如內容、時間等）產生，針對分析功能的進度信息會根據決定最終信息產品的度量模型產生，針對數據收集的進度信息會根據度量模型中對基本度量數據的要求以及相關的評估和度量步驟產生。

數據分析模塊負責加工相關的信息產品。根據來自于度量規劃模塊的進度信息，數據分析模塊會在適當的時間點采用某些分析模型、加工基本的度量數據、創建相應的信息產品并把它提交到信息反饋模塊。

信息反饋模塊負責把相關信息產品反饋給請求者。完成反饋的途徑有很多種，可以在Web上進行顯示，可以被打印出來，也可以通過電子郵件的方式進行發送。

度量數據往往存儲在度量數據庫中。歷史度量數據庫中存儲的是以往度量活動中產生的度量產品和相關的度量經驗。度量模型數據庫中存儲的是各類度量模型的詳細信息，包括使用的分析模型、適應性條件、基本度量數據等。當項目結束時，所有模型數據庫中的信息會被轉存到軟件組織的歷史度量數據庫中。

3 數據收集和度量分析

考慮到企業及組織內部的多樣性，列寫并評估所有與度量過程有關的詳細方面和內容是不現實且無意義的[3]。本文把度量并改善軟件過程作為首要目標，因此決定選擇軟件規模、工作量、項目進度、成本及軟件缺陷作為主要的度量因素。通常，可以用功能點、代碼行、文檔的頁數來衡量軟件的規模，用人時、人天等來表述工作量。項目進度反映了實際每一個工作階段的開始及結束日期。而軟件缺陷則按照嚴重度等級、生產階段以及不合格內容的類型分別進行計算和統計。由于上述的所有度量點都直接或間接地與工作量有關，所以下文拿工作量度量作為例子來介紹與軟件過程度量有關的各個活動階段。

3.1 數據捕捉（數據收集和驗證）

軟件項目的實際過程數據一般來自于項目日/周報和針對軟件產品的評估及測試報告。而關于工作量的信息則一般來自于員工的工作日記。

項目經理必須負責每周統計出項目中每一個任務的執行情況并如實填寫《項目狀況報告》，包括每一個任務的實際工作量、成本、規模、缺陷信息以及為修正這些缺陷所需的額外工作量等。當項目的每個階段結束時，項目經理必須總結該階段的所有過程數據并完成《項目情況總結報告》以記錄與項目該階段有關的所有度量數據，包括實際工作量、規模、進度以及該階段的實際情況與預計成本、計劃的偏離程度。在每一周和項目的每一個主要里程碑上，項目經理必須跟蹤缺陷的關閉情況并確保項目數據在由SQA評估及驗證之后被存入過程數據庫中。來自于項目開發的數據必須至少包括如下信息：

1) 需求定義、設計、編碼和測試等階段所需的預計時間和工作量；

2) 項目管理、質量保證、工作產品評估、配置管理、培訓等階段所需的預計工作量；

3) 在開發階段的初期所確定的需求數量以及后續增加或更改的需求數量；

4) 開發過程中及其后所記錄的缺陷數量，即，在需求定義、設計、編碼、測試以及系統測試之后等階段中所發現的不同類型、不同嚴重度的缺陷數；

5) 基于干代碼行技術或功能點計算等方法的針對項目規模的預測。

3.2 過程度量分析

實施度量分析的目的是為了發現現存軟件過程中的問題并定義出過程改進的計劃和目標。過程度量分析的關鍵是對實際工作量、項目進度、項目實際情況與計劃或預計成本的偏離程度、過程中存在的缺陷以及在項目中已解決的缺陷進行分析和統計。因此，必須首先按照特定的數據模型提取并統計現存的過程數據，使其能夠很好地反映出度量的范圍和目標，然后，再把經過轉換的數據同使用相同格式的基準參數進行比較，以發現被度量過程中存在的問題并把其作為過程改進的依據和基礎。

表1是一個在通過CMM3級認證的軟件公司中使用的針對軟件過程度量的統計數據模型。文中的項目數據是由組織的軟件過程能力度和實際的項目情況所決定的。當項目結束的時候，項目經理、軟件工程過程小組以及軟件質量保證人員就可以根據項目的評估數據和實際的項目過程數據并使用表1中所示的過程度量數據模型對相關的數據進行轉換和解釋。

4 過程度量應用實例

基于度量過程的相關定義以及上述的統計數據模型，下文將介紹一個針對中等規模財務軟件開發過程開展度量和分析活動的實例。其中，那些用于度量的數據來自于公司員工的工作日記、缺陷評估清單、軟件測試記錄、用戶反饋記錄等，并在經過項目經理的確認以及質量保證人員的驗證之后被實時地錄入到公司的數據收集系統之中。根據每一個項目、任務和工作階段的編號，項目經理可以很方便地使用數據收集系統統計出關于每個任務、每一階段及整個項目的實際工作量、人員工作時間、成本以及缺陷數據等信息。表2與表3中列寫的就是針對該項目度量數據的統計結果。為了對項目的過程進行評估及分析，表2中還列出了與相關度量數據對應的組織基準參數。

由于并未設立組織內部針對缺陷的基準參數，因此，表3只是列寫了項目中的一些關于缺陷的實際度量數據，并按照發現并修正缺陷的階段對這些數據進行了分類。

通過比較和統計上述的度量數據，可以得到如下針對該項目軟件過程的分析和評估結果：

1) 如表2所示，項目進度和工作量的偏差對應于基準參數各增長了68%和80%，而需求穩定度和編碼方面的工作量又基本與相應的基準參數保持一致，因此，項目工作量的增加和進度的延遲并不是由于需求的不確定性和需求的頻繁變更所導致的。而相應的，花費在設計階段的工作量太少。與需求分析階段相比，設計階段的實際工作量明顯低于基準參數。如果設計階段的工作量不夠，就會導致軟件的設計出現問題，使代碼的缺陷增多，繼而影響到產品的質量和整個項目的進度。

2) 根據相應的需求穩定度、工作量分布率以及缺陷分布率可知，雖然針對系統需求的工作量分布比相應的基準多了20%，但也因此換來了更好的需求穩定性，而且與需求分析相關的缺陷分布率也相對較低，所以，該項目中在需求分析階段的軟件過程質量是很高的。

3) 評審過程（包括同行評審和代碼審查等）的質量及效率并不高。如表3所示，在評審過程中只發現了426個缺陷中的158個，而剩下的268個缺陷是直到最終測試階段才發現并進行修正的。這樣一來，就把原先可以盡早發現的缺陷拖延至了系統測試階段才加以解決，從而增加了后續測試工作的壓力和工作量，并將直接導致項目進度的落后。

針對上述分析結果，可以提出如下建議以改進該項目的軟件過程：

1) 增加在設計階段的工作量；

2) 加強針對工作產品的評審力度；

3) 盡可能多地在早期階段移除系統中的缺陷，繼續堅持并改善單元測試和代碼審查的效率。

5 總結

本文給出了一個軟件度量過程模型并定義了相關的角色、度量內容、主要活動、有關的支持工具以及實施軟件過程度量的一系列方法。還介紹了在過程度量數據的收集、認證和分析活動中的有關目標、任務和相應的方式方法。文章的后半部分介紹了在一個通過CMM3級認證的軟件公司中使用本文提出的過程度量方法的實例，從而證明了該方法的靈活性和有效性。該文的研究成果對有效地評估和改善軟件過程從而進一步增強組織軟件過程的成熟度是很有幫助的。（下轉第1690頁）

（上接第1649頁）

參考文獻：

[1] Watts S. Managing the Software Process[M]. Addison-Wesley Publishing Co， Reading， Massachusetts， 1989.

[2] Mark C Paulk， Charles V Weber. Key Practices of the Capability Maturity Model， SM， Version 1.1[R]. Technical Report， CMU/SEI-93-TR-025， ESC-TR-93-178， 1993.

[3] Florac W A， Carleton A D. Measuring the Software Process: Statistical Process Control for Software Process Improvement[M]. Addison Welsley， 1999.

[4] Dorling， A. SPICE: Software Improvement and Capability Determination[J]. Software Quality Journal， 1993， 2.

[5] Zhu S Y， Qian L Q， Su W M. Software Engineering Technology Conspectus[M]. Publication of Science， 2002: 117-134.

[6] Basli V R， Caldiera G， Rombach H D. The Goal Question Metric Approach[Z]. The encyclopedia of Software engineering， john Wiley， 1994.

[7] Jalote P. CMM in Practice: Process for Executing Software Projects at Infosys[M]. Addison-Wesley， 2000.

[8] Xu Ruzhi， Qian Leqiu. Research on Metricsbased Software Process Control Optimization[J]. Journal of Electronics， 2003， 31(12A):1206-1209.

[9] CMMI-SE/SW Version 1.1[S]. Copyright 2002 by Carnegie Mellon University， January 11， 2002.

[10] Xu R Z， Nie P Y. Optimizing Software Process based on Risk Assessment and Control[C]. Proceedings of the 5th International Conference on Computer and Information Technology， Shanghai， IEEE Computer Society，2005:896-900.