面向開發(fā)階段的軟件缺陷分類方法研究

摘要：提出一種面向開發(fā)階段的軟件缺陷分類方法PhaseDC，將缺陷和軟件開發(fā)各階段相關(guān)聯(lián)，計算階段及過程的缺陷排除有效性，并結(jié)合缺陷的類型和表現(xiàn)形式等詳細信息分析開發(fā)過程的質(zhì)量，以幫助軟件組織促進并實施過程改進活動。通過實例說明了該方法在過程改進中的應(yīng)用，并對方法的完備性、正交性和一致性進行了分析驗證。

關(guān)鍵詞：軟件缺陷；缺陷分類；開發(fā)階段；過程改進

中圖分類號：TP393．04文獻標志碼：A

文章編號：1001－3695(2008)03－0759－05

0引言

軟件缺陷分類是軟件缺陷度量和分析的基礎(chǔ)，IEEE/ANSI標準中將缺陷理解為產(chǎn)品中的反常現(xiàn)象。一方面，缺陷的檢測和清除能夠保證最終開發(fā)的軟件產(chǎn)品的質(zhì)量；另一方面，缺陷包含著豐富的信息，對缺陷的分析可以幫助軟件組織獲得開發(fā)過程的質(zhì)量，跟蹤并控制項目的進程，從而實施過程改進活動。缺陷的度量已成為軟件產(chǎn)品度量和過程度量中的必要環(huán)節(jié)；同時缺陷的分析既可以用來評估軟件產(chǎn)品的質(zhì)量，又可以幫助掌握和評價軟件開發(fā)過程的質(zhì)量。良好的缺陷分類方法是幫助實施缺陷度量和分析的必要前提。

目前有很多應(yīng)用成熟的缺陷分類方法，這些方法的側(cè)重點不同，其復雜程度和適用的具體條件也不相同。本文提出了一種面向開發(fā)過程中的各個階段來實施缺陷分類的分類方法PhaseDC。這種分類方法能夠幫助軟件項目的開發(fā)人員和測試人員快速地定位各個缺陷的屬性值，建立缺陷和開發(fā)階段的關(guān)聯(lián)關(guān)系，從而分析每個階段的缺陷排除有效性；結(jié)合缺陷的詳細描述信息找到改進軟件過程的依據(jù)，從而有效地實施過程改進活動。不同于已有的缺陷分類方法，該方法著重關(guān)注缺陷關(guān)聯(lián)的開發(fā)階段，確定了每個缺陷的引入階段和發(fā)現(xiàn)階段；利用階段的信息對缺陷進行充分的分析，找到開發(fā)過程中存在的問題和需要改進的地方。

1相關(guān)工作

缺陷可以被捕獲并分析的屬性特征有多種，通常包括的語義信息有：缺陷被檢測到的位置、引入；發(fā)現(xiàn)及修改缺陷的活動；缺陷產(chǎn)生的征兆及原因、嚴重程度、最終影響、形成或修復機制以及發(fā)現(xiàn)并排除缺陷的成本等[1]。

最初使用的缺陷分類方法比較簡單，如Putnam等人提出的缺陷分類方法[2]；國家軍用標準GJB437的軟件錯誤分類方法。這兩種方法可以分析缺陷的來源和出處，為開發(fā)過程的改進提供線索，但提供的缺陷相關(guān)信息是很有限的。

Thayer軟件錯誤分類方法是按錯誤性質(zhì)分類[3]，包括16個類、164個子類。該方法通過對錯誤進行分類統(tǒng)計來了解錯誤分布狀況，對錯誤集中的位置重點加以改進。其執(zhí)行過程比較復雜，同時沒有考慮缺陷相關(guān)的過程原因，并不適用于過程改進活動。

