應(yīng)用系統(tǒng)發(fā)展管理課件

1、第十一章 應(yīng)用系統(tǒng)發(fā)展管理本投影片（下稱教用資源）僅授權(quán)給採用教用資源相關(guān)之旗標(biāo)書籍為教科書之授課老師（下稱老師）專用，老師為教學(xué)使用之目的，得摘錄、編輯、重製教用資源（但使用量不得超過各該教用資源內(nèi)容之80%）以製作為輔助教學(xué)之教學(xué)投影片，並於授課時搭配旗標(biāo)書籍公開播放，但不得為網(wǎng)際網(wǎng)路公開傳輸之遠(yuǎn)距教學(xué)、網(wǎng)路教學(xué)等之使用；除此之外，老師不得再授權(quán)予任何第三人使用，並不得將依此授權(quán)所製作之教學(xué)投影片之相關(guān)著作物移作他用。1第十一章 應(yīng)用系統(tǒng)發(fā)展管理應(yīng)用程式開發(fā)是軟體安全的第一步，軟體開發(fā)者必須了解開發(fā)程序與模式，並導(dǎo)入相關(guān)之安全管理機制，以確保軟體安全，本章介紹與軟體開發(fā)相關(guān)之管理模式。軟體

2、開發(fā)也常忽略軟體測試，本章亦介紹各種軟體測試概念，以提高系統(tǒng)之安全性。有良好的軟體開發(fā)管理才能使軟體系統(tǒng)具備整體安全性，提供良好的服務(wù)。本章包含以下內(nèi)容：軟體系統(tǒng)開發(fā)軟體發(fā)展模式軟體測試軟體建構(gòu)管理資訊安全架構(gòu)服務(wù)等級合約211.1 軟體系統(tǒng)開發(fā)軟體系統(tǒng)的發(fā)展是一個循環(huán)的過程，稱為系統(tǒng)發(fā)展生命週期 (System Development Life Cycle；SDLC)，如圖 11-1?；旧?，系統(tǒng)發(fā)展生命週期包含四個階段：概念階段發(fā)展階段執(zhí)行階段結(jié)束階段圖 11-1 系統(tǒng)發(fā)展的四個階段311.1 軟體系統(tǒng)開發(fā)軟體系統(tǒng)的發(fā)展從概念階段開始，經(jīng)過發(fā)展階段、執(zhí)行階段、結(jié)束階段，資訊系統(tǒng)開發(fā)完成且正

3、式啟用。導(dǎo)入使用一些時日之後，為了因應(yīng)使用者需求的改變，系統(tǒng)需要修正或更新，再回到系統(tǒng)分析的階段，再一次進(jìn)入發(fā)展階段，如此週而復(fù)始。 為了控制軟體系統(tǒng)的品質(zhì)、時效、與成本，軟體工程界發(fā)展出各種可供參考的軟體系統(tǒng)發(fā)展模型。在1970 年由 Royce 等人發(fā)展出瀑布模式 (Waterfall Model) 。1971 年 由 Mill 等人發(fā)展遞增模式 (Incremental Model) 。1988 年Boehm 發(fā)展出螺旋模式 (Spiral Model)。至1997 年，美國卡內(nèi)基美隆大學(xué)發(fā)展出軟體能力成熟度整合模式 (Capacity Maturity Model Integratio

4、n；CMMI)。而 1998 年，由Rational 公司發(fā)展出統(tǒng)一流程模式 (Rational Unified Process；RUP)。 411.2 軟體發(fā)展模式 軟體系統(tǒng)發(fā)展過程，遵循軟體發(fā)展模式，可以建立系統(tǒng)化之步驟及執(zhí)行程序，有利於標(biāo)準(zhǔn)、規(guī)範(fàn)與政策之推行，使得開發(fā)的過程更有效率，能確保品質(zhì)，並且容易管理。不同的軟體發(fā)展模式適用於不同的資訊系統(tǒng)開發(fā)。511.2.1 瀑布模式瀑布模式 ( Waterfall Model ) 是一種軟體系統(tǒng)開發(fā)方法，將系統(tǒng)開發(fā)過程分成四個階段：分析 (Analysis)、設(shè)計 (Design)、實作(Implementation) 與測試 (Testing

5、)，明確定義每一階段的工作。當(dāng)面對比較複雜的系統(tǒng)時，其實作階段可以在細(xì)分成多個階段。例如圖11-2。對於較小型或比較單純的系統(tǒng)時，使用瀑布模式來開發(fā)系統(tǒng)，各個階段所需交付的文件與完成的任務(wù)都很明確，管理容易。但瀑布模式也有其缺點，必須要等到最後階段，才能有成果，風(fēng)險較高，如果分析階段不夠明確，設(shè)計與實作階段都很難實施，修改原分析文件工程浩大，耗費時間與經(jīng)費。圖 11-2 瀑布模式611.2.2 螺旋模式螺旋模式 ( Spiral Model ) 如迴圈般地持續(xù)發(fā)展系統(tǒng)，由雛型發(fā)展開始以至於系統(tǒng)成熟。例如圖11-3，螺旋模式包含四個階段：決定目標(biāo)、可行方案與限制開發(fā)雛型 發(fā)展與驗證下階段產(chǎn)品 規(guī)

