E-mail : lcwu@cht.com.tw 「資訊安全國家標準草案之研擬」計畫 之 軟體處理評估分項計畫 主講者：吳林全 先生 E-mail : lcwu@cht.com.tw.

Presentation on theme: "E-mail : lcwu@cht.com.tw 「資訊安全國家標準草案之研擬」計畫 之 軟體處理評估分項計畫 主講者：吳林全 先生 E-mail : lcwu@cht.com.tw."— Presentation transcript:

1 E-mail : lcwu@cht.com.tw
「資訊安全國家標準草案之研擬」計畫 之 軟體處理評估分項計畫 主講者：吳林全 先生

2 簡報大綱 簡介 ISO — 軟體生命週期之程序 ISO — 軟體程序評鑑 結語與討論

3 簡介

4 IT 安全之階層化示意

5 「資訊安全國家標準草案之研擬」計畫 軟體程序評鑑分項計畫(計畫主持人：劉燦雄 博士) 資訊安全產品驗證分項計畫 資訊安全管理驗證分項計畫
資訊安全管理認證程序分項計畫 資訊安全機制標準規範實作研擬分項計畫

6 軟體程序評估分項計畫成果 軟體生命週期之程序 軟體程序評鑑 系統及軟體完整性等級
符合 IEEE/EIA P 之我國國家標準草案 符合 IEEE/EIA P 之我國國家標準草案 符合 IEEE/EIA P 之我國國家標準草案 軟體程序評鑑 符合 ISO/IEC TR 之我國國家標準草案 符合 ISO/IEC TR 之我國國家標準草案 符合 ISO/IEC TR 之我國國家標準草案 符合 ISO/IEC TR 之我國國家標準草案 符合 ISO/IEC TR 之我國國家標準草案 符合 ISO/IEC TR 之我國國家標準草案 符合 ISO/IEC TR 之我國國家標準草案 符合 ISO/IEC TR 之我國國家標準草案 符合 ISO/IEC TR 之我國國家標準草案 系統及軟體完整性等級 符合 ISO/IEC 之我國國家標準草案

7 緣由 軟體開發工作的複雜性甚高，大部分情況會發生錯誤而只有少許的機會能正確運作無誤
瞭解軟體開發時所涉及的程序種類，以及根據某些指標來評估所使用程序的成熟度，可利用評估後的結果來改善軟體的品質，以提昇系統和產品的安全性及可靠度。 若能遵循某種程序、規則或綱要指引，則： 吾人可使用相似的方法來解決類似的問題 吾人總是能知道下一步如何進行 吾人能累積經驗以改進方法 軟體開發工作將是可確定 軟體開發工作能被控管

8 ISO/IEEE 12207 軟體生命週期之程序

9 程序的種類 主要生命週期程序 (Primary) 組織生命週期程序 (Organizational) 支援生命週期程序
1.客戶及供應者 2.工程技術 組織生命週期程序 (Organizational) 1.管理 2.組織 支援生命週期程序 (Supporting)

10 主要生命週期程序(Primary)

11 支援生命週期程序(Supporting)

12 組織生命週期程序(Organizational)

13 ISO 12207 定義的所有程序 支 援 主 要 組 織 支援 顧客與供應者 管理 工程技術 組織 程序種類 程序
SUP.1 文件說明 (7) SUP.2 組態管理 (9) SUP.3 品質保證 (7) SUP.4 驗證 (4) SUP.5 確認 (4) SUP.6 共同覆審 (8) SUP.7 稽核 (8) SUP.8 問題排除 (6) 支 援 主 要 基本 顧客與供應者 CUS.1 取得 (3) CUS.1.1 取得籌備 (4) CUS.1.2 選擇供應商 (3) CUS.1.3 監督供應商 (4) CUS.1.4 顧客接受度 (2) CUS.2 供應 (5) CUS.3 需求抽取 (6) CUS.4 運作 (3) CUS.4.1 運作使用 (8) CUS.4.2 顧客支援 (5) 子程序 組 織 管理 MAN.1 管理 (8) MAN.2 專案管理 (12) MAN.3 品質管理 (6) MAN.4 風險管理 (8) 工程技術 ENG.1 開發 (4) ENG.1.1 系統需求分析及設計 (7) ENG.1.2 軟體需求分析) (6) ENG.1.3 軟體設計 (5) ENG.1.4 軟體建構 (4) ENG.1.5 軟體整合 (6) ENG.1.6 軟體測試 (4) ENG.1.7 系統整合及測試 (8) ENG.2 系統及軟體維護 (7) 組織 ORG.1 組織調整 (5) ORG.2 改善 (4) ORG.2.1 程序建立 (9) ORG.2.2 程序評等 (10) ORG.2.3 程序改善 (9) ORG.3 人力資源管理 (10) ORG.4 基礎架構 (7) ORG.5 評定 (7) ORG.6 重新使用 (7) 共有 249 項基本實務

