雷 挺

（中國電子科技集團公司第十五研究所，北京100083）

0 引 言

近年來，由于大量的缺陷給軟件企業(yè)帶來了大量維護費用，軟件測試技術(shù)越來越受到重視，不少企業(yè)相繼對研發(fā)資質(zhì)進行了提升，引入能力成熟度模型集成（capability maturity model integration，CMMI），研發(fā)缺陷管理和跟蹤系統(tǒng)，將缺陷分析和預(yù)測的功能逐步融入到缺陷管理系統(tǒng)中，缺陷預(yù)防也開始受到關(guān)注，現(xiàn)有的缺陷預(yù)防方法有FMEA（故障模式和效果分析）、FTA（故障樹分析）、防御性編程、軟件易測試性設(shè)計等，但是目前還沒有一個能夠綜合缺陷分析和缺陷預(yù)測的成熟技術(shù)，針對不同的生命周期進行有效的分析和提前預(yù)防，為了解決以上問題，本文將缺陷預(yù)測技術(shù)與改進的正交缺陷分類方法相結(jié)合，提出了一套缺陷預(yù)防流程，并用實際項目進行對比實驗，驗證該流程的有效性。

1 缺陷預(yù)防的概念及意義

缺陷預(yù)防（defect prevention）是在軟件缺陷沒有出現(xiàn)時，就采取積極有效的預(yù)防措施，把缺陷消滅在萌芽狀態(tài)的一種技術(shù)［1］。

美國質(zhì)量保證研究所對軟件測試的研究結(jié)果表明，在開發(fā)過程后期發(fā)現(xiàn)問題的成本是非常高的。補救成本會隨著開發(fā)周期的進展而大幅上升，這是因為需要修改設(shè)計與編碼，需要重新進行測試以及考慮對其他相關(guān)模塊的影響［2］。行業(yè)研究已經(jīng)表明，如果在設(shè)計時修正一個缺陷的成本是1x，那么在軟件發(fā)布之后進行修正的成本將是100x［3］。

為了避免質(zhì)量低下所帶來的巨大成本，最佳選擇是在缺陷預(yù)防方面進行投入。如果開發(fā)團隊能夠在上游階段預(yù)防缺陷，而不是在后期發(fā)現(xiàn)和修正缺陷，那么設(shè)計人員、開發(fā)人員和其他相關(guān)人員等都將從中受益［4］。

2 常用的缺陷預(yù)測方法

缺陷預(yù)測是預(yù)防的基礎(chǔ)，準確預(yù)測才能集中有限的資源對缺陷進行針對性預(yù)防。按照預(yù)測技術(shù)的不同，缺陷預(yù)測方法可以分為類比法、Delphi估算法、數(shù)學預(yù)測模型法三大類方法，但是因為前兩種方法有著無法克服的局限性，目前軟件缺陷預(yù)測領(lǐng)域的研究工作大部分是集中在數(shù)學預(yù)測模型法方面。

常見數(shù)學預(yù)測模型方法有：線性判別分析（linear discriminant analysis，LDA），布爾判別函數(shù)（boolean discriminant function，BDF），貝葉斯網(wǎng)絡(luò)（bayesian network，BN），分 類 回 歸 樹（classification and regression tree，CART），優(yōu)化集精簡（optimized set reduce，OSR），聚類分析（clustering analysis，CA），支持向量機（support vector machine，SVM），人工神經(jīng)網(wǎng)絡(luò)（artificial neural network，ANN），平均單一相關(guān)評估器（average one－dependence estimators，AODE）［5］等。各種預(yù)測方法有著不同的適應(yīng)面，可以解決不同的問題，也有各自的局限［6］。它們的詳細比較結(jié)果見表1。

表1 缺陷預(yù)測方法的比較

迄今為止，國內(nèi)外有100多種缺陷預(yù)測模型發(fā)表在各種專業(yè)刊物和學術(shù)會議上，但大多數(shù)模型并沒有得到充分的項目數(shù)據(jù)的支撐和驗證，其有效性和準確性得不到有力地證明，因而未能廣泛應(yīng)用。

3 缺陷預(yù)測模型的優(yōu)化

作者所在的組織多年來致力于缺陷預(yù)測的研究，積累了大量缺陷數(shù)據(jù)，在此基礎(chǔ)上建立了multi－AODE缺陷預(yù)測模型。

假設(shè)F（Xi）表示包含屬性Xj的樣本數(shù)，屬性Xj、Y均依賴于屬性Xi，m表示m－估計量，AODE方法的原理可用下列公式表達［7］