正交缺陷分類ODC是IBM公司提出的缺陷分類方法[4]。該分類方法提供了一個從缺陷中提取關(guān)鍵信息的測量范例，用于評價軟件開發(fā)過程，提出過程改進方案。ODC分類方法主要包括缺陷的八個屬性特征，即發(fā)現(xiàn)缺陷的活動、缺陷影響、缺陷引發(fā)事件、缺陷載體、缺陷年齡、缺陷來源、缺陷類型和缺陷限定詞。該方法覆蓋的語義信息包括缺陷的位置、缺陷產(chǎn)生的征兆、最終影響以及缺陷的形成機制等。其中并沒有特別針對開發(fā)階段來對缺陷進行分類的屬性，即沒有明確的缺陷引入階段、發(fā)現(xiàn)階段等信息。此外，ODC中的缺陷類型主要是針對編碼階段的缺陷劃分的，也不適用于對整個軟件生命周期中產(chǎn)生的缺陷進行分類。

HewlettPackard缺陷分類方法是HP公司軟件度量委員會于1986年開發(fā)的缺陷分類方法[5]。HP缺陷分類方法主要通過三個屬性來描述缺陷，即缺陷來源、缺陷類型和缺陷的形成方式。這種分類方法同樣沒有獲取缺陷被引入和發(fā)現(xiàn)時所在的開發(fā)階段，因此也不易明確地將缺陷定位在開發(fā)過程的各個階段上。

電氣和電子工程師學會制定的軟件異常分類標準(IEEE standard classification for anomalies 10441933)對軟件異常進行了全面分類，給出整個缺陷分類方法的屬性框架，具有較高的權(quán)威性；同時可針對實際的軟件項目進行裁剪，靈活度高。然而，該標準通常需要根據(jù)項目情況訂制，且分類過程復雜，不利于快速地對缺陷進行分類和度量。

此外還有一些用于特定活動的缺陷分類方法，如用于需求檢查的缺陷分類方法、用于設(shè)計檢查的缺陷分類方法[6]等。由于這些方法是為某一特定的軟件開發(fā)活動提出的，其使用范圍也是有限的。

2PhashDC軟件缺陷分類方法

PhaseDC是筆者提出的一種新的缺陷分類方法，它通過結(jié)合對軟件開發(fā)階段的分析來指導過程改進。

2．1總體框架

在缺陷分類方法中，采用缺陷的屬性來描述缺陷。為了能夠清晰地定義刻畫缺陷的屬性，本文首先建立了PhaseDC方法的總體框架，如圖1所示。缺陷一方面存在于軟件系統(tǒng)或軟件產(chǎn)品之中；另一方面又將影響著產(chǎn)品質(zhì)量和用戶的使用效果。

在軟件系統(tǒng)層面，在缺陷引入和發(fā)現(xiàn)的時候可以獲得缺陷相應(yīng)的引入階段和發(fā)現(xiàn)階段；同時也可以確定缺陷的類型及缺陷存在的表現(xiàn)形式。特定類型和表現(xiàn)形式的缺陷將改變軟件產(chǎn)品的某些質(zhì)量特性，給用戶帶來某種使用上的影響，由此體現(xiàn)為用戶層面的影響性。通過確定缺陷的引入階段和發(fā)現(xiàn)階段可以獲得各個階段以及過程的缺陷排除有效性，找到過程改進的入口，進而通過缺陷類型、表現(xiàn)形式以及影響性的詳細分布情況，幫助軟件組織深入分析過程改進的實施，從而有效地推動過程改進活動。這也正是PhaseDC方法的目的所在。

2．2度量目標

在實現(xiàn)PhaseDC方法之前，需要確定方法中缺陷的度量目標。根據(jù)缺陷可以被捕獲并分析的語義信息[1]，結(jié)合PhaseDC方法的總體框架，缺陷的度量目標主要覆蓋以下三個方面：

