B-1系統分析與設計 楊子青

B 、資訊系統開發模式 系統開發生命週期 資訊系統開發模式

– 結構化的 (Structured) 方法論• 瀑布式方法論• 雛型方法論• 螺旋式方法論

– 物件導向的 (Object-Oriented) 方法論 • Rational Unifies Process (RUP)

B-2系統分析與設計 楊子青

1. 系統開發生命週期 蓋房子的過程

– 一開始，你會有一些構想。– 然後你會開始繪製這個房子的外觀，形狀。– 然後，建築師會開始繪製房子的藍圖 (blueprint) 。

• 藍圖不只是表現出房子的外觀，藍圖更仔細地描述出房子的細部設施。房間的尺寸、大小、坪數。– 藍圖可能會歷經多次的討論、修改，直到客戶滿意為止才會定案– 接下來，地基開挖，依據藍圖的設計，房子開始真正的蓋起來了。在這期間，可能因為一些因素，會做一些變更與修改。

B-3系統分析與設計 楊子青

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

B-4系統分析與設計 楊子青

2. 資訊系統開發模式

階段模式(Benington, 1956)

瀑布模式(Royce, 1970)

漸增模式(Mills, 1972)

雛型模式(Bally et al., 1977)

螺旋模式(Mills et al., 1986;

Boehm, 1988)同步模式

(Aoyama, 1996)

RUP(Jacobson et al., 1999)

1950 1960 1970 1980 1990 2000

MDA(OMG, 2001)

敏捷軟體開發(Beck et al., 2001)

編碼與修正模式

B-5系統分析與設計 楊子青

資訊系統開發模式

資訊系統開發活動的一系列步驟及執行程序– 系統開發依循系統化、邏輯化的步驟進行

• 有利於標準、規範與政策之推行和建立• 開發過程將更有效率、更能確保品質，也更容易管理。

– 不同的資訊系統開發模式，適用於不同情況的 系統開發。– 上頁前兩者已幾乎無人使用

B-6系統分析與設計 楊子青

資訊系統開發模式分類結構化的 (Structured) 方法論

瀑布式方法論雛型方法論螺旋式方法論物件導向的 (Object-Oriented) 方法論 Rational Unifies Process (RUP)

B-7系統分析與設計 楊子青

2.1 瀑布式方法論是結構化的方法論中最早被提出且被接受為開發一個系統的有效方式。

1970 年由 W. W. Royce 提出接續所提出之許多方法論基本上都是將瀑布式方法論加以改良以及演變出來。利用上面所述之系統 開發的生命週期，我們可以將此模式簡要地描繪如下：

B-8系統分析與設計 楊子青

瀑布式方法論

B-9系統分析與設計 楊子青

更多階段且允許回饋的瀑布式方法論可行性分析

需求分析

教育訓練

操作與維護

B-10系統分析與設計 楊子青

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

B-11系統分析與設計 楊子青

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

B-12系統分析與設計 楊子青

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

B-13系統分析與設計 楊子青

2.2 雛型方法論計畫開始時，通常很難就對於系統的完整輪廓給出詳細的定義。

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

B-14系統分析與設計 楊子青

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

B-15系統分析與設計 楊子青

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

適合用於小型的計畫專案 , 且使用者可以高度參與系統開發過程的計畫專案。

B-16系統分析與設計 楊子青

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

B-17系統分析與設計 楊子青

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

B-18系統分析與設計 楊子青

螺旋式方法論經過各步驟進展

累積成本

決定目標、可行方案及限制

風險分析

風險分析

風險分析

風險分析 雛型 1 雛型 2 雛型 3

可操作雛型

模擬、模型、標竿作業觀念 軟體

需求需求驗證

設計確認及驗證

軟體產品設計

細部設計

編碼單元測試整合

&測試

驗收測試

實施

需求計畫生命週期計畫發展計畫整合與測試計畫

承諾

分割回顧

計劃下階段

發展、驗證下一階層之產品

方案評估、風險識別與分析

B-19系統分析與設計 楊子青

螺旋式方法論主要焦點在於風險的評估及管理

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

B-20系統分析與設計 楊子青

2.4 Rational Unified Process (RUP)

物件導向的方法論結構化的方法論在執行的過程中，主要是以處理或是資料為中心，焦點放在如何將問題分解成為一群處理，資料也是如此。然而資料與處理基本上是息息相關的，因此有了物件導向技術的發展。

RUP ：結合反覆式、螺旋式與物件導向開發 方法等諸多優點的一種軟體開發模式

B-21系統分析與設計 楊子青

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

B-22系統分析與設計 楊子青

(1) 由使用個案驅動

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

B-23系統分析與設計 楊子青

(2) 以架構為中心

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

B-24系統分析與設計 楊子青

(3) 反覆且漸進

RUP 將開發的過程看成是一序列的反覆過程，稱之為 iteration 。

B-25系統分析與設計 楊子青

RUP優點結合了眾多成功的方法論

提供完整的軟體開發流程UML 作為其視覺化軟體分析與設計語言

使軟體開發人員之間的溝通與資訊的交換無礙以 UML 中的使用者案例 (Use-Case) 作為整個核心

B-26系統分析與設計 楊子青

RUP缺點學習困難

為了無所不包，相對使得該程序變得非常巨大，不論是學習或管理都很困難。花費時間工具受限

支援工具相對受限於 Rational公司自己的產品。