Transcript 11. 第11章

第十一章 應用系統發展管理
本投影片（下稱教用資源）僅授權給採用教用資源相關之旗標書籍為教科書之授課老師
（下稱老師）專用，老師為教學使用之目的，得摘錄、編輯、重製教用資源（但使用量
不得超過各該教用資源內容之80%）以製作為輔助教學之教學投影片，並於授課時搭配
旗標書籍公開播放，但不得為網際網路公開傳輸之遠距教學、網路教學等之使用；除此
之外，老師不得再授權予任何第三人使用，並不得將依此授權所製作之教學投影片之相
關著作物移作他用。
1
第十一章 應用系統發展管理
 應用程式開發是軟體安全的第一步，軟體開發者必須了解
開發程序與模式，並導入相關之安全管理機制，以確保軟
體安全，本章介紹與軟體開發相關之管理模式。軟體開發
也常忽略軟體測試，本章亦介紹各種軟體測試概念，以提
高系統之安全性。有良好的軟體開發管理才能使軟體系統
具備整體安全性，提供良好的服務。本章包含以下內容：
 軟體系統開發
 軟體發展模式
 軟體測試
 軟體建構管理
 資訊安全架構
 服務等級合約
2
11.1 軟體系統開發
 軟體系統的發展是一個循環的過程，稱為系統發展生命週期 (System
Development Life Cycle；SDLC)，如圖 11-1。基本上，系統發展生
命週期包含四個階段：




概念階段
發展階段
執行階段
結束階段
階段 I
概念
階段 II
發展
階段 III
執行
階段 IV
結束
工
作
量
時間
圖 11-1 系統發展的四個階段
3
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)。
4
11.2 軟體發展模式
 軟體系統發展過程，遵循軟體發展模式，可以建立系統化
之步驟及執行程序，有利於標準、規範與政策之推行，使
得開發的過程更有效率，能確保品質，並且容易管理。不
同的軟體發展模式適用於不同的資訊系統開發。
5
11.2.1 瀑布模式
 瀑布模式 ( Waterfall Model ) 是一種軟體系統開發方法，將系統開發過程分成
四個階段：分析 (Analysis)、設計 (Design)、實作(Implementation) 與測試
(Testing)，明確定義每一階段的工作。當面對比較複雜的系統時，其實作階
段可以在細分成多個階段。例如圖11-2。
 對於較小型或比較單純的系統時，使用瀑布模式來開發系統，各個階段所需
交付的文件與完成的任務都很明確，管理容易。但瀑布模式也有其缺點，必
須要等到最後階段，才能有成果，風險較高，如果分析階段不夠明確，設計
與實作階段都很難實施，修改原分析文件工程浩大，耗費時間與經費。
分析
設計
實作
測試
圖 11-2 瀑布模式
6
11.2.2 螺旋模式
 螺旋模式 ( Spiral Model )
如迴圈般地持續發展系
統，由雛型發展開始以至
於系統成熟。例如圖113，螺旋模式包含四個階
段：
 決定目標、可行方案與限
制
 開發雛型
 發展與驗證下階段產品
 規劃下階段
決定目標
可行方案與限制
風險分析
雛形_2
雛形_1
規劃下一階段
發展驗證
下一階層產品
圖 11- 3 螺旋模式
7
11.2.2 螺旋模式
 在發展雛型之前需要經過風險分析，方案評估與風險識別
並解決問題，這些是『決定目標、可行方案與限制』階段
的工作。『發展與驗證下階段產品』階段，則依雛型建立
模型與標竿，作為下階段參考，在本階段的工作，包含：
建立需求、設計、細部設計、單元測試、整合測試、驗證
測試等規劃設計。『規劃下階段』階段，則包含發展計劃
與整合測試計劃。依序重覆地執行上述四個階段工作，以
至於完成產品。
8
11.2.3 軟體能力成熟度模式
 軟體能力成熟度模式可協助整合傳統上分開的企
業組織功能，並訂立流程改善目標及優先順序，
同時為欲實行最佳流程的公司提供指引及評估。
軟體能力成熟度模式依軟體發展的能力成熟分為
五個等級，如圖 11-4：
初始級 ( Initial )
管理級 ( Managed )
定義級 ( Defined )
量化管理級 ( Quantitatively Managed )
最佳化級 ( Optimizing )
9
11.2.3 軟體能力成熟度模式
 『初始級』成熟度沒有軟
體發展流程，只在事件發
生後，反應式的改進。
『管理級』成熟度已有專
案流程定義。『定義級』
成熟度已有機構的流程定
義，軟體發展依照一套正
式且有文件的流程，在既
定的發展模式，並積極改
善流程。『量化管理級』
成熟度盡可能了解發展流
程並量化，流程是可以度
量與控制，依照量化數
據，改進流程。『最佳化
級』成熟度能持續與專注
在流程改善。
最佳化級
專注與持續流程改善
量化管理級
流程可度量與控制
定義級
機構流程已定義
管理級
專案流程已定義
初始級
沒有定義專案流程
圖 11- 4成熟度等級
10
11.2.4 Rational 統一流程 (RUP)模式
 Rational 統一流程 ( Rational Unified Process ； RUP) 具