a)階段信息，即對一個缺陷引入和發(fā)現(xiàn)時所關(guān)聯(lián)的開發(fā)階段的確定。引入階段是指缺陷形成并進入系統(tǒng)時所處的軟件開發(fā)階段；發(fā)現(xiàn)階段是當缺陷被檢測出來時所處的開發(fā)階段。這兩類階段信息將作為PhaseDC方法中將缺陷關(guān)聯(lián)到開發(fā)階段及過程的兩個基本屬性，也是獲得開發(fā)過程中各個階段的缺陷排除有效性的必要信息。

b)形成機制，主要通過缺陷類型以及缺陷的表現(xiàn)形式來描述。這里借用ODC的思想來確定缺陷的類型，即通過描述對缺陷所作的實際修復來定義缺陷類型[4]。此外，通過刻畫缺陷被發(fā)現(xiàn)的原因來描述缺陷的形成方式，即定義每個缺陷的外在表現(xiàn)形式。在PhaseDC方法中，這兩個屬性將作為分析過程改進根源的重要依據(jù)。

c)用戶影響，即描述缺陷對使用軟件產(chǎn)品的最終用戶所產(chǎn)生的影響。為了更深入地挖掘過程改進的重點，開發(fā)出高質(zhì)量的產(chǎn)品，分析缺陷對用戶的使用影響同樣必要，這也是促進和幫助組織排除缺陷、改進過程的有效方式之一。因此，缺陷對用戶的影響性也將成為缺陷分類方法中刻畫缺陷的屬性之一。

2．3實現(xiàn)過程

可以定義完整的PhaseDC缺陷分類方法。其中包括對缺陷進行分類的屬性、每個屬性含義的描述以及屬性值的定義。與此同時，本文對缺陷類型這一屬性的屬性值提供了更詳細的語義信息，以指導軟件組織對缺陷類型進行準確的分類。

建立下面這個五元組模型來描述PhaseDC方法的分類屬性，即〈injectphase，detectphase，defecttype，defectmode，defectimpact〉。其中：injectphase和detectphase分別表示缺陷的引入階段和發(fā)現(xiàn)階段；defecttype用來定義整個軟件生命周期中產(chǎn)生的缺陷所具有的類型；defectmode標志缺陷的表現(xiàn)形式；defectimpact表示缺陷對用戶的影響性。

根據(jù)Stephen H.Kan對軟件開發(fā)階段的分析[7]，有定義如下：

定義1injectphase=detectphase={requirement，highlevel design，lowlevel design，code implementation，unit test，system test，check test}。

集合中的屬性值分別表示在產(chǎn)品交付用戶使用之前，一個完整的軟件生命周期所經(jīng)歷的主要開發(fā)階段，即需求階段、概要設(shè)計階段、詳細設(shè)計階段、編碼階段、單元測試階段、系統(tǒng)測試階段和驗收測試階段，也即缺陷可能覆蓋的引入階段和發(fā)現(xiàn)階段。其中：unit test、system test、check test可以作為測試過程的主要階段；requirement、highlevel design、lowlevel design以及code implementation對應(yīng)開發(fā)中主要的評審和檢查活動，可以看做是審查過程的主要階段。

Defecttype是定義缺陷類型的屬性，如2.2節(jié)中所述，采用ODC的思想，通過描述對缺陷所作的實際修復來確定defecttype的屬性值。這里屬性值的定義不同于正交缺陷分類方法，即需要覆蓋整個軟件開發(fā)過程中的缺陷類型。采用專家方法和正式評審的方式定義defecttype。

定義2defecttype={document description，document format，function description，logical description，standards，interface，environment，user interface，functionality，checking，algorithm，integration}。

對各個屬性值的含義描述如表1所示。

定義4defectimpact={function，performance，usability，reliability，maintenance}。

綜上所述，本文定義了PhaseDC缺陷分類方法的五個屬性及相應(yīng)的屬性值。為了指導軟件組織使用PhaseDC方法，一方面對軟件組織的開發(fā)人員和測試人員實施方法的培訓，另一方面針對各個屬性作了完整清晰的描述，如表2所示。結(jié)合表1對缺陷類型的屬性值的定義及描述，共同構(gòu)成了完整的PhaseDC缺陷分類方法。

