1

第十一章 應用系統發展管理

本投影片（下稱教用資源）僅授權給採用教用資源相關之旗標書籍為教科書之授課老師（下稱老師）專用，老師為教學使用之目的，得摘錄、編輯、重製教用資源（但使用量不得超過各該教用資源內容之 80% ）以製作為輔助教學之教學投影片，並於授課時搭配旗標書籍公開播放，但不得為網際網路公開傳輸之遠距教學、網路教學等之使用；除此之外，老師不得再授權予任何第三人使用，並不得將依此授權所製作之教學投影片之相關著作物移作他用。

2

第十一章 應用系統發展管理 應用程式開發是軟體安全的第一步，軟體開發者必須了解

開發程序與模式，並導入相關之安全管理機制，以確保軟體安全，本章介紹與軟體開發相關之管理模式。軟體開發也常忽略軟體測試，本章亦介紹各種軟體測試概念，以提高系統之安全性。有良好的軟體開發管理才能使軟體系統具備整體安全性，提供良好的服務。本章包含以下內容： 軟體系統開發 軟體發展模式 軟體測試 軟體建構管理 資訊安全架構 服務等級合約

3

11.1 軟體系統開發 軟體系統的發展是一個循環的過程，稱為系統發展生命週期 (System

Development Life Cycle ； SDLC) ，如圖 11-1 。基本上，系統發展生命週期包含四個階段： 概念階段 發展階段 執行階段 結束階段

工作量

I階段概念

I I階段發展

I I I階段執行

I V階段結束

時間

圖 11-1 系統發展的四個階段

4

11.1 軟體系統開發 軟體系統的發展從概念階段開始，經過發展階段、執行階

段、結束階段，資訊系統開發完成且正式啟用。導入使用一些時日之後，為了因應使用者需求的改變，系統需要修正或更新，再回到系統分析的階段，再一次進入發展階段，如此週而復始。

為了控制軟體系統的品質、時效、與成本，軟體工程界發展出各種可供參考的軟體系統發展模型。在 1970 年由 Royce 等人發展出瀑布模式 (Waterfall Model) 。 1971 年 由 Mill 等人發展遞增模式 (Incremental Model) 。 1988 年 Boehm 發展出螺旋模式 (Spiral Model) 。至 1997 年，美國卡內基美隆大學發展出軟體能力成熟度整合模式 (Capacity Maturity Model Integration ； CMMI) 。而 1998 年，由 Rational 公司發展出統一流程模式 (Rational Unified Process ； RUP) 。

5

11.2 軟體發展模式 軟體系統發展過程，遵循軟體發展模式，可以建立系統化

之步驟及執行程序，有利於標準、規範與政策之推行，使得開發的過程更有效率，能確保品質，並且容易管理。不同的軟體發展模式適用於不同的資訊系統開發。

6

11.2.1 瀑布模式 瀑布模式 ( Waterfall Model ) 是一種軟體系統開發方法，將系統開發過程分

成四個階段：分析 (Analysis) 、設計 (Design) 、實作 (Implementation) 與測試 (Testing) ，明確定義每一階段的工作。當面對比較複雜的系統時，其實作階段可以在細分成多個階段。例如圖 11-2 。

對於較小型或比較單純的系統時，使用瀑布模式來開發系統，各個階段所需交付的文件與完成的任務都很明確，管理容易。但瀑布模式也有其缺點，必須要等到最後階段，才能有成果，風險較高，如果分析階段不夠明確，設計與實作階段都很難實施，修改原分析文件工程浩大，耗費時間與經費。

分析

設計

實作

測試

圖 11-2 瀑布模式

7

11.2.2 螺旋模式 螺旋模式 ( Spiral Model )

如迴圈般地持續發展系統，由雛型發展開始以至於系統成熟。例如圖 11-3 ，螺旋模式包含四個階段： 決定目標、可行方案與限

制 開發雛型 發展與驗證下階段產品 規劃下階段

_1雛形_2雛形

風險分析

發展驗證下一階層產品規劃下一階段

、 決定目標可行方案與限制

圖 11- 3 螺旋模式

8

11.2.2 螺旋模式 在發展雛型之前需要經過風險分析，方案評估與風險識別

並解決問題，這些是『決定目標、可行方案與限制』階段的工作。『發展與驗證下階段產品』階段，則依雛型建立模型與標竿，作為下階段參考，在本階段的工作，包含：建立需求、設計、細部設計、單元測試、整合測試、驗證測試等規劃設計。『規劃下階段』階段，則包含發展計劃與整合測試計劃。依序重覆地執行上述四個階段工作，以至於完成產品。

9

11.2.3 軟體能力成熟度模式

軟體能力成熟度模式可協助整合傳統上分開的企業組織功能，並訂立流程改善目標及優先順序，同時為欲實行最佳流程的公司提供指引及評估。軟體能力成熟度模式依軟體發展的能力成熟分為五個等級，如圖 11-4 ： 初始級 ( Initial ) 管理級 ( Managed ) 定義級 ( Defined ) 量化管理級 ( Quantitatively Managed ) 最佳化級 ( Optimizing )

