软体系统开发模式.ppt

軟體開發模式 內容大綱 導論 編碼與修正模式 階段模式 瀑布模式 漸增模式 雛型模式 螺旋模式 同步模式 RUP模式 敏捷軟體開發 第四代技術* 快速應用軟體開發* 結論 導論 「軟體開發模式」是描述軟體開發過程的一系列步驟及其執行程序。 開發的過程依循系統化、邏輯化的步驟進行時，將有利於標準、規範與政策之推行和建立，而且開發過程將更有效率，更能確保品質，也更容易管理。 不同的開發模式，適用於不同情況的系統開發。 軟體開發模式 編碼與修正模式 階段模式 瀑布模式 漸增模式 雛型模式 螺旋模式 同步模式 RUP模式 各種開發模式之演進 編碼與修正模式 無方法論可言，主要包含兩個步驟： 先寫部分程式， 再修正程式中之問題。 編碼與修正模式 (c.2) 主要之問題： 過程中沒有規劃(plan)、分析及設計，故經過幾次修正之後，程式碼的邏輯變得難以理解。 無使用者需求分析與確認，軟體雖設計得很好，但可能並不符合使用者的需求。 階段模式 具有方法論之雛型。 改善了編碼與修正模式之問題，強調 系統開發前要有規劃(plan)， 程式編碼(coding)前要有分析與設計， 系統上線前要有測試(testing)等。 階段模式 (c.2) 階段模式 (c.3) 雖已改善了編碼與修正模式之問題，但使用上仍衍生以下之問題： 不論系統之大小或複雜程度均需經歷八階段， 各階段之進行是循序的且階段間沒有回饋， 各階段均需考量完整的系統範圍，不可僅考量部份系統， 假設使用者需求可完整且清楚的描述。 瀑布模式 開發的過程分成幾個階段，且劃分上較有彈性。 每個階段清楚定義要做那些工作及交付那些文件，使系統開發之工作更明確及容易掌握。 可允許階段間之回饋，若在各階段發現錯誤，能儘早修正以減少系統修改或重做之成本。 各階段循序的執行且僅循環一次。 瀑布模式 (c.2) 當系統較小或較單純，劃分的階段可能少至三個，例如分析、設計、實作(Implementation) 等階段。 瀑布模式 (c.3) 瀑布模式 (c.4) 若面對較大或複雜之系統時，其階段可再被細分成更多個階段： 瀑布模式 (c.5) 瀑布模式 (c.6) 瀑布模式的一些問題： 假設在專案開始時，需求可完整且清楚描述， 所有需求在各階段均需同時考量，且系統開發在一個週期內完成， 在程式編輯前過於強調完整的分析與設計文件，故一但需求變更，文件需大幅修改， 程式編輯於系統開發週期之後段才開始，故風險較高，且失敗之成本亦較高， 瀑布模式 (c.7) (5)系統開發週期較長且過程中使用者參與不足。 漸增模式 把需求分成幾個部分，然後將每個部分的需求之開發訂為一個開發週期，每個週期可依序或平行開發。 每個週期之階段清楚定義要做那些工作及交付那些文件， 每個週期內，各階段循序進行且僅循環一次。 漸增模式 (c.2) 漸增模式 (c.3) 特色： 系統被分成幾個子系統或功能，各子系統可獨立依序或平行開發。 系統開發可由多個週期完成，每個週期均有分析設計、程式編輯及測試，每個週期完成不同版本之系統。 使用者參與程度高，每個週期均參與，故相較於瀑布模式，漸增模式之風險較低。 漸增模式 (c.4) 漸增模式適用之情況： (1) 目標與需求可完全與清楚描述。 (2) 預算需分期編列。 (3) 需要時間來熟悉和接受新科技。 雛型模式 此方法先針對使用者需求較清楚的部分或資訊人員較能掌握之部份，依分析、設計與實施等步驟快速進行雛型系統開發。 過程中，強調儘早以雛型系統做為使用者與資訊人員需求溝通與學習之工具，雙方透過雛型之操作與回饋，以釐清、修改及擴充需求，並藉以修改與擴充雛型系統。 上述步驟反覆進行，直到系統符合雙方約定為止。 雛型系統有時是一個：只有使用者界面，而沒有核心部分的軟體。 雛型模式(c.2) 雛型模式 (c.3) 主要特性與原則： 強調雛型之儘早開發及使用者高度的參與。 強調以雛型作為使用者及系統開發者之需求溝通與學習機制。 從需求最清楚部分著手開發雛型，並透過使用者對雛型之操作與回饋，反覆修改與擴充，每次反覆之週期要儘可能縮短。 雛型模式 (c.4) 其他適用情形： 當無法立即獲得解決問題的方法。 當軟／硬體之技術與支援不確定。 雛型模式 (c.5) 雛型模式的潛在問題： 系統文件較不完備，程式亦較難維護。短期可能較能滿足使用者需求，但長期而言系統較易失敗。 因缺乏整體之規劃、分析與設計，故較不適合於大型及多人參與之系統開發專案。 雛型模式 (c.6) 有兩種常見之應用策略： 演進式雛型 (Evolutionary Prototyping) 用後丟棄雛型 (Rapid Throwaway Prototyping) 演進式雛型策略(c.7) 將所有需求看成一個整體，從需求最清楚的部分快速的經歷一