第二章 資訊系統開發模式

內容大綱 學習目標 2.1 導論 2.2 瀑布模式 2.3 漸增模式 2.4 雛型模式 2.5 螺旋模式 2.6 同步模式 2.1   導論 2.2   瀑布模式 2.3   漸增模式 2.4   雛型模式 2.5   螺旋模式 2.6   同步模式 2.7 Rational 統一流程模式 2.8 敏捷軟體開發 2.9 MDA 發展生命週期 2.10 結論

學習目標 詳讀本章，你至少能瞭解： 資訊系統開發模式之演進與時代背景。 目前有哪些常用之資訊系統開發模式。 各種資訊系統開發模式之特色、應用程序及適用情況。 資訊系統之特性及其適用的開發模式。 如何選擇一個較適當的資訊系統開發模式 。

2.1 導論 資訊系統開發模式或稱為軟體流程模式是資訊系統開發活動的一系列步驟及執行程序。 系統開發依循系統化、邏輯化的步驟進行時，有利於標準、規範與政策之推行和建立，開發的過程將更有效率、更能確保品質，也更容易管理。 不同的資訊系統開發模式，適用於不同情況的系統開發，圖2-1描述資訊系統開發模式之演進。 這些模式中，前兩者已幾乎無人使用，本章將依序介紹後八種系統開發模式。

圖2-1 資訊系統開發模式之演進

2.2 瀑布模式(1/3) 瀑布模式是一種系統開發之方法，該方法把系統開發的過程分成「幾」個階段，每個階段清楚定義要做哪些工作及交付哪些文件，各個階段循序執行且僅循環一次。 當問題較小或較單純時，劃分的階段可能少至三個，例如分析、設計、實施等階段（如圖2-2）;若面對較大或較複雜之問題時，其階段可能再被細分成更多個階段，例如可能擴充至十個階段（如表2-1、圖2-3）。

圖2-2 三個階段之瀑布模式

表2-1 大略與詳細之資訊系統開發階段

圖2-3 十階段之瀑布模式

2.2 瀑布模式(2/3) 瀑布模式除了在階段劃分上較有彈性外，該模式也提供兩個主要的加強項目： 若在各階段發現錯誤，可允許階段間之回饋，如此能儘早修正以減少系統修改或重做之成本。 各階段明確定義應做之工作及須交付之文件，使系統開發之工作更明確及容易掌握。

圖2-4 瀑布模式之系統開發程序

2.2 瀑布模式(3/3) 瀑布模式的問題： 在專案開始時，需求須完全且清楚地描述。 所有需求在各階段均需同時考量，且系統開發須在一個週期內完成。 在程式編輯前過於強調完整的分析與設計文件，故一旦需求變更，文件將需大幅修改。 系統開發週期較長且過程中使用者參與不足。 程式編輯於系統開發週期較後階段才開始，故風險較高，且失敗之成本亦高。

2.3　漸增模式(1/3) 漸增模式是一種系統開發之方法，該方法把需求分成「幾」個部分，然後依漸增開發計畫將每個「部分需求」之開發訂為一個開發週期，每個週期可依序或平行開發。每個週期之階段清楚定義要做哪些工作及交付哪些文件，每個階段循序進行且僅循環一次。

圖2-5 漸增模式之系統開發程序

2.3 漸增模式(2/3) 系統被分成幾個子系統或功能，各子系統可獨立依序開發；而瀑布模式則是各個子系統需同時開發。 2.3　漸增模式(2/3) 漸增模式與瀑布模式大致相同，但仍有一些地方不同，例如： 系統被分成幾個子系統或功能，各子系統可獨立依序開發；而瀑布模式則是各個子系統需同時開發。 系統開發可由多個週期完成，每個週期表示不同版本之系統，因為每個週期均有程式編輯及上線實施，使用者均有參與，故漸增模式之風險較低。

2.3 漸增模式(3/3) 漸增模式適用於下列情況： 組織的目標與需求可完全且清楚地描述。 2.3　漸增模式(3/3) 漸增模式適用於下列情況： 組織的目標與需求可完全且清楚地描述。 預算須分期編列，將系統做整體規劃，往後再分期執行。 當組織需要時間來熟悉與接受新科技時，應用漸增模式有充裕的時間來學習與轉移技術。

