1、一、引言二、軟件失效機理與對策三、軟件失效管理與作用四、軟件可靠性與安全性設計與實現1對高質量軟件的需求 軟件應用廣泛, 在許多領域已成為產品創新的源泉 軟件使系統更加智能、靈活, 越來越多的系統能力由軟件實現 系統對軟件的需求和依賴, 使得軟件既要滿足用戶的功能要求, 又必須穩定可靠地完成賦予的任務 在許多應用場景下, 軟件失效有可能帶來重大損失, 安全性必須得到保證1軟件的質量狀況 硬件飛速發展, 越來越可靠, 軟件成為系統失效的主要原因 軟件規模和復雜性持續增加, 給獲得安全可靠的軟件帶來巨大挑戰 軟件質量的定量評估困難, 往往成為項目要素中最容易被忽略的部分 經濟性使得相關各方都在考慮

2、成本, 在資源受限的情況下, 質量的要求會降低, 常常不得不在帶有許多缺陷的情況下發布軟件1軟件質量 明確聲明的功能和性能需求、明確文檔化的開發標準、以及專業開發人員開發的軟件所應具有的所有隱含特征都得到滿足軟件質量模型是多樣的軟件質量模型是動態的軟件質量是多維度的軟件質量是多視角的軟件質量特性之間存在交互影響1動態的軟件質量軟件/系統質量模型(ISO/IEC 25010:2011)外部和內部質量功能穩定性可靠性性能效率易用性安全保密性相容性維護性可移植性可靠性(R)可用性(A)安全性(S2)可維護性(M)&RAMS2軟件質量的關鍵特性2軟件失效機理 導致軟件失效的缺陷主要是設計問題 老化/磨

3、損不會導致軟件失效, 軟件失效沒有趨勢性預兆 周期性的重啟可幫助防止/修復一些軟件失效 除非輸入(指令、數據、運行環境)發生變化,否則, 運行時間的長短不會對軟件可靠性產生影響 除非影響到軟件的輸入(指令、數據、運行環境), 否則, 物理環境因素的變化不會對軟件可靠性產生影響 通常, 不能通過對單條語句的分析來預計軟件失效率 軟件的接口完全是概念上的、不可見的, 但對軟件可靠性有影響 標準件可用于改善可靠性和可維護性, 但軟件重用還沒有形成工程趨勢 硬件維修使其恢復到良好狀態, 而軟件修改使其到達未知狀態2使用環境對失效的影響 軟件缺陷只有被遇到時才會產生故障, 才有可能導致失效, 不同使用方

4、式下, 對軟件可靠性的感受是不一樣的決定軟件使用方式的因素很多內部參數、歷史數據、當前輸入、 軟件失效狀態受到操作及環境條件的影響軟件不會脫離環境運行軟件失效對系統的影響程度取決于使用環境, 在某個環境中是安全的軟件, 可能在另一個環境中就不安全了 軟件失效的統計特性IBM關于缺陷與失效的統計研究數據客戶所看到的57%以上的失效是由占缺陷總數2%以下的缺陷引起的超過總數61%的缺陷只引起低于3%的客戶將會經歷的失效不同的缺陷在所引發的失效率上存在高達4個數量級的巨大差異2軟件缺陷的特性及影響變異的預期常常產生缺陷在實際項目中, 完全消除缺陷是不可能的, 基于軟件開發經濟學的考慮, 減少缺陷是現

5、實的選擇缺陷有可能非常簡單, 也有可能極其復雜程序設計語言與缺陷的復雜性和數量的關系是未知的不論人的能力和背景, 都可能產生缺陷缺陷在軟件中的位置未知軟件缺陷的影響缺陷可能導致故障, 甚至失效同樣的缺陷在不同的場景下導致的失效狀態可能會有很大的差別, 可能只是使用不便, 也有可能帶來災難性后果缺陷的復雜度與失效的嚴重性之間的關系是未知的最大限度的減少缺陷, 可以提高軟件的可靠性缺陷除了帶來失效損失之外, 還帶來開發、驗證和維護成本的全面增加2軟件防錯策略 第一次就做正確(Do It Right the First Time)建立先進的理念, 避免錯誤及預防失誤采取適當的實踐, 形成缺陷預防的趨

6、勢利用一切可用的方法及工具, 確保不引入缺陷到軟件典型實踐建立組織級別的規范和指南, 全體人員共同遵守用戶的早期參與進行專業分工, 使用有能力、經驗及進取心的人員在生命周期各階段, 使用現代的方法論和自動化工具, 促進生產力提升的同時及達到預定質量的目標2軟件排錯策略 盡早檢測, 一旦可行立即修正(Detect It Early; Fix It as Soon as Practicable)測試及修復成為計劃性和經常性活動, 對缺陷進行早期檢測及消除, 使得缺陷一旦產生就立刻解決修正系統缺陷時, 應考慮問題的嚴重程度、發生頻率及完成測試及管理的可能性在操作和維護階段發現的缺陷, 不一定要立即修

7、正 典型實踐舉例在生命周期各階段, 對軟件進行原型化、仿真、審查和檢查, 驗證正確性, 改善可靠性盡早開展多層次的測試工作, 發現并消除缺陷和隱患優先解決最高風險的問題, 加強配置管理, 防止變更失控建立并運行軟件故障報告、分析及糾正措施系統, 做好軟件故障管理可靠性問題的答案在哪里?你的軟件可靠嗎？你是如何知道的？不可靠的原因是什么？你的開發過程需要改進嗎？你的測試過程需要改進嗎？3軟件失效管理 利用“信息反饋, 閉環控制”的原理, 通過一套規范化的程序, 使分散發生的產品失效能得到及時報告、查清原因、正確糾正, 防止失效再現, 從而實現產品可靠性的增長, 達到對產品可靠性和維修性的預期要求

