摘要：該文首先介紹了上海軟件度量基準體系，其次對缺陷的特征以及缺陷管理的意義進行了分析和研究，最后在上海軟件度量基準體系收集的軟件開發(fā)過程中的各種數(shù)據(jù)的基礎上，按照項目過程模型，過程改進模型，系統(tǒng)架構類型，業(yè)務領域，開發(fā)平臺，開發(fā)類型等標準，對缺陷密度進行了詳細的分析和研究，隨后研究了基于過程改進模型的企業(yè)在各開發(fā)階段的缺陷分布情況，提出了自己的見解和意見。

關鍵詞：缺陷密度；度量；基準

中圖分類號：TP393文獻標識碼：A文章編號：1009-3044(2008)28-0140-03

The Analysis of Software Defect Based on SSMBSS

WENG Zhi-wen

(Software College， Tongji University， Shanghai 210096， China)

Abstract: The article firstly introduces Shanghai Software Metrics Benchmarking standards System (SSMBSS)， secondly it analyses the character of defect and the sense of defect management， finally with the help of Shanghai Software Metrics Benchmarking standards System， according to process model， process ameliorate model， business domain， development flat and so on， it analyses defect consistency particularly and studies defect distribution of software development phase.

Key words: defect consistency; Metrics; benchmarking

1 SSMBSS簡介

軟件從最早的單個人開發(fā)，單一的程序，逐漸朝著龐大，復雜，需要人數(shù)眾多的人參與，協(xié)同開發(fā)才能完成的軟件項目，軟件行業(yè)也作為一種新興行業(yè)而崛起，行業(yè)分工不斷細化。與此同時，軟件開發(fā)的復雜度也越來越高，出現(xiàn)的BUG也越來越多。為了度量軟件開發(fā)的生產(chǎn)率，上海信息委決定建立上海軟件度量基準體系，簡稱SSMBSS，來了解和促進上海軟件企業(yè)的軟件開發(fā)能力。