通過一對多方法可以實現(xiàn)multi－AODE分類器，即組合多個AODE二值分類器來實現(xiàn)多值分類。使用multi－AODE預(yù)測模型進行缺陷預(yù)測的過程如圖1所示。

向該模型輸入軟件生命周期中的各個階段的度量數(shù)據(jù)，應(yīng)用離散化、再抽樣等數(shù)據(jù)預(yù)處理技術(shù)，并通過multi－AODE分類器進行預(yù)測運算，輸出各階段注入和遺留缺陷密度等級的預(yù)測值。如果預(yù)測出的注入和遺留缺陷密度值較小，則意味著質(zhì)量的前景是樂觀的；反之，則意味著需要改進過程，增加對質(zhì)量控制的關(guān)注。

按照覆蓋域盡可能廣的原則，從歷史項目中挑選了83個軟件項目（其中包括36個大型項目，47個中小型項目），使用不同模型進行缺陷預(yù)測，結(jié)果見表2。

圖1 使用multi－AODE預(yù)測模型進行缺陷預(yù)測的過程

表2 不同缺陷預(yù)測模型的預(yù)測結(jié)果比較

從表2不難看出，同其他預(yù)測模型相比，multi－AODE預(yù)測模型有著更好的預(yù)測結(jié)果，但仍有較大的提升空間，為進一步提高其預(yù)測的準確性，作者根據(jù)多年項目經(jīng)驗，對該模型做了如下優(yōu)化。

（1）增加度量元個數(shù)：遵循度量元可理解、易估計、與缺陷相關(guān)度高的原則，將原預(yù)測模型的度量元個數(shù)從21個增加至28個（去掉其中的10個并新增17個），同時細化度量標準，將度量元取值從3至6級擴展至9級，以提高預(yù)測的準確性。約定度量元分級如下：A、B、C、D、E分別取1、3、5、7、9級，介于A、B、C、D、E的中間值分別取2、4、6、8級。需要說明的是：

1）提取所有相關(guān)度量元并不能提高預(yù)測的準確性，甚至會適得其反。應(yīng)從度量目標出發(fā)，確定適當?shù)亩攘吭?/p>

2）“開發(fā)過程的度量元”是指在生命周期的每個階段都會影響軟件質(zhì)量的度量元，由于每個階段都可能采取預(yù)防措施，所以下一個階段數(shù)據(jù)采集時應(yīng)當更新 “開發(fā)過程的度量元”的取值，并且其權(quán)重高于另外3個階段的度量元。

（2）控制度量數(shù)據(jù)的采集：將軟件生命周期中的各個階段的度量數(shù)據(jù)采集環(huán)節(jié)集成到了本組織的Gems項目管理工具中，該工具根據(jù)項目進度及時提醒相關(guān)人員及時填寫各個階段度量數(shù)據(jù)，若忘記填寫，工具將給出提示信息，這一設(shè)計保證數(shù)據(jù)采集的及時性和有效性，避免了 “垃圾進，垃圾出”的度量。

（3）調(diào)整1類／2類錯誤率：1類錯誤是指將低風險模塊錯誤地預(yù)測為高風險模塊。2類錯誤是指將高風險模塊錯誤地預(yù)測為低風險模塊。毋庸置疑，這兩類錯誤會帶來不同的損失，通過調(diào)整度量元的數(shù)目、權(quán)重、度量標準和取值范圍，實現(xiàn)對可能帶來風險的度量值的放大，犧牲1類錯誤率來保證較低的2類錯誤率，以滿足軍工及科研領(lǐng)域的特殊需要［8］。

使用優(yōu)化后的預(yù)測模型對相同的83個歷史項目進行預(yù)測，實驗結(jié)果見表3。

表3 模型改進前后的預(yù)測結(jié)果比較

分析表3可知，盡管優(yōu)化后的訓練時間略有增加，但是預(yù)測值的準確性（平均、最好、最壞）和一致性（Kappa statistic統(tǒng)計值）都有了較大的提高。以每個項目預(yù)測值的準確率作為數(shù)據(jù)樣本，計算方差和熵，更小的方差和熵意味著優(yōu)化后的預(yù)測模型有著更好的穩(wěn)定性和更小的不確定性，此外，優(yōu)化后的預(yù)測模型在1類／2類錯誤率的調(diào)整上也具有更大的靈活性。