2.4 雛型模式(1/3) 雛型模式是一種系統開發方法，該方法先針對使用者需求較清楚的部分或資訊人員較能掌握之部分，依分析、設計與實施等步驟快速開發雛型。 開發過程中，強調盡早以雛型作為使用者與資訊人員需求溝通與學習之工具，雙方透過雛型之操作與回饋，釐清、修改及擴充需求，並藉以修改與擴充雛型。上述步驟反覆進行，直到系統符合雙方約定為止。

圖2-6 雛型模式之系統開發程序 及參與人員

2.4 雛型模式(2/3) 雛型模式之主要特性與原則如下： 強調雛型之快速開發及使用者高度參與。 強調以雛型作為使用者及系統開發者之需求溝通與學習機制。 從需求最清楚的部分著手開發雛型，並透過使用者對雛型之操作與回饋，反覆修改與擴充，每次反覆時間間隔（週期）要盡可能縮短。

2.4 雛型模式(3/3) 雛型模式的潛在問題： 因強調以「雛型演進」代替完整之分析與設計，故系統文件較不完備，程式亦可能較難維護。短期而言，可能較能滿足使用者需求；但對長期而言，系統較易失敗。 因缺乏整體之規劃、分析與設計，故較不適用於大 型及多人參與之系統開發專案。 雛型模式有兩種常見之應用策略： 演進式雛型策略 用後丟棄式雛型策略

2.4.1 演進式雛型策略 演進式雛型策略主要係將所有需求看成一個整體，從需求最清楚的部分先快速經歷一系統開發週期，以完成初版雛型系統之開發。 再利用該雛型與使用者溝通，以確定、修改和擴充需求，並藉以作為下一週期雛型演進之依據。 該週期不斷地反覆進行，直到雛型系統符合雙方約定為止。

圖2-7 演進式雛型策略之系統開發程序

2.4.2 用後丟棄式雛型策略(1/2) 用後丟棄式雛型策略一般是以一種快而粗糙的方式建立雛型，以促使使用者能夠盡快藉由與雛型之互動來決定需求項目，或允許資訊人員藉以研發問題之解決方法與資訊科技之應用等。 這種雛型因為用後即丟，所以不需要考慮雛型系統之運用效率與可維護性，也不需要考慮容錯的能力。

2.4.2 用後丟棄式雛型策略(2/2) 用後丟棄式雛型策略若用於具高困難度之技術或設計的專案，可以藉由快速的雛型開發與檢討，探索出問題之解決方法或資訊科技應用的可行性。 用後丟棄雛型策略僅實施在風險程度最高的地方，例如在使用者需求或解決問題之知識、概念與資訊科技整合最不清楚的情況，而其他情況則盡可能地採用演進式雛型策略，因為雛型之丟棄也意謂著成本的浪費。

2.5 螺旋模式(1/6) 螺旋模式之軟體開發程序是基於瀑布模式應用於政府大型軟體專案之經驗，經多次修改而成。 其執行由三個步驟形成一週期： 找出系統的目標、可行之實施方案與限制。 依目標與限制評估方案。 由剩下之相關風險決定下一步驟該如何進行。 此週期反覆進行，直到系統開發完成為止。

圖2-8 螺旋模式之開發程序

2.5 螺旋模式(2/6) 步驟一：找出系統的目標、可行之實施方案與限制 找出系統的目標 系統目標之評核因素很多，例如系統的績效、功能與容忍改變之能力等。 找出系統之實施方案 系統實施方案會因問題而異，例如找出之實施方案有設計方案A、設計方案B、重用、購買等。 實施方案之限制 實施方案之限制可能為專案之成本、時程、系統介面等。

2.5 螺旋模式(3/6) 步驟二：依目標與限制評估方案 主要是找出各方案之不確定處並設法解決，其步驟如下： 找出不確定的部分，也就是專案風險之重要來源。 解決風險來源。 可用雛型、模擬、標竿(Benchmarking)、參考點檢查(Reference Checking)、問卷、分析模式、上述方式之綜合或其他技術以解決風險。 選擇風險解決方法時，應考慮成本效益。

2.5 螺旋模式(4/6) 步驟三：由剩下之相關風險決定下一步驟 若績效或使用者介面風險將強力影響程式開發或內部介面控制，則下一步驟可能是採取演進式雛型策略。 若該雛型使用性佳且夠強韌 (Robust)，足以當作未來系統發展之基礎，則往後的步驟將是一系列的雛型演進。 假如先前之雛型已解決所有的績效或使用者介面之風險，且程式開發及介面控制之風險獲得掌控，則下一步將遵循基本的瀑布模式，亦可適當地修飾以整合漸增模式。

