第一章 系統開發概論 1-1 系統開發概論 1-2 常見的資訊系統 1-3 系統開發生命週期 1-4 系統開發方法論簡介.

Presentation on theme: "第一章 系統開發概論 1-1 系統開發概論 1-2 常見的資訊系統 1-3 系統開發生命週期 1-4 系統開發方法論簡介."— Presentation transcript:

1 第一章 系統開發概論 1-1 系統開發概論 1-2 常見的資訊系統 1-3 系統開發生命週期 1-4 系統開發方法論簡介

2 1.1 什麼是系統？ P. 1-2 “System” - “A group of interacting, interrelated, or interdependent elements or parts that function together as a whole to accomplish a goal.”  ”一群互動的，相關聯的或是相互依賴的元素或是組成部份，它們一起運作以完成一個目標。“ 舉例來說

3 資訊系統的結構 結構上來看，資訊系統分為兩大部分： 硬體：電腦主機、網路設備、伺服器、鍵盤、滑鼠、螢幕、硬碟等---實體設備。
P. 1-2 結構上來看，資訊系統分為兩大部分： 硬體：電腦主機、網路設備、伺服器、鍵盤、滑鼠、螢幕、硬碟等---實體設備。 軟體：驅動一個系統執行其所賦予的功能---程式。

4 系統開發 重點在討論一個軟體資訊系統的開發過程中所涉及到的： 系統建置的規劃與管理 分析與設計所採用的方法 分析與設計所採用的技術
P. 1-2 重點在討論一個軟體資訊系統的開發過程中所涉及到的： 系統建置的規劃與管理 分析與設計所採用的方法 分析與設計所採用的技術 以及各種相關事項

5 1.2 常見的資訊系統 人事管理資訊系統 會計資訊系統 交易處理系統 POS(Point of Sale)系統 訂票資訊系統 信用卡付款系統

6 關注的焦點 網際網路的普及，以及便利性的訴求。企業紛紛將其業務執行由傳統的作業方式，移植到網際網路上來執行。
P. 1-4 網際網路的普及，以及便利性的訴求。企業紛紛將其業務執行由傳統的作業方式，移植到網際網路上來執行。 如何建構一個以網際網路為溝通平台的資訊系統將是未來的焦點。

7 1.3 系統開發生命週期 系統開發生命週期：一個系統從無到有的過程。 包含幾個重要的階段： 以蓋房子的過程為例 了解系統如何支援企業的需求。
P. 1-4 系統開發生命週期：一個系統從無到有的過程。 包含幾個重要的階段： 了解系統如何支援企業的需求。 明確的需求 + 對需求清楚的定義→開始從事系統的分析、設計工作。 將設計予以實作 + 經過不同的測試階段→ 系統正式上線運行執行它所賦予的任務。 以蓋房子的過程為例

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

9 1.4 系統開發方法論簡介 結構化的(Structured)方法論。 瀑布式(Waterfall)方法論
P. 1-6 結構化的(Structured)方法論。 瀑布式(Waterfall)方法論 雛型方(Prototyping)法論 螺旋式(Spiral)方法論 Q 物件導向的(Object-Oriented)方法論。

10 瀑布式方法論(Waterfall) 結構化的方法論中最早被提出且被接受為開發一個系統的有效方式。 1970年由W. W. Royce提出。
P. 1-7 結構化的方法論中最早被提出且被接受為開發一個系統的有效方式。 1970年由W. W. Royce提出。 之後的許多方法論，基本上都是將瀑布式方法論加以改良以及演變出來。 此模式描繪(如圖)：

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

12 瀑布式方法論 循序式的方式。 每一個步驟會有確認的過程。 每一個階段允許對於上一層階段的回饋，以利於修訂與校正。
P. 1-7 循序式的方式。 每一個步驟會有確認的過程。 每一個階段允許對於上一層階段的回饋，以利於修訂與校正。 以文件驅動(document-driven)為其主要的特徵。 很重視文件的紀錄，在每一個階段產生大量的文件。這些文件都要經過計畫支持者的批准，然後才可以開始下一個階段的工作。 使用者的參與只有在系統剛開始以及最後的成果。 缺乏彈性的架構。

13 雛型方法論 先就清楚且肯定的部份先開始系統的開發(分析、設計、實作等等過程，通常不是很有規劃)。所開發出來的就是系統的雛形。
P. 1-8 先就清楚且肯定的部份先開始系統的開發(分析、設計、實作等等過程，通常不是很有規劃)。所開發出來的就是系統的雛形。 使用者與開發團隊再經由不斷的溝通討論、測試、修改，擴充此雛型直到系統滿足使用者的需求。這種方式就是雛型模式。 為快速地開發出系統雛形，雛型模式會利用CASE工具為開發過程的輔助工具。

