導語：基于BBNs的軟件故障預測方法一文來源于網友上傳，不代表本站觀點，若需要原創文章可咨詢客服老師，歡迎參考。

摘要:本文在分析已有軟件故障預測方法后指出:論文單純從軟件開發過程的某個階段或基于幾種度量來預測軟件故障是不充分的.提出綜合利用軟件開發過程信息構建基于bbns軟件故障預測模型.本文從一個基本的貝葉斯信念網(BBNs)故障預測模型出發,擴展基本節點,得到了一個較完善的故障預測模型,結合已有的關于軟件度量的研究成果,提出利用軟件度量和專家知識確定節點狀態概率分布.仿真實驗結果表明該模型與實際情況相符合,具有一定的故障預測能力.

關鍵詞:軟件故障預測;貝葉斯信念網;軟件度量

1引言

當前關于軟件故障預測的研究大都集中于軟件工程領域的某個方面,畢業論文如面向對象系統中利用各種度量屬性建立模型預測故障數和故障傾向,利用測試過程中用例的覆蓋率預測模塊故障,利用專家經驗建立專家知識庫預測故障等等.軟件故障的原因貫穿于軟件開發全過程,僅從一個方面來考察軟件故障是不充分的.近十幾年備受關注的貝葉斯網絡(BBNs)對于解決復雜系統不確定因素引起的故障具有很大的優勢,被認為是目前不確定知識表達和推理領域最有效的理論模型.本文提出基于BBNs的故障預測方法,綜合利用軟件開發過程信息預測軟件故障.

2軟件故障預測的研究現狀

預測故障的方法可以分為兩大類:(1)基于數量的技術,關注預測軟件系統中的故障數;碩士論文(2)基于分類的技術,關注于預測哪些子系統具有故障傾向.第一類已經有一些研究,但是開發一個有效的模型比較困難.第二類方法更成功一些.利用軟件度量來預測故障傾向是一個重要的趨勢和研究內容,當前的預測模型涉及軟件設計度量,代碼度量和測試度量.軟件維護的歷史數據,例如軟件改變歷史[1]和過程質量數據[2]也被用于軟件故障預測.很多專家認為開發過程的質量是產品質量(這里默認是殘留故障密度)最好的預測器.AhmedE.Hassan等人提出利用啟發式規則預測軟件子系統故障傾向[3].還有文獻提出利用測試過程中的各種數據(如測試覆蓋率)來預測故障[2].

分析已有的故障預測模型,它們大多基于軟件開發過程中的某一個或幾個階段的數據,或者基于一種或者幾種度量,如軟件復雜性度量和測試度量.但顯而易見,影響軟件質量的關鍵因素不僅僅是其幾個度量.軟件故障與軟件開發全過程往往具有不確定的因果關聯關系,導致軟件故障的因素很多,單純從軟件開發過程的某個階段或基于幾種度量來預測軟件故障是不充分的.BBNs本身是一種不確定性因果關聯模型,具有強大的不確定性問題處理能力,能有效進行多源信息表達與融合.因此本文提出基于BBNs構建軟件故障預測模型,綜合利用軟件開發過程信息預測軟件故障.

3貝葉斯網絡

一個BBNs是一個有向無環圖,由代表變量的節點及連接這些節點的有向邊構成.節點代表隨機變量,可以是任何問題的抽象,醫學論文如問題復雜度,觀測現象,意見征詢等.節點間的有向邊代表了節點間的相互關聯關系.有向圖蘊涵了條件獨立性假設,用A(vi)表示非vi后代節點構成的任何節點集合,用∏(vi)表示vi的直接雙親節點集合,則P(vi|(A(vi)∪∏(vi)))=P(vi|∏(vi)).用條件概率表(conditionalprobabilitiestable,CPT)來描述點與點之間關聯,條件概率表可以用P(vi|∏(vi))來描述,它表達了節點同其父節點的相關關系———條件概率.沒有任何父節點的節點概率為其先驗概率.圖1用BBNs描述了一個簡單的關于軟件產品質量的例子[4],產品質量由管理能力和開發能力確定,表1為其CPT.BBNs對構造者的信念(專家知識和經驗)建模,基于這個模型它能夠提供精確的數學計算和預測.