盡管優(yōu)化后的預(yù)測模型在預(yù)測效果上有顯著的提升，但其預(yù)測結(jié)果仍不足以具體指導(dǎo)組織或項目進行缺陷預(yù)防，為解決這一問題，引入正交缺陷分類（orthogonal defect classification，ODC）方法，并結(jié)合組織的實際情況對該方法進行了改進，使用改進的ODC方法對缺陷進行分類，同時分析缺陷原因，通過對大量缺陷數(shù)據(jù)的分析，找出導(dǎo)致軟件缺陷的共性原因，有針對性地進行預(yù)防。

4 改進的ODC：基于缺陷分類的定量分析方法

表4比較了兩類缺陷原因分析方法，顯然，基于缺陷分類的定量分析方法在缺陷預(yù)防上有著巨大的優(yōu)勢。

表4 基于RCA的定性分析方法和基于缺陷分類的定量分析方法

正交缺陷分類（orthogonal defect classification，ODC）是IBM公司提出的缺陷分類方法［9］。該分類方法定義了缺陷特征的8個屬性，用來描述缺陷特征，這些屬性對應(yīng)著缺陷的發(fā)現(xiàn)和修復(fù)兩類特定活動。當一個測試人員發(fā)現(xiàn)并提交一個缺陷時，給這個缺陷分配 “Activity（測試活動）”、 “Trigger（缺陷觸發(fā)）”、 “Impact（缺陷影響）”屬性，稱為Opener（發(fā)現(xiàn)者屬性）。當一個開發(fā)人員修復(fù)或者回應(yīng)了一個缺陷時，可以分配 “Age（歷史版本）”、“Source（缺陷來源）”、 “Type（缺陷類型）”、 “Qualifier（類型進一步限定）”以及 “Target（缺陷載體）”，這些屬性被稱為解決者屬性（Closer）。

在打開和關(guān)閉軟件缺陷時運用ODC方法記錄缺陷的相應(yīng)屬性值，分析這些信息可以確定缺陷原因，進行錯誤跟蹤，追溯到缺陷的引入階段，反映出軟件的設(shè)計、代碼質(zhì)量等各方面的問題，提供改進線索。此外，還可以從缺陷記錄中獲取大量有價值的語義信息，作為量化評估依據(jù)，并為缺陷預(yù)防提供數(shù)據(jù)支持。

結(jié)合缺陷預(yù)防的要求，對ODC方法的改進如下：在已有的8個屬性的基礎(chǔ)上，擴展 “Target”、 “Type”屬性的取值，仍保持其正交性，同時增加 “Defect Cause（缺陷原因）”和 “Measure（預(yù)防措施）”兩個屬性。改進的ODC方法如圖2所示。

使用改進的ODC方法對歷史數(shù)據(jù)進行缺陷原因分析的流程如下。

（1）發(fā)現(xiàn)并提交一個缺陷時，在正交化分類的缺陷數(shù)據(jù)集（defect data set，以下簡稱缺陷數(shù)據(jù)集）中記錄 “Activity”、“Trigger”、“Impact”這3個屬性值；

圖2 改進的ODC方法

（2）修復(fù)或者回應(yīng)一個缺陷時，在缺陷數(shù)據(jù)集中記錄“Age”、 “Source”、 “Qualifier”、 “Type”以及 “Target”5個屬性值，同時記錄修復(fù)缺陷所采取的糾正措施、修復(fù)效果；

（3）結(jié)合（1）、（2）進行缺陷跟蹤，追溯到缺陷的引入階段，分析并確定可能的缺陷原因，并結(jié)合修復(fù)措施和修復(fù)效果以及專家經(jīng)驗（如果有相關(guān)記錄的話）進行缺陷預(yù)防的措施分析，同時記錄 “Defect Cause”和 “Measure”屬性；

（4）對大量缺陷數(shù)據(jù)重復(fù)上述步驟，得到一個相對全面的缺陷數(shù)據(jù)集，它記錄了大量缺陷的可能原因及相應(yīng)預(yù)防措施，從中找出導(dǎo)致軟件缺陷的共性原因和相應(yīng)的預(yù)防措施，按需求、設(shè)計、編碼3個階段進行分類。將該數(shù)據(jù)集應(yīng)用于新的項目中，可以在項目的需求、設(shè)計、編碼階段輔助進行缺陷原因分析（Assist DCA）并指導(dǎo)缺陷預(yù)防（Guide DP）。

