1 / 34

軟體工程

軟體工程. 第 9 章 關鍵系統規格 Critical Systems Specification. 學習目標. 透過分析 關鍵系統 所面對的風險找出 可信賴 度（ Dependability ）需求 安全性（ Safety ）需求是透過風險分析產生的，不是由系統擁有者提供 瞭解建立保全性（ Security ）需求的程序 藉由保全性需求對抗各種威脅 瞭解可靠性（ Reliability ）規格的測量方式，以及如何定義可靠性需求. 系統需求. 功能性需求（ Functional Requirements ） 檢查 錯誤 從錯誤狀態中復原

fergal
Download Presentation

軟體工程

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 軟體工程 第9章 關鍵系統規格 Critical Systems Specification

  2. 學習目標 • 透過分析關鍵系統所面對的風險找出可信賴度（Dependability）需求 • 安全性（Safety）需求是透過風險分析產生的，不是由系統擁有者提供 • 瞭解建立保全性（Security）需求的程序 • 藉由保全性需求對抗各種威脅 • 瞭解可靠性（Reliability）規格的測量方式，以及如何定義可靠性需求

  3. 系統需求 • 功能性需求（Functional Requirements） • 檢查錯誤 • 從錯誤狀態中復原 • 非功能性需求（Non-Functional Requirements） • 可靠度（Reliability） • 可用性（Availability）

  4. 9.1 風險性規格Risk Driven Specification • 關鍵系統的規格針對系統的可信賴度 • 補充一般的需求規格程序的不足 • 瞭解系統所面對的風險，找出能應付風險的可信賴度需求 • 風險性規格程序的過程包括 • 瞭解系統所面對的風險 • 找出根源 • 制定能夠管理這些風險的需求。

  5. Risk Decomposition Risk Reduction Assessment Risk Analysis & Classification Risk Identification Risk Assessment Risk Description Root Cause Analysis Dependability Requirements

  6. 進行風險分析的程序 • 風險識別（Risk Identification） • 找出可能出現的風險 • 和系統環境有關 • 風險分析和分類（Risk Analysis and Classification） • 風險必須個別處理 • 特別嚴重和令人難以置信的風險必須做進一步的分析 • 不太可能發生的風險會在這個階段被刪除

  7. 進行風險分析的程序 • 風險分解（Risk Decomposition） • 對每個風險個別分析，找出造成風險的根源 • 失誤樹分析法（Fault-Tree Analysis）。 • 風險降低評估（Risk Reduction Assessment） • 提出可降低或消除風險的方法，轉換成可信賴度需求 • 預防風險發生 • 即使風險發生了，也在控制範圍之內

  8. 風險識別Risk Identification • 找出關鍵系統必須應付的風險。 • 困難 • 風險通常不在正常的狀況下發生 • 系統元件以特定的方式互動產生風險 • 罕見的環境狀況 • 可能導致意外的危險（Hazard） • 身體的危險、電力的危險、生理的危險、幅射危險，以及服務故障危險等。

  9. 風險分析和分類Risk Analysis & Classification • 主要的目的 • 風險發生的機率有多高？ • 萬一風險發生，危害程度有多大？ • 是否能夠接受？ • Statement of acceptance

  10. 風險的接受程度 • 無法忍受（Intolerable） • 不能讓這種風險發生 • 威脅人命、影響企業財務穩定，而且發生機率不低 • 盡可能降低危險（As Low As Reasonably Practical, ALARP） • 在可能的範圍內（考慮成本），盡可能避免發生 • 比較不嚴重，或是發生機率很低的風險。 • 可接受（Acceptable） • 仍應採取所有可能的步驟，降低危險發生的可能性， • 不增加成本、延遲系統交付時間或是影響其他非功能屬性

  11. 風險等級

  12. 機率高低 預估風險 危害程度 中 高 低

  13. 風險分解Risk Decomposition • 找出根本原因（Root Cause） • 演繹法（Deductive） • 由上往下，比較容易使用 • 以風險為起點往下分析系統可能發生的故障 • 歸納法（Inductive） • 從系統可能發生的故障開始，找出可能引發這些故障的危險。

  14. 失誤樹分析Fault-Tree Analysis 找出不希望它發生的事件 回溯，找出可能的原因 不同狀態彼此之間可以 AND、OR 合併（AND）多項原因的風險比較不會發生

  15. 風險降低評估 • 風險避免（Risk Avoidance） • 令風險或危險不會發生 • 風險偵測與移除（Risk Detection and Removal） • 在風險導致意外發生前，先偵測並排除該風險 • 限制損害程度（Damage Limitation） • 將意外的傷害降到最低

  16. 9.2 安全規格Safety Specification • 定義安全規格與保險的程序，是整體安全生命週期（Safety Life Cycle）的一部分 • 安全管理國際標準 IEC 61508 • IEC 1998 • 功能性安全需求（Functional Safety Requirement） • 安全性整合需求（Safety Integrity Requirement） • 安全整合等級（Safety Integrity Level, SIL） • 系統越關鍵，SIL越高

  17. IEC 61508安全生命週期

  18. 9.3 保全規格 Security Requirement • 不適合量化 • 通常是「不應該」的需求 • “Shall NOT” Requirements • 定義無法接受的系統行為，而不是定義系統的功能需求。 • 傳統的（非電腦化）保全分析方法，是以被保護的資產以及對組織的價值為主。

  19. 保全分析程序包括下列階段 • 資產識別與評估 • 識別資產（資料和程式） • 所需要的保護程度（依資產的價值而定） • 威脅分析與風險評估 • 找出保全方面可能的威脅，評估這些威脅相關的風險 • 威脅歸類 • 找出與資產相關的威脅，為每項資產列出相關威脅的清單 • 技術分析 • 評估可用的保全技術以及對已識別威脅的適用性。 • 制定保全需求規格 • 制定保全需求規格 • 明確列出可能用來保護系統抵抗威脅的保全技術

  20. 保全規格圖示

  21. 10種保全需求 識別（Identification） 驗證（Authentication） 授權（Authorization） 免疫（Immunity） 完整性（Integrity） 入侵偵測（Intrusion Detection） 無法否認（Non-repudiation） 隱私權（Privacy） 保全稽核（Security Auditing） 系統維護保全（System Maintenance Security）

  22. 9.4 軟體可靠性規格Software Reliability Specification • 應該從整體系統的角度考慮可靠性，而不是從元件層級 • 系統中的元件有相互依賴的關係，若其中一個元件故障可能就會擴散到整個系統，影響到其他元件的運作。

  23. 可靠性的3個方面 • 硬體可靠性（Hardware Reliability） • 硬體元件故障的機率有多高？ • 修復該元件所需的時間多長？ • 軟體可靠性（Software Reliability） • 軟體元件產生不正確輸出的可能性多大？ • 軟體不會因為用太久而磨損。即使產生不正確的結果，之後它還是能繼續正常運作。 • 操作員可靠性（Operator Reliability） • 操作人員犯錯的可能性多大？

  24. 硬體的可靠性測量值 • 故障前平均時間 • Mean Time to Failure 縮寫為 MTTF • 元件可正常運作的平均時間 • 修復前平均時間 • Mean Time to Repair 縮寫為 MTTR • 修復或替換該元件所需的時間

  25. 軟體的可靠性測量值 • 服務故障率 • Probability of Failure on Demand, POFOD • 出錯率 • Rate of Occurrence of Failure, ROCOF • 故障前平均時間 • Mean Time to Failure, MTTF • 可用率 • Availability

  26. 在評估系統可靠性時，可以使用下列3種測量方法： • 對系統服務發出固定次數的要求，測量系統發生故障的次數。這個方法可以用來測量POFOD。 • 測量系統發生故障之間的時間（或交易個數）。這個方法可以用來測量ROCOF和MTTF。 • 測量當系統發生故障，修復所花的時間或重新啟動的所需時間。假設系統必須連續提供服務，這個方法可以用來測量AVAIL。

  27. 非功能性的可靠性需求 • 在許多系統需求文件中，可靠性需求都沒有仔細描述。 • 可靠性規格是主觀且無法測量的。 • 描述系統動態行為的敘述也沒有意義。因為系統可靠性是受到軟體故障的影響，而非軟體缺陷。

  28. 建立可靠性規格的步驟 • 針對每個子系統找出各種可能發生的故障，並分析這些故障的後果。 • 以系統故障分析的結果將故障分成幾類。 • 針對每一種故障類別，使用適當的可靠性測量值來定義可靠性需求。 • 不同類別的故障不需要使用相同的測量值 • 在適當的時候，找出定義系統功能的可靠性需求，可以降低嚴重故障的機率。

  29. 範例：進銷存系統 • 進銷存系統應用於製造業或貿易公司，流程： • 客戶訂單：訂購項目、金額、交貨日期、交貨地址 • 檢查成品庫存量，是否能夠滿足訂購量？ • 如果庫存量不足，則開出工單（製令）安排生產流程。 • 依工單與BOM表向零件倉提取零件，若零件庫存不足，則開出採購單，進行採購程序。 • 庫存足夠，開出貨單，向成品倉提貨、檢驗、包裝出貨 • 結帳 • 客戶：應收帳款 • 廠商：應付帳款

  30. 範例：進銷存系統 • 風險識別（Risk Identification） • 訂單逾期未交貨 • 風險分析和分類（Risk Analysis and Classification） • 發生機率：Low • 危害程度：High • 接受度：Intolerable • 風險分解（Risk Decomposition） • 失誤樹分析法（Fault-Tree Analysis） • 風險降低評估（Risk Reduction Assessment）

More Related