14 雛型方法論 強調使用者的參與，不強調嚴格的文件定義。
P. 1-8 強調使用者的參與，不強調嚴格的文件定義。 從開發模式的本質上來看，雛型模式很適合用於小型的計畫專案， 並且使用者可以高度參與系統開發過程的計畫專案。

15 螺旋式方法論 又稱反覆式(Iterative)方法論。 主要在改進瀑布式僵化的開發原則。
P. 1-8 又稱反覆式(Iterative)方法論。 主要在改進瀑布式僵化的開發原則。 改進方法：反覆地執行系統開發的各階段過程，直到系統完成為止。

16 螺旋式方法論 螺旋式方法論是由許多個循環所組成(如圖)。 每次循環都要經歷系統開發的階段以及風險評估。
P. 1-8 螺旋式方法論是由許多個循環所組成(如圖)。 每次循環都要經歷系統開發的階段以及風險評估。 主要的特徵：風險驅動(risk-driven)。

17 螺旋式方法論 開發過程中，其每一步驟均使用到瀑布模式。 主要焦點：風險的評估及管理。
P. 1-8 開發過程中，其每一步驟均使用到瀑布模式。 主要焦點：風險的評估及管理。 →開始並不會很仔細地去定義整個系統，只定義系統中具有最高優先權的部份 →然後先行分析、設計以及實作部份 →從客戶或是使用者得到回饋 →有回饋資訊後，再回到定義以及實作更多其他系統所需具備之部分。

18 物件導向的方法論 結構化的方法論在執行的過程中主要是以處理或是資料為中心。 焦點：如何將問題分解成一群較小範圍的處理。
P. 1-9 結構化的方法論在執行的過程中主要是以處理或是資料為中心。 焦點：如何將問題分解成一群較小範圍的處理。 每個處理，如果執行邏輯還是很複雜，可以再將它分解為更小的處理。依此類推下去。 對於資料也是如此。 資料與處理基本上是息息相關的，因此有了物件導向技術的發展。

19 物件導向的方法論 物件導向技術強調 物件導向分析與設計vs傳統的結構化分析與設計→ 完全不同思維 物件以及物件跟物件之間的靜態關係。
P. 1-9 物件導向技術強調 物件以及物件跟物件之間的靜態關係。 物件之間互動的動態關係。 物件將資料與處理(在物件導向的世界，稱為操作或是方法)封裝起來。 物件導向分析與設計vs傳統的結構化分析與設計→ 完全不同思維

20 過程 P. 1-10 物件導向方法論涵蓋了三個過程 物件導向分析 物件導向設計 物件導向程式設計

21 統一塑模語言(UML) 早期的物件導向方法論是由三位大師所主導 各門派的方法論各有其考量的範圍以及優缺點。
P. 1-10 早期的物件導向方法論是由三位大師所主導 Grady Booch/Jim Rumbaugh/Ivar Jacobson。 各門派的方法論各有其考量的範圍以及優缺點。 Rational Software( )將這三位Amigo請來共同發展出一套以物件導向為主的統一塑模語言(UML – Unified Modeling Language)。 1997年將研究成果送交物件管理聯盟(OMG – Object Management Group)審理。 OMG在1997年11月正式通過並且接受UML為物件導向開發的標準塑模語言。 從此，UML開啟了物件導向系統開發的新紀元。

22 Rational Unified Process(RUP)
1998年Grady Booch， Jim Rumbaugh，Ivar Jacobson 提出Rational Unified Process (RUP) ---一套物件導向系統開的方法論。 是一種軟體開發的方法(Software development approach)。 是一種軟體工程的處理流程(Software engineering process) 。 是一種處理產品(Process product) 。 Q

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

24 由使用案例驅動 P. 1-11 如果你不懂什麼叫做使用案例(Use Case)，沒關係。這在後面會有明確的定義。目前，你只要知道使用案例是用來捕捉系統所提供的功能。並且，這一點很重要：是從使用者的角度。

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

26 以架構為中心 面對日趨複雜的資訊系統，若沒有一個定義分明的系統架構藍圖，這個系統在日後必將面臨許多問題，終就難逃被淘汰的命運。
P. 1-13 面對日趨複雜的資訊系統，若沒有一個定義分明的系統架構藍圖，這個系統在日後必將面臨許多問題，終就難逃被淘汰的命運。 這對於網路時代的資訊系統更形重要。對於系統架構，可以利用許多不同的觀點來記錄它。我們將在後面介紹RUP所提出有關架構藍圖的4+1觀點。

27 反覆且漸進 相對於一次就定義出系統的完整模型細節，RUP則將開發的過程看成是一序列的反覆過程，稱之為iteration(反覆)。
反覆的意思：開發過程是週期性的。可以把一個週期看成是一個小型、循序式的開發過程。每一個週期可以在紙上或是利用雛型來檢驗，並且其結果可以做為下個週期的輸入(如圖)。 Q