10

11.2.3 軟體能力成熟度模式 『初始級』成熟度沒有軟體

發展流程，只在事件發生後，反應式的改進。『管理級』成熟度已有專案流程定義。『定義級』成熟度已有機構的流程定義，軟體發展依照一套正式且有文件的流程，在既定的發展模式，並積極改善流程。『量化管理級』成熟度盡可能了解發展流程並量化，流程是可以度量與控制，依照量化數據，改進流程。『最佳化級』成熟度能持續與專注在流程改善。 初始級

沒有定義專案流程

管理級專案流程已定義

定義級機構流程已定義

量化管理級流程可度量與控制

最佳化級專注與持續流程改善

圖 11- 4 成熟度等級

11

11.2.4 Rational 統一流程 (RUP) 模式

Rational 統一流程 ( Rational Unified Process ； RUP) 具有很多優點，是由 Rational 公司發展，採用瀑布式改良開發流程，在迭代的開發過程，建立了簡潔和清晰的過程結構，為開發過程提供較大的通用性。

傳統上的項目組織是順序地通過每個工作流 (Workflow) ，每個工作流只有一次，也就是我們熟悉的瀑布模式生命週期。

12

11.2.4 Rational 統一流程 (RUP) 模式

RUP 模式軟體工程，由 Rational 公司發展，採用瀑布式改良開發流程，分為四個階段： 起始階段 (Initial phase) 精細規劃階段 (Elaboration phase) 建構階段 (Construction phase) 移轉階段 (Transition phase)

13

11.2.4 Rational 統一流程 (RUP) 模式

RUP中有九個核心的工作流 (Core Workflows) ： 商業建模 (Business Modeling) 需求 (Requirements) 分析和設計 (Analysis & Design) 實作 (Implementation) 測試 (Test) 部署 (Deployment) 配置和變更管理 (Configuration & Change Management) 項目管理 (Project Management) 環境 (Environment)

14

11.2.4 Rational 統一流程 (RUP) 模式

RUP 模式與傳統的瀑布模式相比較，其迭代過程具有以下優點： 降低了經費支出的風險。管理與開發人員了解開發過程，減少重覆開發的流程，解省經費的支出。

降低了產品延誤上市的風險。通過在開發早期就確定風險，可以盡早來解決問題，而不至於延誤到開發後期，因匆忙而無法解決問題。

加速工程進度。因為開發人員清楚問題的焦點所在，有利於解決問題，提高工作效率。

15

11.3 軟體測試

軟體測試依照軟體發展程序，包含以下各種測試： 單元測試 (Unit Test) 功能測試 (Function Test) 整合測試 (Integration Test) 驗收測試 (User Acceptance Test ； UAT)

這些測試最終目的就是為了讓整個系統能夠正常順利的運作，只要測試的項目涵蓋範圍夠廣泛完整，那麼就可以精確掌握各種可能的狀況，讓系統出錯的機率降到最低。

16

11.3 軟體測試

在軟體發展完成交付使用前或發布前，需要經過全面完整的測試，軟體測試方法有兩種： 白箱測試 ( White Box Testing ) 黑箱測試 ( Black Box Testing )

白箱測試，測試程式內部邏輯架構的正確性。白箱測試使用測試資料，檢查特定的條件或迴圈，是否與預計之狀態一致，判斷內部邏輯的正確性。比較重要白箱測試方法是路徑測試 ( Path Testing ) 和資料流測試 (Data Flow Testing ) 。

17

11.3 軟體測試 黑箱測試，則是測試軟體是否符合功能需求，對於軟體做

介面測試。如圖 11-5 ，測試程式輸出與輸入之間的正確性。

待測系統輸入資料 輸出資料 判斷 正確

不正確

圖 11-5 黑箱測試示意圖

18

11.3 軟體測試 白箱測試與黑箱測試皆是系統重要的測試，在測試概念、

測試要項與測試內容皆不一樣，其主要差異比較如表 11-1 。

測試種類 白箱測試 黑箱測試測試概念 結構性測試 功能測試測試要項 檢查特定的條件或迴圈，是否與

預期之狀態一致不合乎規格或功能遺漏、介面錯誤、功能錯誤、資料結構錯誤、啟動或結束錯誤

測試內容 軟體內容仔細檢查 程式輸出與輸入之間的正確性

表 11- 1白箱測試與黑箱測試之差異

19

11.4 軟體建構管理 為避免已審查定案的工作產出遭受任意更改，而造成其他

相關人員工作之錯誤，則需要建立一套對建構項目妥善管理控制的流程和方法，讓大家共同遵守，以避免失去控制。

軟體建構管理，即是協調開發週期中相關的管理工作，以避免版本的混亂與錯誤，尤其當用戶需求變更時；並採用適當的管理工具，以增進管理的效率。

在系統上線營運時，要保持系統的完整性，若任意改變系統的環境或參數時，會使系統不穩定、產生漏洞、缺失、錯誤，降低系統之安全性，造成系統安全弱點。因此需要完善的建構管理，以降低風險，提高系統安全性。

