第2章 資訊系統開發模式.

Similar presentations


Presentation on theme: "第2章 資訊系統開發模式."— Presentation transcript:

1 第2章 資訊系統開發模式

2 本章大綱 學習目標 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 發展生命週期 結論

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

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

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

6 編碼與修正模式 編碼與修正模式(Code-end-fix Model)是最早(1956年前)使用之模式,該模式並無方法論可言,主要包含兩個步驟: 先寫部分程式 再修正程式中之問題 主要之問題 沒有規劃及設計,故經過幾次之修正後,程式碼的邏輯變得難以理解。 過程中並無使用者需求分析與確認,軟體雖然設計得很好,但可能並不符合使用者的需求。

7 階段模式(Stragewise Model)之執行程序
Operational Plan 作業規劃 程式規格描述 編 碼 參數測試 整合測試 系統評估 上線測試 作業規格描述 Operational Specification Coding Specification Coding Parameter Testing Assembly Testing Shakedown System Evaluation

8 階段模式 階段模式已具有方法論之雛型,該模式強調系統開發前要有規劃,程式編輯前要有分析與設計,系統上線前要有測試等。階段模式雖已改善了編碼與修正模式之缺點,但使用上仍衍生以下之問題: 不論系統之大小或複雜程度均需經歷八階段。 各階段之進行是循序的且階段間沒有回饋。 各階段均需考量完整的系統範圍,不可僅考量部分系統。 假設需求可完整且清楚地描述。

9 2.2 瀑布模式(1/3) 瀑布模式是一種系統開發之方法,該方法把系統開發的過程分成「幾」個階段,每個階段清楚定義要做哪些工作及交付哪些文件,各個階段循序的執行且僅循環一次。(系統發展生命週期,System Development Life Cycle) 當問題較小或較單純,劃分的階段可能少至三個,例如分析、設計、實施等階段(如圖2-2);若面對較大或較複雜之問題時,其階段可再被細分成更多個階段,例如可能擴充至十個階段(如表2-1、圖2-3) 。通常被分為五大階段:系統規劃、系統需求分析、系統設計、系統建置與測試、系統上線與維護。

10 圖2-2 三階段之瀑布模式 分 析 設 計 實 施 瀑布模式在階段劃分上較有彈性,另提供兩項功能加強:
1.可行性分析2.需求分析 3.系統分析 實 施 設 計 分 析 4.概念性設計5.細部設計 6.程式編輯與單元測試 7.整合測試 8.安裝與系統測試 9.教育訓練 10.操作與維護 瀑布模式在階段劃分上較有彈性,另提供兩項功能加強: 1.若在各階段發現錯誤可允許階段間之回饋,始能儘早修正以 減少系統修改或重做之成本。 2.各階段明確定義應作之工作及交付之文件,使系統開發之工 作更明確且更容易掌握。

11 表2-1 大略與詳細之資訊系統開發階段 分 析 設 計 實 施 1.可行性分析 2.需求分析 3.系統分析 4.概念性設計 5.細部設計
分 析 設 計 實 施 1.可行性分析 2.需求分析 3.系統分析 4.概念性設計 5.細部設計 6.程式編輯與單元測試 7.整合測試 8.安裝與系統測試 9.教育訓練 10.操作與維護

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

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

14 圖2-4 瀑布模式的開發程序與系統 明確的、完 整的需求 最終系統 使用者 瀑布模式鼓勵依SDLC階段來進行規劃,且每一階段的產出都必須經過確認(Validation)、驗證(Verification)或測試(Testing) 。執行上,資訊人員有明確責任對前階段產出做接收與確認。 應用瀑布模式於軟體開發時,各階段必須考量完整的需求,且前一階段必須完全成功才能進入下一階段,最後整個系統才能被開發出來。

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

16 SDLC各階段工作內容與交付的產品-系統規劃階段
工作項目 交付產品 系統範圍及目標確認 系統功能確認 排定開發時程表 系統效益與成本評估 可行性評估 風險評估 成立開發團隊及品保小組 系統規劃書 風險評估文件 品質確認文件 使用者同意書