6、劃下階段 圖 11- 3 螺旋模式711.2.2 螺旋模式在發(fā)展雛型之前需要經(jīng)過風(fēng)險分析，方案評估與風(fēng)險識別並解決問題，這些是決定目標(biāo)、可行方案與限制階段的工作。發(fā)展與驗證下階段產(chǎn)品階段，則依雛型建立模型與標(biāo)竿，作為下階段參考，在本階段的工作，包含：建立需求、設(shè)計、細(xì)部設(shè)計、單元測試、整合測試、驗證測試等規(guī)劃設(shè)計。規(guī)劃下階段階段，則包含發(fā)展計劃與整合測試計劃。依序重覆地執(zhí)行上述四個階段工作，以至於完成產(chǎn)品。811.2.3 軟體能力成熟度模式軟體能力成熟度模式可協(xié)助整合傳統(tǒng)上分開的企業(yè)組織功能，並訂立流程改善目標(biāo)及優(yōu)先順序，同時為欲實行最佳流程的公司提供指引及評估。軟體能力成熟度模式依軟體發(fā)展的

7、能力成熟分為五個等級，如圖 11-4：初始級 ( Initial )管理級 ( Managed )定義級 ( Defined )量化管理級 ( Quantitatively Managed )最佳化級 ( Optimizing )911.2.3 軟體能力成熟度模式初始級成熟度沒有軟體發(fā)展流程，只在事件發(fā)生後，反應(yīng)式的改進(jìn)。管理級成熟度已有專案流程定義。定義級成熟度已有機構(gòu)的流程定義，軟體發(fā)展依照一套正式且有文件的流程，在既定的發(fā)展模式，並積極改善流程。量化管理級成熟度盡可能了解發(fā)展流程並量化，流程是可以度量與控制，依照量化數(shù)據(jù)，改進(jìn)流程。最佳化級成熟度能持續(xù)與專注在流程改善。圖 11- 4成熟

8、度等級1011.2.4 Rational 統(tǒng)一流程 (RUP)模式Rational 統(tǒng)一流程 ( Rational Unified Process ； RUP) 具有很多優(yōu)點，是由Rational 公司發(fā)展，採用瀑布式改良開發(fā)流程，在迭代的開發(fā)過程，建立了簡潔和清晰的過程結(jié)構(gòu)，為開發(fā)過程提供較大的通用性。傳統(tǒng)上的項目組織是順序地通過每個工作流 (Workflow)，每個工作流只有一次，也就是我們熟悉的瀑布模式生命週期。1111.2.4 Rational 統(tǒng)一流程 (RUP)模式RUP 模式軟體工程，由Rational 公司發(fā)展，採用瀑布式改良開發(fā)流程，分為四個階段：起始階段 (Initial

9、phase)精細(xì)規(guī)劃階段 (Elaboration phase)建構(gòu)階段 (Construction phase)移轉(zhuǎn)階段 (Transition phase)1211.2.4 Rational 統(tǒng)一流程 (RUP)模式RUP中有九個核心的工作流 (Core Workflows)：商業(yè)建模 (Business Modeling) 需求 (Requirements) 分析和設(shè)計 (Analysis & Design) 實作 (Implementation)測試 (Test)部署 (Deployment) 配置和變更管理 (Configuration & Change Management)項目管