14 範例：程序定義 ENG.1.3 軟體設計(Software Design) purpose note 目的
軟體設計程序的目的係定義適當的軟體設計，以實現其需求條件並可 依該需求來進行測試。 結果 — 發展一架構性的設計，以說明將實現軟體需求的主要軟體元件； — 定義每一軟體元件的內部和外部介面； — 發展細部的設計，以說明可製作和測試的軟體單元； — 在軟體需求和軟體設計之間建立一致性。 備註 細部的設計包括軟體單元之間的介面規格。 note

15 ISO 15504 軟體程序評鑑

16 ISO 15504 歷史沿革 1987~1989 美國 SEI 開始相關的計畫
1991 美國 SEI 公布能力成熟度模型(CMM) 1.0 版 ISO 成立程序評鑑的工作小組 1993 ISO 著手制訂程序評鑑的國際標準 美國 SEI 公布能力成熟度模型(CMM) 1.1 版 1995 ISO 公布 SPICE 草案標準 1996 ISO 公布 SPICE 2.0 版 1998 ISO 公布 技術報告 2001 ISO 預計定案及公布 標準(?)

17 SPICE 計畫 計畫目標： 滿足軟對評鑑軟體程序能力日益增加的要求 提供組織良好的程序評鑑架構 統合現有的軟體程序評鑑及改善之模型與方法

18 ISO/IEC TR 15504 標準由來： 內容： 特性：
1998 年由 ISO/IEC/JTC1 SC7 WG10 負責將 SPICE V2 轉換成軟體程序評鑑的國際標準 內容： 程序評鑑 勝任評鑑員的培訓 程序能力判定 持續程序改善 特性： 牽涉廣泛 包括軟體的獲取、供應、發展、操作、維護及支援等工作程序 模組化 允許選取個別的程序來進行評鑑 每個評鑑後的程序會獲得一個能力的標度(scale)

19 實施 ISO 15504 的好處 對需用者而言能提供： 對供應者而言能提供： 對評鑑員而言能提供： 判定軟體供應者程序之現有或潛在的能力
判定本身軟體程序之現有或潛在的能力 定義軟體程序改善之範圍及優先次序 定義軟體程序改善之準則及架構 對評鑑員而言能提供： 實施程序評鑑的一致性架構

20 ISO 各冊的內容

21 軟體程序評鑑各組成元件之關係

22 參考模型與評鑑模型之關連性

23 評鑑模型 vs. 參考模型

24 程序之參考模型

25 程序之評鑑模型 利用二維圖形來表示程序及程序能力 程序經評鑑後會獲得一個能力等級之評估結果 程序(Process) 面向
程序種類 (Process Categories) 程序 (P1, …, Pn) 能力(Capability) 面向 能力等級 (CL1, …, CL5) 程序之能力屬性 (Attributes) 程序經評鑑後會獲得一個能力等級之評估結果 CL5 CL4 CL3 CL2 CL1 CL0 CUS.1 CUS.2...ORG.6

26 軟體程序評鑑

27 程序評鑑之流程

28 Level 0 : 未完成程序(Incomplete)
定義：未實作該程序，或是實作了該程序但未能 達到其目的。 證據：欠缺可證實達成目的之工作產出。

29 Level 1 : 已執行程序(Performed)
定義：已經達到程序目的，但該成果可能未詳細 規畫和追蹤。 證據：具有可證實達成目的之工作產出。

