Transcript 2.6 雛型模式
第二章 資訊系統開發模式 1 內容大綱 學習目標 2.1 導論 2.2 編碼與修正模式 2.3 階段模式 2.4 瀑布模式 2.5 漸增模式 2.6 雛型模式 2.7 螺旋模式 2.8 同步模式 2.9 結論 2 學習目標 詳讀本章，你至少能瞭解： 資訊系統開發模式之演進及時代背景。 常用之資訊系統開發模式。 各種系統開發模式之特色、應用程序及適用情 況。 資訊系統之特性及其適用的開發模式。 如何選擇一個適當的開發模式。 3 2.1 導論 資訊系統開發模式或軟體流程模式是開發活動 一系列的步驟及其執行程序。 系統開發依循系統化、邏輯化的步驟進行時， 有利於標準、規範與政策之推行和建立，開發 的過程將更有效率，更能確保品質，也更容易 管理。 不同的資訊系統開發模式，適用於不同情況的 系統開發 圖2-1描述系統開發模式之演進。 4 圖2-1 系統開發模式之演進 螺旋模式 (Mills等人,1986; 同步模式 Boehm,1988) (Aoyama, 1993) 雛型模式 (Bally等人,1977) 漸增模式 (Mills,1971) 瀑布模式 (Royce,1970) 階段模式 (Benington,1956) 1950 1960 1970 1980 1990 5 2.2 編碼與修正模式 編碼與修正模式是最早（1956年前）使用之模式，該 模式並無方法論可言，主要包含兩個步驟： (1) 先寫部分程式 (2) 再修正程式中之問題。 主要問題： (1)沒有規劃及設計，故經過幾次之修正後，程式碼的邏輯變得 難以理解， (2)過程中並無使用者需求分析與確認，軟體雖然設計得很好， 但可能並不符合使用者的需求。 6 2.3 階段模式 作業規劃 作業規格描述 程式規格描述 編碼 參數測試 整合測試 上線測試 系統評估 7 2.3 階段模式 (c.2) 階段模式已具有方法論之雛型，該模式強調 系統開發前要有規劃， 程式編輯前要有分析與設計， 系統上線前要有測試等。 階段模式雖已改善了編碼與修正模式之問題，但使用 上仍衍生以下之問題： 不論系統之大小或複雜程度均需經歷八階段， 各階段之進行是循序的且階段間沒有回饋， 各階段均需考量完整的系統範圍，不可僅考量部份系統。 假設需求可完整且清楚的描述。 8 2.4 瀑布模式 定義： 瀑布模式 是一種系統開發之方法，該方法把系統開發的過程 分成〝幾〞個階段，每個階段清楚定義要做那些工作及交付 那些文件，各個階段循序的執行且僅循環一次。 當問題較小或較單純，劃分的階段可能少至三個，例 如分析、設計、實施等階段（如圖2-3）; 若面對較大或複雜之問題時，其階段可再被細分成更 多個階段，例如可能擴充至十個階段。 9 2.4 瀑布模式 (c.2) 分 析 設 計 實 施 10 2.4 瀑布模式 (c.3) 表2-1、大略vs.詳細vs.業界之系統開發階段 概略 1.分析 2.設計 3.實施 詳細 1.可行性分析 2.需求分析 3.系統分析 4.概念性分析 5.細部分析 6.程式設計&單元測試 7.整合測試 8.安裝與系統測試 9.教育訓練 10.操作與維護 3.系統設計 4.系統開發 5.系統驗收 6.系統維護 1.需求擷取& Power 需求分析 Designer (CASE Tool) 2.系統分析 11 2.4 十階段之瀑布模式(c.4) 可行性分析 需求分析 教育訓練 操作與維護 12 2.4 瀑布模式 (c.5) 瀑布模式除了在階段劃分上較有彈性外，該模 式至少另提供二項主要的加強： 若在各階段發現錯誤可允許階段間之回饋，使能儘 早修正以減少系統修改或重做之成本。 各階段明確定義應做之工作及交付之文件，使系統 開發之工作更明確及容易掌握。 13 圖2-5 瀑布模式開發程序與系統 明確的、 完整的需求 最終系統 使用者 使用者 14 2.4 瀑布模式 (c.7) 瀑布模式的一些問題： (1) 假設在專案開始時需求可完全且清楚描述， (2) 所有需求在各階段均需同時考量，且系統開發在 一個週期內完成， (3) 在程式編輯前過於強調完整的分析與設計文件， 故一但需求變更，文件需大幅修改， (4) 系統開發週期較長且過程中使用者參與不足， (5) 程式編輯於系統開發週期之後段才開始，故風險 較高，且失敗之成本亦較高。 15 2.5 漸增模式 定義： 漸增模式是一種系統開發之方法，該方法把需求分 成〝幾〞個部分，然後依漸增開發計畫將每個〝部 分需求〞之開發訂為一個開發週期，每個週期可依 序或平行開發。每個週期之階段清楚定義要做那些 工作及交付那些文件，每個階段循序進行且僅循環 一次。 漸增模式之開發程序與系統如下： 16 2.5 漸增模式 (c.2) 需求分析 漸增開發規劃 週期1 週期2 週期n 其他 發展 階段 其他 發展 階段 其他 發展 階段 漸增系統1 漸增系統2 最終系統 使用者 ：新發展的 ：再使用的 ：未完成的 17 2.5 漸增模式 (c.3) 漸增模式與瀑布模式大部分相同，但是，仍有 一些地方不同，例如： 系統被分成幾個子系統或功能，各子系統可獨立依 序開發，而瀑布模式是各個子系統需同時開發。 系統開發可由多個週期完成，每個週期表示不同版 本之系統，因此在每個週期均有程式編輯及上線實 施等，使用者每個週期均參與，故相較於瀑布模式， 漸增模式之風險較低。 18 2.5 漸增模式 (c.4) 漸增模式適用之情況： (1) 組織的目標與需求可完全與清楚描述。 (2) 預算需分期編列。 (3) 組織需要時間來熟悉和接受新科技。 19 2.6 雛型模式 定義： 雛型模式是一種系統開發之方法，該方法先針對 使用者需求較清楚的部分或資訊人員較能掌握之 部份，依分析、設計與實施等步驟快速進行雛型 開發。開發過程中，強調儘早以雛型系統做為使 用者與資訊人員需求溝通與學習之工具，雙方透 過雛型之操作與回饋以釐清、修改及擴充需求， 並藉以修改與擴充雛型系統。上述步驟反覆進行， 直到系統符合雙方約定為止。 20 圖2-7 雛型模式之開發程序及參與人員 主要參與人員 開發程序 雙方 需求擷取∕分析 資訊人員 雛型開發 否 雙方 操作及檢討雛型 和需求 雙方 是否 完全符合雙方 約定 雙方 是否 有下一週期 結束 否 21 2.6 雛型模式 (c.3) 雛型模式主要特性與原則如下： 強調雛型之儘早開發及使用者高度的參與。 強調以雛型作為使用者及系統開發者之需求溝通與 學習機制。 從需求最清楚部分著手開發雛型，並透過使用者對 雛型之操作與回饋，反覆修改與擴充。每次反覆之 週期要儘可能縮短。 22 2.6 雛型模式 (c.4) 雛型模式的潛在問題： (1) 系統文件較不完備，程式亦較難維護。短期可能 較能滿足使用者需求，但長期而言系統較易失 敗。 (2) 因缺乏整體之規劃、分析與設計，故較不適合於 大型及多人參與之系統開發專案。 23 2.6 雛型模式 (c.5) 雛型模式有兩種常見之應用策略，分別是 演進式雛型(Evolutionary Prototyping or Evolutionary Development Model) 用後丟棄雛型(Rapid Throwaway Prototyping) 策略。 24 2.6.1 演進式雛型策略 演進式雛型策略將所有需求看成一個整體，從 需求最清楚的部分快速的經歷一系統開發週期， 以完成初版雛型系統，再利用該雛型與使用者 溝通以確定、修改和擴充需求，並藉以做為下 一週期雛型演進之依據。該週期不斷的反覆進 行，一直到雛型系統符合雙方約定為止。 25 2.6.1 演進式雛型策略 (c.2) 演進式雛型策略之系統開發週期、雛型版本及需 週期N 求之演進如下圖所示： 系 統 開 發 各 階 段 週期2 週期1 系 統 開 發 各 階 段 版本1 系 統 開 發 各 階 段 版本2 最終版本 使用者 26 2.6.2 用後丟棄式雛型策略 用後丟棄式雛型策略以一種快而粗糙(Quick and Dirty)的方式建立雛型，以促使使用者能 夠儘快藉由與雛型之互動來決定需求項目， 或資訊人員藉以研發問題之解決方法與資訊 科技之應用。 應用該策略開發之雛型，不需考慮系統之運 用效率、可維護性與容錯能力等。 27 2.6.2 用後丟棄式雛型策略(c.2) 雛型丟棄之原因，例如開發工具不同，設計 方法不相容等。 用後丟棄雛型策略僅實施在風險程度最高的 地方，例如需求或解決問題之知識、概念與 資訊科技整合最不清楚的情況，其它情況則 盡可能的採用演進式雛型策略，因為雛型之 丟棄也意味著成本的浪費。 28 2.7 螺旋模式 螺旋模式之執行由三個步驟形成一週期： (1) 找出系統的目標、可行之實施方案與限制。 (2) 依目標與限制評估方案。 (3) 由剩下之相關風險決定下一步驟該如何進行。此 週期反覆進行，直到系統開發完成為止。 29 圖 2-9 螺旋模式之開發程序 累積成本 經過各步驟進展 決定目標、可行方案及限制 方案評估、風險識別與解析 風 險 分 析 風 險 分 析 風 險 分 析 風險 分析 承諾 回顧 需求計畫 生命週期計畫 分割 發展計畫 整合與測試計畫 雛型 2 模擬、模型、水準標記 作業觀念 軟體需求 軟體產 需求驗證 品設計 設計確認及驗證 實施 計劃下階段 雛型 1 可操作 雛型 3 雛型 驗收 測試 細部 設計 編碼 單元 整合& 測試 測試 發展、驗證下階層之產物 30 2.7 螺旋模式 (c.3) 步驟一： 找出系統的目標、可行之實施方案與限制 (1) 找出系統的目標 系統目標之評核因素很多，例如系統的績效、功能 與容忍改變之能力等。 (2) 找出系統之實施方案 系統實施方案會因問題而異，例如找出之方案有設 計A、設計B、重用、購買等。 (3) 實施方案之限制 實施方案之限制可能為專案之成本、時程、系統介 面等。 31 2.7 螺旋模式 (c.4) 步驟二： 依目標與限制評估方案 主要是找出各方案之不確定處，並設法解決，其步驟如下： (1) 找出專案風險之重要來源。 (2) 解決風險來源： 可用雛型、模擬、標竿 (Benchmarking)、參考點檢查 (Reference Checking)、問卷、分析模式、上述之綜合 或其它技術以解決風險。 32 2.7 螺旋模式 (c.5) 步驟三： 由剩下之風險決定下一步驟 若績效或使用者介面風險將強力影響程式開發或內 部介面控制，則下一步驟可能是採取演進式雛型。 若該雛型使用性佳且夠強韌（Robust），足以當做 未來系統發展之基礎，則往後的步驟將是一系列的 雛型演進。 假如先前之雛型努力已解決了所有的績效或使用者 介面之風險，且程式開發及介面控制之風險獲得掌 控，則下一步將遵循基本的瀑布模式，亦可適當的 修飾以整合漸增模式。 33 2.7 螺旋模式 (c.6) 螺旋模式之特色與應用原則為： 在高風險部分之設計尚未穩定前，規格之發展不需 要一致、詳盡或正式，以避免不必要之設計修改。 在開發之任一階段，螺旋模式可選擇整合雛型模式 以降低風險。 當更吸引人之方案被找出或新風險需被解決時，螺 旋模式整合重做或回到前面之階段。 34 2.7 螺旋模式 (c.7) 螺旋模式包容了現有軟體流程模式之大部分優點， 其風險導向之方法解決了許多模式之問題。在某 些條件下，螺旋模式相當於某一現有之流程模式。 例如： (1) 若專案在使用者介面或綜合績效需求方面屬於低風險， 且在預算及時程控制方面屬於高風險，則這些風險之考 量會使螺旋模式之執行相當於瀑布模式或漸增模式。 (2)若專案在預算及時程控制、大型系統之整合或需求變動 方面之風險較低，且在使用者介面或使用者決策支援需 求方面之風險較高，則這些風險之考量會使螺旋模式之 執行類似於雛型模式。 35 2.8 同步模式 同步模式源自於製造業的同步工程，其目的在 於縮短系統開發時間，以加速版本之更新。 同步模式是基於三個主要的構想來達到時程縮 短的目標： 多個團隊同時開發。這種多組人同時工作的方式稱 為活動同步（Activity Concurrency）。 36 2.8 同步模式(c.2) 資訊同步。不同團隊的資訊互相交流與共享稱為資 訊同步（Information Concurrency）。 資訊同步有三個技巧： (1) 向前傳遞(Front Loading) (2) 向後傳遞(Flying) (3) 建立有效的資訊交換網路及群體工作的支援環境 整合性的管理系統。同步開發方法的管理方法比一 般的系統開發複雜，必須開發一個管理系統以協調 人員、資源、過程和產品間複雜的互動關係。 37 圖2-10 同步模式之執行程序 開 始 功能組劃分 第 團隊開發 第一團隊開發 n 獨立整合 下 一 版 本 下 一 版 本 獨立測試 結 束 38 2.8 同步模式 (c.4) 同步模式的發展目的主要是為了因應商業套裝 軟體的市場競爭 優點是開發時間的縮短可提高產品的競爭力， 缺點則是緊湊的步驟及頻繁的資訊溝通，使得專案 管理的複雜度大幅提高，人力成本也相對提高，若 沒有輔以良好的工具及管理方法，則不易達成目標。 Fujitsu範例 39 圖2-11 同步開發與循序開發方法之比較 功能組:2.2 功能組:2.1 功能組:1.3 功能組:1.2 功能組:1.1 基本系統:版本1 交貨 版本1 整系 統 合測 試 同步開發 系 整統 合測 試 版本2 版本3 循序開發 功能組:版本1.3 功能組:版本1.2 功能組:版本1.1 功能組:版本1 交貨 版本1 版本240 圖2-12 同步開發模式 版本 n 系統整合 整合/系統測試 分析整合前之測試 設計團隊A 功能組 1(次要) 設計團隊B 功能組 2(次要) 設計團隊C 系 統 整 合 團 隊 測 試 團 隊 功能組 i(次要) 版本 n+1 系統整合 整合/系統測試 分析整合前之測試 設計團隊D 設計團隊D和A 功能組 k(主要) 設計團隊B 功能組 j(次要) 設計團隊C 系 統 整 合 團 隊 測 試 團 隊 功能組m(次要) 版本 n+2 系統整合 整合/系統測試 分析整合前之測試 設計團隊C 功能組 p(次要) 41 RUP模式(Rational Unified Process) RUP模式(統一流程模式)是結合螺旋模式的概 念，以反覆與漸增的軟體發展原理進行軟體開 發，且每一次反覆，需產出一個可運作的系統 版本，在每一個反覆週期皆有評估風險，因此 可儘早發現問題。 反覆：重複用相同一系列之操作或步驟進行開發 漸增：每次都在軟體上新增新功能、模組、元件、 子系統。 RUP模式可由“靜態”(9核心工作)與“動 態”(4階段)兩個構面來說明系統開發專案之 實施階段與核心工作，如圖2-13(圖像式記憶)。 42 RUP模式的構面(4時程+9工作流程) 圖2-13 RUP模式的構面 根據「時程」(動態)加以組織 加 以 組 織 ( 根 據 「 工 作 流 程 」 靜 態 ) 管 理 支 援 9個核心工作流程： (1) (2) RA/SA SD (3) (4) 開發/實施 上線/維護 1.企業塑模 軟 體 工 程 2.需求 3.分析與設計 4.實作 5.測試 6.配置 7.型態管理&變更管理 8.專案管理 9.環境 43 RUP模式優點 清楚定義系統各發展階段、核心工作流程。 強調應盡早處理風險問題。 可快速開發出系統初版，並再反覆更新。 因發展年代較晚，可整合各模式之優點。 44 2.9 結論 綜合來說，系統開發模式之發展依其被提出之 時間順序，依序是階段模式、瀑布模式、漸增 模式、雛型模式、螺旋模式、同步模式與RUP 模式。 由於被提出之先後順序不同，後來提出的模式 大多針對前面模式之問題提出修正。 45 表2-2 六個系統開發模式之比較 模 年代 式 RUP模式？ 瀑 布 1970 模 式 漸 增 1971 模 式 雛 型 1977 模 式 基本假設／適用情況 主要特徵 1. 使用者需求可完整且 清楚的描述。 2. 解決問題之知識，例 如模式或方法可得 到。 3. 軟／硬體之技術與支 援沒問題。 1. 開發階段有清楚的定義，每階 段均需考量完整的系統範圍， 且各階段僅循環一次。 2. 強調先有完整的設計與規劃， 再進行編碼。 3. 重視設計與規劃之文件。 4. 一階段的完成需經驗證通過， 才能進入下一階段。 1. 開發階段有清楚的定義，把整 個問題範圍分解成若干個子問 題，各子問題之開發可依序以 瀑布模式進行，亦可平行進行 再整合。 2. 同上第2項。 3. 開發週期反覆的進行。 1. 系統開發階段無清楚之分野， 且開發週期反覆的進行。 2. 不強調先有完整的設計與規劃 再進行編碼。 3. 強調快速的完成雛型且盡早使 用，以作為雙方需求溝通與學 習的工具。 1. 上述各情況之綜合。 2. 強調各開發週期之規劃與風險 評估。 同上 1. 使用者需求無法完整 且清楚的描述。 2. 解決問題之模式或方 法無法立即得到。 3. 軟／硬體之技術與支 援不確定。 螺 旋 1986 模 式 上述各情況均可 同 步 1993 模 式 1. 需求可明確與完整的 描述。 2. 有足夠的人力參與。 3. 團 隊 間 有 良 好 的 溝 通、資訊交換與專案 管理。 1. 將開發工作分割並同時進行。 2. 整合及系統測試不可分割，且 各功能組都要執行。 46 表2-3 資訊系統特性與適用開發模式比較 資訊系統種類 交易處理系統 管理資訊系統 決策支援系統 ERP？ 資訊系統特性 針對大量交易處理之自動化， 其處理程序及資訊需求是非常 結構化的，且一經決定後就不 常改變。 提供給不同層級的管理者，有 關組織營運狀況不同摘述程度 之報表，且報表之格式是預定 的。一般來說，這些資料之處 理與報表之產生，一經決定後 就不常改變。 主要是用於支援決策者半結構 化或非結構化之決策。一般來 說，資訊內容與報表格式之需 求不固定。 適用之系統開發模式 瀑布模式、漸增模式 雛型模式、螺旋模式 同步模式 瀑布模式、漸增模式 雛型模式、螺旋模式 同步模式 雛型模式、螺旋模式 47