仍以前述83個歷史項目為分析對象，用改進的ODC方法隊83個項目中的缺陷逐個進行缺陷原因分析，得到一個相對完備的缺陷數(shù)據(jù)集，下文簡稱 《缺陷屬性數(shù)據(jù)集》。實踐證明，該數(shù)據(jù)集能夠為未來新項目提供有力的數(shù)據(jù)支持。

5 基于缺陷分類和缺陷預(yù)測的缺陷預(yù)防流程

將缺陷預(yù)測與改進的正交缺陷分類方法結(jié)合起來，形成了一套完整的軟件缺陷預(yù)防流程。

（1）通過改進后的multi－AODE預(yù)測模型，將生命周期某個階段的度量信息及開發(fā)過程的度量信息輸入預(yù)測模型，計算出該階段的缺陷密度等級。若預(yù)測的缺陷密度等級較低，意味著質(zhì)量的前景很樂觀，本階段無需額外增加缺陷預(yù)防投入，可以將資源投入到生命周期的下一個階段的缺陷預(yù)防上，實現(xiàn)資源的合理配置；反之，意味著應(yīng)額外進行質(zhì)量控制，并增加在該階段缺陷預(yù)防方面的投入。

（2）查找 《缺陷屬性數(shù)據(jù)集》，獲取該階段引入缺陷的共性原因及對應(yīng)的預(yù)防措施；

（3）根據(jù)項目質(zhì)量要求，使用改進的ODC方法分析風險等級高的度量元，例如分析取值在5級以上的度量元，進一步補充缺陷原因和預(yù)防措施。

（4）結(jié)合項目實際情況，對缺陷原因及相應(yīng)預(yù)防措施進行補充和篩選，針對性地進行缺陷預(yù)防，降低缺陷密度。

基于改進的AODE預(yù)測模型及改進ODC方法的缺陷預(yù)防流程如圖3所示（注：缺陷預(yù)防不必考慮系統(tǒng)測試階段，圖1中預(yù)測的是注入或遺留的缺陷，故需要考慮系統(tǒng)測試階段）

圖3 基于改進的AODE預(yù)測模型及改進ODC方法的缺陷預(yù)防流程

使用該流程應(yīng)注意以下幾點。

（1）對于有特殊要求的項目，可以通過調(diào)整改進的multi－AODE預(yù)測模型的度量元的數(shù)目、權(quán)重、度量標準和取值范圍，實現(xiàn)對可能帶來風險的度量值的放大，犧牲1類錯誤率來保證較低的2類錯誤率；

（2）運用改進ODC分析可能的缺陷原因并獲取預(yù)防措施時，不能局限于缺陷數(shù)據(jù)集中現(xiàn)有的經(jīng)驗數(shù)據(jù)，需重視對度量元的分析，并且充分考慮項目的實際情況，實現(xiàn)對缺陷原因和獲取預(yù)防措施進行篩選和補充，以增加預(yù)防的針對性，節(jié)省項目成本；

6 實驗驗證與分析

選擇某項目中業(yè)務(wù)邏輯和軟件規(guī)模相似的兩個子系統(tǒng)：A系統(tǒng)和B系統(tǒng)作對比實驗，說明如何使用改進的AODE預(yù)測模型及改進ODC方法進行缺陷預(yù)防，以驗上述缺陷預(yù)防流程的效果。

其中B系統(tǒng)作為實驗組，按圖3所示流程進行缺陷預(yù)防；A系統(tǒng)作為對照組，不采取預(yù)防措施，按原有流程進行開發(fā)。

（1）對B系統(tǒng)的設(shè)計階段進行預(yù)測，“開發(fā)過程度量”、“需求度量”、“設(shè)計度量”的數(shù)據(jù)采集結(jié)果如下。

1）開發(fā)過程度量

＠attribute CMMI｛3｝ %項目過程能力成熟度

＠attribute qualityControl｛4｝ %質(zhì)量控制的有效性

＠attribute attitude｛6｝ %人員工作熱情及態(tài)度

＠attribute communication｛4｝ %人員交流溝通有效性

＠attribute complexity｛3｝ %產(chǎn)品業(yè)務(wù)邏輯的復(fù)雜性

＠attribute experience｛3｝ %開發(fā)團隊的經(jīng)驗水平

＠attribute staffStability｛1｝ %人員的連續(xù)性

2）需求度量

＠attribute requirementBreakdown｛3｝ %需求分解的正確性

＠attribute requirementReview｛3｝ %需求評審的充分度