2.5 螺旋模式(5/6) 螺旋模式之特色與應用原則： 在高風險部分之設計尚未穩定前，規格之發展不需要一致、詳盡或正式，以避免不必要之設計修改。 在開發之任一階段，螺旋模式可選擇整合雛型模式以降低風險。 當找到更吸引人之方案或需解決新風險時，螺旋模式可整合重做或回到前面之階段。

2.5 螺旋模式(6/6) 螺旋模式包容了現有軟體流程模式之大部分優點，且其風險導向之方法解決了許多系統開發模式所存在之問題。 在某些條件下，螺旋模式相當於某一現有之流程模式。例如： 若專案在使用者介面或綜合績效需求方面屬於低風險，且在預算及時程控制方面屬於高風險，則這些風險之考量會使螺旋模式之執行相當於瀑布模式或漸增模式。 若專案在預算及時程控制、大型系統之整合或需求變動方面之風險較低，且在使用者介面或使用者決策支援需求方面之風險較高，則這些風險之考量會使螺旋模式之執行類似於雛型模式。

2.6 同步模式(1/3) 同步模式源自於製造業的同步工程，目的在縮短開發時間、加速版本之更新。 同步模式是基於三個主要的構想來達到縮短時程的目標： 多個團隊同時開發。這種多組人同時工作的方式稱為活動同步 (Activity Concurrency)。

2.6 同步模式(2/3) 向前傳遞 (Front Loading) 向後傳遞 (Flying) 2. 資訊同步。不同團隊的資訊互相交流與共享，稱為資訊同步 (Information Concurrency)。 資訊同步有三個技巧： 向前傳遞 (Front Loading) 向後傳遞 (Flying) 建立一個有效的資訊交換網路及支援群體工作的環境 3. 整合性的管理系統。同步模式的管理比一般的開 發模式複雜，必須開發一個管理系統以協調人員、資源、過程及產品間複雜的互動關係。

圖2-9 同步模式之開發程序

2.6 同步模式(3/3) 同步模式的發展主要是為了因應商業套裝軟體的市場競爭。 其優點是開發時間的縮短可提高產品的競爭力。 其缺點則是緊湊的步驟及資訊溝通的頻繁，使得專案管理的複雜度大幅提高，人力成本也相對提高，若沒有輔以良好的工具及管理方法，則不易達成目標。

圖2-10 同步開發與循序開發方法比較

圖2-11 同步開發模式

2.7 Rational 統一流程模式(1/14) RUP 模式於1998年由Jacobson 等人提出。該模式結合螺旋模式的概念，以反覆與漸增的軟體開發原理進行軟體發展，且每一次的反覆後需產出一個可運作的系統版本，並在每一個反覆週期中評估風險，以盡早發現問題。 RUP 模式可由動態與靜態兩個構面來說明系統開發專案之實施階段與核心工作，如圖2-12 。

圖2-11 同步開發模式

2.7 Rational 統一流程模式(2/14) RUP 模式的動態面（水平軸）把軟體開發依序分成四個主要階段：初始、詳述、建構與轉移。這四個階段構成一個週期，週期可反覆進行，每個週期內之各階段也可視情況反覆進行。 RUP 模式的靜態面結構（垂直軸）主要處理依邏輯順序將軟體開發與管理支援工作表達成九個核心工作流程：企業塑模、需求、分析與設計、實作、測試、配置、組態管理與變更管理、專案管理、 環境等，其中前六項是軟體工程工作，而後三項是管理支援工作。 水平軸與垂直軸交叉格上的圖形面積代表其所對應工作之估計工作量或比率。

2.7 Rational 統一流程模式(3/14)－動態面 初始階段：建立系統需求與範圍、接受準則並評估整體風險、構想企業個案，取得參與人員認同。 詳述階段：處理主要的技術工作與探討技術風險。 建構階段：建構一初步可運作的系統版本，並演化為具有完整功能的系統版本。 轉移階段：依使用者回饋調整後，將系統産品移交客戶使用。

2.7 Rational 統一流程模式(4/14)－靜態面