17 SDLC各階段工作內容與交付的產品-系統需求分析階段
工作項目 交付產品 資料蒐集 使用者訪談 現行流程整理 未來系統流程設計 系統功能描述 系統取得評估 風險評估 系統分析品質管理 系統需求書 風險評估文件 品質確認文件 使用者同意書

18 SDLC各階段工作內容與交付的產品-系統設計階段
工作項目 交付產品 功能流程設計 資料庫架構設計 物件設計 使用者介面設計 系統安全考量 使用者授權建置 系統環境建置 風險評估 系統分析品質管理 系統設計規格書 風險評估文件 品質確認文件 使用者同意書

19 SDLC各階段工作內容與交付的產品-系統發展與建置階段
工作項目 交付產品 作業系統安裝與設定 開發環境建置 撰寫程式 封裝物件 建置資料庫 測試資料準備 程式、模組、系統測試 系統安裝 使用者手冊製作 風險評估 系統分析品質管理 作業系統版本及參數 文件 軟硬體版本控管文件 系統建置文件 程式碼及模組 物件 使用者手冊 風險評估文件 品質確認文件 使用者同意書

20 SDLC各階段工作內容與交付的產品-系統上線與維護
工作項目 交付產品 上線規劃 資料轉換 使用者教育訓練 系統維護 風險評估 系統分析品質管理 上線規劃書 系統維護報告 風險評估文件 品質確認文件 使用者同意書

21 可行性研究 可行性研究的目的 可行性研究的評估層面 可行性研究的文件製作

22 可行性研究的目的 可行性研究的目的 是根據系統的需求,分析問題的特性與範圍,並估算系統發展所需的各項資源、費用成本以及工作時程,藉此評價系統是否有繼續進行的價值,對現行環境適不適合或可不可行。

23 可行性研究的評估層面 五種可行性評估層面:

24 技術可行性(technical feasibility)
目的 在於評估完成新系統的技術是否專案人員有能力可以達成,以及進行此新系統所冒的風險。 內容 新系統目標所需要的週邊設備是否已經具備? 開發新系統所需要的技術,專案小組成員是否已經具有開發之能力? 新系統所需要的效能是否可以達成? 是否有其他人員可以提供我們相關支援,來完成這個系統?

25 經濟可行性(economic feasibility)
目的 在於評估新系統經濟效益方面的得失,以便公司高階主管判斷值不值得投資,其重點在於公司的成本效益分析。 內容 評估推行此系統所需增加的費用支出與以後的使用費用。 評估系統完成後,對現行作業之效益分析與實質服務品質的改善。 比較前項之開發成本與後項之運轉效益,並評估系統的得失。

26 法律可行性(legal feasibility)
目的 在於評估新系統進行的內容是否違反了現行的法令。 內容 新系統的內容是否為現行法令所不允許? 是否侵犯了他人的權益? 是否違反了著作權法或智慧財產權? 軟體開發契約的訂立,與雙方的權利與義務?

27 作業可行性(operational feasibility)
目的 在於評估新系統的推行是否為使用者所接受?是否管理階層同意?現行作業是否可以配合。 內容 所推行的系統對現行作業環境的影響。 系統是否為使用者所接受? 管理階層是否接受此專案?是否支持?是否能配合實施?

28 時程可行性(schedule feasibility)
目的 在於評估新系統是否能於預估的時限內完成。 內容 系統開發的工作時程安排是否合理? 系統工作時程的安排專案小組成員是否可以如期完成? 系統完工之時效性是否可以被管理人員接納?

29

30 可行性研究的文件製作 可行性研究的步驟 成立負責專案小組 蒐集與系統有關的資料 設計各種可行性方案 評估各種可行性方案 選擇最適可行性方案
撰寫可行性研究報告