10、理 (Project Management)環(huán)境 (Environment)1311.2.4 Rational 統(tǒng)一流程 (RUP)模式RUP 模式與傳統(tǒng)的瀑布模式相比較，其迭代過程具有以下優(yōu)點：降低了經(jīng)費支出的風(fēng)險。管理與開發(fā)人員了解開發(fā)過程，減少重覆開發(fā)的流程，解省經(jīng)費的支出。降低了產(chǎn)品延誤上市的風(fēng)險。通過在開發(fā)早期就確定風(fēng)險，可以盡早來解決問題，而不至於延誤到開發(fā)後期，因匆忙而無法解決問題。加速工程進(jìn)度。因為開發(fā)人員清楚問題的焦點所在，有利於解決問題，提高工作效率。1411.3 軟體測試軟體測試依照軟體發(fā)展程序，包含以下各種測試：單元測試 (Unit Test)功能測試 (Functio

11、n Test)整合測試 (Integration Test)驗收測試 (User Acceptance Test；UAT)這些測試最終目的就是為了讓整個系統(tǒng)能夠正常順利的運作，只要測試的項目涵蓋範(fàn)圍夠廣泛完整，那麼就可以精確掌握各種可能的狀況，讓系統(tǒng)出錯的機率降到最低。1511.3 軟體測試在軟體發(fā)展完成交付使用前或發(fā)布前，需要經(jīng)過全面完整的測試，軟體測試方法有兩種：白箱測試 ( White Box Testing ) 黑箱測試 ( Black Box Testing ) 白箱測試，測試程式內(nèi)部邏輯架構(gòu)的正確性。白箱測試使用測試資料，檢查特定的條件或迴圈，是否與預(yù)計之狀態(tài)一致，判斷內(nèi)部邏輯的正

12、確性。比較重要白箱測試方法是路徑測試 ( Path Testing ) 和資料流測試 (Data Flow Testing )。1611.3 軟體測試黑箱測試，則是測試軟體是否符合功能需求，對於軟體做介面測試。如圖11-5，測試程式輸出與輸入之間的正確性。圖11-5 黑箱測試示意圖 1711.3 軟體測試白箱測試與黑箱測試皆是系統(tǒng)重要的測試，在測試概念、測試要項與測試內(nèi)容皆不一樣，其主要差異比較如表11-1。測試種類白箱測試黑箱測試測試概念結(jié)構(gòu)性測試功能測試測試要項檢查特定的條件或迴圈，是否與預(yù)期之狀態(tài)一致不合乎規(guī)格或功能遺漏、介面錯誤、功能錯誤、資料結(jié)構(gòu)錯誤、啟動或結(jié)束錯誤測試內(nèi)容軟體內(nèi)容仔

13、細(xì)檢查程式輸出與輸入之間的正確性表11- 1白箱測試與黑箱測試之差異1811.4 軟體建構(gòu)管理為避免已審查定案的工作產(chǎn)出遭受任意更改，而造成其他相關(guān)人員工作之錯誤，則需要建立一套對建構(gòu)項目妥善管理控制的流程和方法，讓大家共同遵守，以避免失去控制。軟體建構(gòu)管理，即是協(xié)調(diào)開發(fā)週期中相關(guān)的管理工作，以避免版本的混亂與錯誤，尤其當(dāng)用戶需求變更時；並採用適當(dāng)?shù)墓芾砉ぞ撸栽鲞M(jìn)管理的效率。在系統(tǒng)上線營運時，要保持系統(tǒng)的完整性，若任意改變系統(tǒng)的環(huán)境或參數(shù)時，會使系統(tǒng)不穩(wěn)定、產(chǎn)生漏洞、缺失、錯誤，降低系統(tǒng)之安全性，造成系統(tǒng)安全弱點。因此需要完善的建構(gòu)管理，以降低風(fēng)險，提高系統(tǒng)安全性。1911.4 軟體建構(gòu)管理

14、建構(gòu)管理包含四項主要工作：建構(gòu)識別 ( Configuration Identification)建構(gòu)控制 ( Configuration Control)建構(gòu)狀態(tài)記錄 ( Configuration Status Accounting )建構(gòu)審查 ( Configuration Audit)建構(gòu)識別是為了要能有效率與清楚的控管建構(gòu)項目，必須針對每一個建構(gòu)項目分別命名。建構(gòu)管理小組必須制訂建構(gòu)項目的命名規(guī)則，以利建構(gòu)項目命名後的版本管理工作。2011.4 軟體建構(gòu)管理建構(gòu)控制，系統(tǒng)開發(fā)完成或已上線的系統(tǒng)，若要更改系統(tǒng)參數(shù)、程式、或架構(gòu)，需要經(jīng)由建構(gòu)管理流程去改變，包含三種程序：需求控制 ( R

15、equest Control ) 變更控制 ( Change Control )釋放控制 ( Release Control )建構(gòu)狀態(tài)記錄，任何異動都要提出申請，由建構(gòu)管理人員評估其影響層面，並通知專案負(fù)責(zé)人，由其召集相關(guān)單位進(jìn)行評估，並決定是否準(zhǔn)予異動，並加以紀(jì)錄追蹤。 建構(gòu)稽核，為達(dá)成對於建構(gòu)管理系統(tǒng)中的項目的正確性，建構(gòu)管理人員需要定時檢視建構(gòu)管理項目以確保其結(jié)構(gòu)的完整性。2111.4 軟體建構(gòu)管理建構(gòu)管理需要建構(gòu)管理工具的輔助，如圖11-6，為建構(gòu)管理工具 Star Team ，圖中顯示其在管理軟體能力成熟度整合 ( CMMI ) 之各項文件。圖11-6 建構(gòu)管理工具2211.5 資