2.7 Rational 統一流程模式(5/14)－靜態面之企業塑模 企業塑模 (Business Modeling)工作流程之目的是為了瞭解系統要部署的目標組織 (Target Organization)之未來結構 (Structure) 與動態 (Dynamics)，瞭解其目前問題與找出可能的改善方式，確保客戶、終端使用者與開發者對目標組織有共同的瞭解，及導出系統需求以支援目標組織等，並產出企業模型。 為達該目的，企業模型需描述如何發展目標組織的願景，基於該願景訂定目標組織的企業模型之流程、角色與責任；該企業模型由企業使用個案模式與企業物件模式所組成。

2.7 Rational 統一流程模式(6/14) －靜態面之需求 需求 (Requirement)工作流程之目的是建立與維護客戶及其他參與者對系統應做什麼 (What) 與為何做 (Why) 之認同，提供系統開發者較好理解的系統需求；定義系統範圍，提供基準以供規劃反覆發展的技術內容；提供基準以供估算系統開發之成本與時程，及針對使用者之需求與目標定義系統之使用者介面等。 為達該目的，需求必須描述如何定義系統的願景，再將願景轉換成使用個案模式，定義系統之細部軟體需求，描述如何應用需求屬性以幫助管理系統的範圍與需求變更等。

2.7 Rational 統一流程模式(7/14)－靜態面之分析與設計 分析與設計 (Analysis and Design)工作流程之目的是將需求轉換成如何實作系統之規格。 為達到該目的，分析與設計須描述對需求之瞭解，及如何藉由選擇最佳的實施策略將需求轉換成系統設計。 在專案初期須建立強韌的系統結構，以供設計一個容易瞭解、建立與演化的系統，接著調整設計以符合實作環境及績效、強韌性、可擴充性、測試性與其他品質之要求等。

2.7 Rational 統一流程模式(8/14)－靜態面之實作 實作 (Implementation) 工作流程之目的是以子系統之組織階層 (Layers) 定義程式碼之組織，以元件實作類別與物件，對各元件進行單元測試，將個別實作者或團隊之成果整合成可執行的系統等。 實作僅侷限於個別元件之單元測試，而系統測試與整合測試是屬於測試之工作範圍。

2.7 Rational 統一流程模式(9/14)－靜態面之測試 測試 (Test)工作流程之目的是發現與紀錄軟體產品的瑕疵與問題，向管理者報告軟體品質，經由具體的系統展示評估在設計與需求規格所做的假設，驗證軟體是否能依設計運作，驗證需求是否有被適當的實作等。 測試與其他RUP 模式之工作流程有一些有趣的差異，例如需求、分析與設計、實作等三項工作流程主要針對軟體產品之完整性、一致性與正確性，而測試工作流程主要針對軟體產品是否有哪些遺漏、不正確或不一致的情況。

2.7 Rational 統一流程模式(10/14)－靜態面之配置 配置 (Deployment) 工作流程之目的是測試軟體在最終作業環境之運作（β 測試），包裝軟體以便交付、配送軟體、安裝軟體、訓練終端使用者與銷售人員、移轉 (Migrating) 現有軟體或轉換 (Converting) 資料庫等。 這些活動之實行會因不同的產業、專案規模大小、交付方式、企業環境，而有差異。

2.7 Rational 統一流程模式(11/14)－靜態面之組態管理與變更管理 組態管理與變更管理 (Configuration and Change Management)工作流程之目的是追蹤與維護專案資產在演進過程之完整性 (Integrity)。 在軟體發展生命週期中，會製作許多有價值的產出，這些是重要的投資，也是重要的資產，因此必須被安全地看管，且隨時可以被重用。 這些產出在反覆發展過程中會被一再更新，因此版本必須被妥善管理，包括每個版本之存放位址、如何存取、為何被修改、目前之狀態與負責管理之人員等。

2.7 Rational 統一流程模式(12/14)－靜態面之專案管理 專案管理 (Project Management)工作流程之目的是提供管理軟體專案的架構，提供實務準則以供規劃、人員訓練、執行與監督專案，提供管理風險的架構。 然而，RUP 模式並不含括所有專案管理之議題，例如不包括人員、預算、合約管理等；而針對反覆發展之方面，例如規劃整個專案生命週期的反覆與某一個特定的反覆、風險管理、監督專案反覆與衡量之進展等。

