资源预览内容
第1页 / 共29页
第2页 / 共29页
第3页 / 共29页
第4页 / 共29页
第5页 / 共29页
第6页 / 共29页
第7页 / 共29页
第8页 / 共29页
第9页 / 共29页
第10页 / 共29页
亲,该文档总共29页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述
1 第十一章 應用系統發展管理 本投影片(下稱教用資源)僅授權給採用教用資源相關之旗標書籍為教科書之授課老師 (下稱老師)專用,老師為教學使用之目的,得摘錄、編輯、重製教用資源(但使用量 不得超過各該教用資源內容之80%)以製作為輔助教學之教學投影片,並於授課時搭配 旗標書籍公開播放,但不得為網際網路公開傳輸之遠距教學、網路教學等之使用;除此 之外,老師不得再授權予任何第三人使用,並不得將依此授權所製作之教學投影片之相 關著作物移作他用。 2 第十一章 應用系統發展管理 l 應用程式開發是軟體安全的第一步,軟體開發者必須了解 開發程序與模式,並導入相關之安全管理機制,以確保軟 體安全,本章介紹與軟體開發相關之管理模式。軟體開發 也常忽略軟體測試,本章亦介紹各種軟體測試概念,以提 高系統之安全性。有良好的軟體開發管理才能使軟體系統 具備整體安全性,提供良好的服務。本章包含以下內容: 軟體系統開發 軟體發展模式 軟體測試 軟體建構管理 資訊安全架構 服務等級合約 3 11.1 軟體系統開發 l 軟體系統的發展是一個循環的過程,稱為系統發展生命週期 (System Development Life Cycle;SDLC),如圖 11-1。基本上,系統發展生 命週期包含四個階段: 概念階段 發展階段 執行階段 結束階段 圖 11-1 系統發展的四個階段 4 11.1 軟體系統開發 l 軟體系統的發展從概念階段開始,經過發展階段、執行階 段、結束階段,資訊系統開發完成且正式啟用。導入使用 一些時日之後,為了因應使用者需求的改變,系統需要修 正或更新,再回到系統分析的階段,再一次進入發展階段 ,如此週而復始。 l 為了控制軟體系統的品質、時效、與成本,軟體工程界發 展出各種可供參考的軟體系統發展模型。在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 軟體發展模式 l 軟體系統發展過程,遵循軟體發展模式,可以建立系統化 之步驟及執行程序,有利於標準、規範與政策之推行,使 得開發的過程更有效率,能確保品質,並且容易管理。不 同的軟體發展模式適用於不同的資訊系統開發。 6 11.2.1 瀑布模式 l 瀑布模式 ( Waterfall Model ) 是一種軟體系統開發方法,將系統開發過程分 成四個階段:分析 (Analysis)、設計 (Design)、實作(Implementation) 與測試 (Testing),明確定義每一階段的工作。當面對比較複雜的系統時,其實作階 段可以在細分成多個階段。例如圖11-2。 l 對於較小型或比較單純的系統時,使用瀑布模式來開發系統,各個階段所需 交付的文件與完成的任務都很明確,管理容易。但瀑布模式也有其缺點,必 須要等到最後階段,才能有成果,風險較高,如果分析階段不夠明確,設計 與實作階段都很難實施,修改原分析文件工程浩大,耗費時間與經費。 圖 11-2 瀑布模式 7 11.2.2 螺旋模式 l 螺旋模式 ( Spiral Model ) 如迴圈般地持續發展系統 ,由雛型發展開始以至於 系統成熟。例如圖11-3, 螺旋模式包含四個階段: 決定目標、可行方案與限 制 開發雛型 發展與驗證下階段產品 規劃下階段 圖 11- 3 螺旋模式 8 11.2.2 螺旋模式 l 在發展雛型之前需要經過風險分析,方案評估與風險識別 並解決問題,這些是決定目標、可行方案與限制階段 的工作。發展與驗證下階段產品階段,則依雛型建立 模型與標竿,作為下階段參考,在本階段的工作,包含: 建立需求、設計、細部設計、單元測試、整合測試、驗證 測試等規劃設計。規劃下階段階段,則包含發展計劃 與整合測試計劃。依序重覆地執行上述四個階段工作,以 至於完成產品。 9 11.2.3 軟體能力成熟度模式 l 軟體能力成熟度模式可協助整合傳統上分開的企 業組織功能,並訂立流程改善目標及優先順序, 同時為欲實行最佳流程的公司提供指引及評估。 軟體能力成熟度模式依軟體發展的能力成熟分為 五個等級,如圖 11-4: 初始級 ( Initial ) 管理級 ( Managed ) 定義級 ( Defined ) 量化管理級 ( Quantitatively Managed ) 最佳化級 ( Optimizing ) 10 11.2.3 軟體能力成熟度模式 l 初始級成熟度沒有軟 體發展流程,只在事件發 生後,反應式的改進。 管理級成熟度已有專案 流程定義。定義級成 熟度已有機構的流程定義 ,軟體發展依照一套正式 且有文件的流程,在既定 的發展模式,並積極改善 流程。量化管理級成 熟度盡可能了解發展流程 並量化,流程是可以度量 與控制,依照量化數據, 改進流程。最佳化級 成熟度能持續與專注在流 程改善。 圖 11- 4成熟度等級 11 11.2.4 Rational 統一流程 (RUP)模式 l Rational 統一流程 ( Rational Unified Process ; RUP) 具 有很多優點,是由Rational 公司發展,採用瀑布式改良開 發流程,在迭代的開發過程,建立了簡潔和清晰的過程結 構,為開發過程提供較大的通用性。 l 傳統上的項目組織是順序地通過每個工作流 (Workflow), 每個工作流只有一次,也就是我們熟悉的瀑布模式生命週 期。 12 11.2.4 Rational 統一流程 (RUP)模式 l RUP 模式軟體工程,由Rational 公司發展,採用 瀑布式改良開發流程,分為四個階段: 起始階段 (Initial phase) 精細規劃階段 (Elaboration phase) 建構階段 (Construction phase) 移轉階段 (Transition phase) 13 11.2.4 Rational 統一流程 (RUP)模式 l RUP中有九個核心的工作流 (Core Workflows): 商業建模 (Business Modeling) 需求 (Requirements) 分析和設計 (Analysis & Design) 實作 (Implementation) 測試 (Test) 部署 (Deployment) 配置和變更管理 (Configuration & Change Management) 項目管理 (Project Management) 環境 (Environment) 14 11.2.4 Rational 統一流程 (RUP)模式 l RUP 模式與傳統的瀑布模式相比較,其迭代過程 具有以下優點: 降低了經費支出的風險。管理與開發人員了解開發過程, 減少重覆開發的流程,解省經費的支出。 降低了產品延誤上市的風險。通過在開發早期就確定風險 ,可以盡早來解決問題,而不至於延誤到開發後期,因匆 忙而無法解決問題。 加速工程進度。因為開發人員清楚問題的焦點所在,有利 於解決問題,提高工作效率。 15 11.3 軟體測試 l 軟體測試依照軟體發展程序,包含以下各種測試 : 單元測試 (Unit Test) 功能測試 (Function Test) 整合測試 (Integration Test) 驗收測試 (User Acceptance Test;UAT) l 這些測試最終目的就是為了讓整個系統能夠正常 順利的運作,只要測試的項目涵蓋範圍夠廣泛完 整,那麼就可以精確掌握各種可能的狀況,讓系 統出錯的機率降到最低。 16 11.3 軟體測試 l 在軟體發展完成交付使用前或發布前,需要經過 全面完整的測試,軟體測試方法有兩種: 白箱測試 ( White Box Testing ) 黑箱測試 ( Black Box Testing ) l 白箱測試,測試程式內部邏輯架構的正確性。白 箱測試使用測試資料,檢查特定的條件或迴圈, 是否與預計之狀態一致,判斷內部邏輯的正確性 。比較重要白箱測試方法是路徑測試 ( Path Testing ) 和資料流測試 (Data Flow Testing )。 17 11.3 軟體測試 l 黑箱測試,則是測試軟體是否符合功能需求,對於軟體做 介面測試。如圖11-5,測試程式輸出與輸入之間的正確性 。 圖11-5 黑箱測試示意圖 18 11.3 軟體測試 l 白箱測試與黑箱測試皆是系統重要的測試,在測試概念、 測試要項與測試內容皆不一樣,其主要差異比較如表11-1 。 測試種類白箱測試黑箱測試 測試概念結構性測試功能測試 測試要項檢查特定的條件或迴圈,是否與 預期之狀態一致 不合乎規格或功能遺漏、介面 錯誤、功能錯誤、資料結構錯 誤、啟動或結束錯誤 測試內容軟體內容仔細檢查程式輸出與輸入之間的正確性 表11- 1白箱測試與黑箱測試之差異 19 11.4 軟體建構管理 l 為避免已審查定案的工作產出遭受任意更改,而造成其他 相關人員工作之錯誤,則需要建立一套對建構項目妥善管 理控制的流程和方法,讓大家共同遵守,以避免失去控制 。 l 軟體建構管理,即是協調開發週期中相關的管理工作,以 避免版本的混亂與錯誤,尤其當用戶需求變更時;並採用 適當的管理工具,以增進管理的效率。 l 在系統上線營運時,要保持系統的完整性,若任意改變系 統的環境或參數時,會使系統不穩定、產生漏洞、缺失、 錯誤,降低系統之安全性,造成系統安全弱點。因此需要 完善的建構管理,以降低風險,提高系統安全性。 20 11.4 軟體建構管理 l 建構管理包含四項主要工作: 建構識別 ( Configuration Identification) 建構控制 ( Configuration Control) 建構狀態記錄 ( Configuration Status Accounting ) 建構審查 ( Configuration Audit) l 建構識別是為了要能有效率與清楚的控管建構項 目,必須針對每一個建構項目分別命名。建構管 理小組必須制訂建構項目的命名規則,以利建構 項目命名後的版本管理工作。 21 11.4 軟體建構管理 l 建構控制,系統開發完成或已上線的系統,若要更改系統 參數、程式、或架構,需要經由建構管理流程去改變,包 含三種程序: 需求控制 ( Request Control ) 變更控制 ( Change Control ) 釋放控制 ( Release Control ) l 建構狀態記錄,任何異動都要提出申請,由建構管理人員 評估其影響層面,並通知專案負責人,由其召集相關單位 進行評估,並決定是否准予異動,並加以紀錄追蹤。 l 建構稽核,為達成對於建構管理系統中的項目的正確性, 建構管理人員需要定時檢視建構管理項目以確保其結構的 完整性。 22 11.4 軟體建構管理 l 建構管理需要建構管理工具的輔助,如圖11-6,為建構管理工具 Star Team ,圖中顯示其在管理軟體能力成熟度整合 ( CMMI ) 之各項文件 。 圖11-6 建構管理工具 23 11.5 資訊安全架構 l 企業資訊安全架構,涵蓋企業安全政策、隱私權保護、降 低威脅、交易與資料保護、應用程式安全、身份識別、存 取管理、實體安全與人員安全等重大安全議題進行分析評 估,以確保企業資訊安全程度能滿足內部營運及外部法規 之要求。 l 企業的資訊服務部門必須建置完善的資訊
网站客服QQ:2055934822
金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号