＠attribute requirementStability｛5｝ %需求穩(wěn)定性

＠attribute requirementDetailed Degree｛2｝ %需求粒度

＠attribute userParticipation｛3｝ %用戶的參與程度

＠attribute userExpressiveness｛4｝ %用戶對需求的表達能力

＠attribute domainKnowledge｛4｝ %用戶的應(yīng)用領(lǐng)域經(jīng)驗

3）設(shè)計度量

＠attribute designStandardability｛7｝ %設(shè)計過程的規(guī)范性

＠attribute designerParticipation｛6｝ %設(shè)計人員在早期的參與程度

＠attribute requirementAcknowledge｛4｝ %設(shè)計人員對需求的理解

＠attribute codeKnowledge｛5｝ %設(shè)計人員對編碼技術(shù)的了解

＠attribute moduleComplexity｛3｝ %軟件模塊的復(fù)雜度

＠attribute designDetailed Degree｛3｝ %設(shè)計粒度

＠attribute designReview｛5｝ %設(shè)計評審

輸入上述度量數(shù)據(jù)，使用預(yù)測模型進行運算，輸出＠attribute requirementDefect｛［1.05，1.125）｝，預(yù)測結(jié)果表明設(shè)計階段的缺陷密度等級較高，可采取針對性預(yù)防措施，以降低缺陷密度。

（2）從 《缺陷屬性數(shù)據(jù)集》中獲取設(shè)計階段引入缺陷的共性原因及對應(yīng)的預(yù)防措施；

（3）使用改進的ODC方法分析取值在5級以上的度量元，進一步補充缺陷原因和預(yù)防措施。

（4）對缺陷原因及相應(yīng)預(yù)防措施進行補充和篩選，分析項目實際情況，去掉預(yù)防措施。

1）重視工作效率，避免過度加班；

2）明確設(shè)計標準與規(guī)范；

3）防范內(nèi)部攻擊；

考慮到本項目涉及到裝備管理方面的業(yè)務(wù)知識和相關(guān)規(guī)則，增加預(yù)防措施。

（1）對設(shè)計人員進行業(yè)務(wù)知識及業(yè)務(wù)規(guī)則培訓；

（2）加強編碼人員和設(shè)計人員間的溝通，使他們對控制／邏輯流程的設(shè)計思路有更好的理解；

若實踐證明有效，應(yīng)及時將這兩個預(yù)防措施加入缺陷數(shù)據(jù)集中，并作正交化分類，豐富和完善缺陷數(shù)據(jù)集。

綜合上述3個方面，得到設(shè)計階段應(yīng)采取的缺陷預(yù)防措施如下。

（1）規(guī)范流程、加強管理；

（2）培養(yǎng)員工的良好的工作態(tài)度及責任意識

（3）培養(yǎng)良好的工作氛圍；

（4）加強風險分析；

（5）控制需求文檔版本，避免頻繁變更；

（6）加強設(shè)計分析人員內(nèi)部的溝通以及與需求人員間的溝通，讓設(shè)計人員及早參與到項目中；

（7）嚴格的設(shè)計評審；

（8）充分考慮軟件運行平臺和軟件的可移植性；

（9）考慮軟件內(nèi)部模塊間的兼容及前后版本間的兼容；

（10）記錄系統(tǒng)日志便于問題的分析跟蹤；

（11）考慮安全性與易用性或功能的折中；

（12）事先考慮可能發(fā)生的異常，做好相應(yīng)的安全處理；

（13）對設(shè)計人員進行業(yè)務(wù)知識及業(yè)務(wù)規(guī)則培訓；

（14）加強編碼人員和設(shè)計人員間的溝通，使他們對控制／邏輯流程的設(shè)計思路有更好的理解。

由于需求分析階段、編碼階段的缺陷預(yù)防流程與上述過程相似，限于篇幅，這里不一一列舉。實驗組B系統(tǒng)和對照組A系統(tǒng)各階段檢測出的缺陷數(shù)對比如圖4所示。

圖4 實驗組B系統(tǒng)和對照組A系統(tǒng)各階段檢測出的缺陷數(shù)對比

從圖4可以看出，由于采用了缺陷預(yù)防措施，相比A系統(tǒng)，B系統(tǒng)各個階段引入的缺陷數(shù)均大為減少：需求分析階段的缺陷減少了21%，架構(gòu)設(shè)計階段的缺陷減少了18%，編碼實現(xiàn)階段的缺陷減少了29%。此外，由于在上游階段減少了大量缺陷，實驗組的開發(fā)周期比對照組縮短了23%。這一結(jié)果證明本文所提出的軟件缺陷預(yù)防流程的可行性和有效性。