3PhaseDC在過程改進中的應(yīng)用

SoftPM[8]是中國科學院軟件研究所開發(fā)的一個軟件過程管理工具包。本文針對其中的工具之一——軟件質(zhì)量管理平臺v2.8應(yīng)用PhaseDC方法進行缺陷的分類。該產(chǎn)品的開發(fā)覆蓋了injectphase和detectphase中定義的所有階段，從需求分析至驗收測試階段總計發(fā)現(xiàn)的缺陷數(shù)目為845個，用戶使用產(chǎn)品過程中反饋的缺陷數(shù)為21個。每當缺陷被檢測出來的時候，相應(yīng)的缺陷發(fā)現(xiàn)人員給缺陷的五個屬性賦予適當?shù)膶傩灾怠Ｓ脩衄F(xiàn)場發(fā)現(xiàn)的缺陷由指定的測試人員統(tǒng)一來分類。針對缺陷的分類結(jié)果，采用圖2的流程進行分析，以便找到實施過程改進活動的依據(jù)。

3．1 建立缺陷流模型

根據(jù)缺陷分類的結(jié)果可以得到各個階段引入和發(fā)現(xiàn)的缺陷數(shù)目，如表3所示。其中的階段名稱分別對應(yīng)injectphase和detectphase屬性中定義的階段。

根據(jù)表3中的信息可以建立圖3所示的缺陷流模型。其中:x軸表示injectphase和detectphase中定義的階段名稱；y軸對應(yīng)每個階段引入和發(fā)現(xiàn)的缺陷數(shù)目。缺陷流模型提供了軟件開發(fā)生命周期中各階段缺陷分布的基本信息，也是缺陷度量和分析工作的基礎(chǔ)。

3．2計算缺陷排除有效性

可以計算各個階段的缺陷排除有效性，以便量化地衡量每個階段清除缺陷的能力。使用的工具是缺陷源/發(fā)現(xiàn)處缺陷矩陣[7]。如圖4所示的矩陣信息，參照這個缺陷矩陣，根據(jù)缺陷排除有效性的定義就可以分別計算得到每個階段的缺陷排除有效性，以及整體審查過程的有效性、整體測試過程的有效性。圖4中行列標志的字母分別對應(yīng)injectphase和detectphase屬性中定義的階段名稱。

根據(jù)缺陷排除有效性的定義[7]，有