31 可行性研究報告撰寫的目的 主要在於將可行性研究之內容、結果與建議,以文字的表達方式,呈給公司最高管理階層主管審閱,供最高階層主管用以判斷應採取的方案,同時,也讓公司最高階層主管了解所選擇的方案對組織的影響。

32 可行性研究報告的內容 緒論 說明此可行性研究的目的與研究的範圍、系統的緣由以及為什麼會有這個專案。 系統目標與需求 說明系統的目標,要具備那些功能?需要的操作條件如何?完工的期限是什麼時候?公司願意提供的開發經費是多少。 現行作業說明 說明目前組織的結構如何?現行組織的工作環境如何?與系統有關的現行作業有那些?現行組織的工作環境中有那些軟體、硬體設備?

33 可行性方案研擬與說明 列出符合前述系統需求的可行性方案,說明各可行性方案的架構與內容、各方案的軟硬體設備需求、各方案所需的經費以及各方案的工期如何。 可行性方案評估 將前述列舉的可行性方案,依照可行性研究的判斷條件逐項評估,評估的項目必需包含有技術可行性、經濟可行性、法律可行性、作業可行性、時程可行性。在本節中,必須詳細說明各方案的評估結果。

34 結論與建議 說明專案小組的評估結果,建議公司應選擇的方案,並說明為何選擇此方案,此方案對公司的影響層面如何?同時並對公司未來可採取的措施,提出具體的建議。 參考資料 列出在此報告中曾經參考過的資料與書目,必須詳細列出參考資料的出處。 附錄 敘述報告本文中所不足而需要補充的內容。

35 一、系統簡介 1.1 簡述 1.2 系統目標 1.3 系統範圍 1.4 系統主要功能 二、現行作業分析 2.1 現行組織圖 2.2 各相關單位作業說明 2.3 現行環境的軟硬體架構 三、可行性方案研擬與說明 3.1 各項方案說明 3.1.1 方案構想說明 3.1.2 方案架構 3.1.3 方案的軟硬體需求 3.1.4 方案運作的環境與流程 3.2 各項方案評估 3.2.1 技術可行性 3.2.2 經濟可行性 3.2.3 法律可行性 3.2.4 作業可行性 3.2.5 時程可行性 四、結論與建議 參考資料 附錄

36 2.3 漸增模式(1/3) 由於瀑布模式在軟體開發之各階段均需同時考量所有需求,且系統開發須在一個週期內完成,例如:人員不足之組織或較大之專案,均無法考量所有需求。因此,此模式在某些情況下執行會有困難。 Mills, H. 1971年提出漸增模式以解決此問題。但直到1970年代末期才受到重視。 漸增模式是一種系統開發之方法,該方法把需求分成「幾」個部分,然後依漸增開發計畫將每個「部分需求」之開發訂為一個開發週期,每個週期可依序或平行開發。每個週期之階段清楚定義要做哪些工作及交付哪些文件,每個階段循序進行且僅循環一次。

37 漸增模式(Incremental Model)
漸增模式需先經歷需求分析已完全掌握需求,接著再進行漸增開發規劃,其工作如下: 對系統分析與設計採由上而下方式,將明確將需求分成若干部分,並進行上層規格描述;包括整個系統之上層架構,可能重復使用之部分與依序將發展之各子系統。 完成上層規格描述後,需進一步擬定漸增開發計畫,以規範與指引系統之漸增發展(i.e.每一次都在系統上增加新功能、模組、元件或子系統等。),然後依計畫進行,最後經歷幾個版本之漸增,才能完成系統開發。 應用漸增模式,其重要開發階段、週期、程序與系統之關係如下圖:

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

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

40 2.3 漸增模式(3/3) 漸增模式適用於下列情況: 組織的目標與需求可完全且清楚地描述。
預算須分期編列,將系統做整體規劃,往後再分期執行。如未來未獲得預算,已完成的部份功能仍可運作,另可降低財務負擔及風險。 當組織需要時間來熟悉與接受新科技時,應用漸增模式有充裕的時間來學習與轉移技術。

