Chapter 2 資訊系統開發模式 - Ian-Liu-1990/Systems-Analysis-Design GitHub Wiki

1. 瀑布模式

• 定義 : 系統開發必須經歷一個"完整週期"，一個週期嚴格的"分成數個階段和其目標"，又稱為SDLC

  • 週期 : 清楚定義一個週期有哪些階段，只少３階段包括：分析，設計，實施且各階段都必須同時考量"整個專案的所有需求"

  • 階段 : 清楚定義那些工作及需交付文件，各階段循序執行，並只可以循環一次

• 特色 : 開發過程中強調必須要有完整的規劃，分析，設計，測試，階段結束前必須經過確認，完全成功才會進入下一階段作為管理控制的手段

• 適性

2. 漸增模式

• 定義 : 系統開發的需求被切割成數個子需求，每個部分需求被制訂成一個週期

  • 週期 : 清楚定義一個週期有哪些階段，只少３階段包括：分析，設計，實施，每一個週期可依序或平行開發，各階段不必再同時考量"整個專案的所有需求"

  • 階段 : 清楚定義那些工作及需交付文件，各階段循序執行，並只可以循環一次

• 特色 : 每一個週期獨立依序或同步開發，增加新功能，模組或子系統，子系統不再如同瀑布一樣"需全部同時完成"，而是分好幾個週期，每個週期就是一個新版本

• 適性

3. 雛型模式

• 定義 : 整個專案生命週期間，需求可能會不斷的改變，針對使用者需求明確清楚得部分，開發人員依分析，設計與實施等步驟快速開發一個雛形

演進式策略

• 定義 : 將所有需求看成一個整體，從需求最清楚明確的，技術最成熟的部分。快速經歷一開發週期來完成初版雛型系統，再以初版雛型系統為基礎，與使用者溝通，以修改和擴充需求，再成為下一週期雛形演進之依據，同時需要考量上一週期的需求與新需求，雛型系統不斷演進直到雙方合約結束。

用後丟棄式策略

• 定義 : 要求快速而粗糙的方式建立雛型，促使使用者與之互動來"決定需求項目"，或"允許資訊人員藉以解決問題與導入資訊科技"。每次雛型開發的回饋成為資訊人員探索問題與導入科技應用可行性的參考

• 適性

---

模式比較

模式	模式需求限制條件	成本	潛在風險	需求變動	專案規模	其他
瀑布	1. 使用者自己可將需求完整且明確表達 2. 解決問題之知識與經驗充足3. 資金與人員充足4.軟硬體技術與支援沒問題	昂貴，開發週期長	過程中後期參與者不足，程式編撰過於後期，需求改變突然，失敗機率高	1.需求變動不可頻繁2.過於強調編寫前的完整分析與設計需求文件3.所有需求必須在同一個週期內完成	大型且低風險	1.強調先有完整設計和規劃文件再編碼2.重視需求改變需求設計與規劃文件要大幅度的改寫
漸增	同瀑布資金，人力和技術有明顯缺口	成本採分期編列的預算模式	改採多個子系統開發，每個週期都可及早發現上一個週期的問題並與參與者一起討論，做為下一週期之基礎，"風險稍降低"	1.每一次階段性需求不用再同時考量其他接端需求2.所有需求沒有要求要在一個週期內完成	同上	1.適合資金短缺2.需要時間來熟悉與接受新科技的引入
雛型	1.使用者無法明確和量化表達自己真正的需求，需求還有待擴充或修正2.資訊人員對應用領域不熟悉，開發技術知識與解決問題欠缺3.需求改變頻繁，使用者必須全程積極參與討論	?	1.演進取代完整分析與設計，缺乏完整規劃文件，長期導致後續人員維護困難而系統失敗2.缺乏整體規劃，分析與設計，不適合大型專案開發	1.強調"快速開發"，使用者高度積極與雛型系統互動，"大量需求反覆修改與擴充"2.資訊人員從回饋中提早發現問題與解決，技術引進與熟悉		演進式策略：在於解決使用者無法明確詳述需求，資訊人員缺乏領域知識和技術支援，需要頻繁互相溝通來完成系統用後丟棄式策略：高難度技術或設計專案，藉由快速雛型開發與檢討，探索前所未知的問題解決方法與科技技術的可行性
螺旋	綜合瀑布，漸增，雛型各種情況					強調各週期之規劃與風險評估來決定下一個步驟
同步	1.需求可清楚與完整描述2.有足夠的人力3.團隊必須要有良好的溝通，資訊交換與專案管理					1.工作分割並同時多團隊進行2.系統整合與測試必去全部一起執行，功能組不可缺少

---

4. 螺旋模式(Spiral Model)

• 定義 ：漸增和雛型無法完全解決瀑布模式執行上的問題(需求變動，技術支援，開發時間)，強調每個週期結束後的風險評估與規劃，以此為基礎做為下一次週期的模式選擇

• 週期 : 每個週期均包含以下步驟

目標一. 找出系統的目標，可行性之實施方案與限制

• 動機 : 每一週期，不管需求或技術引進都有可能變動，目標與可施行方案與限制都會因週期而異

目標二. 依目標與限制評估方案

• 動機 : 替新的目標與方案找出重要風險，並解決風險

目標三. 由剩下之相關風險決定下一步驟或模式選擇

• 動機 : 依據風險有無解決，風險高低決定下一步驟

  • 風險無法解決，預算短缺和時程控制差

  風險高低	說明
  高	用後丟棄式策略，目的再找到解決方法
  低	演進式策略，繼續解決主要風險，若性能佳且夠強韌再採一系列雛型逐步完成該週期

  • 風險解決且預算和時程控制差掌握度佳 : 下個週期可再依循瀑布模式或適當地修飾以整合漸增式

• 適性

---

5. 同步模式

• 定義 ：將每個版本(Release)的系統的多個工作分成數個功能組，交由多個團隊同時開發縮短開發時間，同一個版本的功能組全部開發完成再交由一團隊整合和測試，其他開發團隊再繼續進行下一版本的開發

• 功能組 : 由多個功能集合，基於多個團隊平行開發來縮端開發時程，加速版本更新

• 適性

6. Rational統一流程模式

7. 敏捷軟體開發

8. MDA軟體發展生命週期