2.7 Rational 統一流程模式(13/14)－靜態面之環境 環境 (Environment) 工作流程之目的是以一些流程與工具支援軟體開發之組織，這包括選擇與取得工具、裝配與配置工具以適合組織、處理組態與改善技術服務以支援流程等。

2.7 Rational 統一流程模式(14/14) －塑模元件(1/4) RUP 模式用四種塑模元件來描述每個核心流程工作： 1. 工作人員 工作人員 (Worker) 是參與專案的人們在專案中所扮演的角色 (Role)（例如系統分析師、專案經理等），它定義每位參與者在專案中所做之流程工作、應具備的才能與應負的責任。 一位參與者可以扮演一個或多個角色，且不同的人可能扮演相同的角色。

2.7 Rational 統一流程模式(14/14) －塑模元件(2/4) 2. 活動 一項活動 (Activity) 是一位特定工作人員在其角色上所執行的一個工作單元。 活動有清楚的目標，通常會產生或更新工作產出（例如模式、類別或計畫）。 每個活動至少會分配給一位工作人員，且須定義工作人員所應執行的工作，及活動完成後對專案會產生哪些有意義的結果，例如有哪些產出等。

2.7 Rational 統一流程模式(14/14) －塑模元件(3/4) 3. 工作流程 一個工作流程 (Workflow) 是一連串活動的組合，而且這些活動會產生有價值或有意義的結果。 工作流程通常會描述活動之順序，顯示工作人員所參與之活動及彼此間之互動，而且這些活動有順序地組合能產生有價值或有意義的產出。

2.7 Rational 統一流程模式(14/14) －塑模元件(4/4) 4. 產出 一項產出 (Artifact) 是經由活動或工作流程所製造、修改或使用的一件資訊。 產出是專案的實際產品，也就是在產生最終產品的過程中，專案所產生或使用的東西，它可以是工作人員在執行活動時的輸入資訊，也可能是輸出資訊或結果。 工作產出可能是企業個案 (Business Case) 或軟體結構文件 (Software Architecture Document) 等；產出可以用多種方式表達，包括語言、圖形、模式、多媒體等。

2.8 敏捷軟體開發(1/5) 一群不同軟體開發方法的領域代表於2001年共同推出敏捷宣言 (Agile Manifesto)。 其主要目的為提出一套較傳統軟體開發方式更為簡捷且快速的軟體開發概念，此即敏捷軟體開發 (Agile Software Development)。

2.8 敏捷軟體開發(2/5) 敏捷軟體開發的主要開發理念和價值觀如下(Beck et al., 2001) ： 個體與互動勝於流程與工具。 可運作的軟體勝於全面性的文件。 與客戶的協同合作勝於契約談判。 因應變化勝於遵循計畫。 目前有多種軟體開發方法，包括動態系統開發方法、精實軟體開發和極限編程等，皆以上述敏捷軟體開發概念為基礎。

2.8 敏捷軟體開發(3/5) －動態系統開發方法(1/2) 此方法之開發過程主要以反覆與漸增的方式進行，並強調使用者在開發過程中的參與。 在開發過程中，動態系統開發方法會隨需求改變而反覆調整，目的在於準時且於預算內將軟體開發完成，因此主要應用於時程緊湊且預算有限之專案。

2.8 敏捷軟體開發(3/5) －動態系統開發方法(2/2) 動態系統開發方法實施的過程分為：專案前 (Pre-Project)、專案生命週期 (Project Life-Cycle) 和專案後 (Post-Project) 三個階段。 其中，專案生命週期之主要工作可分為五個階段： 可行性研究 (Feasibility Study) 企業研究 (Business Study) 反覆功能建模 (Functional Model Iteration, FMI) 反覆設計與建置 (Design and Build Iteration, DBI) 實施 (Implementation) 動態系統開發方法之實施過程如圖2-13。

2.8 敏捷軟體開發(4/5) －精實軟體開發 精實軟體開發為將豐田生產系統 (Toyota Productive System, TPS) 提出之精實生產 (Lean Manufacturing) 原則與方法，應用於軟體開發領域。 包括七項原則概念： 消除浪費 (Eliminate Waste) 增進學習 (Amplify Learning) 延遲決定 (Delay Commitment) 快速遞送 (Deliver Fast) 團隊授權 (Empower the Team) 建置完整 (Build Integrity In) 全盤檢視 (See the Whole)