41 2.4 雛型模式(1/4) 瀑布模式與漸增模式均需假設在專案開始時,使用者需求能清楚且完整的描述。此種假設通常不切實際。
雛型模式是一種系統開發之方法,該方法先針對使用者需求較清楚的部分或資訊人員較能掌握之部分,依分析、設計與實施等步驟快速進行雛型開發。 開發過程中,強調盡早以雛型作為使用者與資訊人員需求溝通與學習之工具,雙方透過雛型之操作與回饋,以釐清、修改及擴充需求,並藉以修改與擴充雛型。上述步驟反覆進行,直到系統符合雙方約定為止。

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

43 2.4 雛型模式(2/4) 雛型模式適用於需求改變可能發生於整個專案生命期間、客戶能高度參與、應用領域不熟悉或高風險等情況的專案。較不適用於具有固定需求與實際技術上沒有困難的專案。 雛型模式主要優點 有助於了解問題、目標與解答、提供一般化的雛型以增進系統開發者與使用者之間的溝通、提早發現需求是否有問題及使用者參與系統開發並迅速回應需求的改變等。

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

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

46 2.4.1 演進式雛型策略 演進式雛型策略將所有需求看成一個整體,從需求最清楚的部分快速的經歷一系統開發週期,以完成初版雛型系統之開發。
再利用該雛型與使用者溝通,以確定、修改和擴充需求,並藉以作為下一週期雛型演進之依據。 該週期不斷地反覆進行,一直到雛型系統符合雙方約定為止。 此策略適用於對雛型模式有經驗的發展者,因為使用此策略需注意雙方(使用者與資訊人員)要有良好的溝通與專案管理,否則易產生如編碼與修正模式之問題。

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

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

49 2.4.2 用後丟棄式雛型策略(2/3) 該策略若用以確認需求規格,回饋的資訊將被用來修改需求規格,以反映出使用者真正的需求,而資訊人員也因此能夠根據這個規格,很有自信地進行真實系統的設計與實施。 該策略若用於具高困難度之技術或設計的專案,可以藉由快速的雛型開發與檢討,探索出問題之解決方法或資訊科技應用的可行性。也就是藉由一個個雛型的研究、開發與檢討,來幫助此彈性概念之具體化,並發展出設計方法及所需整合之資訊科技等。 雛型丟棄之原因很多,例如所用之開發工具非最終決定之工具、最後之設計方法與原來的方法不同或不相容等。

50 2.4.2 用後丟棄式雛型策略(3/3) 用後丟棄雛型策略僅實施在風險程度最高的地方,例如在使用者需求或解決問題之知識、概念與資訊科技整合最不清楚的情況,而其他情況則盡可能地採用演進式雛型策略,因為雛型之丟棄也意謂著成本的浪費。 2-50

51 2.5 螺旋模式(Spiral Model)(1/7)
漸增模式與雛型模式均無法完全解決瀑布模式執行上之問題。 螺旋模式之軟體開發程序主要是基於瀑布模式應用於政府大型軟體之經驗,經多次修改而成。螺旋模式之執行由三個步驟形成一週期: 步驟一:找出系統的目標、可行之實施方案與限制。 步驟二:依目標與限制評估方案。 步驟三:由剩下之相關風險決定下一步驟該如何進行。 此週期反覆進行,直到系統開發完成為止。

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

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

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

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

56 螺旋模式(5/7) 風險導向之螺旋模式是規格導向、雛型導向、模擬導向、自動轉換導向或其他軟體開發方式之組合。應用該模式之重點在於如何選擇前述方式,以適當的混合應用,選擇時主要是考慮程式風險大小與不同技術對風險解決之效能。 螺旋模式之重要特色是,每個週期之結束須由與系統有關之主要人員或組織來檢討系統績效。檢討的內容包括上一週期之所有系統發展,對下一週期之規劃及所需之資源等。

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

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