上海軟件度量基準體系，是在上海信息委的要求和指導下，在借鑒國外ISBSG，北京CSBSG的基礎上，在廣大軟件企業(yè)尤其是上海軟件企業(yè)的通力合作下建立的。上海軟件度量基準體系(SSMBSS)數(shù)據(jù)全部來源于企業(yè)，具有相當?shù)膶嵺`性，可靠性，可信性。上海軟件度量基準體系是對上海市、全國甚至世界范圍內的軟件項目或產(chǎn)品開發(fā)過程中的各種數(shù)據(jù)進行收集、整合和分析以得到軟件行業(yè)的各種度量指標，從而更有效的為軟件企業(yè)的項目管理及政府部門的決策提供支持。

2 缺陷分析研究

2.1 缺陷定義和特征

軟件缺陷是指在程序中或文檔中存在各種不希望出現(xiàn)的問題。如語法錯誤、拼寫錯誤、標點錯誤，或者是一個不正確的、冗余的程序語句或有缺陷的程序段等，缺陷可能出現(xiàn)在程序中、設計中，甚至出現(xiàn)在需求規(guī)格說明或其他文檔中。事實上，缺陷是任何可以影響到程序完整而有效地滿足用戶要求的東西。

軟件缺陷是軟件“生來具有”的特征。不管是小程序還是大型軟件系統(tǒng)，無一例外地都存在缺陷，而且無法完全避免。這些軟件缺陷，有的容易表現(xiàn)出來，有的隱藏很深難以發(fā)現(xiàn)，有的對使用影響輕微，有的會造成財產(chǎn)甚至生命的巨大損失。

軟件缺陷的特征可歸結為如下幾個方面：

l) 糾正一個缺陷造成了另一缺陷現(xiàn)象(暫時)的消失，相關缺陷一般會具有這種特征；

2) 某些缺陷征兆只是假象；

3) 因操作人員一時疏忽造成的某些缺陷征兆不易追蹤，如輸入操作等；

4) 缺陷是由于分時而不是程序引起的；

5) 輸入條件難以精確地再構造（例如:某些實時應用的輸入次序不確定）；

6) 缺陷征兆時有時無，此現(xiàn)象對嵌入式系統(tǒng)尤其普遍；

7) 缺陷是由于把任務分布在若干臺不同處理機上運行而造成的。

3 缺陷管理的意義

雖然缺陷無法完全避免，但缺陷管理可以幫助開發(fā)者盡可能避免缺陷。使得開發(fā)者把精力投入在最可能出現(xiàn)缺陷的地方，這樣才能有效地提高軟件質量。

對缺陷的管理，必須要建立一個比較完整的缺陷信息，如果缺陷信息不完整，就會難對己有缺陷進行分析處理，就無法科學地評估軟件的質量，發(fā)現(xiàn)軟件產(chǎn)品和軟件過程的待改進之處，就會不便于相關人員日后作為經(jīng)驗教訓的積累和查詢一個完整的缺陷信息。應該包括:缺陷的狀態(tài)、嚴重性、所在模塊、軟件版本、類型、詳細描述、階段、提交者、測試者，測試日期和時間等。

對缺陷的登記、缺陷的處理過程，通過字典定義、輸入界面的約束，達到了一致的缺陷編寫要求，實現(xiàn)了缺陷信息處理的規(guī)范化。對于缺陷登記、缺陷修復登記、缺陷回歸測試登記形成的缺陷信息，通過軟件自動統(tǒng)計，.可以迅速獲得任意時間段內、任意系統(tǒng)模塊、任意缺陷級別、任意缺陷狀態(tài)等各種組合的缺陷信息、缺陷統(tǒng)計數(shù)據(jù)，實現(xiàn)了查詢、統(tǒng)計的自動化。

通過使用缺陷管理工具收集缺陷數(shù)據(jù)，將測試結果數(shù)據(jù)在測試過程中總結的excel模板結合，可以制作得到各種缺陷分析圖表。通過分析缺陷生成趨勢圖，指導軟件發(fā)布時機，根據(jù)缺陷趨勢曲線來確定測試過程是否結束是常用并且較為有效的一種方式。如:在發(fā)現(xiàn)缺陷數(shù)量未收斂時發(fā)布軟件，顯然風險很大，當然使用圖表時還應結合實際，如在曲線平坦時，考慮是否有效的開展了測試工作，曲線上升時，缺陷的嚴重性是否很低等。

通過嚴重性等級的柱狀圖可分析被測系統(tǒng)的總體狀況，從而預測項目風險或解釋測試結果。通過導致缺陷產(chǎn)生的原因分布圖，可以將測試注意力集中到引起最嚴重、最頻繁問題的領域，從而消耗最少的資源改進過程取得最顯著的成果。

4 缺陷分布研究

SSMBSS收集了項目在各個時期的缺陷數(shù)據(jù)，本文在這主要關注缺陷密度分布，缺陷密度被定義為每單位規(guī)模的缺陷數(shù)量，雖然用于統(tǒng)計規(guī)模的方法很多，但本文主要考慮用FP，KLOC統(tǒng)計規(guī)模的項目，這主要是因為目前國內主要用KLOC統(tǒng)計規(guī)模，而在國外主要使用FP?，F(xiàn)在國內開始使用FP統(tǒng)計規(guī)模的軟件企業(yè)也在逐漸的增多。在本文中，如果未對規(guī)模單位加以說明，則默認為KLOC。

4.1 按項目開發(fā)的過程模型的缺陷密度分布（見表1、表2）

表1 表2

■

過程模型在SSMBSS中分為瀑布模型，增量模型，螺旋模型，原型模型，RUP模型以及其他模型。沒有數(shù)據(jù)的過程模型沒有列出，所以上下表模型種類有所不同，從表中可看才出原型模型的缺陷密度最高，這可能和需求不明確有很大的關系。

3.2 按不同組織或企業(yè)定義的標準過程的等級的缺陷密度分布（見表3、表4）

過程改進模型在本文主要包括CMM/CMMI。缺陷密度并不會隨CMM/CMMI的等級成正比例，這主要是因為CMM/CMMI等級高的企業(yè)開發(fā)的軟件的規(guī)模和復雜度也相對更高。但CMM5的企業(yè)的開發(fā)能力明顯高于其他等級。

3.3 按項目系統(tǒng)架構類型（C/S 、B/S）的缺陷密度分布（見表5、表6）

系統(tǒng)架構主要是指客戶機/服務器，瀏覽器/服務器，單機。從表中可以看出瀏覽器/服務器（B/S）架構的缺陷密度較小，可以看出良好的架構可以降低缺陷的發(fā)生概率。

3.4 按項目業(yè)務領域的缺陷密度分布（見表7、表8）

業(yè)務領域的不同，主要會影響到軟件的復雜度，從表中數(shù)據(jù)可以看出操作系統(tǒng)或軟件應用系統(tǒng)，軟件開發(fā)工具，文檔管理系統(tǒng)的缺陷密度都處于一個較高的水平，這可能與它們的功能需求復雜有較大的關系，因此對功能復雜的系統(tǒng)，我們必須做好充分需求分析和詳細的設計分析，從而降低缺陷的發(fā)生的可能性。

3.5 按項目開發(fā)平臺統(tǒng)計的缺陷密度分布（見圖1）

開發(fā)平臺主要包括PC或微機，小型機，中型機，大型機，多平臺。其他開發(fā)平臺沒有出現(xiàn)是因為數(shù)據(jù)。從總體上看多平臺的缺陷密度高于單平臺，可見平臺的復雜度也會影響到開發(fā)中的缺陷密度，而且用UCP估計規(guī)模的項目的缺陷密度也處于較高的水平，這可能是因為相對KLOC，F(xiàn)P等規(guī)模方法，UCP的使用經(jīng)驗相對較小。

3.6 按項目開發(fā)類型統(tǒng)計的缺陷密度分布（見圖2）

開發(fā)類型主要包括新開發(fā)型和功能增強型。功能增強型的缺陷密度總體上比新開發(fā)型，這說明對原系統(tǒng)進行拓展比新開發(fā)一個系統(tǒng)難度更高，這可能是因為后來的開發(fā)人員不是原系統(tǒng)的開發(fā)者，對原系統(tǒng)的各個方面都不是很熟悉。因此保持各種文檔的完整性非常重要，因為人員流動比較難控制，尤其是IT行業(yè)。

3.7 按項目組織類型統(tǒng)計的缺陷密度分布（見圖3）

從表中可以看到電信，金融，物流的缺陷密度都比較高，這主要是因為這些行業(yè)的業(yè)務都非常復雜。從而為需求和設計帶來很大的難度。因此在開發(fā)這些行業(yè)的軟件時，需求和設計的所用時間應該更長一些。

3.8 項目各階段實際發(fā)現(xiàn)缺陷的數(shù)量分布比率（見圖4）

3.9 CMMI3的軟件企業(yè)的項目各階段實際發(fā)現(xiàn)缺陷的數(shù)量分布比率（見表10）

3.10 CMMI4的軟件企業(yè)的項目各階段實際發(fā)現(xiàn)缺陷的數(shù)量分布比率（見表11）

表10表11

■

3.11 CMMI5的軟件企業(yè)的項目各階段實際發(fā)現(xiàn)缺陷的數(shù)量分布比率（見表12）

表12

■

從圖4、表10到表11，可以明顯看出缺陷的發(fā)現(xiàn)主要在測試階段，而且無論企業(yè)處于CMM/CMMI等級的哪個級別都是如此。所以我們在開發(fā)中必須關注測試，不能把測試看成是可有可無的工作，因為測試是軟件質量保障的重要手段之一。此外設計和構建是出現(xiàn)缺陷的兩個主要開發(fā)階段，所以在開發(fā)當中，開發(fā)者應該在這兩個階段投入更多的精力。

4 小結

從上述圖表中可以看出國內大部分企業(yè)還是在使用KLOC進行規(guī)模估算，而且使用經(jīng)驗也相當?shù)某墒?，處于主流地位，F(xiàn)P規(guī)模方法正在處于逐步流行的階段，相對KLOC經(jīng)驗還不是很充足。需要大力推廣，同時也可以看出開發(fā)者的經(jīng)驗會影響到項目的缺陷密度水平。

上海軟件度量基準體系(SSMBSS)是在借鑒國外ISBSG，北京CSBSG的基礎上建立起來的，目前收集的數(shù)據(jù)主要來源于上海軟件企業(yè)，正處于起步階段。

國外ISBSG已經(jīng)比較成熟，2007年下半年召開的軟件過程改進大會，ISBSG的主席peter到會，并發(fā)表了精彩的演講。從他的報告中可以了解到ISBSG對軟件開發(fā)的各項核心參數(shù)進行了比較詳細的分析研究，其中就包括缺陷這個非常重要的參數(shù)，但peter的報告都是保密的。因此我們只能獨立地進行自己的研究。

北京CSBSG起步要早于上海，也積累了不少成功的經(jīng)驗，發(fā)現(xiàn)了不少的問題。為上海軟件度量基準體系的建立奠立了比較好的基礎。使得上海軟件度量基準體系的建立少走了不少的彎路。目前北京CSBSG已經(jīng)進入國家863計劃，由此可以看到國家對這項研究的重視以及該項研究的重要意義。

參考文獻：

[1] 國家標準局.軟件工程國家標準：軟件需求說明書（GB856T—88）[S].

[2] Pressman R.Software Engineering-a practitioner's approach[M].6 edition.McGraw-Hill Science/Engineering/Math，2004.

[3] Jacobaso I，Booch G， Rumbaugh J.The Unified Software Development Process[M].Addison-Wesley，2002.

[4] CSPIN.軟件度量綱要 ISBSG[S].