試論軟件的可靠性及其保證

用軟件系統規模越做越大越復雜，其可靠性越來越難保證。應用本身對系統運行的可靠性要求越來越高，在一些關鍵的應用領域，如航空、航天等，其可靠性要求尤為重要，在銀行等服務性行業，其軟件系統的可靠性也直接關系到自身的聲譽和生存發展競爭能力。

　　特別是軟件可靠性比硬件可靠性更難保證，會嚴重影響整個系統的可靠性。在許多項目開發過程中，對可靠性沒有提出明確的要求，開發商(部門)也不在可靠性方面花更多的精力，往往只注重速度、結果的正確性和用戶界面的友好性等，而忽略了可靠性。在投入使用后才發現大量可靠性問題，增加了維護困難和工作量，嚴重時只有束之高閣，無法投入實際使用。

　　一. 軟件可靠性與硬件可靠性的區別

　　軟件可靠性與硬件可靠性之間主要存在以下區別:

　　1.最明顯的是硬件有老化損耗現象，硬件失效是物理故障，是器件物理變化的必然結果，有浴盆曲線現象；軟件不發生變化，沒有磨損現象，有陳舊落后的問題，沒有浴盆曲線現象。

　　2.硬件可靠性的決定因素是時間，受設計、生產、運用的所有過程影響，軟件可靠性的決定因素是與輸入數據有關的軟件差錯，是輸入數據和程序內部狀態的函數，更多地決定于人。

　　3.硬件的糾錯維護可通過修復或更換失效的系統重新恢復功能，軟件只有通過重設計。

　　4.對硬件可采用預防性維護技術預防故障，采用斷開失效部件的辦法診斷故障，而軟件則不能采用這些技術。

　　5.事先估計可靠性測試和可靠性的逐步增長等技術對軟件和硬件有不同的意義。

　　6.為提高硬件可靠性可采用冗余技術，而同一軟件的冗余不能提高可靠性。

　　7.硬件可靠性檢驗方法已建立，并已標準化且有一整套完整的理論，而軟件可靠性驗證方法仍未建立，更沒有完整的理論體系。

　　8.硬件可靠性已有成熟的產品市場，而軟件產品市場還很新。

　　9.軟件錯誤是永恒的，可重現的，而一些瞬間的硬件錯誤可能會被誤認為是軟件錯誤。

　　總的說來，軟件可靠性比硬件可靠性更難保證，即使是美國宇航局的軟件系統，其可靠性仍比硬件可靠性低一個數量級。

　　二. 影響軟件可靠性的因素

　　軟件可靠性是關于軟件能夠夠滿足需求功能的性質，軟件不能滿足需求是因為軟件中的差錯引起了軟件故障。軟件中有哪些可能的差錯呢?

　　軟件差錯是軟件開發各階段潛入的人為錯誤：

　　1.需求分析定義錯誤。如用戶提出的需求不完整，用戶需求的變更未及時消化，軟件開發者和用戶對需求的理解不同等等。

　　2.設計錯誤。如處理的結構和算法錯誤，缺乏對特殊情況和錯誤處理的考慮等。

　　3.編碼錯誤。如語法錯誤，變量初始化錯誤等。

　　4.測試錯誤。如數據準備錯誤，測試用例錯誤等。

　　5.文檔錯誤。如文檔不齊全，文檔相關內容不一致，文檔版本不一致，缺乏完整性等。

　　從上游到下游，錯誤的影響是發散的，所以要盡量把錯誤消除在開發前期階段。

　　錯誤引入軟件的方式可歸納為兩種特性：程序代碼特性，開發過程特性。

　　程序代碼一個最直觀的特性是長度，另外還有算法和語句結構等，程序代碼越長，結構越復雜，其可靠性越難保證。

　　開發過程特性包括采用的工程技術和使用的工具，也包括開發者個人的業務經歷水平等。

　　除了軟件可靠性外，影響可靠性的另一個重要因素是健壯性，對非法輸入的容錯能力。

　　所以提高可靠性從原理上看就是要減少錯誤和提高健壯性。

　　三. 提高軟件可靠性的方法和技術

　　1.建立以可靠性為核心的質量標準