59 2.6 同步模式(Concurrent Model)-Aoyama, M. 1993(1/4)
同步模式源自於製造業的同步工程,目的在縮短開發時間、加速版本之更新。 (如套裝軟體) 同步模式是基於三個主要的構想來達到縮短時程的目標: 多個團隊同時開發。這種多組人同時工作的方式稱為活動同步(Activity Concurrency)。如大型的系統開發專案。

60 2.6 同步模式(2/4) 2. 資訊同步。不同團隊的資訊互相交流與共享,稱為資訊同步(Information Concurrency)。 資訊同步有三個技巧: 向前傳遞(Front Loading):將下一個階段的重要議題與考慮因素提前讓前一個階段的開發團隊知道。 向後傳遞(Flying):將前一個階段開發的情況極重要的資訊傳遞給下一個階段的開發團隊。 建立有效的資訊交換網路及群體工作的支援環境。 3. 整合性的管理系統。同步模式的管理比一般的開 發模式複雜,必須開發一個管理系統以協調人員、資源、過程及產品間複雜的互動關係。

61 同步模式 (3/4) 同步模式的執行程序與原則(如下圖2-9)
首先將每一版本(Release)的工作分成數個功能組(Enhancement),功能組是一個或多個功能的組合。 接著,將功能組的工作分配給數個團隊平行開發,當同一版本的功能組都完成開發之後,便交給獨立的團隊進行整合測試,開發團隊的人力則可進行下一版本的開發。 同理,當整合及測試團隊完成了一個版本的工作後,便可進行下一版本的整合與測試。

62 圖2-9 同步模式之開發程序 開  始 功能組劃分 n 獨立整合 獨立測試 結  束 下一版本 ……………….

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

64 圖2-10 同步開發與循序開發方法之比較-Fujitsu進行的同步軟體開發為例
整 合 系統測試 功能組: 2.2 2.1 整合 1.3 1.2 1.1 基本系統:版本1 同步開發 版本 1 2 3 交 貨 循序開發 功能組:版本 版本3 Release3 版本2 Release2 團隊 3 團隊 1 團隊 2

65 圖2-11 同步開發模式

66 2.7 Rational統一流程模式(1/20) - Jacobson 等1998提出
RUP(Rational Unified Process)模式結合螺旋模式的概念,以反覆(i.e.重複用相同的一系列操作或步驟以進行軟體開發)與漸增(i.e.每一次都在軟體產品上增加新功能、模組、元件或子系統等)的軟體發展原理進行軟體開發,且每一次的反覆需產出一個可運作的系統版本,並在每一個反覆週期評估風險,以儘早發現問題。 RUP模式可由動態與靜態兩個構面來說明系統開發專案之實施階段與核心工作,如圖2-12 。

67 Rational統一流程模式(2/20) RUP模式動態構面把軟體開發依序分成四個主要階段,這四個階段構成一個週期,週期可反覆進行;週期內各階段亦可視情形反覆進行: 初始階段(Inception Phase):詳細構想出建構系統所需的企業個案(系統需求與範圍),取得所有參與專案人員對推展該專案的認同。 詳述階段(Elaboration Phase):處理主要的技術工作(如設計、實施、測試、系統結構等),並以實際可執行的程式編輯來探討主要的技術風險(如資源主張、績效與資料安全等風險)。

68 Rational統一流程模式(3/20) RUP模式動態構面把軟體開發依序分成四個主要階段:(續)
建構階段(Construction Phase):建構一個初步可運作的系統版本,繼續演化幾個內部版本確保系統是可用的及滿足使用者的需求。亦須完成安裝與支援文件及訓練教材。 轉移階段(Transition Phase):依使用者回饋精調系統、組態、安裝與可用性等議題,並將系統產品移交用戶使用,包括備份、培訓、支援、維護等。

69 Rational統一流程模式(4/20) RUP模式的靜態構面主要表達成九個核心工作流程:企業塑模、需求、分析與設計、實作、測試、配置、專案管理、組態管理與變動管理、環境等。其中,前六項是軟體工程工作,而後三項則是管理支援工作。 水平軸與垂直軸交叉格上的圖形面積代表其所對應工作之估計工作量或比率。

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