有很多優點，是由Rational 公司發展，採用瀑布式改良開
發流程，在迭代的開發過程，建立了簡潔和清晰的過程結
構，為開發過程提供較大的通用性。
 傳統上的項目組織是順序地通過每個工作流 (Workflow)，
每個工作流只有一次，也就是我們熟悉的瀑布模式生命週
期。
11
11.2.4 Rational 統一流程 (RUP)模式
 RUP 模式軟體工程，由Rational 公司發展，採用
瀑布式改良開發流程，分為四個階段：
起始階段 (Initial phase)
精細規劃階段 (Elaboration phase)
建構階段 (Construction phase)
移轉階段 (Transition phase)
12
11.2.4 Rational 統一流程 (RUP)模式
 RUP中有九個核心的工作流 (Core Workflows)：
商業建模 (Business Modeling)
需求 (Requirements)
分析和設計 (Analysis & Design)
實作 (Implementation)
測試 (Test)
部署 (Deployment)
配置和變更管理 (Configuration & Change Management)
項目管理 (Project Management)
環境 (Environment)
13
11.2.4 Rational 統一流程 (RUP)模式
 RUP 模式與傳統的瀑布模式相比較，其迭代過程
具有以下優點：
降低了經費支出的風險。管理與開發人員了解開發過程，
減少重覆開發的流程，解省經費的支出。
降低了產品延誤上市的風險。通過在開發早期就確定風
險，可以盡早來解決問題，而不至於延誤到開發後期，因
匆忙而無法解決問題。
加速工程進度。因為開發人員清楚問題的焦點所在，有利
於解決問題，提高工作效率。
14
11.3 軟體測試
 軟體測試依照軟體發展程序，包含以下各種測
試：
單元測試 (Unit Test)
功能測試 (Function Test)
整合測試 (Integration Test)
驗收測試 (User Acceptance Test；UAT)
 這些測試最終目的就是為了讓整個系統能夠正常
順利的運作，只要測試的項目涵蓋範圍夠廣泛完
整，那麼就可以精確掌握各種可能的狀況，讓系
統出錯的機率降到最低。
15
11.3 軟體測試
 在軟體發展完成交付使用前或發布前，需要經過
全面完整的測試，軟體測試方法有兩種：
白箱測試 ( White Box Testing )
黑箱測試 ( Black Box Testing )
 白箱測試，測試程式內部邏輯架構的正確性。白
箱測試使用測試資料，檢查特定的條件或迴圈，
是否與預計之狀態一致，判斷內部邏輯的正確性。
比較重要白箱測試方法是路徑測試 ( Path Testing )
和資料流測試 (Data Flow Testing )。
16
11.3 軟體測試
 黑箱測試，則是測試軟體是否符合功能需求，對於軟體做
介面測試。如圖11-5，測試程式輸出與輸入之間的正確
性。
輸入資料
待測系統
輸出資料
判斷
正確
不正確
圖11-5 黑箱測試示意圖
17
11.3 軟體測試
 白箱測試與黑箱測試皆是系統重要的測試，在測試概念、
測試要項與測試內容皆不一樣，其主要差異比較如表111。
表11- 1白箱測試與黑箱測試之差異
測試種類
白箱測試
黑箱測試
測試概念
結構性測試
功能測試
測試要項
檢查特定的條件或迴圈，是否與
預期之狀態一致
不合乎規格或功能遺漏、介面
錯誤、功能錯誤、資料結構錯
誤、啟動或結束錯誤
測試內容
軟體內容仔細檢查
程式輸出與輸入之間的正確性
18
11.4 軟體建構管理
 為避免已審查定案的工作產出遭受任意更改，而造成其他
相關人員工作之錯誤，則需要建立一套對建構項目妥善管
理控制的流程和方法，讓大家共同遵守，以避免失去控
制。
 軟體建構管理，即是協調開發週期中相關的管理工作，以
避免版本的混亂與錯誤，尤其當用戶需求變更時；並採用
適當的管理工具，以增進管理的效率。
 在系統上線營運時，要保持系統的完整性，若任意改變系
統的環境或參數時，會使系統不穩定、產生漏洞、缺失、
錯誤，降低系統之安全性，造成系統安全弱點。因此需要
完善的建構管理，以降低風險，提高系統安全性。
19
11.4 軟體建構管理
 建構管理包含四項主要工作：
建構識別 ( Configuration Identification)
建構控制 ( Configuration Control)
建構狀態記錄 ( Configuration Status Accounting )
建構審查 ( Configuration Audit)
 建構識別是為了要能有效率與清楚的控管建構項