4基于BBNs的軟件故障預測方法

將BBNs應用于軟件故障預測的步驟是:(1)確定變量及其順序;(2)建立BBNs結構;(3)確定BBNs的參數(CPT).本文從軟件開發過程來建立一個BBNs基本模型,并以此模型為基礎擴展節點.

4·1一個BBNs故障預測的基本模型

影響軟件項目風險的基本因素可分為兩組,一是與組織相關的因素,包括組織文化,管理經驗和能力以及過程成熟度.二是與項目相關的因素[4].影響軟件故障的基本因素可以描述為圖2的基本模型.方框是可以擴展的基點.“項目特征”和“驗證和確認”影響到軟件開發的需求分析,設計,實現和測試過程,軟件故障受開發過程的影響,這個模型涵蓋了軟件開發過程

4·2擴展的BBNs故障預測模型

我們用已探測的故障數,殘留故障數,職稱論文殘留故障密度和測試中故障密度四個節點來描述軟件故障,分別用“問題復雜度”,“設計功效”和“測試功效”節點描述需求分析,設計和測試過程.V&V[4]與問題復雜度,設計功效和測試功效三個變量關系緊密,因此本文去掉V&V節點,將這些描述V&V節點的變量(如測試覆蓋率,員工能力等)用來確定問題復雜度,設計功效和測試功效的參數.

本文采用如圖3所示的BBNs故障預測模型,這個模型可以解釋為兩個階段:第一個階段覆蓋了軟件生命周期的規約,設計和編碼;第二個階段覆蓋了測試.設計規模和缺陷數節點為整數或者一個限定的范圍,故障密度為實數,其他節點有下面的狀態:很高,高,中等,低,很低.問題復雜度表示待開發問題集中內在的復雜度,這些問題是規約中離散的功能需求,問題復雜度和設計功效之間的不匹配將導致引入故障數和設計規模增大.測試階段在設計階段之后,實踐中實際分配的測試功效比所要求的少得多.測試功效和設計規模之間的不匹配將會影響已探測故障的數目,引入故障是其邊界條件.已探測故障和引入故障之差是殘留故障數.測試中故障密度是已探測故障和設計規模的函數(已探測故障/設計規模),同樣,殘留故障密度是殘留故障數/設計規模.這里的問題復雜度,設計功效和測試功效的粒度仍然較大,不利于確定其狀態,將其繼續擴展,建立相應子網來描述這些節點:(1)問題復雜度子網(圖4);(2)設計功效子網(圖5);(3)測試功效子網(圖6).

4·3確定BBNs參數

接下來的問題是確定變量狀態的概率和變量之間關系的強度.從對軟件開發過程的各種文檔記錄中我們可以得到一些確定性知識.對于不確定性知識,傳統的方法是根據專家經驗主觀確定.研究人員定義了大量軟件度量描述軟件質量[2,5,6],將這些研究與專家知識和經驗結合起來確定BBNs參數.

4·4推理規則

采用應用最廣的隨機模擬采樣法(PearlsandGibbs算法).首先,為網絡上的節點做初始實例化,證據節點實例化為觀察值,非證據節點實例化為隨機值;然后,開始遍歷圖,對每一非證據節點Y,計算在其他節點給定值的情況下Y的后驗概率分布:

P(Y|WY)=αP(Y|Pa(Y))∏iP(si|Pa(si))

式中,WY表示除Y的節點集合,Si表示Y的第i個子女,工作總結為正規化因子,其余乘積項為條件概率.公式表明了本節點的概率僅與其父母節點,子節點及其子節點的父母節點有關;Pearl使用上式結果對節點進行采樣,結果作為Y的新實例化,反復進行,直到近似過程收斂(設進行了m次遍歷),這時查詢結果為:P(Y|e)=1m∑mi=1fi,fi為第i次遍歷Y的條件概率,e為證據向量的觀察值.