71 圖2-12 RUP模式之二維構面

72 2.7 Rational統一流程模式(6/20)──靜態面

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

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

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

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

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

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

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

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

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

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

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

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

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

86 Rational統一流程模式(20/20) 綜言之,RUP模式整合上述模式之優點,清楚定義系統發展的階段與核心工作流程,強調儘早處理風險問題,快速開發出一個系統的初始版本,並反覆進行之。 此外,該模式並不假設在專案的起始階段須有清楚且完整的需求,而允許隨著專案的演化不斷地詳述需求,也可根據團隊的需求調整或擴充各階段之實施、目標與里程碑等。

87 2.8 敏捷軟體開發(Agile Software Development)(1/9)
一群不同軟體開發方法的領域代表於2001年共同推出敏捷宣言(Agile Manifesto)。 其主要目的為提出一套較傳統軟體開發方式更為簡捷且快速的軟體開發概念,此即敏捷軟體開發(Agile Software Development)。 敏捷軟體開發的主要開發理念和價值觀如下(Beck et al., 2001): 個體與互動勝於流程與工具。 可運作的軟體勝於全面性的文件。 與客戶的協同合作勝於契約談判。 因應變化勝於遵循計畫。

88 2.8 敏捷軟體開發(2/9) 目前有多種軟體開發方法,包括動態系統開發方法(Dynamic Systems Development Method,DSDM)、精實軟體開發(Lean Software Development)和極限編程(Extreme Programming,XP)等,皆以上述敏捷軟體開發概念為基礎。 除上述三種開發方法外,尚有調適性軟體開發(Adaptive Software Development, ASD)、水晶方法(Crystal Method)、特色驅動開發(Feature Driven Development)等敏捷軟體開發方法,因非本書重點,不在此贅述。

89 2.8 敏捷軟體開發(3/9)─動態系統開發方法 此概念起始於1990年代中期,為快速應用開發(Rapid Application Development)法之延伸。 此方法之開發過程主要以反覆與漸增的方式進行,並強調使用者在開發過程中的參與。 在開發過程中,動態系統開發方法會隨需求改變而反覆調整,目的在於準時且於預算內將軟體開發完成,因此主要應用於時程緊湊且預算有限之專案。

90 2.8 敏捷軟體開發(4/9)─動態系統開發方法 動態系統開發方法實施的過程分為:專案前(Pre-Project)、專案生命週期(Project Life-Cycle)和專案後(Post-Project)三個階段。 其中,專案生命週期之主要工作可分為五個階段: 可行性研究(Feasibility Study) -評估專案的型態、組織和成員是否適用於動態系統開發方法。 企業研究(Business Study) -分析該企業之需求與技術能力等。 反覆功能建模(Functional Model Iteration, FMI) -反覆地開發階段,最後依所定之功能模型產出功能雛型系統(Functional Prototype)。

91 2.8 敏捷軟體開發(5/9)─動態系統開發方法 反覆設計與建置(Design and Build Iteration, DBI) -考量功能性與非功能性之需求後,精練反覆功能建模階段所產出之雛型系統,並釋出一設計雛型系統(Design Prototype)以供使用者使用與測試。 實施(Implementation) -將完成的系統建置於使用者的環境中。 動態系統開發方法之實施過程如圖2-13。

92 2.8 敏捷軟體開發(6/9)─精實軟體開發 精實軟體開發為將豐田生產系統(Toyota Productive System, TPS)提出之精實生產(Lean Manufacturing)原則與方法,應用於軟體開發領域。 包括七項原則概念: 消除浪費(Eliminate Waste) -任何未對客戶產生加值的行為或作業皆為浪費。 增進學習(Amplify Learning) -軟體開發過程中,可利用短期(1週至1個月)且完整循環(Full Cycle)的反覆開發方式來取得回饋並增進學習。 延遲決定(Delay Commitment) -最終決策須根據事實(而非假設)訂定,之前應避免驟下結論。

