軟件失效的相關概念
一、軟件失效機理
由于軟件內部邏輯復雜,運行環(huán)境動態(tài)變化,并且不同的軟件可能差異很大,因而軟件失效機理可能有不同的表現(xiàn)形式。例如,有的失效過程比較簡單,易于跟蹤分析;有的失效過程可能非常復雜,難于甚至不可能進行詳盡地描述和分析。因此,對于軟件的失效機理及有關軟件失效的基本概念,目前尚無統(tǒng)一的認識和定義。
為了避免在使用術語時造成歧義,首先應明確缺陷(Defect)、故障(Fault)、隱錯或臭蟲(Bug)、錯誤(Error)、失效(Failure)等近義詞匯的含義。
1.軟件故障和缺陷、隱錯或臭蟲
軟件故障和缺陷、隱錯或臭蟲是同義詞,是存在于軟件(包括說明文檔、應用數(shù)據(jù)、程序代碼等)之中的那些不期望的或不可接受的偏差。軟件故障靜態(tài)地存在于軟件內部,是軟件開發(fā)過程中人為錯誤的結果。例如缺少一個逗號、多一條語句等等。其后果是當軟件運行于某一特定條件時將導致軟件失效。
軟件故障具有下列一些特征:
1)軟件故障的固有性
軟件故障主要源于人的失誤和水平、能力的局限性。一旦軟件開發(fā)結束后交付給用戶,如果存在軟件故障,那么它將一直潛伏于軟件之中直到被發(fā)現(xiàn)或被修改。
2)軟件故障對環(huán)境的敏感性
所謂環(huán)境,是指軟件的運行環(huán)境(包括軟硬件平臺、軟硬件配置和其他支撐軟件)和輸入環(huán)境(如應用對象、用戶要求、輸入數(shù)據(jù)等)。在大多數(shù)情況下,一個程序的運行,并不一定遍歷程序的所有部分。程序中的各個部分可做多種不同的邏輯組合,形成不同的執(zhí)行路徑,從而實現(xiàn)不同的功能。而這些組合取決于輸入環(huán)境,輸入環(huán)境的改變決定了程序內部路徑的重新組合。如果程序中有故障,并且程序的執(zhí)行路徑經(jīng)過了故障點,那么必然會引起錯誤;如果程序的執(zhí)行路徑?jīng)]有經(jīng)過故障點,則不會引起錯誤;而對在一定輸入環(huán)境下執(zhí)行出錯的程序,當退出該環(huán)境后,對于其他環(huán)境又可能正常執(zhí)行,但當再次進入該環(huán)境時,程序又會出錯。可見,軟件故障對輸入環(huán)境十分敏感。至于軟件故障對運行環(huán)境的敏感性則更容易理解。一般在某一運行環(huán)境下開發(fā)和正常執(zhí)行的程序,改換到另一運行環(huán)境下去執(zhí)行,就會表現(xiàn)出許多的軟件錯誤。
3)軟件故障的傳染性
軟件一旦出錯,如果不對軟件故障進行糾正,那么其錯誤結果作為后續(xù)邏輯路徑的輸入必然使得運行結果不是程序本身所期望的合理結果,從而故障可能會一直存在并影響其他位置而發(fā)生錯誤,最終造成系統(tǒng)失效的后果。例如一個子程序的故障,通過子程序的調用可能傳染調用者,通過進程間的通信,還可能傳染更多其他的進程。
2.軟件錯誤
軟件錯誤是指系統(tǒng)運行時,引起或可能潛在的引起系統(tǒng)失效的軟件故障。在大多數(shù)情況下,錯誤可被檢測并排除,但是在某些情況下,仍然會有部分錯誤隱藏于軟件內部之中。
軟件錯誤和軟件故障具有相同或十分近似的含義,在GB/T11457-89“軟件工程術語”中沒有刻意對這兩個詞加以區(qū)別。軟件故障并非就一定會使軟件出錯,它只有在特定的條件下才會導致軟件錯誤,在一般的情況下,軟件仍然能夠正常運行。
3.軟件失效
軟件失效是泛指程序在運行中喪失了全部或部分功能、出現(xiàn)偏離預期的正常狀態(tài)的事件。預期的正常狀態(tài)應以用戶的需求為依據(jù)。
可見,軟件錯誤是相對于軟件而言的,是一種面向開發(fā)的概念,而軟件失效則是一種面向用戶的概念。一個錯誤在在沒有被排除的情況下,可以使軟件發(fā)生多次失效。相同的失效現(xiàn)象,可能由不同的錯誤所造成。
綜上所述,軟件失效機理可以概述為三個不同層次概念的因果關系。軟件故障可以導致軟件錯誤并最終造成系統(tǒng)的失效,因而軟件故障是一切系統(tǒng)失效的根源。
二、軟件失效的軟劃分
系統(tǒng)處于不同狀態(tài)時,可能會發(fā)生多種不同類型的失效,這些失效對整個系統(tǒng)完成規(guī)定功能的影響程度千差萬異,因而在研究處理措施時應按輕重緩急區(qū)別對待。當具體分析軟件發(fā)生的某種失效的危害度(Criticality,簡稱為Cr)時,須考慮兩個重要因素:失效發(fā)生的可能性(Possibility,簡稱為Po),和失效對系統(tǒng)影響的嚴重度(Severity,簡稱為Se)。不妨定義某種失效的危害度
Cr=Se×Po,
顯然,不同失效的危害性千差萬別,當需考慮多種失效時,則可針對具體系統(tǒng)建立相應的復雜模型。
軟件失效嚴重程度類是一個失效集合,其中失效發(fā)生時對用戶產(chǎn)生相同影響。常見的分級標準包括對人員生命、成本和系統(tǒng)能力的影響。這些分級標準又包括很多子標準,不同的子標準對于特定的不同的應用系統(tǒng)來說可能非常重要。例如,成本影響可能包括額外的運行成本、修復和恢復成本、現(xiàn)有或潛在業(yè)務機會的損失;系統(tǒng)能力影響可能包括關鍵數(shù)據(jù)損失、可恢復性和停機時間等子標準。對于可應用性很重要的系統(tǒng),導致更長時間停機的失效常常被分配更高的失效嚴重程度類。還需要注意的是,嚴重程度可以隨失效發(fā)生的時間而發(fā)生變化。
在定義要使用的失效程度類時,經(jīng)驗表明最好的方法是集體討論需要考慮的所有可能的導致失效的因素,然后逐步確定最重要的失效因素。有些因素是客觀存在的,但是很難度量,例如對公司榮譽的影響,進而對市場份額產(chǎn)生的影響。
一般而言,軟件失效嚴重程度類的影響分布很廣泛,因而不可能很準確地估計影響。表1給出了一個根據(jù)成本硬性劃分的失效嚴重程度類的例子,然而用戶的實際評價在各個失效嚴重等級之間并不存在“非此即彼”的清晰分界點,相鄰等級之間存在著“亦此亦彼”的性質。根據(jù)系統(tǒng)能力影響劃分失效嚴重程度類,如表2所示,但該表中定義含混,沒有進一步闡明“多項”、“關鍵”、“重要”、“小錯誤”等概念。
表1 根據(jù)成本劃分的失效嚴重程度類
表2 根據(jù)系統(tǒng)能力影響劃分失效嚴重程度類
Putnam等將軟件失效嚴重度分為4類:致命的(Critical)、嚴重的(Serious)、一般的(Moderate)、輕微的(Cosmetic)。
李德毅等將系統(tǒng)失效嚴重度分為5類:①保持系統(tǒng)“全部功能正?!钡哪芰?,即系統(tǒng)無任何失效;②保持系統(tǒng)“主要功能正?!钡哪芰?,即系統(tǒng)有弱失效;③保持系統(tǒng)“基本功能正?!钡哪芰Γ聪到y(tǒng)有失效,但尚能維持;④保持系統(tǒng)“最低功能”正常的能力,即失效已達到臨界,再嚴重則不能容忍;⑤系統(tǒng)失去最低功能,即系統(tǒng)出現(xiàn)了致命失效。顯然,這種劃分同樣適用于軟件失效。
人類思維具有不確定性,我們習慣于且擅長用自然語言對失效的嚴重度和可能性進行軟性劃分。一般地,系統(tǒng)發(fā)生失效的嚴重度和可能性都可用自然語言中“很小”、“小”、“一般”、“大”、“很大”等五個定性概念來描述,我們稱這五個語言值的集合構成一個軟件失效評價概念集。若要從定量的角度分析,我們可以應用云模型有效地實現(xiàn)語言值表示的定性概念與其定量表示之間不確定性轉換,從而可對軟件失效程度的定量描述實現(xiàn)類似自然語言的軟性劃分。這些語言值都可適當?shù)剡x用一些定義在論域[0, 1]上的云模型(通常采用云變換方法根據(jù)屬性域中數(shù)據(jù)值的分布情況,自動生成一系列由云模型表示的基本概念,實現(xiàn)對論域的軟劃分,具體請參見附錄)來表示。圖1為相應的不確定定性定量表示轉換示意圖,其中“很小”、“很大”分別用半降云、半升云表示。
圖1 軟件失效嚴重度(或可能性)評價概念集的云圖表示
三、軟件失效數(shù)據(jù)
軟件失效數(shù)據(jù)是整個軟件可靠性分析和估測過程的工作基礎,在整個軟件可靠性工程的研究中,占據(jù)重要的地位。所收集的數(shù)據(jù)是否真實、準確和有效,是否滿足模型要求,都直接影響到軟件可靠性評估的準確性和可信性。因此,在研究軟件可靠性模型之前,對軟件失效數(shù)據(jù)做一個透徹的了解是非常必要的。
在實際研究工作中,通常將軟件失效數(shù)據(jù)分為完全數(shù)據(jù)和不完全數(shù)據(jù)兩大類。其定義如下:
定義3.1 數(shù)據(jù)集合{N(ti)|N(t0)=0,i=1,2, …,n}稱為完全數(shù)據(jù)集合,如果
?i∈{1,2, …,n},有N(ti)-N(ti-1)=1,
其中:t0為初始時刻,ti表示累積時刻,N(ti)為時刻ti時的累積失效數(shù)。
定義3.2 數(shù)據(jù)集合{N(ti)|N(t0)=0,i=1,2, …,s}稱為不完全數(shù)據(jù)集合,如果
?i∈{1,2, …,s},有N(ti)-N(ti-1)>1,
其中:t0為初始時刻,ti表示累積時刻,N(ti)為直到時刻ti時的累積失效數(shù)。
顯而易見,完全數(shù)據(jù)給出了每個失效發(fā)生的時間間隔,而不完全數(shù)據(jù)給出了在一定的時間間隔(不一定要求是均勻的)內的累積失效數(shù)。
由于軟件中一個相同的錯誤可能會導致多次失效,并且若干個錯誤之間有時存在相關性,從而會降低所收集數(shù)據(jù)的精確度。因此,收集軟件可靠性數(shù)據(jù)時,首先要制訂出詳細的計劃和標準,諸如人力資源、時間的分配,所收集數(shù)據(jù)的形式、記錄方式、存儲方式等等;其次,應對數(shù)據(jù)作具體的分析處理后方可應用,如數(shù)據(jù)的提取、合并、相關性分析等,采用的主要技術有EM算法、分段擬合技術等;另外,當使用某一具體的軟件可靠性模型時,可能會出現(xiàn)需要的是其中的一類失效數(shù)據(jù),而收集到的卻是另一類,這時需進行失效數(shù)據(jù)間的轉換。目前雖已開發(fā)出了一些自動收集軟件可靠性數(shù)據(jù)的支持工具,但局限性很大,因此,如何準確而高效地自動收集各種軟件可靠性數(shù)據(jù),還是一項有待于進一步研究和實踐的課題。
1.軟件失效數(shù)據(jù)的缺乏
要保證全部、精確的數(shù)據(jù)收集是十分困難的,特別是要保證出現(xiàn)失效時作出完全而精確的報告則更難。其中,最經(jīng)常也是最嚴重的問題是失效時間的丟失。目前,軟件可靠性研究工作者,普遍感到由于缺乏數(shù)據(jù),嚴重地影響到研究工作的進展。同時,關于數(shù)據(jù)的收集工作,又存在著許多問題有待解決:
(1)收集到的數(shù)據(jù)大多總是不完全的,而遺漏的數(shù)據(jù)確恰恰又是最重要的;
(2)進行數(shù)據(jù)收集同樣需要方便實用的工具,這方面的工作目前還十分缺乏;
(3)由于所使用的數(shù)據(jù)而產(chǎn)生的可靠性估計誤差比由于使用軟件可靠性模型而產(chǎn)生的誤差要大一個數(shù)量級,這說明數(shù)據(jù)質量改進的重要性。
2.影響軟件失效數(shù)據(jù)收集的因素
軟件產(chǎn)業(yè)是一門典型的知識密集型產(chǎn)業(yè),存在于軟件開發(fā)過程中的特殊復雜性問題,大多來源于人類腦力勞動的社會化,對它的管理要復雜、困難得多。由于受到許多潛在因素的影響,要想從一個實際的項目中收集一組軟件失效數(shù)據(jù)是十分困難的。主要因素有:
(1)對軟件進行度量的尺度定義混亂不清。如對時間、失效、錯誤類型、模型結構等的定義,就相當含糊,缺乏統(tǒng)一的標準。這樣就使得在進行軟件失效數(shù)據(jù)的收集時,目標不明確。
(2)對軟件產(chǎn)品的管理問題。軟件產(chǎn)品的隨意復制,可使它們在不同的系統(tǒng)上運行;同一產(chǎn)品的不同版本,又可以不受限制地同時被使用。于是,其后果就可能使收集的軟件失效數(shù)據(jù)含混不清。
(3)不完全的排錯及診斷,使收集的數(shù)據(jù)中含有不少的虛假成分,它們不能正確反映軟件的真實狀況。
(4)收集技術本身需要許多方便、實用的工具,以及結構精良、定義嚴謹?shù)臄?shù)據(jù)庫。但是,目前由于這些工具及數(shù)據(jù)庫的制作、設計及應用并未受到應有的重視,以致嚴重妨礙了對軟件失效數(shù)據(jù)的收集。特別是在“自動錯誤數(shù)據(jù)收集”的問題,因為有關錯誤信息與自動診斷難以定義,存在著許多有待解決的難題。
(5)心理因素的障礙。在軟件開發(fā)過程中,自始至終存在著進度壓力。爭取將軟件早日投放市場的激烈競爭,使進度成為首先要考慮的問題。如果缺乏嚴格而科學的管理,數(shù)據(jù)收集的任務就會被當作令人厭煩的“額外負擔”而得不到應有的重視,從而無法完成。
長按二維碼識別關注我們
免責聲明:本文內容由21ic獲得授權后發(fā)布,版權歸原作者所有,本平臺僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!





