590 likes | 957 Vues
軟體開發模式. 第三章. 本章大綱. 學習目標 3.1 導論 3.2 瀑布模式 3.3 快速雛型法 3.4 漸進模式 3.5 演化雛型模式 3.6 螺旋模式 3.7 同步模式 3.8 軟體開發程序模式. 學習目標. 軟體生命週期模式與程序模式的差別。 軟體生命週期模式的運作方法及管理意義,包括: 瀑布模式 快速雛型法 漸進模式 演化雛型模式 螺旋模式 同步模式. 學習目標( c.2). 軟體生命週期模式的選擇策略。 程序模式的運作方法及管理意義,包括: 開發程序模式 反覆定義與改善程序模式 連續改善程序模式. 導論.
E N D
軟體開發模式 第三章
本章大綱 學習目標 3.1 導論 3.2 瀑布模式 3.3 快速雛型法 3.4 漸進模式 3.5 演化雛型模式 3.6 螺旋模式 3.7 同步模式 3.8 軟體開發程序模式
學習目標 • 軟體生命週期模式與程序模式的差別。 • 軟體生命週期模式的運作方法及管理意義,包括: • 瀑布模式 • 快速雛型法 • 漸進模式 • 演化雛型模式 • 螺旋模式 • 同步模式
學習目標(c.2) • 軟體生命週期模式的選擇策略。 • 程序模式的運作方法及管理意義,包括: • 開發程序模式 • 反覆定義與改善程序模式 • 連續改善程序模式
導論 • 軟體開發模式描述軟體開發一系列的步驟或階段。 • 軟體開發模式可分為生命週期模式(Life-Cycle Models)和程序模式(Process Models)。 • 生命週期模式 • 將軟體開發的階段及各階段的關係以概念性的模式表示。 • 隱含著開發程序的時間順序。 • 瀑布模式、快速雛型法、漸進模式、演化雛型模式、螺旋模式和同步模式,每一種方法代表一種系統開發的策略。
導論(c.2) • 程序模式 • 為了某一特定目的而設計一系列的活動。 • 程序模式的範例如: • 軟體開發程序 • 品質改善 • 演化程序 • 專案管理程序 • 顧客導向程序 • 需求程序 • 維護程序 • 同步程序
導論(c.3) • 生命週期模式的最終結果是軟體系統﹔ • 程序模式的最終結果則是某一管理目標。 • 註:生命週期模式也可視為程序模式的一種,當程序模式所指為開發程序時,兩者所表示的是相同的概念。有學者也將兩名詞互用。
導論(c.4) • 軟體專案依循某一開發模式有多方面的優點: • 統一的名詞及概念有助於溝通、規劃及管理。 • 有利於標準、規範與政策的建立及推行。 • 可提供評估、檢核及里程碑的參考特點。 • 簡要地描繪重要的功能、活動及特性。 • 開發過程更結構化、更容易管理。 • 提供一個不斷改善的基礎。
瀑布模式 • 瀑布模式 • 瀑布模式是基於下列的構想而設計: • 軟體開發應依照一序列的階段進行。 • 一個階段的產出必須經過驗證或確認才能視為完成。 • 任何更改、錯誤或爭議都必須回溯到前面相關的階段加以修正。 • 若發現錯誤或新需求時,必須回溯到前面相關的階段。
圖3.1 瀑布模式(c.2) 系統需求 確認(Validation) 軟體需求 確認 初步設計 驗證(Verification) 細部設計 驗證 編碼和除錯 單元測試 整合測試 驗證 操作與維護 確認
瀑布模式(c.3) • 瀑布模式的管理意義 • 它鼓勵依生命週期階段來進行規劃。每一階段的結束正好成為管理控制的里程碑。 • 每一階段的產出都必須經過確認、驗證或測試。確認(validation)用來檢驗產出是否符合顧客的需求,以真實世界的問題為檢驗的對象。驗證 (verification)是檢驗系統是否依規格正確地執行。 • 從事前階段工作的人,有責任將正確、完整、可行且容易瞭解的產出移交給下一階段的人員。 • 開發的程序變得更結構化且更容易管理。
瀑布模式(c.4) • 瀑布模式的缺點 • 必須到了最後階段才能看到可執行的軟體系統,風險太高。 • 過於複雜與費時。 • 若需求不明確,而每一階段又要求非常結構化、嚴謹、完整的開發方法,將使得開發時程拉得很長。
快速雛型法 • 快速雛型法 • 快速雛型法主要是基於下列的構想: • 需求變更無可避免。 • 一個可看得到、可操作的雛型是開發者與顧客溝通的良好工具。 • 雛型的建造及修改應該要非常快速,以因應顧客的要求。 • 提高使用者參與的意願,進而改進使用者滿意度。
快速雛型法(c.2) • 雛型法的層次 • Cherveny 提出了一個三階層的雛型法架構。 • 第一階雛型 • 又稱輸入/ 輸出設計(Input / Output Design),它只產生輸入/ 輸出的螢幕及列印的報表。 • 第二階雛型 • 包含使用介面及系統功能,經由第四代語言及關聯式資料庫快速地設計一個可執行的系統。
快速雛型法(c.3) • 第三階雛型 • 發展一個適應環境的雛型,這種策略將系統永遠當作一個雛型,以因應外在環境的不確定性。
圖3.2 需求分析雛型 快速分析需求 建立雛型 意見回饋和 需求更改 使用者試驗 凍結需求 拋棄雛型 設計 編碼 測試 操作與維護
快速雛型法(c.5) • 需求分析雛型依下列步驟進行: • 快速地分析使用需求,並建立雛型。此雛型包括使用介面和互動的功能,讓使用者可以操作並試驗。 • 蒐集試驗後的意見和需求的更改,並依此修改雛型。此循環重複數次直到可接受的程度為止。 • 將需求凍結並捨去雛型,再依傳統的瀑布模式進行設計、編碼、測試和操作維護。
快速雛型法(c.6) • 分析與設計雛型 • 在建造雛型之前先做詳細的需求分析與初步設計,此法可降低重大需求變更和雛型修改的次數。 • 雛型經使用者的試驗和修改後,接下來的細部設計、編碼、測試和操作維護與瀑布模式的作法一樣。 • 雛型系統的架構和主要功能模組都加以保留,經修改後成為最終的產品。
圖3.3 分析與設計雛型 需求分析 初步設計 意見回饋 需求更改 建立雛型 使用者試驗 細部設計 編碼 測試 操作與維護
快速雛型法(c.8) • 子系統雛型 • 需求分析和初步設計依照傳統的瀑布模式進行。 • 初步設計時將系統分為數個子系統。 • 針對每一個子系統建立一個雛型。 • 子系統都完成後,便可進行整合。 • 各子系統雛型不予拋棄,而是演化為最終的產品。
圖3.4 子系統雛型 需求分析 初步設計 子系統雛型N 子系統雛型I 設計 編碼 ……….. 使用者試驗 意見回饋 需求變更 系統整合 操作與維護 設計 編碼 使用者試驗 意見回饋 需求變更
快速雛型法(c.10) • 整體系統雛型 • 經需求分析、設計、編碼、測試等階段建造一個可運作但並不完美的雛型系統,這個快速發展的系統經使用者的操作與試驗,得以發掘更完整的需求,系統也漸趨穩定。
圖3.5 整體系統雛型 需求分析 設計 意見回饋 需求更改 編碼 測試 操作與維護
表3.1 開發策略與專案特性 • 選擇策略 • 雛型法可以和傳統的瀑布模式混合或獨自運作,Burns與Dennis提出了一個二維的架構,將專案依不確定性與複雜性兩個維度來區分選擇的策略。 專案複雜度 高 低 低 高 專案不確定性
表3.2 系統開發策略的權變架構 交易處理系統(TPS) 瀑布模式輔以第一階雛型法 資訊回報系統(IRS) 瀑布模式輔以第二階雛型法 使用者開發系統(EUDA) 第三階雛型法 決策支援系統(DSS) 第三階雛型法輔以瀑布模式 • Louadi 合併 Burns 與 Dennis 的架構及 Chrveny 的三階層分類,提出了權變 (Contingency)架構。 專案複雜度 高 低 低 高 專案不確定性
快速雛型法(c.14) • 雛型法的優點 • 雛型法可增進使用者參與。 • 可看得到、可操作的雛型成為開發者與使用溝通的基礎。 • 需求分析的時間及成本可以降低。 • 系統的正確性提高。
快速雛型法(c.15) • 雛型法的缺點 • 由於溝通較複雜、專案開發較動態,因此,專案的管理及控制也較為困難。 • 較難建造大型系統的雛型。 • 缺乏深入的分析及開發的工具,因此系統的效率較差。
漸進模式 • 漸進模式(Incremental Model) • 漸進模式是基於下列的構想而設計: • 將一個軟體系統分割成數個子系統,每個子系統執行一部分功能。 • 設計一個彈性、開放的系統架構,使後續的功能能夠加入,而不需修改基本的架構。 • 後續的子系統陸續與已完成的部分整合在一起。
圖3.6 漸進模式 第一個子系統的分析、設計、編碼與測試 整合新子系統至現有系統 操作與維護 新子系統的設計、編碼與測試
漸進模式(c.3) • 漸進模式適用於下列的情況: • 預算分期編列的限制下,系統在一開始先做整體規劃,往後再分期執行。 • 一個組織需要時間來熟悉和接受新科技。 • 不必一次大量投資,可降低財務負擔及風險。 • 初期的成功使得往後的工作容易推動。 • 不可避免的需求更改及維護可併入漸進的開發方法中。
演化雛型模式 • 演化雛型模式(Evolutionary Prototyping Model) • 考量系統開發將延伸至很長的時間,在軟體使用的期間預期將會成長、變動。 • 先建造一個可運作的雛型,經使用、試驗及環境的變化後,發現新的需求,此時系統將演化到另一個雛型。 • 每一代的雛型都視為新系統的開發,有如階梯式的演進。
圖3.7 演化雛型模式 觀查 需求 抽象化 確認 規格 驗證 雛型建立 驗證 試驗 確認
螺旋模式 • 螺旋模式(Spiral Model) • 螺旋模式是基於下列的構想而產生: • 在生命週期的每一階段,應該主動發覺風險並設法解決。 • 運用模擬、雛型、模式建立、標竿(Benchmarks)等方法來降低風險。 • 每一階段都必須經過確認或驗證。 • 考量每一階段的目標、可行的方案及限制條件。
圖3.8 螺旋模式 累積成本 經過各步驟進展 決定目標、可行方案及限制 方案評估、風險識別與解析 風 險 分 析 風 險 分 析 風 險 分 析 可操作 雛型 雛型 3 風險 雛型 2 承諾 1 雛型 分析 審查 模擬、模型、標竿 需求計畫 分割 作業觀念 生命週期計畫 軟體需求 細部 發展計畫 設計 軟體產 需求驗證 品設計 整合與測試計畫 編碼 設計確認及驗證 單元 測試 整合 驗收 測試 實施 測試 計劃下一階段 發展驗證下一階層產品
螺旋模式(c.3) • 螺旋模式的特性: • 結合瀑布模式、雛型模式、風險分析和逐步規劃的精神。 • 強調每一階段的風險分析。 • 考慮因素非常廣泛,適用於大型而高風險的專案,對於小型或需求明確的系統此法會太複雜,且成本太高。
同步模式 • 同步模式(Concurrent Model) • 同步模式的目的是,縮短產品開發時間以提高市場競爭力。 • 同步模式是基於下列的構想以縮短開發時間: • 多個團隊同時開發,稱為活動同步。做法可以是一個階段內的工作、多個階段內的工作、或多個專案內的工作平行進行。
同步模式(c.2) • 不同團隊的資訊互相交流共享,稱為資訊同步。做法可以將後階段的重要議題提前讓前階段的人知道;將前階段的開發情況傳遞給後階段的開發團隊,或建立一個有效的資訊交換網路或群體工作環境。 • 開發一個管理系統以協調人員、資源、程序和產品間複雜的互動關係。
圖3.9 同步模式 開 始 下一版本 功能組劃分 第一團隊開發 第 N 團隊開發 ………... 獨立整合 下一版本 獨立測試 結 束
圖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
圖3.11 同步開發模式 設計團隊 C 版本4 功能組 ( L) 設計團隊 C 整 測 功能組 ( K) 合 試 設計團隊 B 功能組 團 ( J) 團 版本3 隊 隊 設計團隊 和 功能組 D A ( I ) 設計團隊 功能組 C ( 3) 整 測 合 試 版本2 設計團隊 功能組 B ( 2) 團 團 ) 隊 隊 設計團隊 功能組 A ( 1 版本1 功能組:版本 1
軟體開發程序模式 • 軟體開發程序模式(Software Process Model)是為達成某一特定目標之一系列活動,其定義如下: • 「程序是一個系統,它將輸入、活動、工作流程、資訊流程及其他相關的項目轉換成特定的結果與產品。 」 • 「程序是一系列經過特殊安排的步驟以達到特定的目標,軟體開發程序的目標是完成或改進符合品質要求的軟體產品。」
軟體開發程序模式(c.2) • 「軟體程序是一組的工具、方法、做法以製造軟體產品。 • 「程序模式描述一個開發階段中的工作,各工作間的關係,以及啟動工作的條件。」
軟體開發程序模式(c.3) • 程序模式的類型 • 開發者依不同的目的而設計不同類型的程序模式。 • 開發程序模式 • 反覆定義與改進程序模式 • 連續改進程序模式
軟體開發程序模式(c.4) • 開發程序模式 • 開發程序模式就像生命週期模式,這種模式的重要概念如下: • 程序是一個連續的循環,是一個持續進行、不斷改進的過程。 • 一個階段的輸出成為下一階段的輸入。 • 程序中的每一階段都包含一系列的活動。 • 每項活動都有負責的人員。 • 每項活動都必須依循設定的標準與程序,每一階段都必須定義它所包含的活動。
圖3.12 軟體開發程序模式 淘 汰 專案發啟 維 護 概念探索 系統配置 操作支援 裝 置 編 碼 設 計 需求分析
軟體開發程序模式(c.6) • 反覆模式(Iteration model) • 反覆模式是基於下列的構想: • 將程序視為產品。程序產品(Process Product)可包含套裝軟體、文件指引、訓練、諮詢顧問與工具開發等。 • 程序產品應配合顧客的特殊需求以達成其企業目標。
軟體開發程序模式(c.7) • 強調反覆的定義和改進,並透過下列的方法來達成: • 使用者使用程序產品後將資訊回饋。 • 對程序問題的即時反應。 • 專案計畫與專案程序間密切的協調。 • 適應環境的改變並引進新科技以創造優勢。 • 程序的定義必須符合組織的目標並適合所處的環境。組織的目標如時程控制、成本降低、品質提升。環境因素如科技、組織型態、產品類別等。
圖3.13 反覆定義與改進程序模式 目標與 科技 定義 Define 交貨 Delivery 目標與 科技 重新定義 Redefine 應用 Apply 評量 Assess
軟體開發程序模式(c.9) • 定義階段 • 此階段將程序的輸入與輸出明確定義。輸入的重要資訊為程序的目標與可用的科技﹔輸出則為工作的定義、工作的規格及樣板。包含的項目如(Gelman, 1994): • 作業名稱 • 訓練 • 樣板 • 平台架構
軟體開發程序模式(c.10) • 品質保證 • 人員 • 工具 • 時間估計