B、資訊系統開發模式 系統開發生命週期 資訊系統開發模式 結構化的(Structured)方法論

Presentation on theme: "B、資訊系統開發模式 系統開發生命週期 資訊系統開發模式 結構化的(Structured)方法論"— Presentation transcript:

1 B、資訊系統開發模式 系統開發生命週期 資訊系統開發模式 結構化的(Structured)方法論
瀑布式方法論 雛型方法論 螺旋式方法論 物件導向的(Object-Oriented)方法論 Rational Unifies Process (RUP)

2 1. 系統開發生命週期 蓋房子的過程 一開始，你會有一些構想。 然後你會開始繪製這個房子的外觀，形狀。
然後，建築師會開始繪製房子的藍圖(blueprint)。 藍圖不只是表現出房子的外觀，藍圖更仔細地描述出房子的細部設施。房間的尺寸、大小、坪數。 藍圖可能會歷經多次的討論、修改，直到客戶滿意為止才會定案 接下來，地基開挖，依據藍圖的設計，房子開始真正的蓋起來了。在這期間，可能因為一些因素，會做一些變更與修改。

3 系統開發生命週期 計劃階段 - 計劃階段在回答：Why。 分析階段 - 分析階段在回答：What。 設計階段 - 設計階段在回答：How。
實作階段 。

4 2. 資訊系統開發模式

5 資訊系統開發模式 資訊系統開發活動的一系列步驟及執行程序 系統開發依循系統化、邏輯化的步驟進行
有利於標準、規範與政策之推行和建立 開發過程將更有效率、更能確保品質，也更容易管理。 不同的資訊系統開發模式，適用於不同情況的 系統開發。 上頁前兩者已幾乎無人使用

6 資訊系統開發模式分類 結構化的(Structured)方法論 物件導向的(Object-Oriented)方法論 瀑布式方法論 雛型方法論
螺旋式方法論 物件導向的(Object-Oriented)方法論 Rational Unifies Process (RUP)

7 2.1 瀑布式方法論 是結構化的方法論中最早被提出且被接受為開發一個系統的有效方式。
1970年由W. W. Royce提出 接續所提出之許多方法論基本上都是將瀑布式方法論加以改良以及演變出來。 利用上面所述之系統 開發的生命週期，我們可以將此模式簡要地描繪如下：

8 瀑布式方法論

9 更多階段且允許回饋的瀑布式 方法論

10 瀑布式方法論 系統的每一個階段，定義出相當嚴謹的開發程序與步驟。 每一個階段必須完成後，才可以轉移到下個階段。
好比如水流一樣，一階流過一階。因此這種開發方式被稱為瀑布模式。

11 瀑布式方法論 以循序式的方式來進行系統的開發。 在每一個步驟會有確認的過程。
瀑布模式中的每一階段，允許對於上一階段的回饋，以利修訂與校正。 瀑布模式以文件驅動(document-driven)為主要的特徵 重視各階段的文件紀錄，因此將會於每一個階段產生大量的文件。 這些文件都要經過計畫支持者的批准，才可開始下一階段的工作。 使用者的參與只有在系統剛開始以及最後的成果。

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

13 2.2 雛型方法論 計畫開始時，通常很難就對於系統的完整輪廓給出詳細的定義。
Ex: 使用者對於需求無法做最後的確認等等。 基於此，可以先就清楚且肯定的部份先開始系統的開發(分析、設計、實作等等過程，但通常都不是很有規劃)。所開發出來的就是系統的雛形。 使用者與開發團隊再經由不斷的溝通討論，測試，修改，擴充此雛型直到系統滿足了使用者的需求。

14 雛型模式之系統開發程序 及參與人員

15 雛型方法論 為了能夠快速地開發出系統雛形，雛型模式常利用CASE工具為開發過程的輔助工具。 強調使用者的參與，但是不強調嚴格的文件定義
即使有文件來記錄系統的各項工作，其內容到最後也都與實際不符。 適合用於小型的計畫專案, 且使用者可以高度參與系統開發過程的計畫專案。

16 雛型方法論的潛在問題 強調「雛型演進」代替完整之分析與設計，系統文件較不完備，程式亦可能較難維護。
短期而言，可能較能滿足使用者需求；但對長期而言，系統較易失敗。 因缺乏整體之規劃、分析與設計，故較不適用於大型及多人參與之系統開發專案。

17 2.3 螺旋式方法論 也稱為反覆式(Iterative)方法論。 由許多個循環所組成 改進瀑布式僵化的開發原則
反覆執行系統開發的各階段過程，直到系統完成為止。 由許多個循環所組成 每一次的循環都要經歷系統開發的階段以及風險評估。 螺旋式開發方法以風險驅動(risk-driven)為其主要的特徵。

18 螺旋式方法論

19 螺旋式方法論 主要焦點在於風險的評估及管理 在一開始並不會很仔細地去定義整個系統。
開發人員只定義系統中具有最高優先權的部份，然後先行分析、設計以及實作這一部份。 然後從客戶或是使用者那方面得到回饋。 有了這方面的資訊後，再回到定義以及實作更多其他系統所需具備之部分。

20 2.4 Rational Unified Process (RUP)
物件導向的方法論 結構化的方法論在執行的過程中，主要是以處理或是資料為中心，焦點放在如何將問題分解成為一群處理，資料也是如此。 然而資料與處理基本上是息息相關的，因此有了物件導向技術的發展。 RUP：結合反覆式、螺旋式與物件導向開發 方法等諸多優點的一種軟體開發模式

21 RUP強調的重點 由使用個案驅動(Use-Case Driven) 以架構為中心(Architecture Centric)
反覆且漸進(Iterative and Incremental)

22 (1) 由使用個案驅動 用來捕捉系統所提供的功能
且是從使用者的角度 如何掌握使用者的需求、如何用一種有效的方式、工具來捕捉使用者對於系統的期望，一直是資訊系統發展過程中很重要的課題。 而使用個案為這些問題提供了一個解答。 也就是以使用者的角度來看系統該做什麼，以此為系統開發的出發點。

23 (2) 以架構為中心 面對日趨複雜的資訊系統，需一個定義分明的系統架構藍圖 對於系統架構，可以利用許多不同的觀點來記錄它。
架構藍圖的4+1觀點

24 (3) 反覆且漸進 RUP將開發的過程看成是一序列的反覆過程，稱之為iteration。

25 RUP優點 結合了眾多成功的方法論 UML作為其視覺化軟體分析與設計語言 提供完整的軟體開發流程 使軟體開發人員之間的溝通與資訊的交換無礙
以UML中的使用者案例(Use-Case)作為整個核心

26 RUP缺點 學習困難 花費時間 工具受限 為了無所不包，相對使得該程序變得非常巨大，不論是學習或管理都很困難。
支援工具相對受限於Rational公司自己的產品。