8、 基于風險水平管理失效 建立企業的可靠性經驗3SFRACAS 軟件失效報告、分析及糾正措施系統, 是Software Failure Report Analysis and Corrective Action System 的縮寫, 有時也稱為“失效信息閉環管理系統” 一組過程、規則和軟件工具, 在產品生存期后端開始使用, 是跟蹤系統可靠性的方法 建立企業失效信息數據庫, 提供數據支持軟件可靠性分析、設計、改進和評價維修策略、保障策略和備件策略的制定3SFRACAS知識積累失效記錄失效報告失效分析糾正措施閉環管理售后服務數據庫SFRACAS數據庫外場失效廠內失效通用質量知識庫知識管理3防錯性設

9、計簡化設計算法與數據管理慎用易錯架構使用監錯技術多任務管理4防錯性設計-簡化設計復雜性是可靠性最兇惡的對手復雜的軟件代碼規模更大、缺陷更多交互關系更多、缺陷更多更難測試、不充分的可能性更大設計、實現、配置、使用的難度更大用戶更難理解結構復雜性接口復雜度調用關系復雜度單元復雜性規模圈復雜度基本圈復雜度4復雜度圈復雜用于衡量一個軟件單元的復雜程度, 數量上表現為獨立路徑的條數V(G)=e n + 2復雜性的影響圈復雜度與可靠性風險的關系圈復雜度可靠性風險110簡單過程，較少風險簡單過程，較少風險1120比較復雜，中等風險比較復雜，中等風險2150復雜，高風險復雜，高風險50不可測試，極高風險不可測

10、試，極高風險4防錯性設計-算法選擇對規定時間內要完成規定任務的軟件, 應采用在規定時間內能得出結果的算法例如, 不采用只有“計算迭代到|為止”的算法, 而采用迭代到一定次數為止, 或者迭代到|為止或迭代到一定次數為止的算法算法所使用的存儲空間應具有完全確定性例如, 盡量不采用動態堆空間4防錯性設計-數據管理參數化在軟件設計中, 用統一的符號來表示參數、常量和標志, 以便在不改變源程序邏輯的情況下, 對它們進行修改尋址模式的選用盡量不使用間接尋址方式在確實有必要采用間接尋址方式時, 慎重考慮和充分論證, 并在執行之前驗證地址是否在可接受的范圍內文件文件必須唯一且用于單一目的文件在使用前必須成功地

11、打開, 在使用結束必須成功地關閉文件的屬性應與對它的使用相一致4防錯性設計-慎用易錯架構使用語言的安全子集進行實現典型易錯架構浮點數浮點數指針指針遞歸遞歸中斷中斷繼承繼承別名別名無界數組無界數組動態內存分配動態內存分配全局變量全局變量公用數據和公共變量公用數據和公共變量不檢查輸入參數長度的庫函數不檢查輸入參數長度的庫函數4防錯性設計-慎用易錯架構浮點數先天不精確, 有可能導致無效的比較指針指針引用錯誤的內存區域可能導致數據誤用遞歸錯誤的遞歸容易導致內存溢出當使用遞歸時, 應有明顯的判據, 可預測遞歸的深度中斷有可能導致關鍵操作的終止使程序難以理解類似 goto 語句4防錯性設計-慎用易錯架構繼

12、承代碼非局部化, 代碼的修改可能導致無法預期行為, 產生難以理解的問題別名使用多個變量名來訪問相同狀態變量, 會使程序的理解和修改變得困難無界數組如果不進行任何數組邊界檢查, 可能出現緩沖區溢出失效動態內存分配在有些場景下, 軟件運行時內存塊大小不能在代碼編譯時確定, 需要根據代碼的運行環境來確定軟件執行過程中, 根據需要分配或者回收存儲空間在C/C+程序中, 應正確使用malloc、calloc、realloc、new、alloca與free、delete管理動態內存4防錯性設計-慎用易錯架構不當動態內存分配的后果內存泄露內存碎片內存泄露的原因忘記了回收回收前失去了對內存的追蹤, 如: 存儲

13、指針值的變量被移出了作用域; 指針值被重寫; 沒有保存地址指針庫函數存在內存泄露缺陷, 對庫函數接口的誤解全局變量全局變量不好控制不利于程序的結構化不用或少用全局變量公用數據和公共變量指明由兩個或多個模塊公用的數據和公共變量盡量減少對公共變量的改變, 以減少模塊間的副作用4防錯性設計-使用監錯技術使用條件判斷int z;if (y != 0)z = x / y;else / deal with this situation here在開發和維護階段, 使用監錯技術提示相互矛盾的假設傳入程序的不良數值主要的監錯技術斷言異常情況處理4防錯性設計-多任務設計多任務設計多任務設計是軟件應用的新趨勢, 但是多任務之間可能存在難以預知的交互, 導致同步錯誤多任務設計的原則注意函數的可重入性避免死鎖與活鎖避免臨界點競爭注意函數的可重入性不為連續的調用持有靜態數據不返回指向靜態數據的指針, 所有數據都由