Download
1 / 23
230 likes | 465 Views
軟體工程. 第 9 章 關鍵系統規格. 學習目標. 瞭解關鍵系統的可信賴度需求，是如何透過分析這些系統所面對的風險而找出來 瞭解安全性需求是由風險分析所產生的，而非系統擁有者 瞭解衍生出保全性需求的程序，以及保全性需求是如何用來對抗各種類型的威脅 瞭解可靠性規格的測量方式，以及如何使用這些測量方式來指定可靠性需求. 9.1 風險性規格. 關鍵系統的規格是針對系統的可信賴度，補充一般的需求規格程序的不足。它的目的是瞭解系統所面對的風險，並找出能應付它們的可信賴度需求。制定風險性規格一直是安全和保全關鍵系統的開發人員廣泛使用的方法。
E N D
軟體工程 第9章 關鍵系統規格
學習目標 • 瞭解關鍵系統的可信賴度需求，是如何透過分析這些系統所面對的風險而找出來 • 瞭解安全性需求是由風險分析所產生的，而非系統擁有者 • 瞭解衍生出保全性需求的程序，以及保全性需求是如何用來對抗各種類型的威脅 • 瞭解可靠性規格的測量方式，以及如何使用這些測量方式來指定可靠性需求
9.1風險性規格 • 關鍵系統的規格是針對系統的可信賴度，補充一般的需求規格程序的不足。它的目的是瞭解系統所面對的風險，並找出能應付它們的可信賴度需求。制定風險性規格一直是安全和保全關鍵系統的開發人員廣泛使用的方法。 • 風險性規格程序的過程包括瞭解系統所面對的風險，找出根源並產生能管理這些風險的需求。
進行風險分析的反覆程序： • 風險識別（risk identification）：找出可能出現的風險，這些風險會根據即將使用此系統的環境而定。 • 風險分析和分類（risk analysis and classification）：風險必須個別處理，一些特別嚴重和令人難以置信的風險必須做進一步的分析。有些不太可能發生的風險會在此階段被刪除，例如同時發生閃電和地震的情況。 • 風險分解（risk decomposition）：對每個風險個別分析，找出造成引發風險的根源。可能會使用的技術如失誤樹分析法（本章稍後討論）。 • 風險降低評估（risk reduction assessment）：提出可降低或消除風險的方法，然後產生能預防風險發生與如果發生風險該如何管理的系統可信賴度需求。
風險識別 • 風險分析的第一階段是風險識別，目的是找出關鍵系統必須應付的風險。 • 在安全關鍵系統中，主要的風險是那些可能導致意外的危險。識別這類風險的這個問題，可以從考量不同類別的危險來著手，例如身體的危險、電力的危險、生理的危險、幅射危險，以及服務故障危險等。
風險分析和分類 • 風險分析和分類程序主要的目的是瞭解風險發生的機率，以及風險發生所造成的意外後果。 • 需要進行這個分析的原因，是瞭解風險對系統或環境是否為嚴重的威脅，並且在將來要決定管理此風險所需要的資源時，能提供基本資料。
風險的接受程度可分為下列3類： • 無法忍受（intolerable）：系統必須設計成不會發生任何風險，或是如果發生風險將不會造成意外事件。無法忍受的風險一般是指那些威脅到人命或是影響企業的財務穩定，而且發生機率不低的風險。 • 盡可能降低危險（As low as reasonably practical, ALARP）：系統必須設計成盡量降低危險的嚴重程度，還要考慮其他因素，如成本與系統完成時間等。ALARP風險通常是指那些比較不很嚴重，或是發生機率很低的風險。 • 可接受（acceptable）：雖然說是可接受，但系統設計者仍應採取所有可能的步驟，來降低危險發生的可能性，但是這些步驟不應該增加成本、延遲系統交付時間或是影響其他非功能屬性。
風險分解 • 風險分解是找出某個系統的風險根源的過程。風險分解的技術主要是衍生自安全關鍵系統的開發，因為危險分析是安全程序的核心部份。風險分析可以使用演繹（deductive）或歸納（inductive）的方法。 • 演繹法是由上往下，比較容易使用，只要以風險為起點往下分析系統可能發生的故障；歸納法則是從系統可能發生的故障開始，找出可能引發這些故障的危險。
風險降低評估 • 這裡有3個可能的策略可用： • 風險避免（risk avoidance）：系統要設計成不會發生風險或危險。 • 風險偵測與移除（risk detection and removal）：系統要設計成可以在風險導致意外發生前，先偵測並排除該風險。 • 限制損害程度（damage limitation）：系統要設計成能夠將意外的傷害降到最低。
9.2安全規格 • 定義安全規格（safety specification）與保險的程序，是整體安全生命週期（safety life cycle）的一部分，它是定義在一份安全管理的國際標準IEC 61508中（IEC, 1998）。
9.3保全規格 • 系統的保全需求（security requirement）規格有些和安全需求一樣。這些需求不適合量化，而且保全需求通常是「不應該」的需求，用來定義無法接受的系統行為，而不是定義系統的功能需求。 • 傳統的（非電腦化）保全分析方法，是以被保護的資產以及對組織的價值為主。
這個程序包括以下幾個階段： • 資產識別與評估：識別資產（資料和程式）與它們所需要的保護程度，後者是依據資產的價值而定，所以一個密碼檔案通常比一堆公開網頁更有價值，因為如果密碼檔被破解，可能會對整個系統造成嚴重的傷害。 • 威脅分析與風險評估：找出保全方面可能的威脅，並且評估這些威脅相關的風險。 • 威脅歸類：找出與資產相關的威脅，並且為每項資產列出相關威脅的清單。 • 技術分析：評估可用的保全技術以及對已識別威脅的適用性。 • 制定保全需求規格：制定出保全需求規格。可能的話，也明確的列出可能用來保護系統抵抗威脅的保全技術。
9.4軟體可靠性規格 • 可靠性（reliability）是一個複雜的觀念，它應該從整體系統的角度，而不是從元件層級來考量。 • 因為系統中的元件有相互依賴的關係，若其中一個元件故障可能就會擴散到整個系統，影響到其他元件的運作。
在描述電腦化系統整體的可靠性時，必須考慮以下3個方面： • 硬體可靠性（hardware reliability）：硬體元件故障的機率有多高？修復該元件所需的時間多長？ • 軟體可靠性（software reliability）：軟體元件產生不正確輸出的可能性多大？軟體故障與硬體故障不同，軟體不會因為用太久而磨損。即使產生不正確的結果，之後它還是能繼續正常運作。 • 操作員可靠性（operator reliability）：操作人員犯錯的可能性多大？
可靠性的測量值 • 可靠性測量值（reliability metric）原本是專為硬體元件設計的。 • 由於硬體元件的物理性質原因，如機械磨損或用電過熱等，所以硬體故障是無法避免的。元件一般都有平均的使用壽命，這也是最常見的硬體可靠性測量值「故障前平均時間」（Mean Time to Failure, MTTF）。 • MTTF是指某個元件預計的可運作平均時間。硬體元件故障通常是永久的，因此通常修復或替換該元件所需的時間也很重要，也就是「修復前平均時間」（Mean Time to Repair, MTTR）。
在評估系統可靠性時，可以使用下列3種測量方法： • 對系統服務發出固定次數的要求，測量系統發生故障的次數。這個方法可以用來測量POFOD。 • 測量系統發生故障之間的時間（或交易個數）。這個方法可以用來測量ROCOF和MTTF。 • 測量當系統發生故障，修復所花的時間或重新啟動的所需時間。假設系統必須連續提供服務，這個方法可以用來測量AVAIL。
非功能性的可靠性需求 • 在許多系統需求文件中，可靠性需求都沒有仔細描述。可靠性規格是主觀且無法測量的。 • 描述系統動態行為的敘述也沒有意義。因為系統可靠性是受到軟體故障的影響，而非軟體缺陷。
建立可靠性規格的步驟如下： • 針對每個子系統找出各種可能發生的故障，並分析這些故障的後果。 • 以系統故障分析的結果將故障分成幾類。圖9.11的故障分類是可用的參考起點。 • 針對每一種故障類別，使用適當的可靠性測量值來定義可靠性需求。不同類別的故障不需要使用相同的測量值。例如假設某種故障需要操作人員介入才能回復，最好使用「服務故障率」做為測量值。假如故障可能可以自動回復，而且故障只是造成使用者不便時，使用ROCOF可能比較適合。 • 在適當的時候，找出定義系統功能的可靠性需求，這樣可以降低嚴重故障的機率。
