软体开发模式.pptVIP

第三章 軟體開發模式 本章大綱 3.1 導論 3.2 瀑布模式 3.3 雛型法 3.4 漸進模式 3.5 演化雛型模式 3.6 螺旋模式 3.7 同步模式 3.8 軟體開發程序模式 3.9 結論 學習目標(1/2) 軟體生命週期模式與程序模式 軟體生命週期模式的運作方法及管理意義，包括： 瀑布模式 雛型法 漸進模式 演化雛型模式 螺旋模式 同步模式 學習目標(2/2) 軟體生命週期模式的選擇策略 程序模式的運作方法及管理意義，包括： 開發程序模式 反覆定義與改善程序模式 連續改善程序模式 導論(1/4) 軟體開發模式描述軟體開發一系列的步驟或階段。 軟體開發模式可分為生命週期模式(Life Cycle Models)和程序模式(Process Models)。 生命週期模式 將軟體開發的階段及各階段的關係以概念性的模式表示。 隱含著開發程序的時間順序。 瀑布模式、雛型法、漸進模式、演化雛型模式、螺旋模式和同步模式，每一種方法代表一種系統開發的策略。 導論(2/4) 程序模式 為了某一特定目的而設計一系列的活動。 程序模式範例 軟體開發程序 品質改善程序 專案管理程序 顧客導向程序 需求程序 維護程序 同步程序 演化程序 導論(3/4) 生命週期模式的最終結果是軟體系統﹔程序模式的最終結果則是某一管理目標。 註：生命週期模式也可視為程序模式的一種，當程序模式所指為開發程序時，兩者所表示的是相同的概念。但也有學者將兩名詞互用。 導論(4/4) 軟體專案依循某一開發模式有多方面的優點： 統一的名詞及概念有助於溝通、規劃及管理。 有利於標準、規範與政策的建立及推行。 可提供評估、檢核及里程碑的參考時點。 簡要描繪重要的功能、活動及特性。 開發過程更結構化、更容易管理。 提供一個不斷改善的基礎。 瀑布模式(1/3) 瀑布模式 瀑布模式是基於下列的構想而設計： 軟體開發應依照一序列的階段進行。 一個階段的產出必須經過驗證或確認才能視為完成。 任何更改、錯誤或爭議都必須回溯到前面相關的階段加以修正。 若發現錯誤或新需求時，必須回溯到前面的相關階段。 圖3.1 瀑布模式 瀑布模式(2/3) 瀑布模式的管理意義 它鼓勵依生命週期階段來進行規劃。每一階段的結束正好成為管理控制的里程碑。 每一階段的產出都必須經過確認、驗證或測試。 確認是用來檢驗產出是否符合顧客的需求，以真實世界的問題為檢驗的對象。 驗證 是檢驗系統是否依規格正確地執行。 從事前階段工作的人，有責任將正確、完整、可行且容易瞭解的產出移交給下一階段的人員。 開發的程序變得更結構化且更容易管理。 瀑布模式(3/3) 瀑布模式的缺點 必須到了最後階段才能看到可執行的軟體系統，風險太高。 過於複雜與費時。 若需求不明確，而每一階段又要求非常結構化、嚴謹、完整的開發方法，將使得開發時程拉得很長。 雛型法(1/9) 雛型法 雛型法主要是基於下列的構想而設計的： 需求變更無可避免。 一個可看得到、可操作的雛型是開發者與使用者溝通的良好工具。 雛型的建造及修改應該要非常快速，以因應顧客的要求。 提高使用者參與的意願，進而提高顧客滿意度。 雛型法(2/9) 雛型法的層次 Cherveny 等人(1986)提出了以下之架構： 第一階雛型：又稱輸入／輸出設計，它只產生輸入／輸出的螢幕及列印的報表。 第二階雛型：包含使用介面及系統功能，經由第四代語言及關聯式資料庫快速地設計一個可執行的系統。 第三階雛型：發展一個適應環境的雛型，這種策略將系統永遠當作一個雛型，以因應外在環境的變動。 圖3.2 需求分析雛型 雛型法(3/9) 需求分析雛型依下列步驟進行：　 快速地分析使用需求，並建立雛型。此雛型包括使用介面和互動的功能，讓使用者可以操作並試驗。 蒐集試驗後的意見和需求的更改，並依此修改雛型。此循環重複數次直到滿意或可接受的程度為止。 將需求凍結並捨去雛型，再依傳統的瀑布模式進行設計、編碼、測試和操作維護。 雛型法(4/9) 分析與設計雛型 在建造雛型之前先做詳細的需求分析與初步設計，此法可降低重大需求變更和雛型修改的次數。 雛型經使用者的試驗和修改後，接下來的細部設計、編碼、測試和操作維護，與瀑布模式的作法一樣。 雛型系統的架構和主要功能模組都加以保留，經修改後成為最終的產品。 圖3.3 分析與設計雛型 雛型法(5/9) 子系統雛型 需求分析和初步設計依照傳統的瀑布模式進行。 初步設計時將系統分為數個子系統。 針對每一個子系統建立一個雛型。 子系統都完成後，便可進行整合。 各子系統雛型不予拋棄，而是演化為最終的產品。 圖3.4 子系統雛型 雛型法(6/9) 整體系統雛型 經需求分析、設計、編碼、測試等階段建造一個可運作但並不完美的雛型系統，這個快速發展的系統經使用者的操作與試驗，得以發掘更完整的需求，系統也