2.8 敏捷軟體開發(5/5) －極限編程(1/2) 為Kent Beck 於1996年提出之軟體開發方法。與其他敏捷軟體開發方法相似，極限編程亦著重於開發流程是否對使用者或企業產生價值，強調以有效率且富彈性（反覆與漸增）之方式，開發高品質之軟體系統。

2.8 敏捷軟體開發(5/5) －極限編程(2/2) 極限編程提出四項軟體開發基本行為： 編碼 (Coding)：系統開發過程中最重要的產出為可運作的程式碼，程式碼有助於找出適當的解決方案。 測試 (Testing)：若藉由小部分的測試可減少某些多餘的流程，則藉由許多的測試過程將可減少更多累贅的流程。 傾聽 (Listening)：系統開發人員必須傾聽使用者希望系統為其達成的需求，並以技術的觀點回饋使用者。 設計 (Design)：系統開發過程若不經由設計可能無法釐清系統開發的範圍，亦導致系統內協同運作的元件過度相依，即修改部分元件會影響其他運作的元件。

2.9 MDA發展生命週期(1/5) 模式驅動結構 (Model Driven Architecture, MDA) 是由OMG (Object Management Group) 定義的一種軟體開發架構，其關鍵是軟體開發過程中每個階段（或步驟）的產出均須建構出模式，且該模式之產出為下一個階段的輸入。 MDA 的發展生命週期其實與其他系統開發模式（例如瀑布模式或RUP 模式）的主要的差別是在發展過程中步驟之產出，強調該產出是由電腦可理解的正規模式 (Formal Model) 表達。

圖2-14 MDA 軟體發展生命週期

2.9 MDA發展生命週期(2/5) MDA 有三個核心模式：PIM、PSM 與Code。 平台獨立模式 (PIM) PIM 是一種高階抽象模式，該模式與開發技術獨立。PIM 是分析與設計結果的重要產出，主要根據需求塑模的結果，從如何支援企業運作的觀點描述一個軟體系統，並不涉及描述系統開發與運作之平台。 PIM 必須以有完整定義 (Well-Defined) 的語言來描述，一個具有完整定義的語言具有完整定義的語法 (Syntax) 與語意 (Semantics)，且適合用電腦來自動解譯 (Automated Interpretation)。因此，以UML 來描述PIM 是目前最好的選擇。

2.9 MDA發展生命週期(3/5) 特定平台模式 (PSM) PSM 是一種特定平台的模式，也就是該模式相依於軟體開發技術。對某一種PSM 而言，可能僅具有該特定平台知識的開發者才能理解。 一個PIM 可被轉成一至多個PSM，因為一個系統可能由數種技術開發而成，對每一個特定的技術平台需產生一個與其他技術分開的PSM，而PSM 間可藉由溝通橋樑 (Communication Bridge) 的機制來互動。

2.9 MDA發展生命週期(4/5) 程式模式 (Code) 每一個PSM 都需被轉成程式模式（簡稱程式碼），因為一個PSM 相依於其開發技術，因此PSM 轉成程式碼之步驟非常直接。 若有多個PSM 則會轉出多種的程式碼，不同的程式碼間也須藉由溝通橋樑的機制來互動。

圖2-15 PIM 轉PSM 轉Code

2.9 MDA發展生命週期(5/4) 圖2-16 MDA 之三個主要模式與轉換步驟 MDA 轉換程序 如圖2-15 吳仁和 (2010) 2.9 MDA發展生命週期(5/4) MDA 轉換程序 如圖2-15 MDA 的每一個轉換（例如PIM→PSM，PSM→Code）須有清楚的轉換定義，且該轉換的工作是藉由CASE Tool 來執行，也就是PIM 可藉由CASE Tool 轉換成PSM，再轉換成Code。 圖2-16 MDA 之三個主要模式與轉換步驟

2.9 結論 綜合來說，系統開發模式之發展依其被提出之時間順序，依序是瀑布模式、漸增模式、雛型模式、螺旋模式、同步模式、RUP 模式、敏捷軟體開發與MDA 模式。 由於被提出之先後順序不同，後來提出的模式大多針對前面模式之問題提出修正。 表2-3說明本章介紹之八種系統開發模式的基本假設或適用情況及其主要特徵。

表2-3 八種系統開發模式比較(1/3)

表2-3 八種系統開發模式比較(2/3)

表2-3 八種系統開發模式比較(3/3)