　　在軟件項目規劃和需求分析階段就要建立以可靠性為核心的質量標準。這個質量標準包括實現的功能、可靠性、可維護性、可移植性、安全性、吞吐率等等，雖然還沒有一個衡量軟件質量的完整體系，但還是可以通過一定的指標來指定標準基線。

　　軟件質量從構成因素上可分為產品質量和過程質量。

　　產品質量是軟件成品的質量，包括各類文檔、編碼的可讀性、可靠性、正確性，用戶需求的滿足程度等。

　　過程質量是開發過程環境的質量，與所采用的技術、開發人員的素質、開發的組織交流、開發設備的利用率等因素有關。

　　還可把質量分為動態質量和靜態質量。靜態質量是通過審查各開發過程的成果來確認的質量，包括模塊化程度、簡易程度、完整程度等內容。動態質量是考察運行狀況來確認的質量，包括平均故障間隔時間(MTBF)、軟件故障修復時間(MTRF)、可用資源的利用率。在許多實際工程中，人們一般比較重視動態質量而忽視靜態質量。

　　所定的質量標準度量，至少應達到以下兩個目的:

　　(1).明確劃分各開發過程(需求分析過程，設計過程，測試過程，驗收過程)，通過質量檢驗的反饋作用確保差錯及早排除并保證一定的質量。

　　(2).在各開發過程中實施進度管理，產生階段質量評價報告，對不合要求的產品及早采取對策。

　　確定劃分的各開發過程的質量度量：

　　(1).需求分析質量度量

　　需求分析定義是否完整、準確(有無二義性)，開發者和用戶間有沒有理解不同的情況，文檔完成情況等，要有明確的可靠性需求目標、分析設計及可靠性管理措施等。

　　(2).設計結果質量度量

　　設計工時，程序容量和可讀性、可理解性，測試情況數，評價結果，文檔完成情況等。

　　(3).測試結果質量度量

　　測試工時，差錯狀況，差錯數量，差錯檢出率及殘存差錯數，差錯影響評價，文檔等，以及有關非法輸入的處理度量。

　　(4).驗收結果質量度量

　　完成的功能數量，各項性能指標，可靠性等。

　　最后選擇一種可靠度增長曲線預測模型，如時間測量、個體測量、可用性，在后期開發過程中，用來計算可靠度增長曲線的差錯收斂度。

　　在建立質量標準之后，設計質量報告及評價表，在整個開發過程中就要嚴格實施并及時作出質量評價，填寫報告表。

　　2. 選擇開發方法

　　軟件開發方法對軟件的可靠性也有重要影響。

　　目前的軟件開發方法主要有Parnas方法、Yourdon方法、面向數據結構的Jackson方法和Warnier方法、PSL/PSA方法、原型化方法、面向對象方法、可視化方法、ICASE方法、瑞理開發方法等，其他還有BSP方法、CSF方法等。這里特別要提一下的是Parnas方法。

　　Parnas方法是最早的軟件開發方法，是Parnas 在1972年提出來的，基本思想是在概要設計時預先估計未來可能發生變化，提出了信息隱藏的原則以提高軟件的可靠性和可維護性。

　　在設計中要求先列出將來可能要變化的因素，在劃分模塊時將一些可能發生變化的因素隱含在某個模塊的內部，使其他模塊與此無關，這樣就提高了軟件的可維護性，避免了錯誤的蔓延，也就提高了軟件的可靠性。還提出了提高可靠性的措施：

　　(1)考慮到硬件有可能出故障，接近硬件的模塊要對硬件行為進行檢查，及時發現錯誤。

　　(2)考慮到操作人員有可能失誤，輸入模塊對輸入數據進行合法性檢查，是否合法、越權，及時糾錯。

　　(3)考慮到軟件本身有可能失誤，加強模塊間檢查，防止錯誤蔓延。

　　對瑞理方法可能許多人還不熟悉，這里簡要介紹一下。

　　瑞理（Rational)模式是美國瑞理軟件工程公司發展出來的，其模式是：
　　面向對象；
　　螺旋式上升；
　　管理與控制；
　　高度自動化；

　　以管理觀點和技術觀點把軟件生命周期劃分為起始、規劃、建構、轉移、進化五個階段，也可把這五個階段歸并為研究時期（起始和規劃）和生產時期（建構和轉移），最后是維護時期（進化），特別適合對高風險部分及變動需求的處理。