5仿真實驗

本文在AgenaRisk[7]系統中對該模型進行仿真實驗.實驗部分采用了AgenaRisk中關于軟件故障預測和軟件項目風險管理的數據.由于具體的項目數據難以收集,我們根據圖3所描述的簡化模型來做仿真實驗.在實驗中我們用軟件需求復雜性度量和軟件需求變更度量來描述問題復雜度[6].利用各種度量來描述設計功效,包括對象(模塊)之間的耦合數(耦合度量),不使用公共屬性的方法的個數(內聚度量),繼承樹的深度和繼承的平均深度(繼承度量)[5].用代碼覆蓋度量來描述測試功效,定義一個相應策略的測試有效率(testeffective-nessratio,TER),TER1是語句覆蓋的測試有效率,TER2是分支覆蓋的測試有效率,TER3是線性代碼順序和跳轉覆蓋測試有效率.我們設定的是一個中等規模的系統,嚴格按照軟件工程開發過程開發,花費了大量資源在設計和測試上,盡量減少耦合,增加內聚,TER1,TER2達到100%,TER3達到90%,因此可以判定設計功效為很高(概率為100%),測試功效很高(概率為100%),如圖7所示.從仿真結果可以看到設計規模較小,引入故障數較少(期望值為17.8),已探測故障密度相對較高,剩余故障數較小(期望值為6.6),這與實際情況是相符合的.當我們將設計功效設置為較低時(概率為100%),如圖8所示,明顯設計規模變大,引入故障數增加(期望值為43.1),相應的剩余故障數增加(期望值13.0),已探測故障密度減少.表2是兩者的對比結果.在實驗中我們分別對問題復雜度,測試功效和設計功效賦值,以檢查模型對各種環境下的變化,其結果與實際較為符合,說明了模型的合理性.

6結語

本文從軟件開發全生命周期來考察故障,給出了一個BBNs故障預測原型系統,并在AgenaRisk系統中對該模型進行仿真實驗.從實驗結果可以看到,BBNs能夠使用來自主觀和客觀的概率分布和不充分的數據預測軟件故障數.仿真實驗還只是基于一個簡化的模型,將實際項目數據應用于模型,探討建立完備網絡結構和確定節點狀態的方法,建立適應具體項目便于數據收集和確定節點狀態的網絡是需要進一步探討的問題.

參考文獻:

[1]ToddLGraves,AlanFKarr,JSMarron,HarveySiy.Predict-ingfaultincidenceusingsoftwarechangehistory[J].IEEETransactionsonSoftwareEngineering,2000,26(7):653-661.

[2]Fenton,NE,NeilM.Acritiqueofsoftwaredefectpredictionmodels[J].IEEETransactionsonSoftwareEngineering,1999,25(5):675-689.

[3]AhmedEHassan,RichardCHolt.Thetoptenlist:dynamicfaultprediction[A].Proceedingsofthe21stIEEEInternationalConferenceonSoftwareMaintenance(ICSM’2005)[C].Bu-dapest,Hungary:IEEE,2005.263-272.

[4]Chin-FengFan,Yuan-ChangYu.BBN-basedsoftwareprojectriskmanagement[J].JournalofSystemsandSoftware,2004,73(2):193-203.

[5]MunsonJC,NikoraAP.Towardaquantifiabledefinitionofsoftwarefaults[A].Proceedingsof13thInternationalSympo-siumonSoftwareReliabilityEngineering(ISSRE2002)[C].Annapolis,MD,USA:IEEE,2002.388-395.

[6]王青,李明樹.基于SPC的軟件需求度量方法[J].計算機學報,2003,26(10):1312-1317.WangQing,LIMing-Shu.MeasurementofSoftwareRequire-mentBasedonSPC[J].ChineseJournalofComputers,2003,26(10):1312-1317.(inChinese)

[7]AgenaRisk.[EB/OL].2005/2006-7-15.