20

11.4 軟體建構管理

建構管理包含四項主要工作： 建構識別 ( Configuration Identification) 建構控制 ( Configuration Control) 建構狀態記錄 ( Configuration Status Accounting ) 建構審查 ( Configuration Audit)

建構識別是為了要能有效率與清楚的控管建構項目，必須針對每一個建構項目分別命名。建構管理小組必須制訂建構項目的命名規則，以利建構項目命名後的版本管理工作。

21

11.4 軟體建構管理 建構控制，系統開發完成或已上線的系統，若要更改系統

參數、程式、或架構，需要經由建構管理流程去改變，包含三種程序： 需求控制 ( Request Control ) 變更控制 ( Change Control ) 釋放控制 ( Release Control )

建構狀態記錄，任何異動都要提出申請，由建構管理人員評估其影響層面，並通知專案負責人，由其召集相關單位進行評估，並決定是否准予異動，並加以紀錄追蹤。

建構稽核，為達成對於建構管理系統中的項目的正確性，建構管理人員需要定時檢視建構管理項目以確保其結構的完整性。

22

11.4 軟體建構管理 建構管理需要建構管理工具的輔助，如圖 11-6 ，為建構管理工具 St

ar Team ，圖中顯示其在管理軟體能力成熟度整合 ( CMMI ) 之各項文件。

圖 11-6 建構管理工具

23

11.5 資訊安全架構 企業資訊安全架構，涵蓋企業安全政策、隱私權保護、降低威脅、交易與資料保護、應用程式安全、身份識別、存取管理、實體安全與人員安全等重大安全議題進行分析評估，以確保企業資訊安全程度能滿足內部營運及外部法規之要求。

企業的資訊服務部門必須建置完善的資訊安全機制，以防止其核心資訊系統與資料遭受內部的破壞者竊取、竄改、或破壞。並且避免外部的駭客透過網際網路惡意入侵、攻擊企業營運的神經中樞─網路系統，造成網路服務中斷而影響其正常運作。

資訊安全架構工具，包含：防火牆、加密系統、負載平衡、管理分析系統、網頁過濾與稽核系統、郵件備份與稽核系統、網路防毒牆、動態密碼卡、入侵偵測系統、弱點稽核系統等。

24

11.5 資訊安全架構 在所有安全系統中，硬體設備與作業系統都需要

具備基本的安全等級。作業系統安全架構，包含以下幾個層面： 流程獨立 ( Process Isolation ) 保護圈環 ( Protection Rings ) 抽象介面 ( Abstraction Interface) 抽象介面 ( Abstraction Interface)

作業系統中的各個流程獨立完成，每個流程有隔離機制，互不影響，各個流程有自己資料堆疊、記憶體空間等系統資源，透過系統功能與其它流程交換資料。

25

11.5 資訊安全架構 保護圈環提供作業系統安

全防護，限制系統的執行權限，以達到保護系統的目的。如圖 11-7 為四階層的作業系統保護圈環。

抽象介面是簡化與一般化的使用者介面，使用者與程式開發者不需要了解使用資源之細節，即可以使用系統資源，細節封裝在更低階的程式中。

2350Level 0

Level 1

Level 2

Level 3

圖 11-7 作業系統保護圈環示意圖

26

11.5 資訊安全架構 Level 0 表示作業系統的核心，是系統的核心流

程，可以控制系統所有資源，使用資源必須要完全確認的使用權限，所以在此圈環執行的流程稱為特權模式 ( Privileged Mode ) 或監管模式 ( Supervisory Mode ) 。

Level 1 和 2 是驅動程式或作業系統的其它服務程式，提供高階使用系統資源的介面。

Level 3 是應用程式，這一階層常稱為使用者模式 ( User Mode ) 或保護模式 ( Protected Mode ) ，這一模式不可以直接存取系統資源，必須經過授權才可以使用系統資源。

27

11.6 服務等級合約 資訊系統上線營運後，系統開發廠商如無法提供後續的服

務，將造成業者或顧客重大損失。為了確保後續的服務品質，需要訂立服務等級合約 ( Service Level Agreements ；SLA ) 。

服務等級合約需要考慮項目如下： 系統上線時間 ( Percentage of Overall Operating Time ) 系統連續停止運作時間 ( Maximum Consecutive Downtime ) 尖峰容量 ( Peak Load ) 平均負載 ( Average Load ) 診斷責任 ( Responsibility for Diagnostics ) 故障復原時間 ( Failover Time )

28

11.6 服務等級合約 服務等級合約之週期包含五項：

產品與服務發展 協商與銷售 提供與改進 執行 評估

產品與服務發展，公司與客戶簽訂服務等級合約時，首先需要了解客戶需求，確認適當的服務特性，確認資源與能力。協商與銷售，依照服務的特性，選取相當的服務水準與種類。提供與改進，公司提供所需的服務與資源。執行，一般狀態下的服務提供與監控，即時報告與服務品質的確認，服務水準發生變異時的即時處理。評估，客戶進行定期評估與內部營業評估。