30 Level 2 : 已管理程序(Managed)
定義：程序經詳細計畫和追蹤並依規定程序交出 工作產出，且其必須符合規定的標準和需求 條件。 證據：程序能在既定時間內，利用所需資源交付 可接受的工作產出品質。

31 Level 3 : 已建置程序(Established)
定義：使用基於良好軟體工程方法之既定程序來 加以執行和管理。 證據：使用能夠達成其程序結果的既定程序(defined process)。

32 Level 4 : 可預測程序(Predictable)
定義：既定程序在實務上係一致地在所定義的控管 範圍內執行，以達成其既定的程序目標。 證據：對程序能力以量化來表示，並能預測及管理 已改善的能力。故一致地在所定義的限制中 執行，以達成既定的程序結果。

33 Level 5 :最佳化程序(Optimizing)
定義：所實作的程序可達到重複性，以符合其所定 義的業務目標，並建置量化的程序有效性 (effectiveness)和效率(efficiency)的績效目標。 證據：導入創新的理論和技術，以及變更非有效的 程序，可動態變更和調整，以有效地符合目 前和未來的業務目標。

34 程序屬性及能力等級 Level 5 最佳化 Level 4 可預測 Level 3 已建置 Level 2 已管理 Level 1 已執行
PA.5.1 程序變更 PA.5.2 持續改善 最佳化(Optimising) 對持續改善的程序作量化評定 Level 4 可預測 PA.4.1 評 定 PA.4.2 程序控制 可預測(Predictable) 量測單位致使程序效能及結果可控制 Level 3 已建置 PA.3.1 程序定義 PA.3.2 程序資源 已建置(Established) 修改預先定義的程序供特殊用途且資源受到管理 Level 2 已管理 PA.2.1 效 能 管 理 PA.2.2 工作產出管理 已管理(Managed) 程序及工作產出受管理且能歸屬責任 Level 1 已執行 PA.1.1 程序效能 已執行(Performed) 程序直覺地執行而輸入與輸出的工作產出皆可用 未完成(Incomplete) 效能及結果都是不完整且凌亂的程序 Level 0 未完成

35 能力判定之流程

36 程序指標 vs. 能力等級

37 程序屬性的標度

38 程序的能力等級

39 範例：程序評鑑 目標：欲對客戶在開發軟體的需求程序進行評鑑 可能選取的實作程序為： 工作內容： CUS.2 供應 CUS.3 需求引出
ENG.1.1 系統需求及設計 ENG.1.2 軟體需求分析 SUP.1 文件製作 工作內容： 訪談專案經理及相關的軟體發展人員 檢視合約內容、軟體需求規格、使用者需求描述及變更請求記錄等文件

40 範例：程序評鑑(續) 能力判定的步驟： 檢查每個程序的基本實務以確定此程序為已執行程序(Level 1)
每個程序皆會得到 N, P, L 或 F 其中之一的標度 若其標度為 N 或 P，則執行此程序的能力為 Level 0 若標度為 L 或 F，則此程序可能具備更高能力等級的屬性 CL5 CL4 CL3 CL2 CL1 CL0 CUS CUS SUP.1

41 依程序屬性來表示評鑑結果

42 評鑑後的程序能力等級

43 程序改善之流程

44 資料來源：SEI 1999 “Process Maturity Profile of Software Community”
程序改善所需的時間 資料來源：SEI 1999 “Process Maturity Profile of Software Community”

45 結語及討論

46 結語 Bruce Schneier : 「Security is a process, not a product」
標準化的軟體程序評鑑架構及方法，有助於加速軟體工業的蓬勃發展及提升軟體的品質

47 參考文獻 ISO/IEC 12207 Series Standard, 1995
K. El Emam and D. Goldenson, “An Empirical Review of Software Process Assessment”, 2000 K. El Emam and H.W. Jung, “An Empirical Evaluation of the ISO/IEC Assessment Model”, 2000 K. El Emam and A. Birk, “Validating the ISO/IEC Measure of Software Requirement Analysis Process Capability”, 1999 K. El Emam, “The Internal Consistency of the ISO/IEC Software Process Capability Scale”, 1995 Steve McConnell, “After the Gold Rush”, 1999

48 討論 Any question ?