軟體可靠性設計工程是一門還處於不成熟的正在發展確立階段的新工程學科，以下是小編蒐集整理的一篇探究計算機軟體可靠性設計的論文範文，供大家閱讀參考。
摘要：本文介紹了軟體可靠性設計的基本概念,軟體故障產生的機理,軟體質量的可靠性引數,並且著重介紹了軟體可靠性設計方法。
關鍵詞：計算機軟體;可靠性設計;機理;引數
隨著科學技術的不斷進步，軟體可靠性成為我們關注的一個問題，軟體系統規模越做越大越複雜，其可靠性越來越難保證。應用本身對系統執行的可靠性要求越來越高，在一些關鍵的應用領域，如航空、航天等，其可靠性要求尤為重要，在銀行等服務性行業，其軟體系統的可靠性也直接關係到自身的聲譽和生存發展競爭能力。特別是軟體可靠性比硬體可靠性更難保證，會嚴重影響整個系統的可靠性。在許多專案開發過程中，對可靠性沒有提出明確的要求，開發商(部門)也不在可靠性方面花更多的精力，往往只注重速度、結果的正確性和使用者介面的友好性等，而忽略了可靠性。在投入使用後才發現大量可靠性問題，增加了維護困難和工作量，嚴重時只有束之高閣，無法投入實際使用。本文僅就軟體可靠性工程在軟體開發過程中的應用談談自己的認識。
1.軟體可靠性設計的基本概念
1.1 軟體及軟體故障。軟體(也稱程式)本質上是一種把一組離散輸入變成一組離散輸出的工具,它由一組編碼語句組成,這些語句的功能基本上是以下功能之一:(1)計算一個表示式並將其結果儲存在單元裡;(2)決定下一步要執行哪個語句;(3)進行輸入/輸出控制。
軟體產品與硬體產品一樣。軟體的可靠性工作也是貫穿於軟體的整個壽命週期的。軟體的壽命週期,是指從軟體任務的提出一直到它完成使命,因陳舊而被廢棄為止的整個時間歷程,這個壽命週期包括了提出要求/規格說明、設計、實現、檢驗、維護等五個階段,前四個階段為開發期,維護階段為使用期。
1.2 軟體可靠性。關於軟體可靠性的定義是什麼。較多的人認為軟體的可靠性與“概率統計的可靠性”的概念密切相關,軟體的可靠性是軟體在規定的條件下、規定的時間週期內執行所要求功能的能力。軟體的可靠度是軟體在規定的條件下、規定的時間內不引起系統故障的概率,該概率是系統輸入與系統使用的函式。
2.軟體質量的可靠性引數
2.1 系統平均不工作間隔時間(MTBSD或MTBD)。設d為軟體正常工作總時間,d為系統由於軟體故障而停止工作的次數,則定義TBSD=Tv/(d+1)。式中,TBSD―MTBSD;Tv―軟體正常工作總時間(h);d―系統由於軟體故障而停止工作的次數。MTBSD反映了系統的穩定性。
2.2 系統不工作次數(一定時期內)。由於軟體故障而停止工作,必須由操作者介入再啟動才能繼續工作的次數。
2.3 可用度A。設Tv為軟體正常工作總時間,TD為由於軟體故障使系統不工作的時間,則定義A=TV/(TV+TD)。它反映了系統的穩定性,亦可表達為A=TBD/(TBD+TDT)。式中,TBD―MTBD(h),TDT―平均不工作時間,以下簡稱MDT(h)。對一般生產用計算機系統,要求A≥99.8%;銀行計算機系統,要求A>99.9%。
2.4 MTTR。它反映了出現軟體缺陷後採取對策的效率。在一定程度上也反映了軟體企業對社會服務的責任心。對於線上系統而言,MTT只要求不超過2天,變差係數應小於1。一般的MTTR也應小於7天,變差係數小於1。
2.5 平均不工作時間(MDT)。即由於軟體故障,系統不工作的均值。對線上系統而言。MDT要求不超過10min一般的MDT<30min。
2.6 初期故障。一般以軟體交付使用後的三個月內為初期故障期。初期故障率的大小取決於軟體設計水平、檢查項日數、軟體規模、軟體除錯徹底與否等因素。
2.7 偶然故障率。一般以軟體交付給使用方四個月後為偶然故障期,偶然故障率以每1000h的故障數為單位,它反映了軟體處於穩定狀態下的質量。一般最少要求偶然故障率不超過1,即每千小時不到1個故障,亦即MTBF超過1000h。
2.8 使用方誤用率。使用方不按照軟體規範及說明等使用造成的錯誤叫使用方誤用。在總使用次數中,使用方誤用次數佔的百分率叫使用方誤用率。造成使用方誤用的原因之一是使用方對說明理解不深,操作不熟練,但也有可能是說明沒有講得很清楚而引起誤解。其他的原因還有軟體系統的可操作性還應改進、對使用方的使用培訓還要更深入等等
2.9 使用者提出補充要求數。這反映軟體未能充分滿足使用者的`需要,有時要求是特定使用者的特定要求,生產方為了更好地為社會服務,應該盡力滿足他們的要求。
2.10 處理能力。處理能力有各種指標。例如可用每小時平均處理多少檔案、每項工作的反應時間多少秒等來表示,根據需要而定。在評價軟體及系統的經濟效益時需用這項指標。
3.軟體可靠性設計方法
從軟體可靠性的概念可知,軟體的缺陷可以導致錯誤並造成系統的故障,因此,缺陷是一切錯誤的根源。為了提高軟體的可靠性,最關鍵的還是力求減少軟體中的缺陷。軟體的缺陷來自軟體壽命週期的各個階段,因此應想方設法在壽命週期的各個階段減少缺陷。缺陷在一定的環境條件下暴露,導致系統執行中出現錯誤。軟體的錯誤概括地說可能由規範(要求/規格說明)、軟體系統設計及編碼過程產生。
3.1 要求/規格說明。只要在規格說明與使用者要求說明之間存在誤差,就會產生規範錯誤。
規範它不僅規定程式的要求,還規定所用的結構、研製及試驗中需要的程式試驗要求和檔案,以及程式語言、輸入和輸出的基本要求。通過對這些方面作出適當的規定,就可以建立使產生錯誤的可能性最小、並保證錯誤能被發現和改正的程式生成的結構。
這種說明書是軟體設計人員和使用者間相互瞭解的基礎,是軟體設計人員進行程式設計、除錯的基礎和評價軟體的依據。要求/規格說明書應具有以下性質:
(1)可測性:生產出來的軟體產品應能根據要求/規格說明書的內容進行測試。(2)完整性:對軟體要求的描述要完整無缺。(3)明確性:對軟體的要求必須是明確的,不存在語義上的支義性。(4)一致性:要求說明書中的概念與規範化。(5)彈性:當軟體的工作環境發生變化時,其功能說明也相應地擴充或壓縮。
3.2 軟體設計。軟體系統是根據要求/規格說明(規範)設計的,通過設計將確定程式結構、測試點及限制等。為設計出可靠的軟體,需要在考慮諸如機型、資源、語言、模型及資料結構等實際問題的基礎上,採取一些有效的設計方法。
3.2.1 “自頂向下設計”法。這種設計方法是處理分級問題最有效的設計技術。它是以一個系統功能的最抽象描述開始作為最高層次;從它出發,設計一系列較詳細的子系統。由這些子系統來完成員高層次的功能;再以每個子系統為基礎,設計出一系列更詳細的子系統,等等。如此逐次向下作功能分解,直到最低層次的子系統能夠比較方便用計算機程式設計語言來實現為止。自頂向下設計方法的價值在於,它在設計的同時,指出了複雜性不同的處理層次,而且各種設計要素之間的關係是比較清楚的。通過這樣一種結構化構造途徑,有可能在早期就洞察出設計問題,從而避免了不必要地先去考慮較低層次的細節問題。
3.2.2 結構化程式設計。軟體結構對軟體的可靠性具有重要的意義。結構良好的程式易於編寫、檢查,便於查錯定位、修改和維護。結構化程式設計(也稱為模組化程式設計)把程式要求分成若干獨立的、更小的程式要求或模組化的功能要求,分別提出各自的要求/規格說明,並註明是如何與程式中的其他部分介面,還必須指出所有的輸入與輸出,以及測試要求。對每一個更小的程式和模組,可分別程式設計和測試,使得模組間高度分離。
3.2.3 容錯設計。對軟體錯誤所引起的後果特別嚴重的情況,如飛機的飛行控制系統、空中交通管制系統、核反應爐安全系統等,需採用容錯軟體。容錯設計的途徑有:(1)加強軟體的健壯性;使程式設計得能夠緩解錯誤的影響,不致造成諸如死鎖或崩潰這樣的嚴重後果,並能指出錯誤源。(2)採用N(>2)版本程式設計法:即儘可能用不同的演算法與程式語言,經不同的班組編制,以提高各軟體版本的獨立性。這N個軟體版本同時在N臺計算機上執行,各計算機間能進行高效通訊,並作出快速比較,當結果不一致時,按多數表決或預定的策略選擇輸出。(3)恢復塊法:給需要作容錯處理的塊(基本塊)提供備份塊,並附加錯誤檢測和恢復措施
3 軟體編碼。在軟體結構設計的基礎上就可以進行編碼,編碼產生的缺陷是軟體錯誤的主要來源。一般的編碼錯誤是:鍵入錯程式碼;數值錯誤(尤其是單位不統一時易出這類錯誤);丟失程式碼(如括號);用了被零除這樣不定值的表示式等。為了減少編碼錯誤,實現設計與生產分離,首先由高水平的軟體工程師完成結構設計,再由程式設計員完成程式的編制是合理的、必要的,並在編碼過程中儘早地查出缺陷予以改正。
4.結束語
軟體可靠性設計工程是一門雖然得到普遍承認,但還處於不成熟的正在發展確立階段的新工程學科，任然存在很多問題,需要去探索、研究和解決。本文介紹只在軟體可靠性設計方面拋磚引玉,提供借鑑。
參考文獻
[1] 張磊,周繼鋒,張強.系統軟體可靠性驗證測試方法研究[J].計算機與數字工程,2010,06.
[2] 曾福萍,靳慧亮,陸民燕.軟體缺陷模式的研究[J].電腦科學,2011,02