16、訊安全架構(gòu) 企業(yè)資訊安全架構(gòu)，涵蓋企業(yè)安全政策、隱私權(quán)保護(hù)、降低威脅、交易與資料保護(hù)、應(yīng)用程式安全、身份識別、存取管理、實體安全與人員安全等重大安全議題進(jìn)行分析評估，以確保企業(yè)資訊安全程度能滿足內(nèi)部營運及外部法規(guī)之要求。企業(yè)的資訊服務(wù)部門必須建置完善的資訊安全機制，以防止其核心資訊系統(tǒng)與資料遭受內(nèi)部的破壞者竊取、竄改、或破壞。並且避免外部的駭客透過網(wǎng)際網(wǎng)路惡意入侵、攻擊企業(yè)營運的神經(jīng)中樞網(wǎng)路系統(tǒng)，造成網(wǎng)路服務(wù)中斷而影響其正常運作。 資訊安全架構(gòu)工具，包含：防火牆、加密系統(tǒng)、負(fù)載平衡、管理分析系統(tǒng)、網(wǎng)頁過濾與稽核系統(tǒng)、郵件備份與稽核系統(tǒng)、網(wǎng)路防毒牆、動態(tài)密碼卡、入侵偵測系統(tǒng)、弱點稽核系統(tǒng)等。23

17、11.5 資訊安全架構(gòu)在所有安全系統(tǒng)中，硬體設(shè)備與作業(yè)系統(tǒng)都需要具備基本的安全等級。作業(yè)系統(tǒng)安全架構(gòu)，包含以下幾個層面：流程獨立 ( Process Isolation )保護(hù)圈環(huán) ( Protection Rings ) 抽象介面 ( Abstraction Interface)抽象介面 ( Abstraction Interface)作業(yè)系統(tǒng)中的各個流程獨立完成，每個流程有隔離機制，互不影響，各個流程有自己資料堆疊、記憶體空間等系統(tǒng)資源，透過系統(tǒng)功能與其它流程交換資料。2411.5 資訊安全架構(gòu)保護(hù)圈環(huán)提供作業(yè)系統(tǒng)安全防護(hù)，限制系統(tǒng)的執(zhí)行權(quán)限，以達(dá)到保護(hù)系統(tǒng)的目的。如圖11-7為四階層的作

18、業(yè)系統(tǒng)保護(hù)圈環(huán)。抽象介面是簡化與一般化的使用者介面，使用者與程式開發(fā)者不需要了解使用資源之細(xì)節(jié)，即可以使用系統(tǒng)資源，細(xì)節(jié)封裝在更低階的程式中。圖 11-7 作業(yè)系統(tǒng)保護(hù)圈環(huán)示意圖2511.5 資訊安全架構(gòu)Level 0 表示作業(yè)系統(tǒng)的核心，是系統(tǒng)的核心流程，可以控制系統(tǒng)所有資源，使用資源必須要完全確認(rèn)的使用權(quán)限，所以在此圈環(huán)執(zhí)行的流程稱為特權(quán)模式 ( Privileged Mode ) 或監(jiān)管模式 ( Supervisory Mode )。Level 1 和 2 是驅(qū)動程式或作業(yè)系統(tǒng)的其它服務(wù)程式，提供高階使用系統(tǒng)資源的介面。Level 3 是應(yīng)用程式，這一階層常稱為使用者模式 ( User Mode ) 或保護(hù)模式 ( Protected Mode )，這一模式不可以直接存取系統(tǒng)資源，必須經(jīng)過授權(quán)才可以使用系統(tǒng)資源。2611.6 服務(wù)等級合約資訊系統(tǒng)上線營運後，系統(tǒng)開發(fā)廠商如無法提供後續(xù)的服務(wù)，將造成業(yè)者或顧客重大損失。為了確保後續(xù)的服務(wù)品質(zhì)，需要訂立服務(wù)等級合約 ( Service Level Agreements；SLA )。服務(wù)等級合約需要考慮項目如下：系統(tǒng)上線時間 ( Percentage of Overall Operating Time )系統(tǒng)連續(xù)停止運作時間 ( Maximum Consecutive Downtime ) 尖峰容量 ( Peak Loa