28 RUP的開發處理架構 P. 1-13 在圖中，水平軸代表時間，顯示RUP過程進行中的動態組成面，並且從循環(cycle)，階段(phase)，反覆(iteration)等觀念來描述它。而垂直軸代表RUP 過程進行中的靜態組成面，並且利用活動，產出，工作流程等觀念來描述它。

29 RUP系統開發的過程：四大階段 起始階段(Inception) 詳述階段(Elaboration) 建構階段(Construction)
移轉階段(Transition) 每一個階段，RUP均定義了階段目標以及所須從事的相關活動。 每一個階段中，又再細分許多的iteration。

30 RUP定義了九個工作流程(Workflow)
企業塑模(business modeling) 需求(requirements) 分析與設計(Analysis and design) 實作(Implementation) 測試(Test) 部署(Deployment) 配置管理(Configuration Management) 計畫管理(Project Management) 環境(Environment)

31 四個階段、九大流程 4個階段以及9個處理流程是反覆且漸進式的進行著。 隨著時間的遞移，每一個階段所著重的處理流程比重也會不同。
P. 1-14 4個階段以及9個處理流程是反覆且漸進式的進行著。 隨著時間的遞移，每一個階段所著重的處理流程比重也會不同。 例如：起始的階段，需求分析的份量遠比系統實作來的多；而在建構階段時，實作將會是整個計畫的核心工作。

32 參與人員 每一個階段以及不同的工作流程，均有相關的參與人員(稱為角色)以及該角色所應從事的活動。RUP定義了下列幾類參與者的角色：
分析人員(analysts) 開發人員(developers) 測試人員(testers) 經理(managers) 其他角色(other roles)

33 開發人員 P. 1-15

34 工作項目 P. 1-15

35

36 例子 人體就是有許多不同的系統所組成。如：消化系統、呼吸系統等。 不同功能的系統由許多不同的器官所組成以完成某項工作。
房子也包含了許多不同的系統例如電路系統、排水系統等等。 我們所要談論的系統是所謂的資訊系統(Information System) - 一個以資料處理為核心的系統。

37 蓋房子的過程 構想。 繪製外觀、 形狀。 繪製房子的藍圖(blueprint)。---外觀、 細部設施、尺寸、大小、坪數。
藍圖經多次討論、修改，到客戶滿意為止才定案。 地基開挖，依藍圖的設計蓋房子。期間，可能因為一些因素，會做些變更與修改。

38 計劃階段 為什麼要建立一個系統？建立系統所帶來的實質利益、價值？ 可行性分析(feasibility analysis)。
技術面的可行性方析(technical feasibility) 經濟面的可行性方析(economic feasibility)。 產出： 計畫書(Project plan)： 工作報告書(Statement of Work) ：

39 分析階段 了解系統的需求是什麼(What)。 定義系統所要解決的問題 = 系統要提供什麼樣的功能。
產出：需求文件---以功能需求以及非功能需求為主軸。

40 設計階段 了解系統的需求如何被達成(How)。 建立系統的架構模型。 系統的架構描述系統的組成元件 產出：系統架構書。
支援系統的硬體設施的配置與組態。 軟體架構的模型。 使用者介面的設計。 輸出報表格式的樣式。 產出：系統架構書。

41 實作階段 根據設計階段所擬定的系統架構書，以及分析階段的需求分析文件，開始建立系統。
系統建立的過程中，還包含有測試的階段。有些計畫會把測試這項工作獨立出來自成一個階段。並且擬定測試計畫書。 產出：系統本身。

42 瀑布式開發方法

43 螺旋式方法論

44 物件導向分析 重點工作：定義出系統的模型。 接著進行物件導向設計。
分析階段的主要工作：利用類別或是概念模型以及物件的觀點來分析、檢驗系統的需求。

45 物件導向設計 重點工作：定義出一個以物件為設計規範的系統實作藍圖。 設計階段的主要工作：勾勒出邏輯的、具體的以及靜態的和動態的系統模型。

46 物件導向程式設計 使用物件導向程式語言，依據分析與設計的要求與規範實作系統。

47 反覆且漸進

48 Q：什麼是RUP？請分別從是一種軟體開發的方法、軟體工程的處理流程、處理產品三個方向簡述之。
A：P1-10~11

49 Q：RUP強調任何以物件導向為開發基礎的資訊系統必須依循那三個方向？
A：P1-11~12

50 Q：試比較結構化的系統開發方式中的三個方法論？瀑布式方法論、雛型方法論、螺旋式方法論。
A：P1-7~9

51 Q：系統開發生命週期分為那四個階段？各階段所要回答的問題，分別是什麼？
A：P1-4~6