93 2.8 敏捷軟體開發(7/9)─精實軟體開發 快速遞送(Deliver Fast) -一旦使用者確定其需求,軟體開發團隊應立即為其創造價值,不再於決定需求、…、測試、部署等過程中延遲。 團隊授權(Empower the Team) -精實軟體開發過程中,並非由管理者來進行決策,開發團隊應自行設立目標、決定開發流程、蒐集資料並自我督促來達成目標。 建置完整(Build Integrity In) -包含了解使用者或企業需求的認知完整(perceived Integrity)與軟體系統各元間皆能獨立運作的概念完整(Conceptual Integrity)。 全盤檢視(See the Whole) -利用分解(disaggregation)原理來確認使用者之整體需求是否被達成。

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

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

96 2.9 MDA發展生命週期(1/5) 模式驅動結構(Model Driven Architecture, MDA)是由OMG(Object Management Group)定義的一種軟體開發架構,其關鍵是軟體開發過程中每個階段(或步驟)的產出均須建構出模式,且該模式之產出為下一個階段的輸入。 MDA的發展生命週期與其他系統開發模式(例如瀑布模式或RUP模式)的主要的差別是在發展過程中步驟之產出,強調該產出是由電腦可理解的正規模式(Formal Model)表達。 MDA需求階段的產出主要是文字之描述,這些產出是進行分析工作的主要來源(i.e.主要的輸入),並建構出平台獨立模式(Platform Independent Model,PIM);同理,PIM是進行低階設計階段的主要資訊來源,該階段的產出是建購出特定平台模式(Platform Specific Model,PSM);PSM是進行程式編輯階段的主要資訊來源,該階段的產出是建購出程式模式等。

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

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

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

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

101 圖2-15 PIM轉PSM轉Code MDA除了定義PIM、PSM 與Code外,也定義它們之間的關係:先
製作PIM,再將PIM轉成一個或多個PSM,接著再將PSM轉成Code 例如系統由多種技術開發 資料庫是Object-Relational資料庫模式 介面是Web-based模式 應用程式是EJB模式 溝通橋樑彼此互通 溝通橋樑彼此互通 三種不同的PSM 分別轉成不同的 程式碼

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

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

104 表2-3 八種系統開發模式之比較(1/4) 模式 年代 基本假設/適用情況 主要特徵 瀑 布 模 式 1970
1.使用者需求可完整且清楚地描述。 2. 解決問題之知識(例如模式或方法)可以得到。 3. 軟硬體之技術與支援沒問題。 1. 開發階段有清楚的定義,每階段均需考量完整的系統範圍,且各階段僅循環一次。 2. 強調先有完整的設計與規劃,再進行編碼。 3. 重視設計與規劃之文件。 4. 一階段的完成需經驗證通過,才能進入下一階段。 1972 同上。 1. 開發階段有清楚的定義,把整個系統範圍分解成若干個子系統,各子系統之開發可依序以瀑布模式進行,亦可平行進行再整合。 3. 開發週期反覆的進行。

105 表2-3 八種系統開發模式之比較(2/4) 雛型模式 1977 1.使用者需求無法完整且清楚地描述。 2.解決問題之模式或方法無法立即得到。
3.軟硬體之技術與支援不確定。 1.系統開發階段無清楚之分野,且開發週期反覆地進行。 2.不強調先有完整的設計與規劃再進行編碼。 3.強調快速完成雛型且盡早使用,以作為雙方需求溝通與學習的工具。 螺旋模式 1986 適用於上述各情況。 1.綜合上述各情況。 2.強調各開發週期之規劃與風險評估。

106 表2-3 八種系統開發模式之比較(3/4) 同步模式 1993 1.需求可明確與完整的描述。 2.有足夠的人力參與。
3.團隊間有良好的溝通、資訊交換與專案管理。 1.將開發工作分割並同時進行。 2.系統測試不可分割,且各功能組都要執行。 RUP模式 1999 適用於上述各情況。 1.綜合上述各情況。 2.強調反覆與漸增地開發,及各開發週期之規劃與風險評估。 3.強調流程、工作產出與專案管理。