　　在以上的眾多方法中，可視化方法主要用于與圖形有關的應用，目前的可視化開發工具只能提供用戶界面的可視化開發，對一些不需要復雜圖形界面的應用不必使用這種方法；ICASE 技術還沒有完全成熟，所以可視在方法和ICASE方法最多只能用作輔助方法。面向數據結構的方法、PSL/PSA方法及原型化方法只適合于中小型系統的開發。

　　面向對象的方法便于軟件復雜性控制，有利于生產率的提高，符合人類的思維習慣，能自然地表達現實世界的實體和問題，具有一種自然的模型化能力，達到從問題空間到解空間的較為直接自然的映射。

　　在面向對象的方法中，由于大量使用具有高可靠性的庫，其可靠性也就有了保證，用面向對象的方法也利于實現軟件重用。

　　所以建議采用面向對象的方法，借鑒Parnas和瑞理模式的思想，在開發過程中再結合使用其他方法，吸取其它方法的優點。

　　3.軟件重用

　　最大限度地重用現有的成熟軟件，不僅能縮短開發周期，提高開發效率，也能提高軟件的可維護性和可靠性。因為現有的成熟軟件，已經過嚴格的運行檢測，大量的錯誤已在開發、運行和維護過程中排除，應該是比較可靠的。在項目規劃開始階段就要把軟件重用列入工作中不可缺少的一部分，作為提高可靠性的一種必要手段。

　　軟件重用不僅僅是指軟件本身，也可以是軟件的開發思想方法、文檔，甚至環境、數據等，包括三個方面內容的重用：

　　(1)開發過程重用，指開發規范、各種開發方法、工具和標準等。

　　(2)軟件構件重用，指文檔、程序和數據等。

　　(3)知識重用，如相關領域專業知識的重用。

　　一般用的比較多的是軟件構件重用。

　　軟件重用的過程如下：候選，選擇，資格，分類和存儲，查找和檢索。在選擇可重用構件時，一定要有嚴格的選擇標準，可重用的構件必須是經過嚴格測試的、甚至是經過可靠性和正確性證明的構件，應模塊化（實現單一、的完整的功能）、結構清晰（可讀、可理解、規模適當），且有高度可適應性。

　　4.使用開發管理工具

　　開發一個大的軟件系統，離不開開發管理工具，作為一個項目管理員，僅僅靠人來管理是不夠的，需要有開發管理工具來輔助解決開發過程中遇到的各種各樣的問題，以提高開發效率和產品質量。

　　如Intersolv公司的PVCS軟件開發管理工具，在美國市場占有率已超過70％，使用PVCS可以帶來不少好處：規范開發過程，縮短開發周期，減少開發成本，降低項目投資風險；自動創造完整的文檔，便于軟件維護；管理軟件多重版本；管理和追蹤開發過程中危及軟件質量和影響開發周期的缺陷和變化，便于軟件重用，避免數據丟失，也便于開發人員的交流，對提高軟件可靠性，保證質量有很大作用。

　　在我國，開發管理工具并沒有得到有效地使用，許多軟件公司還停留在人工管理階段，所開發的軟件質量不會很高。

　　人的管理比較困難，在保證開發人員素質的同時，要保持人員的穩定性，盡可能避免人員的經常流動。人員流動影響了軟件的質量，工作連續性難保證，繼承者不可能對情況了解很清楚等，也可能影響工作進程等。PVCS也提供了適當的人員管理方法。

　　5.加強測試

　　軟件開發前期各階段完成之后，為進一步提高可靠性，只有通過加強測試來實現了。為最大限度地除去軟件中的差錯，改進軟件的可靠性，就要對軟件進行完備測試。要對一個大的軟件系統進行完備測試是不可能的，所以要確定一個最小測試數和最大測試數，前者是技術性的決策，后者管理性的決策，在實際過程中要確定一個測試數量的下界?？偟膩碚f，要在可能的情況下，進行盡可能完備的測試。

　　誰來做測試呢？一般說來，用戶不大可能來進行模塊測試，模塊測試應該由最初編寫代碼的程序員來進行，要在他們之間交換程序進行模塊測試，自己設計的程序自己測試一般都達不到好的效果。