目，必須針對每一個建構項目分別命名。建構管
理小組必須制訂建構項目的命名規則，以利建構
項目命名後的版本管理工作。
20
11.4 軟體建構管理
 建構控制，系統開發完成或已上線的系統，若要更改系統
參數、程式、或架構，需要經由建構管理流程去改變，包
含三種程序：
 需求控制 ( Request Control )
 變更控制 ( Change Control )
 釋放控制 ( Release Control )
 建構狀態記錄，任何異動都要提出申請，由建構管理人員
評估其影響層面，並通知專案負責人，由其召集相關單位
進行評估，並決定是否准予異動，並加以紀錄追蹤。
 建構稽核，為達成對於建構管理系統中的項目的正確性，
建構管理人員需要定時檢視建構管理項目以確保其結構的
完整性。
21
11.4 軟體建構管理
 建構管理需要建構管理工具的輔助，如圖11-6，為建構管理工具 Star
Team ，圖中顯示其在管理軟體能力成熟度整合 ( CMMI ) 之各項文
件。
圖11-6 建構管理工具
22
11.5 資訊安全架構
 企業資訊安全架構，涵蓋企業安全政策、隱私權保護、降
低威脅、交易與資料保護、應用程式安全、身份識別、存
取管理、實體安全與人員安全等重大安全議題進行分析評
估，以確保企業資訊安全程度能滿足內部營運及外部法規
之要求。
 企業的資訊服務部門必須建置完善的資訊安全機制，以防
止其核心資訊系統與資料遭受內部的破壞者竊取、竄改、
或破壞。並且避免外部的駭客透過網際網路惡意入侵、攻
擊企業營運的神經中樞─網路系統，造成網路服務中斷而
影響其正常運作。
 資訊安全架構工具，包含：防火牆、加密系統、負載平衡、
管理分析系統、網頁過濾與稽核系統、郵件備份與稽核系
統、網路防毒牆、動態密碼卡、入侵偵測系統、弱點稽核
系統等。
23
11.5 資訊安全架構
 在所有安全系統中，硬體設備與作業系統都需要
具備基本的安全等級。作業系統安全架構，包含
以下幾個層面：
流程獨立 ( Process Isolation )
保護圈環 ( Protection Rings )
抽象介面 ( Abstraction Interface)
抽象介面 ( Abstraction Interface)
 作業系統中的各個流程獨立完成，每個流程有隔
離機制，互不影響，各個流程有自己資料堆疊、
記憶體空間等系統資源，透過系統功能與其它流
程交換資料。
24
11.5 資訊安全架構
 保護圈環提供作業系統安
全防護，限制系統的執行
權限，以達到保護系統的
目的。如圖11-7為四階層
的作業系統保護圈環。
 抽象介面是簡化與一般化
的使用者介面，使用者與
程式開發者不需要了解使
用資源之細節，即可以使
用系統資源，細節封裝在
更低階的程式中。
Level 3
Level 2
Level 1
Level
2350 0
圖 11-7 作業系統保護圈環示意圖
25
11.5 資訊安全架構
 Level 0 表示作業系統的核心，是系統的核心流
程，可以控制系統所有資源，使用資源必須要完
全確認的使用權限，所以在此圈環執行的流程稱
為特權模式 ( Privileged Mode ) 或監管模式
( Supervisory Mode )。
 Level 1 和 2 是驅動程式或作業系統的其它服務程
式，提供高階使用系統資源的介面。
 Level 3 是應用程式，這一階層常稱為使用者模式
( User Mode ) 或保護模式 ( Protected Mode )，
這一模式不可以直接存取系統資源，必須經過授
權才可以使用系統資源。
26
11.6 服務等級合約
 資訊系統上線營運後，系統開發廠商如無法提供後續的服
務，將造成業者或顧客重大損失。為了確保後續的服務品
質，需要訂立服務等級合約 ( Service Level Agreements；
SLA )。
 服務等級合約需要考慮項目如下：
 系統上線時間 ( Percentage of Overall Operating Time )
 系統連續停止運作時間 ( Maximum Consecutive Downtime )
 尖峰容量 ( Peak Load )
 平均負載 ( Average Load )
 診斷責任 ( Responsibility for Diagnostics )
 故障復原時間 ( Failover Time )
27
11.6 服務等級合約
 服務等級合約之週期包含五項：
 產品與服務發展
 協商與銷售
 提供與改進
 執行
 評估
 產品與服務發展，公司與客戶簽訂服務等級合約時，首先
需要了解客戶需求，確認適當的服務特性，確認資源與能
力。協商與銷售，依照服務的特性，選取相當的服務水準
與種類。提供與改進，公司提供所需的服務與資源。執行，
一般狀態下的服務提供與監控，即時報告與服務品質的確
認，服務水準發生變異時的即時處理。評估，客戶進行定
期評估與內部營業評估。
28