107 表2-3 八種系統開發模式之比較(4/4) 敏捷軟體開發 2001 1.使用者需求於開發過程中不斷變化。
2.開發團隊與使用者需有良好溝通和互動的機制。 1.強調開發團隊與使用者間協同合作。 2.強調反覆與漸增的開發方式。 3.強調隨時因應變化。 MD A模式 適用於上述各情況。 1.綜合上述各情況。 2.每個階段的產出均須建構模式,且該模式是下一個階段的輸入。 3.各階段之產出是由電腦可理解的正規模式表達。

108 表 資訊系統特性與適用之系統開發模式 資訊系統 種 類 資訊系統特性 適用之系統開發 模 式 交易處理 系統
種 類 資訊系統特性 適用之系統開發 模 式 交易處理 系統 針對大量交易處理之自動化,其處理程序及資訊需求是非常結構化的,且一經決定後就不常改變。 瀑布模式、漸增模式、雛型模式、螺旋模式、同步模式、RUP模式 管理資訊 提供給不同層級的管理者,有關組織營運狀況不同摘述程度之報表,且報表之格式是預定的。一般來說,這些資料之處理與報表之產生,一經決定後就不常改變。

109 表 資訊系統特性與適用之系統開發模式(續)
種 類 資訊系統特性 適用之系統開發模 式 決策支援 系 統 主要是用於支援決策者半結構化或非結構化之決策。一般來說,資訊內容與報表格式之需求不固定。 雛型模式、螺旋模式、RUP模式 企業資源 規劃系統 主要能即時整合與規劃分散於企業各據點之資源,並能隨時依需求彈性的處理與展示企業資訊的系統。 瀑布模式、漸增模式、雛型模式、螺旋模式、同步模式、RUP模式

110 軟體品質改善 CMM 和 CMMI

111 歷史回顧 歷史回顧 1986年11月,美國卡內基美隆大學(Carnegie-Mellon University)的軟體工程學院(Software Engineering Institute,  SEISM),在 Mitre 公司的協助下開始發展一個可以幫助軟體開發者改善軟體流程的流程成熟架構。 1987年6月, SEISM  發表了軟體流程成熟架構的簡簡要描述,接著於當年9月出版了基本成熟度之問卷,提供一個工具用以指出軟體業者軟體流程需要改善的領域。

112 歷史回顧(cont.) 歷史回顧(cont.)
經過了四年的使用經驗與努力,於1991年  SEISM 正式發表 CMM®1.0 ,並於1992年4月辦理座談會,綜合超過400位軟體專家意見,於1993年發表 CMM®1.1 修正版。 CMMISM 是 SEI SM 自1997年以來進行的一項努力,目的在發展一個整合性的架構以整合不同的成熟度模式及相關產品,以提昇使用成熟度模式時之效率與回收效益。

113 CMM 和 CMMI CMM (Capability Maturity Model) 目的是可以幫助軟體開發者改善軟體流程的流程成熟架構。
功能成熟度模式。 CMMI (Capability Maturity Model Integration) 目的在發展一個整合性的架構以整合不同的成熟度模式及相關產品,以提昇使用成熟度模式時之效率與回收效益。

114 功能成熟度模式 等 級 特 性 1.起始 個人主義,毫無章法的管理 2.可重複 專案管理,使用經驗的管理 3.定義
特 性 1.起始 個人主義,毫無章法的管理 2.可重複 專案管理,使用經驗的管理 3.定義 流程定義與制度化,定性化的管理 4.管理 產品與流程品質評量,定量化的管理 5.最佳化 持續流程改善,最佳化的管理

115 功能成熟度模式(cont.)

116 功能成熟度模式整合 功能成熟度模式整合


Download ppt "第2章 資訊系統開發模式."

Similar presentations


Ads by Google