7 結(jié)束語

本文提出了一套完整的軟件缺陷預(yù)防流程：將生命周期某個階段的度量信息及開發(fā)過程的度量信息輸入預(yù)測模型，計算出該階段的缺陷密度等級，根據(jù)缺陷密度等級確定在缺陷預(yù)防上的投入力度，并使用改進的ODC方法分析該階段引入或遺留缺陷的根本原因，針對根本原因分析可行預(yù)防措施，從而有針對性地進行缺陷預(yù)防，在減少軟件缺陷的同時還能夠節(jié)省成本、縮短項目周期［11］。

本文在解決實際項目問題的同時，也是將缺陷預(yù)測和改進ODC方法運用在缺陷預(yù)防領(lǐng)域的一次嘗試。雖然經(jīng)過了實際項目的驗證，本文提出的軟件缺陷預(yù)防流程仍需在實際運用中不斷收集反饋意見，并加以改進完善。下一步將對缺陷預(yù)測模型做更深入的研究，根據(jù)項目特征，對不同的項目采用不同的預(yù)測模型，實現(xiàn)預(yù)測準確性的最優(yōu)化。此外，繼續(xù)收集各種類型的項目缺陷數(shù)據(jù)，獲得更加全面的缺陷數(shù)據(jù)集以提高缺陷預(yù)防的有效性和準確性?？梢灶A(yù)見，隨著本文提出的缺陷預(yù)防流程在實際項目中的不斷應(yīng)用與改進，缺陷數(shù)據(jù)集與預(yù)測模型會日益豐富與完善，預(yù)防效果也會越來越好。

［1］Chang Ching－Pao，Chu Pchih－Ping.Defect prevention in software processes：an action－based approach［J］.Journal of Systems and Software，2007，80（4）：1－27.

［2］James McCurley，Dennis R Goldenson.Performance effects of measurement and analysis：perspectives from CMMI high maturity organizations and appraisers［M］.Software Engineering Measurement and Analysis，2010：45－55.

［3］Lee Shufang，Bai Xiaoying，Chen Yinong.Automatic mutation testing and simulation on OWL－S specified web services［C］／／IEEE Computer Society 41st Annual Simulation Symposium，2008：149－156.

［4］Marc McDonald，Robert Musson，RossSmith.The practical guide to defect prevention［M］.Microsoft Press，2007：1－78.

［5］WANG Qing，WU Shujian，LI Mingshu.Software defect prediction［J］.Journal of Software，2008，19（7）：1566－1577（in Chinese）.［王青，伍書劍，李明樹.軟件缺陷預(yù)測技術(shù)［J］.軟件學報，2008，19（7）：1566－1577.］

［6］Fenton NE，Martin N，William M，et al.Project data incorpora－ting qualitative facts for improved software defect prediction［C］／／Proc of the 3rd Int＇l Workshop on Predictor Models in Software Engineering.Washington，DC：IEEE Computer Society，2007：11－20.

［7］ZHOU Feng，MA Li.Software defect prediction model based on AODE and resampling［J］.Computer Engineering and Design，2011，32（1）：210－212（in Chinese）.［周豐，馬力.基于AODE和再抽樣的軟件缺陷預(yù)測模型［J］.計算機工程與設(shè)計，2011，32（1）：210－212］

［8］Van der Walt C，Etienne Barnard.Data characteristics that determine classifier performance［J］.SAIEE Africa Research Journal，2007，98（3）：87－93.

［9］YIN Xiangle，MA li，GUAN Xin.Research of software defects classification［J］.Computer Engineering and Design，2008，29（19）：4910－4912（in Chinese）［尹相樂，馬力，關(guān)昕.軟件缺陷分類的研究［J］.計算機工程與設(shè)計，2008，29（19）：4910－4912］

［10］Robert W Stoddard II，Dennis R.Goldenson.Approaches to process performance modeling：A summary from the sei series of workshops on CMMI high maturity measurement and analysis［M］.Software Engineering Institute，Carnegie Mellon University，2010：15－42.

［11］Dennis R Goldenson，James McCurley，Robert W Stoddard II.Use and organizational effects of measurement and analysis in high maturity organizations：Results from the 2008SEI state of measurement and analysis practice surveys［M］.Software Engineering Institute，Carnegie Mellon University，2009：23－61.