1 / 54

軟體開發模式

軟體開發模式. 第三章. 本章大綱. 學習目標 3.1 導論 3.2 瀑布模式 3.3 快速雛型法 3.4 漸進模式 3.5 演化雛型模式 3.6 螺旋模式 3.7 同步模式 3.8 軟體開發程序模式. 學習目標. 軟體生命週期模式與程序模式的差別。 軟體生命週期模式的運作方法及管理意義，包括： 瀑布模式 快速雛型法 漸進模式 演化雛型模式 螺旋模式 同步模式. 學習目標（ c.2）. 軟體生命週期模式的選擇策略。 程序模式的運作方法及管理意義，包括： 開發程序模式 反覆定義與改善程序模式 連續改善程序模式. 導論.

ankti
Download Presentation

軟體開發模式

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 軟體開發模式 第三章

  2. 本章大綱 學習目標 3.1 導論 3.2 瀑布模式 3.3 快速雛型法 3.4 漸進模式 3.5 演化雛型模式 3.6 螺旋模式 3.7 同步模式 3.8 軟體開發程序模式

  3. 學習目標 • 軟體生命週期模式與程序模式的差別。 • 軟體生命週期模式的運作方法及管理意義，包括： • 瀑布模式 • 快速雛型法 • 漸進模式 • 演化雛型模式 • 螺旋模式 • 同步模式

  4. 學習目標（c.2） • 軟體生命週期模式的選擇策略。 • 程序模式的運作方法及管理意義，包括： • 開發程序模式 • 反覆定義與改善程序模式 • 連續改善程序模式

  5. 導論 • 軟體開發模式描述軟體開發一系列的步驟或階段。 • 軟體開發模式可分為生命週期模式(Life-Cycle Models)和程序模式(Process Models)。 • 生命週期模式 • 將軟體開發的階段及各階段的關係以概念性的模式表示。 • 隱含著開發程序的時間順序。 • 瀑布模式、快速雛型法、漸進模式、演化雛型模式、螺旋模式和同步模式，每一種方法代表一種系統開發的策略。

  6. 導論（c.2） • 程序模式 • 為了某一特定目的而設計一系列的活動。 • 程序模式的範例如： • 軟體開發程序 • 品質改善 • 演化程序 • 專案管理程序 • 顧客導向程序 • 需求程序 • 維護程序 • 同步程序

  7. 導論（c.3） • 生命週期模式的最終結果是軟體系統﹔ • 程序模式的最終結果則是某一管理目標。 • 註：生命週期模式也可視為程序模式的一種，當程序模式所指為開發程序時，兩者所表示的是相同的概念。有學者也將兩名詞互用。

  8. 導論（c.4） • 軟體專案依循某一開發模式有多方面的優點： • 統一的名詞及概念有助於溝通、規劃及管理。 • 有利於標準、規範與政策的建立及推行。 • 可提供評估、檢核及里程碑的參考特點。 • 簡要地描繪重要的功能、活動及特性。 • 開發過程更結構化、更容易管理。 • 提供一個不斷改善的基礎。

  9. 瀑布模式 • 瀑布模式 • 瀑布模式是基於下列的構想而設計： • 軟體開發應依照一序列的階段進行。 • 一個階段的產出必須經過驗證或確認才能視為完成。 • 任何更改、錯誤或爭議都必須回溯到前面相關的階段加以修正。 • 若發現錯誤或新需求時，必須回溯到前面相關的階段。

  10. 圖3.1 瀑布模式（c.2） 系統需求 確認(Validation) 軟體需求 確認 初步設計 驗證(Verification) 細部設計 驗證 編碼和除錯 單元測試 整合測試 驗證 操作與維護 確認

  11. 瀑布模式（c.3） • 瀑布模式的管理意義 • 它鼓勵依生命週期階段來進行規劃。每一階段的結束正好成為管理控制的里程碑。 • 每一階段的產出都必須經過確認、驗證或測試。確認(validation)用來檢驗產出是否符合顧客的需求，以真實世界的問題為檢驗的對象。驗證 (verification)是檢驗系統是否依規格正確地執行。 • 從事前階段工作的人，有責任將正確、完整、可行且容易瞭解的產出移交給下一階段的人員。 • 開發的程序變得更結構化且更容易管理。

  12. 瀑布模式（c.4） • 瀑布模式的缺點 • 必須到了最後階段才能看到可執行的軟體系統，風險太高。 • 過於複雜與費時。 • 若需求不明確，而每一階段又要求非常結構化、嚴謹、完整的開發方法，將使得開發時程拉得很長。

  13. 快速雛型法 • 快速雛型法 • 快速雛型法主要是基於下列的構想： • 需求變更無可避免。 • 一個可看得到、可操作的雛型是開發者與顧客溝通的良好工具。 • 雛型的建造及修改應該要非常快速，以因應顧客的要求。 • 提高使用者參與的意願，進而改進使用者滿意度。

  14. 快速雛型法（c.2） • 雛型法的層次 • Cherveny 提出了一個三階層的雛型法架構。 • 第一階雛型 • 又稱輸入/ 輸出設計(Input / Output Design)，它只產生輸入/ 輸出的螢幕及列印的報表。 • 第二階雛型 • 包含使用介面及系統功能，經由第四代語言及關聯式資料庫快速地設計一個可執行的系統。

  15. 快速雛型法（c.3） • 第三階雛型 • 發展一個適應環境的雛型，這種策略將系統永遠當作一個雛型，以因應外在環境的不確定性。

  16. 圖3.2 需求分析雛型 快速分析需求 建立雛型 意見回饋和 需求更改 使用者試驗 凍結需求 拋棄雛型 設計 編碼 測試 操作與維護

  17. 快速雛型法（c.5） • 需求分析雛型依下列步驟進行： • 快速地分析使用需求，並建立雛型。此雛型包括使用介面和互動的功能，讓使用者可以操作並試驗。 • 蒐集試驗後的意見和需求的更改，並依此修改雛型。此循環重複數次直到可接受的程度為止。 • 將需求凍結並捨去雛型，再依傳統的瀑布模式進行設計、編碼、測試和操作維護。

  18. 快速雛型法（c.6） • 分析與設計雛型 • 在建造雛型之前先做詳細的需求分析與初步設計，此法可降低重大需求變更和雛型修改的次數。 • 雛型經使用者的試驗和修改後，接下來的細部設計、編碼、測試和操作維護與瀑布模式的作法一樣。 • 雛型系統的架構和主要功能模組都加以保留，經修改後成為最終的產品。

  19. 圖3.3 分析與設計雛型 需求分析 初步設計 意見回饋 需求更改 建立雛型 使用者試驗 細部設計 編碼 測試 操作與維護

  20. 快速雛型法（c.8） • 子系統雛型 • 需求分析和初步設計依照傳統的瀑布模式進行。 • 初步設計時將系統分為數個子系統。 • 針對每一個子系統建立一個雛型。 • 子系統都完成後，便可進行整合。 • 各子系統雛型不予拋棄，而是演化為最終的產品。

  21. 圖3.4 子系統雛型 需求分析 初步設計 子系統雛型N 子系統雛型I 設計 編碼 ……….. 使用者試驗 意見回饋 需求變更 系統整合 操作與維護 設計 編碼 使用者試驗 意見回饋 需求變更

  22. 快速雛型法（c.10） • 整體系統雛型 • 經需求分析、設計、編碼、測試等階段建造一個可運作但並不完美的雛型系統，這個快速發展的系統經使用者的操作與試驗，得以發掘更完整的需求，系統也漸趨穩定。

  23. 圖3.5 整體系統雛型 需求分析 設計 意見回饋 需求更改 編碼 測試 操作與維護

  24. 表3.1 開發策略與專案特性 • 選擇策略 • 雛型法可以和傳統的瀑布模式混合或獨自運作，Burns與Dennis提出了一個二維的架構，將專案依不確定性與複雜性兩個維度來區分選擇的策略。 專案複雜度 高 低 低 高 專案不確定性

  25. 表3.2 系統開發策略的權變架構 交易處理系統(TPS) 瀑布模式輔以第一階雛型法 資訊回報系統(IRS) 瀑布模式輔以第二階雛型法 使用者開發系統(EUDA) 第三階雛型法 決策支援系統(DSS) 第三階雛型法輔以瀑布模式 • Louadi 合併 Burns 與 Dennis 的架構及 Chrveny 的三階層分類，提出了權變 (Contingency)架構。 專案複雜度 高 低 　 低 高 專案不確定性

  26. 快速雛型法（c.14） • 雛型法的優點 • 雛型法可增進使用者參與。 • 可看得到、可操作的雛型成為開發者與使用溝通的基礎。 • 需求分析的時間及成本可以降低。 • 系統的正確性提高。

  27. 快速雛型法（c.15） • 雛型法的缺點 • 由於溝通較複雜、專案開發較動態，因此，專案的管理及控制也較為困難。 • 較難建造大型系統的雛型。 • 缺乏深入的分析及開發的工具，因此系統的效率較差。

  28. 漸進模式 • 漸進模式(Incremental Model) • 漸進模式是基於下列的構想而設計： • 將一個軟體系統分割成數個子系統，每個子系統執行一部分功能。 • 設計一個彈性、開放的系統架構，使後續的功能能夠加入，而不需修改基本的架構。 • 後續的子系統陸續與已完成的部分整合在一起。

  29. 圖3.6 漸進模式 第一個子系統的分析、設計、編碼與測試 整合新子系統至現有系統 操作與維護 新子系統的設計、編碼與測試

  30. 漸進模式（c.3） • 漸進模式適用於下列的情況： • 預算分期編列的限制下，系統在一開始先做整體規劃，往後再分期執行。 • 一個組織需要時間來熟悉和接受新科技。 • 不必一次大量投資，可降低財務負擔及風險。 • 初期的成功使得往後的工作容易推動。 • 不可避免的需求更改及維護可併入漸進的開發方法中。

  31. 演化雛型模式 • 演化雛型模式(Evolutionary Prototyping Model) • 考量系統開發將延伸至很長的時間，在軟體使用的期間預期將會成長、變動。 • 先建造一個可運作的雛型，經使用、試驗及環境的變化後，發現新的需求，此時系統將演化到另一個雛型。 • 每一代的雛型都視為新系統的開發，有如階梯式的演進。

  32. 圖3.7 演化雛型模式 觀查 需求 抽象化 確認 規格 驗證 雛型建立 驗證 試驗 確認

  33. 螺旋模式 • 螺旋模式(Spiral Model） • 螺旋模式是基於下列的構想而產生： • 在生命週期的每一階段，應該主動發覺風險並設法解決。 • 運用模擬、雛型、模式建立、標竿(Benchmarks)等方法來降低風險。 • 每一階段都必須經過確認或驗證。 • 考量每一階段的目標、可行的方案及限制條件。

  34. 圖3.8 螺旋模式 累積成本 經過各步驟進展 決定目標、可行方案及限制 方案評估、風險識別與解析 風 險 分 析 風 險 分 析 風 險 分 析 可操作 雛型 雛型 3 風險 雛型 2 承諾 1 雛型 分析 審查 模擬、模型、標竿 需求計畫 分割 作業觀念 生命週期計畫 軟體需求 細部 發展計畫 設計 軟體產 需求驗證 品設計 整合與測試計畫 編碼 設計確認及驗證 單元 測試 整合 驗收 測試 實施 測試 計劃下一階段 發展驗證下一階層產品

  35. 螺旋模式（c.3） • 螺旋模式的特性： • 結合瀑布模式、雛型模式、風險分析和逐步規劃的精神。 • 強調每一階段的風險分析。 • 考慮因素非常廣泛，適用於大型而高風險的專案，對於小型或需求明確的系統此法會太複雜，且成本太高。

  36. 同步模式 • 同步模式(Concurrent Model) • 同步模式的目的是，縮短產品開發時間以提高市場競爭力。 • 同步模式是基於下列的構想以縮短開發時間： • 多個團隊同時開發，稱為活動同步。做法可以是一個階段內的工作、多個階段內的工作、或多個專案內的工作平行進行。

  37. 同步模式（c.2） • 不同團隊的資訊互相交流共享，稱為資訊同步。做法可以將後階段的重要議題提前讓前階段的人知道；將前階段的開發情況傳遞給後階段的開發團隊，或建立一個有效的資訊交換網路或群體工作環境。 • 開發一個管理系統以協調人員、資源、程序和產品間複雜的互動關係。

  38. 圖3.9 同步模式 開　　始 下一版本 功能組劃分 第一團隊開發 第 N 團隊開發 ………... 獨立整合 下一版本 獨立測試 結　　束

  39. 圖3.10 同步模式與循序模式之比較 同步模式 系 整 功能組:版本2.2 統 測 功能組:版本2.1 合 試 系 功能組:版本1.3 整 統 功能組:版本1.2 測 合 功能組:版本1.1 試 功能組:版本1 版本1 版本2 版本3 功能組:版本2.2 功能組:版本2.1 功能組:版本1.3 循序模式 功能組:版本1.2 功能組: 版本1.1 功能組:版本1 版本1 版本2 版本3

  40. 圖3.11 同步開發模式 設計團隊 C 版本4 功能組 ( L) 設計團隊 C 整 測 功能組 ( K) 合 試 設計團隊 B 功能組 團 ( J) 團 版本3 隊 隊 設計團隊 和 功能組 D A ( I ) 設計團隊 功能組 C ( 3) 整 測 合 試 版本2 設計團隊 功能組 B ( 2) 團 團 ) 隊 隊 設計團隊 功能組 A ( 1 版本1 功能組：版本 1

  41. 軟體開發程序模式 • 軟體開發程序模式(Software Process Model)是為達成某一特定目標之一系列活動，其定義如下： • 「程序是一個系統，它將輸入、活動、工作流程、資訊流程及其他相關的項目轉換成特定的結果與產品。 」 • 「程序是一系列經過特殊安排的步驟以達到特定的目標，軟體開發程序的目標是完成或改進符合品質要求的軟體產品。」

  42. 軟體開發程序模式（c.2） • 「軟體程序是一組的工具、方法、做法以製造軟體產品。 • 「程序模式描述一個開發階段中的工作，各工作間的關係，以及啟動工作的條件。」

  43. 軟體開發程序模式（c.3） • 程序模式的類型 • 開發者依不同的目的而設計不同類型的程序模式。 • 開發程序模式 • 反覆定義與改進程序模式 • 連續改進程序模式

  44. 軟體開發程序模式（c.4） • 開發程序模式 • 開發程序模式就像生命週期模式，這種模式的重要概念如下： • 程序是一個連續的循環，是一個持續進行、不斷改進的過程。 • 一個階段的輸出成為下一階段的輸入。 • 程序中的每一階段都包含一系列的活動。 • 每項活動都有負責的人員。 • 每項活動都必須依循設定的標準與程序，每一階段都必須定義它所包含的活動。

  45. 圖3.12 軟體開發程序模式 淘 汰 專案發啟 維 護 概念探索 系統配置 操作支援 裝 置 編 碼 設 計 需求分析

  46. 軟體開發程序模式（c.6） • 反覆模式(Iteration model) • 反覆模式是基於下列的構想： • 將程序視為產品。程序產品(Process Product)可包含套裝軟體、文件指引、訓練、諮詢顧問與工具開發等。 • 程序產品應配合顧客的特殊需求以達成其企業目標。

  47. 軟體開發程序模式（c.7） • 強調反覆的定義和改進，並透過下列的方法來達成： • 使用者使用程序產品後將資訊回饋。 • 對程序問題的即時反應。 • 專案計畫與專案程序間密切的協調。 • 適應環境的改變並引進新科技以創造優勢。 • 程序的定義必須符合組織的目標並適合所處的環境。組織的目標如時程控制、成本降低、品質提升。環境因素如科技、組織型態、產品類別等。

  48. 圖3.13 反覆定義與改進程序模式 目標與 科技 定義 Define 交貨 Delivery 目標與 科技 重新定義 Redefine 應用 Apply 評量 Assess

  49. 軟體開發程序模式（c.9） • 定義階段 • 此階段將程序的輸入與輸出明確定義。輸入的重要資訊為程序的目標與可用的科技﹔輸出則為工作的定義、工作的規格及樣板。包含的項目如(Gelman, 1994)： • 作業名稱 • 訓練 • 樣板 • 平台架構

  50. 軟體開發程序模式（c.10） • 品質保證 • 人員 • 工具 • 時間估計

More Related