　　測試前要確定測試標準、規范，測試過程中要建立完整的測試文檔，把軟件置于配置控制下，用形式化的步驟去改變它，保證任何錯誤及對錯誤的動作都能及時歸檔。

　　測試規范包括以下三類文檔：

　　(1)測試設計規范：詳細描述測試方法，規定該設計及其有關測試所包括的特性。還應規定完成測試所需的測試用例和測試規程，規定特性的通過/失敗判定準則。

　　(2)測試用例規范：列出用于輸入的具體值及預期輸出結果。規定在使用具體測試用例時對測試規程的各種限制。

　　(3)測試規程規范：規定對于運行該系統和執行指定的測試用例來實現有關測試所要求的所有步驟。

　　測試的方法多種多樣：

　　(1)走查（Walk-through），即手工執行，由不同的程序員(非該模塊設計者)讀代碼，并進行評論。

　　(2)機器測試，對給定的輸入不會產生不合邏輯的輸出。

　　(3)程序證明或交替程序表示。

　　(4)模擬測試，模擬硬件、I/O設備等。

　　(5)設計審查，關于設計的所有各方面的小組討論會，利用所獲得的信息，找出缺陷及違反標準的地方等。

　　以上可以交替并行循環執行，在實際測試過程中要使用測試工具提高效率。

　　除正常的測試之外，還要對軟件進行可靠性測試，確保軟件中沒有對可靠性影響較大的故障。制定測試計劃方案，按實際使用的概率分布隨機選擇輸入，準確記錄運行時間和結果，并對結果進行評價。

　　沒有錯誤的程序同永動機一樣是不可能達到的。一般常用排錯方法有試探法、追溯法、歸納法、演繹法。還要使用適當的排錯工具，如UNIX提供的sdb和dbx編碼排錯工具，這些排錯工具只有瀏覽功能，沒有修改功能，是實際的找錯工具。

　　6.容錯設計

　　提高可靠性的技術一般可以分為兩類，一類是避免故障，在開發過程中，盡可能不讓差錯和缺陷潛入軟件，這類常用的技術有：

　　算法模型化，把可以保證正確實現需求規格的算法模型化。

　　模擬模型化，為了保證在確定的資源條件下的預測性能的發揮，使軟件運行時間、內存使用量及控制執行模型化。

　　可靠性模型，使用可靠性模型，從差錯發生頻度出發，預測可靠性。

　　正確性證明，使用形式符號及數學歸納法等證明算法的正確性。

　　軟件危險分析與故障樹分析：從設計或編碼的結構出發，追蹤軟件開發過程中潛入系統缺陷的原因。

　　分布接口需求規格說明：在設計的各階段使用形式的接口需求規格說明，以便驗證需求的分布接口實現可能性與完備性。

　　這些技術一般都需要比較深厚的數學理論知識和模型化技術。

　　另一類就是采用冗余思想的容錯技術。

　　容錯技術的基本思想是使軟件內潛在的差錯對可靠性的影響縮小控制到最低程度。

　　軟件的容錯從原理上可分為錯誤分析、破壞程度斷定、錯誤恢復、錯誤處理四個階段。

　　常用的軟件容錯技術有N-版本技術、恢復塊技術、多備份技術等。

　　N-版本程序設計是依據相同規范要求獨立設計N個功能相等的程序(即版本)。獨立是指使用不同的算法，不同的設計語言，不同的測試技術，甚至不同的指令系統等。

　　恢復塊技術是使用自動前向錯誤恢復的故障處理技術。

　　以上這些技術可參考有關文獻，這里要說的是防錯性程序設計，在程序中進行錯誤檢查。被動的防錯性技術是當到達檢查點時，檢查一個計算機程序的適當點的信息。主動的防錯性技術是周期性地搜查整個程序或數據，或在空閑時間尋找不尋常的條件。采用防錯性程序設計，是建立在程序員相信自己設計的軟件中肯定有錯誤這一基礎上的，有的程序員可能對此不大習慣，因為他可能太相信自己，相信自己的程序只有很少錯誤，甚至沒有錯誤，作為一個項目管理員應該能說服他或者強制他采用這種技術，雖然在設計時要花費一定的時間，但這對提高可靠性很有用。

原文轉自：http://www.kjueaiud.com