階段的缺陷排除有效性=當前階段排除的缺陷數(shù)/(當前階段入口處的缺陷數(shù)+當前階段注入的缺陷數(shù)）×100%

其中:當前階段排除的缺陷數(shù)即該階段發(fā)現(xiàn)的缺陷數(shù)目；當前階段入口處的缺陷數(shù)是指該階段之前的所有階段引入的缺陷總數(shù)去除了已發(fā)現(xiàn)的缺陷后得到的缺陷數(shù)目；當前階段注入的缺陷數(shù)即該階段引入的缺陷數(shù)目。根據(jù)這三部分的定義計算得到各階段的缺陷排除有效性。采用Pareto圖對各階段的缺陷排除有效性進行了比較，如圖5所示。

結(jié)合圖3缺陷流模型和圖5所示的各階段缺陷排除有效性可以看到，在項目早期的需求階段和設(shè)計階段發(fā)現(xiàn)的缺陷數(shù)目很少，并且這些階段的缺陷排除有效性的值也很低(需求審查、概要設(shè)計審查、詳細設(shè)計審查的有效性分別是15%、14．8%和12.5%)。由此表明，在該版本的產(chǎn)品開發(fā)過程中，需求審查、設(shè)計審查等過程的實施效果并不理想，并未有效地排除需求和設(shè)計階段的缺陷，而是將大多數(shù)的缺陷遺留到后期測試階段，因此需要不斷改進這些過程。

對比審查過程和測試過程的有效性：

整體審查有效性=(12+25+26+246)/866×100%=35.7%

整體測試有效性=(155+266+115)/(155+266+115+21)×100%=96.2%

可以看出，產(chǎn)品的絕大部分缺陷都在后期測試過程中發(fā)現(xiàn)。這樣一方面使得產(chǎn)品的質(zhì)量存在隱患，不能盡早地排除系統(tǒng)中的缺陷；另一方面也增加了后期修復缺陷的成本。

3．3分析缺陷類型及產(chǎn)生原因

為了對前期的評審和檢查過程加以改進，提高整體審查過程的有效性，根據(jù)缺陷分類的結(jié)果進一步深入地分析各個階段的缺陷分布情況。這里以缺陷排除有效性最低的詳細設(shè)計階段為例，分析這一階段引入的64個缺陷的具體信息。表4給出了詳細設(shè)計階段引入的缺陷的類型以及每種類型缺陷的具體表現(xiàn)形式。根據(jù)這些分類信息建立如圖6所示的缺陷類型和缺陷表現(xiàn)形式的分布圖。

從圖6中可知，在分析的這64個缺陷中，function description類型的缺陷所占的比例最大，而且絕大部分缺陷是由于詳細設(shè)計文檔或相關(guān)工作產(chǎn)品中功能描述不清晰和不一致所造成的。在詳細設(shè)計檢查的過程中，如果不能最大限度地排除這些缺陷，遺留到后續(xù)的編碼階段將帶來更多的缺陷，增加了后期缺陷檢測和排除的工作量，同時也將耗費更大的資源和成本來修復缺陷。

這一系列的分析過程為以后的詳細設(shè)計和詳細設(shè)計審查工作指明了改進的重點，即可以通過需求評審和需求培訓等活動讓設(shè)計人員及項目其他相關(guān)成員明確產(chǎn)品的需求，在設(shè)計人員對需求取得一致且清楚的認識后再進入概要設(shè)計和詳細設(shè)計階段；同時評審和檢查過程中也側(cè)重對需求清晰和一致的檢查上。

還可以采用類似的方法分析詳細設(shè)計階段中其他類型的缺陷，找到盡可能排除缺陷的原因；同時也可以建立其他階段上的缺陷類型和缺陷表現(xiàn)形式分布圖，全面完整地分析項目開發(fā)過程中的各個階段的缺陷信息，從而找到過程改進的最佳切入點。此外，PhaseDC分類方法中定義了用戶影響這一屬性，對每個缺陷產(chǎn)生的影響性也可以進行分類。由此可以建立各個階段引入的缺陷對用戶影響的分布，這也可以為軟件組織提供過程改進的信息。這里不再一一列舉。

以上是通過筆者的項目實例將PhaseDC方法應(yīng)用于過程改進活動的分析流程。通過對缺陷進行分類，分析缺陷詳細的語義信息，從而找到過程改進的著手點。缺陷分類是對缺陷數(shù)據(jù)度量和分析的基礎(chǔ)。本文提出的面向軟件開發(fā)階段的缺陷分類方法PhaseDC旨在通過缺陷來分析軟件開發(fā)過程中各個階段及整體過程的質(zhì)量，挖掘缺陷提供的信

息，進而找到過程改進的原因和依據(jù)。

4PhaseDC方法的驗證

為了獲得正確一致的缺陷分類信息，保證質(zhì)量數(shù)據(jù)的真實性和有效性，必要的前提條件是采用一個設(shè)計良好的缺陷分類方法。模糊、冗余、屬性值過多且重復的缺陷分類方法很難被用來對缺陷進行正確可靠的分類，據(jù)此得到的缺陷數(shù)據(jù)分析結(jié)果也是不可靠的。一個方便易用且真實可靠的缺陷分類方法應(yīng)具備完整性、正交性以及分類一致性等質(zhì)量特性[1]。

所謂完整性是指屬性值的完整性，所有的缺陷在各個屬性上都能夠被賦予相應(yīng)的屬性值。正交性是指同一屬性的屬性值是正交的，即對于一個特定的缺陷在一個屬性上有且僅有一個對應(yīng)的屬性值存在。本文在PhaseDC方法的設(shè)計與實現(xiàn)過程中力求遵循這兩個原則，采用問卷調(diào)查、正式評審會、專家評估等方法確定每個屬性的屬性值。在今后使用PhaseDC方法的過程中，還有待于進一步驗證該方法對于完整性和正交性的符合程度。

缺陷分類的一致性，也稱為可靠性或可重復性，是指不同的人使用同一缺陷分類方法對相同的缺陷分類后獲得的分類結(jié)果的一致程度。本文采用Eman提出的方法對PhaseDC缺陷分類方法的可重復性進行驗證[9]。從質(zhì)量管理平臺v2.8的缺陷數(shù)據(jù)中隨機抽取100個缺陷，指定兩位測試人員(tester A，tester B)對這些缺陷進行分類。這里以對缺陷類型這一屬性的分類為代表，使用Kappa系數(shù)值來判斷分類結(jié)果的一致性[10]。

表5是計算Kappa系數(shù)的矩陣表示。Class1~class12分別對應(yīng)PhaseDC缺陷分類方法中的12種缺陷類型。

可見PhaseDC方法具備較好的可重復性，即不同的人使用該方法對一組相同的缺陷進行分類，可以基本保證分類結(jié)果的一致性。采用同樣的方法對缺陷表現(xiàn)形式和影響性的分類結(jié)果計算Kappa統(tǒng)計值，也均表現(xiàn)出良好的分類一致性。

5結(jié)束語

本文提出了一種面向軟件開發(fā)階段的軟件缺陷分類方法PhaseDC，并將該方法應(yīng)用于過程改進中，為過程改進提供著手點和重要依據(jù)。該方法定義了描述缺陷的屬性及屬性值，將缺陷和軟件開發(fā)階段相關(guān)聯(lián)，通過階段的缺陷排除有效性及缺陷的詳細信息評估開發(fā)過程的質(zhì)量，并尋找過程改進的動因。PhaseDC方法具有完整、正交、可重復性較好等特性，可以幫助軟件組織有效地實施缺陷度量和分析工作，并促進軟件過程的不斷改進。

參考文獻：

［1］FREIMUT B.Developing and using defect classification schemes，IESE Report No.072.01/E［R］.Germany:Fraunhofer Epriots，2001.

［2］PUTNAM L H，MYERS W.Measures for excellence:reliable software on time，within budget［M］. New Jersey: Prentice Hall， l992.

［3］黃錫滋．軟件可靠性、安全性與質(zhì)量保證［M］.北京:電子工業(yè)出版社，2002.

［4］CHILLAREGE R，BHANDARI I，CHAAR J，et al.Orthogonal defect classification：a concept for inprocess measurements［J］.IEEE Trans on Software Engineering，1992，18(11):943－956.

［5］GRADY R. Practical software metrics for project management and process improvement［M］. New Jersey: Prentice Hall，1992.

［6］ADAM P，LARRY G，BASILI V R.Comparing detection methods for software requirements inspections:a replicated experiment［J］.IEEE Trans on Software Engineering，1995，21(6):563－575.

［7］STEPHEN H K.Metrics and models in software quality engineering［M］.[S.l.]:AddisonWesley，2003.［8］WANG Qing，LI Minshu.Software process management:practices in China［C］//Proc of Software Process Workshop.2005:317331.

［9］EMAN K，WIECZOREK I.The repeatability of code defect classification ［C］//Proc of International Symposium on Software Reliability Engineering.1998:322333.

［10］ALTMAN D.Practical statistics for medical research［M］. London: ChapmanHall， 1991.

“本文中所涉及到的圖表、注解、公式等內(nèi)容請以PDF格式閱讀原文”