CH 19 資訊系統開發與應用

1
 學習目標
1. 認識各類資訊系統開發之特性, 並瞭解開發這些資訊
系統時所需遵循之原則與建置策略。
2. 認識開發資訊系統時所面臨之環境、軟體專案規劃
構面、與軟體能力成熟等級。
3. 瞭解設計、實作資訊系統所需之基本技術, 包含：結
構化設計雨物件導向分析的主要精神。
4. 認識資訊系統開發模式之演進與挑戰。
5. 認識常用的資訊系統開發模式, 包含系統開發方法與
生命週期。
6. 瞭解資訊系統開發的特性, 與未來系統開發的發展方
向與挑戰。
7. 認識多種代表性資訊系統之應用與範例說明, 如管理
資訊系統、企業資源規劃系統、決策支援系統等等。

2
 大綱

• 19.1 資訊系統開發簡介
• 19.2 資訊系統開發技術：結構化
設計與物件導向分析
• 19.3 資訊系統開發模式之演進與
挑戰
• 19.4 代表性資訊系統之應用與範
例

3
 CH 19 資訊系統簡介
• 一個資訊系統 (Information System), 是一套人、資料、
流程、資訊表示法與資訊科技的妥善安排以支援企業
作業, 幫助使用者解決問題、正確決策。
• 資訊系統可用來支援決策、協作和控制；並幫助決策
者分析解決問題, 創造新產品, 使複雜性問題視覺化。
• 從商業角度看, 一個資訊系統是一個用於解決環境提出
的挑戰, 基於資訊科技的組織管理方案。

4
 19.1 資訊系統開發簡介
• 為能有效管理與應用資訊以支援組織的經營管理和決策需求, 各種資
訊系統乃應運而生。隨著軟體技術的發展, 軟體系統越來越複雜, 逐漸
分化出許多專用的軟體系統, 如作業系統、資料庫系統、應用伺服器,
而且這些專用的軟體系統成為計算環境的一部分。
• 軟體建構過程所涉及的內容越來越豐富, 不再只是程式內部邏輯的設
計活動, 還包括資料庫設計、使用者介面設計、介面設計、通信協定
設計和複雜的系統配置過程。
• 各系統之特性、大小、開發方法或技術可能不同, 但系統開發之過程
可歸納出一些基本而共同的步驟或階段, 如圖19-1a, 19-1b。

5
19.1 資訊系統開發簡介

6
 19.1 資訊系統開發簡介
• 資訊系統開發其實就是要運用資訊科技及資訊系統開發
方法來建構實體的或邏輯的系統, 以協助人們解決資訊
處理的需求。
• 成功的資訊系統開發必須把握以下幾個重要原則：
• 系統的目標應該明確定義。
• 系統的目標要實際而有用。
• 系統開發要充份運用科技。
• 系統開發要依循一定的方法。
• 系統開發必須獲得足夠的資源及支持。
• 系統開發必須符合限制條件。
• 系統開發必須考慮環境因素。

7
 19.1資訊系統建置策略
• 資訊系統建置策略乃指資訊系統之建立、修改、擴充或更新等所採取之
方式。以系統建置過程所涉及到的主要設計者來區分, 資訊系統之建置
策略可分成三種：
(1) 由公司內部獨立完成。還可以再區分為：
a. 使用者自建 (End User Computing)。
b. 由公司資訊部門自行開發。
c. 由相關部門人員組成任務編組開發。
(2) 由公司外部取得, 我們可以採取的管道則有：
a. 委外開發 (Outsourcing)。
b. 購買現成之套裝軟體 (Application Package)。
c. 引進同業之系統。
(3) 其他方式: 資訊系統之建置當然也可以經由綜合上述各種策略, 或由
部份同業聯合共同找資訊公司開發等。

8
19.1 資訊系統開發環境與構面
• 資訊系統開發的環境所涉及的層面很廣, 大體來說, 資訊系統是由人力資
源、相關軟體、硬體及資料這些元素所組成。大型資訊系統的開發工作
涉及許多複雜因素, 包括人、工具、技術、資源、時程、風險等。
• 資訊系統開發要考慮4個構面, 分別為:人 (People)、流程 (Process)、專案
(Project)、產品 (Product)。這就是軟體工程中俗稱的4P。這四個構面互
相關連、牽扯、影響, 各個構面需要均衡發展。

9
19.1資訊系統開發之相關人員
• 要產生出成功的軟體產品須要經由一群人 相互的執行、討論、測試、
整合而成。人在軟體開發過程中扮演了舉足輕重的角色。
• 軟體開發需涵蓋人力資源的管理。 資訊系統開發之相關人員包括：
• 系統分析師：系統分析師扮演的角色是將需求轉換成資訊技術、企
業處理與知識等元件, 並且有組織的結合起來。
• 程式設計師：程式設計師主要之工作是將分析與設計文件轉換成電
腦可執行的指令。
• 終端使用者：終端使用者有企業領域之專業知識, 分析師要與終端
使用者一起工作並將企業上的知識轉換成可支持其工作的資訊系統。
• 企業經理：企業經理們是終端使用者之高層主管, 由於他們的決策
權與企業的專業知識, 能對資訊系統專案發展設定一般性的需求與
限制。企業經理擁有決定系統發展方向, 提出與通過專案的權利及
決定專案之相關重要性等。
• 系統分析師必須要和相關人員保持良好的溝通, 瞭解他們的期望和優先
順序, 從他們口中瞭解組織內的限制和資源。

10
 19.1 專案 (Project)
• 軟體專案管理包括軟體度量、專案估算、時間控制管理、人員組
織管理、配置管理、專案計劃等。
• 在進行專案規劃時必須考慮的重要問題：進行一個專案的範疇
(Scope), 採用何種品質標準 (Quality Standard), 工作順序及時間
(Time) 的需求, 一個專案所需的專案成本 (Cost), 專案所面臨的風
險 (Risk) 等問題。
• 依據美國專案管理協會 (PMI ) 對其專案管理劃分九大領域：整
合管理、範疇管理、成本管理、品質管理、人力資源管理、時間
管理、採購管理、風險管理、溝通管理。在組織中的專案管理項
目 中 , 專 案 經 理 人 特 別 需 要 密 切 注 意 時 間 (time) 、 技 巧
(techniques)、與人力資源 (people) 之間的最適化。
• 據統計, 大多數軟體發展專案的失敗, 並不是由於軟體發展技術方
面的原因；許多專案的失敗是由於不適當的管理造成的。

11
 19.1 流程 (Process)
• 資訊系統開發流程需要有有效的方法與技巧, 以確保專案目標得
以在預定的時間、預算及資源下, 能夠順利達成。
• 軟體專案管理 (Software Project Management) 是將管理的原則與
方法應用在軟體專案的開發上, 使軟體專案能順利達成預期的目
標。專案開發的三個主要的目標為時程、成本與品質。
• 軟體專案規劃流程包括以下步驟：估計軟體工作產品的規模及所
需的資源、制定時間表、鑑別和評估軟體風險以及協商的承諾。
• 美國專案管理協會 (Project Management Institution, PMI) 對其專
案管理流程可分為五個類別即為『五大流程』, 其分別為： I 起
始流程 (Initiating Process)、P 計劃流程 (Planning Process)、E 執
行流程 (Executing Process)、C 控制流程 (Controlling Process)、C
結案流程 (Closing Process)。

12
 19.1 流程 (Process)
• 根據美國卡內基美隆 大學所創設之軟體工程協會 (SEI, 1999)
的分析, 在軟體開發流程中, 一個專案所經歷的階段大致可劃
分為：客戶需求、軟體規格、計劃、設計、實施、整合、維
護、退休。
• 軟體專案規劃工作建議從以下幾個構面進行分析：
1. 技術構面 ─ 選擇與採用軟體開發模式、方法論及工具等。
2. 資源構面 ─ 人力、物力與時間的估計與安排。
3. 資訊構面 ─ 開發人員彼此間的資訊傳遞方式、工具。
4. 管理構面 ─ 時程、風險與人力資源的管理模式。
• 專案規劃涉及的因素非常廣泛, 加上外在環境的變動, 規劃工
作並非只是一次就能完成, 它必須經由不斷且漸進的修正過程
才能臻於完美的境界。

13
19.1軟體能力成熟度整合模式,
• 軟體能力成熟度整合模式 (CMMI, Capability Maturity Model
Integration) 是由美國卡內基美隆大學軟體工程協會研發及對
外授權, 來幫助軟體發展者改善軟體流程能力與成熟度的模式。
• CMMI軟體能力成熟度等級分為五級：
Level 1：初始階段 (Initial)
Level 2：有能力重覆 (Repeatable)
Level 3：已調適階段 (Defined)
Level 4：數量化管理階段 (Managed)
Level 5：最佳化階段 (Optimizing)

14
 19.2 資訊系統開發技術：
結構化設計與物件導向分析
• 軟體開發技術到底是一門科學、藝術、還是一門
工程訓練, 這是一個爭議許久的問題。實際上, 軟
體開發兼有兩者的特點。
• 傳統典型之軟體工程一般而言即是自1960 年代所
流行之結構化軟體發展 。這些技術包括有結構化
分析與設計、結構化程式設計、以及由上而下發
展模式。
• 在軟硬體環境逐漸複雜的情況下, 物件導向程式設
計觀念在1960年在一些語言的發展中即可發現。
物件導向程式設計在透過強調可重複性解決一定
程度的軟體維護問題。
15
 19.2 結構化分析與設計
• 結構化程式設計, 是一種由上而下 (Top-Down), 先將程式功能分解多個獨立
子功能的模組 (Module), 就每個模組合成一個功能完整的程式。結構化程式
設計的特性如下：
1. 唯一出口: 整個程式的執行應該只有一個程式執行結束的出口。
2. 由上而下細分功能: 結構化程式設計的第一步, 是由上而下逐步細化
程式功能, 把一個大程式先分解成幾個功能獨立的模組。如果有某個
模組的功能還可以細分, 應該再將該模組分解成更小的模組。
3. 模組化程式設計: 每個模組都是功能獨立的程式片段。在程式語言中,
通常模組程式可分為副程式 (Subroutine) 和函式 (Function) 兩種。模
組和模組之間, 以傳遞資料 (稱為參數或引數) 的方式連繫。
4. 使用三種基本控制結構: 結構化的程式中, 必須將程式控制邏輯限定
在循序、選擇、重複等三種基本控制結構。
5. 避免使用GoTo敘述: GoTo敘述會使控制結構混亂, 不便於閱讀程式。
6. 程式閱讀性高: 採用結構化程式設計, 還要注意取有意義的變數名稱、
使用程式註解、適當的程式內縮排列等, 以提高程式的閱讀性。

16
 19.2 物件導向分析與設計
• 在1960年代時,在軟硬體環境逐漸複雜的情況下,程式設計領域開始
面臨著軟體維護危機。物件導向程式設計觀念, 透過強調可重複性
在一定程度上解決軟體維護這一問題。
• 為類比環境而設計出的Simula語言是分析式程式的最早概念。在程
式語言中, 將真實世界的物件對映到抽象的物件。
• 1970年代施樂PARC研究所發明的Smalltalk語言則將物件導向程式
設計的概念定義為：在基礎運算中, 對物件和訊息的廣泛應用。
Smalltalk受Simula的影響, 但Smalltalk中的物件是動態的—它們可以
被創建、修改並銷毀。此外, Smalltalk還引入了繼承性的思想。
• 物件導向程式設計在1980年代開始慢慢成為一種程式設計主流思潮,
主要應歸功於C語言的擴充版, C++, 廣受系統設計人員採用的緣故。
在圖形使用者介面 (GUI) 日漸崛起的情況下, 物件導向程式設計剛
好迎合使用者需要的視窗介面應用潮流。

17
 19.2 物件導向分析與設計
物件導向設計可以在三個方面幫助我們從事系統的建置與維護：
1. 在資訊系統開始設計之初, 常常不夠明確具體；完整物件導向
設計模型, 可以較順暢地適應原始程式碼的製作；架構可以先
建立起來, 再慢慢提供細部物件之間的操作,訊息傳遞等等。
2. 實際的系統必須適應系統實際實作的環境。為了達到這個目的,
分析模型必須轉換成設計模型, 且將不同的因素考慮在內。反
映出真實世界需要的資訊模型恰好是物件導向設計的核心基本
概念。
3. 經正確分析、類比實際環境後, 我們也將針對在分析規劃階段
所得的物件分析模型, 做出正式初步分析文件。進行較細部建
立系統分析時, 我們可以對使前階段的初步模型做出必要的修
正與改進, 使系統反應實際的規劃、實作、與文件保存作法, 可
以提高系統的可行性與可維護性。

18
 19.2 物件導向基本理論
• 類別：類別 (Class) 定義了一件事物的抽象特點。通常來
說, 類別定義了事物的屬性和它可以做到的行為。類別可
以為程式提供模版和結構。一個類別的方法和屬性被稱為
成員 (member)。
• 物件：物件 (Object) 是類別的例項(Instance)。物件亦稱為
類別的實現或類別的樣例。一個具體物件屬性的值被稱作
它的「狀態」。假設我們已經在上面定義了一個類別, 我
們就可以用這個類別來定義物件。
• 方法：方法 (Method) 是一個類別能做的事情。每一類別
都有屬於自己的方法, 也就是我們可將眾多的函式依照其
作用的類別存放。

19
 19.2 物件導向基本理論
• 訊息傳遞機制：一個物件透過接受訊息、處理訊息、傳出訊息
或使用其他類別的方法來實作一定功能, 這叫做訊息傳遞機制
(Message Passing)。
• 繼承性：新產品的開發, 常從舊有的產品中繼承某些特性, 再加
入新的零件或修改部份零件而成一項新的產品。繼承性
(Inheritance) 是指, 一個類別會有「子類別」並繼承父類別的成
員。這意味著程式設計師只需要將相同的代碼寫一次。 當一個
類別從多個父類別繼承時, 我們稱之為「多重繼承」。繼承的
優點是同一方法得以在新產品產生時, 可讓數個新舊版本同時
存在, 以滿足不同的產品需求。
• 封裝性：具備封裝性 (Encapsulation) 的物件導向程式設計, 會
隱藏方法的具體執行步驟, 取而代之的是透過訊息傳遞機制傳
送訊息給它。封裝透過限制只有特定類別的例項可以存取這一
特定類別的成員, 通常利用介面實作訊息的傳入傳出。對於類
別的規劃, 我們重視所有方法、欄位及屬性封裝, 使得這些成員
有不同的封裝等級, 以避免主程式與類別庫之間的干擾。

20
 19.2 統一塑模語言
• 統一塑模語言 (Unified Modeling Language, UML) 是非專利的第三
代塑模和規約語言。UML是一種開放的方法, 用於描述、視覺化、
構建和編寫一個正在開發的、物件導向的、軟體密集系統的專案的
方法。對這三個縮寫字母, 我們可以簡單的說明如下：
Unified：UML是一種標準語言, 廣泛運用於全世界。
Modeling：UML用途在於塑模 (Modeling), 也就是畫軟體藍圖。
Language：UML是一種塑模語言, 而非程式語言或標示語言。
• UML是軟體系統發展人員用以建造模型, 而這些模型使得工作團隊
能夠：將系統具象化 (Visualization)、將系統結構及行為規格化
(Specification)、建構 (Construction) 系統、以及記錄 (Documentation)
發展系統過程中之各項決策。
• UML常用來作為形塑物件導向分析和設計 (OOAD) 過程的產物的
圖形化語言。它為物件導向設計中的需求、行為、體系結構和實作
提供了一套綜合的表示法。UML是物件導向建模語言的標準, 適用
於以物件導向技術來描敘任何類型的系統。

21
 19.2 整合開發環境
• 整合開發環境 (Integrated Development Environment, IDE,
也有人稱為Integration Design Environment、Integration
Debugging Environment) 是一種輔助程式開發人員開發
軟體的應用軟體。
• IDE 通常包括程式語言編輯器、編譯器/直譯器、自動建
立工具、通常還包括除錯器。有時還會包含版本控制系
統和一些可以設計圖形用戶界面的工具。許多支援物件
導向的現代化IDE還包括了類別瀏覽器、物件檢視器、
物件結構圖。
• 目 前 有 一 些 IDE 支 援 多 種 程 式 語 言 ( 例 如 Eclipse 、
NetBeans、 Microsoft Visual Studio), 但是一般而言, IDE
主要還是針對特定的程式語言而量身打造 (例如Visual
Basic)。

22
 19.2 軟體測試
• 軟體測試是一種用來促進鑑定軟體的正確性、完整性、
安全性、和品質的過程。軟體產品的測試的目的現在
仍然是：儘可能地找到軟體中的多一點錯誤, 而不是
完全證明軟體的正確性。
• 軟體測試的經典定義是：在規定的條件下對程序進行
操作, 以發現程序錯誤、衡量軟體質量、並對其是否
能滿足設計要求進行評估的過程。
• 程式品質通常會隨系統不同而有差異；不過某些公認
特性是共通的：可靠性、穩定性、輕便性、易於維護、
以及實用性。實際的軟體工程實踐證明, 讓對軟體思
想有深刻理解的工程師進行軟體測試, 可以大幅度的
提高軟體質量。
23
19.3 資訊系統開發模式之演進
• 今日發展環境已經有了很大的改變, 不單是因為組織需要
的不同, 也因為電腦技術一日千里的變化。系統發展的基
本指導原則還是在許多組織的資訊化過程依舊適用。大部
分的企業組織, 在發展新的系統專案時, 都會利用一套系統
發展方法論 (system development methodology) 的標準步驟。
• 資訊系統通常是依據其生命週期來發展。因此, 系統發展
生命週期 (system development life cycle, SDLC) 就是在許
多組織在系統發展上最常見的方法論, 特徵在於分成數個
階段, 標示不同的系統分析發展成效的進程。
• 資訊系統發展模式在過去五十多年中, 學者所提出的資系
統發展生命週期模型並不見得一致, 從四個階段到二十個
階段都有；我們希望藉由較適合的發展模式, 提供全面考
量分析與適當的設計技術, 希望能在更短的時間與更少的
資源投入的情況下, 完成系統的建置。

24
 19.3資訊系統開發模式
• 系統開發模式主要考量開發過程應分成哪些階段, 每
階段應如何進行及要做什麼。常用的資訊系統開發方
法與生命週期如下：
1. 編碼與修正模式 (Build-and-Fix 或Code-and-Fix)
2. 階段模式 (Stagewise Model)
3. 瀑布式模式 (Waterfall)
4. 漸增式模式 (Incremental)
5. 雛型式模式 (Prototyping)
6. 縲旋式模式 (Spiral)
7. 同步模式 (Synchronize-and-Stabilize)
25
 19.3 編碼與修正模式
• 此模式是程式設計中開發最早的模式, 是所有模式開
發的雛型。主要有兩個步驟：先寫程式部份, 再修正
程式中之問題；也就是先編碼, 再考慮需求、設計、
測試及維護。
• 由於沒有詳實的規劃及設計, 經經過幾次修正以後, 程
式碼的邏輯變得難以理解, 後續維護艱難, 成本也很高。
• 編碼修正模式中沒有使用者分析與確認, 軟體設計好
之壞, 也往往不符合使用者的需求, 這軟體可能會被完
全拒絕或者也要大幅度的修整重新開發。
• 此模式開始了後來發展更多更好程式系統的必須條件,
比較所有的模式中算是最基本的模式。

26
 19.3 階段模式
• 階段模式開始有了系統化開發程式的概念, 利用方法來設計程
式, 規劃程式的步驟, 有階段性的完成設計一個程式以改善過去
模式所設計開發出來的程式系統的缺點。比較起所有的模式中,
懂得利用規劃概念來設計程式系統, 可以說是有一種突破性的
發展。
• 歷經過去軟體系統以編碼與修正模式的開發經驗, 提出的階段
模式, 將系統開發過程分成七個階段：
1. 作業規劃
2. 程式作業設計
3. 系統實作
4. 單元測試
5. 子系統測試
6. 整合測試
7. 系統評估

27
 19.3 瀑布模式
• 瀑布模式比階段模式更具彈性, 瀑布模式它的開發過程需有完整的
規劃、分析、設計及文件等管理控制, 每一個階段中都有會清楚的
開發定義, 開始懂得邏輯思考來設計程式, 使得程式結構變得更加易
於管理。

28
 19.3 漸增模式
• 漸增模式是瀑布模式的一種再進化, 希望讓瀑布模式更趨於完善；
這個模式改善瀑布模式各階段同時考量的需求, 在發展漸增模式中,
再加上一些新的元素, 新功能, 把問題再分成各各的小問題, 解決小
問題後再整合一起開發。

29
19.3 雛型模式
• 強調快速的雛型模式,
一般分為演進式與用
後丟棄式的雛型策略,
改善漸增模式中的不
足來加以彌補。
• 雛型模式先經需求分
析、設計、編碼、測
試等階段快速建造一
個可運作但並不完美
雛型系統。經使用者
操作與試驗過雛型系
統後, 開發人員得以發
掘更完整的需求系統
而能漸趨完整與成熟。
30
 19.3 螺旋模式
• 螺旋模式是基於下列的構想而產生：在生命週期的每一階段, 應該
運用模擬、雛型、模式建立等方法來降低風險。每一階段都強調
各開發週期的規劃與風險評估是否會影響到開發的實用性。所以
當一部程式系統在開發時, 先確定目標後再進行討論, 規劃內容後
再評估風險, 當遭遇風險的考量時, 能運用各種的方法來解決問題。

31
 19.3 同步模式
• 同步模式是基於下列構想以縮短開發時間、提高市
場競爭力：多個團隊同時開發, 稱為活動同步。同
步行為可以是一個階段內的工作、多個階段的工作、
或多個專案的工作或軟硬體的工作平行進行。
• 在處理上要求需求明確與完整的描述, 並且有足夠
的人力參與。在人力協調上, 要求團隊間有良好的
溝通。它將開發工作分割並同時進行, 整合系統測
試完整獨立進行, 且各功能系統組都要能確實執行。
• 由於在處理上是處於同步的型態, 在時間的掌控上
尤為重視。相較於前面所列出的開發模式, 此模式
比較能夠因應現代的需要。

32
19.3 資訊系統開發的發展方向
• 軟體設計方法也可以用開發過程所需產出之正式文檔數
量, 區別為重量級的方法和輕量級的方法。
• 重量級的方法中產生大量的正式文檔；因而呈現出一種
謹慎、「防禦型」的姿態。重量級方法強調以開發過程
為中心, 而不是以人為中心。重量級方法的例子比如
ISO 9000, CMM, PSP, TSP, 和統一軟體開發過程 (RUP)。
• 輕量級開發過程沒有對大量正式文檔的要求。著名的輕
量級開發方法包括極限編程 (XP, eXtreme Programming)
和敏捷開發 (Agile Development)。
• 有一些人認為, 「重量級方法」適合於大型的軟體團隊
(數十人以上) 使用, 而「輕量級方法」適合小型的軟體
團隊 (幾人、十幾人) 使用。

33
19.4 代表性資訊系統之應用與範例
• 資訊系統的類型大致上可以依企業組織的作業與管理的不同類型
在上細分為管理支援系統 (Management Support System) 與作業支
援系統 (Operation Support System)。
• 在不同功能的作業支援系統的例子當中, 我們大致可以以交易處理
系統與企業資源規劃系統做為代表；在管理支援系統的例子當中,
我們以管理資訊系統決策支援系統專家系統高階主管資訊系統做
為代表來進一步說明。
• 資訊系統的種類 :
• 交易處理系統 (Transaction Processing System)
• 管理資訊系統 (Management Information System)
• 企業資源規劃系統 (Enterprise Resource Planning System)
• 決策支援系統 (Decision Support System)
• 專家系統 (Expert System)
• 高階主管資訊系統 (Executive Information System)

34
 19.4 交易處理系統
• 商業交易 (transactions) 是企業流程中最基本的重要關鍵
事件。當企業與他的供應商、客戶、夥伴、員工, 以及
政府互動時, 他們是主要的方式。交易幫助企業掌握或
產生相關的重要資料。主要的交易例子包括採購、訂單、
銷售、預約、註冊、提貨單、裝運、發票, 以及付款等
等。
• 交 易 處 理 系 統 亦 稱 資 料 處 理 系 統 (Data Processing
System, DPS), 該系統主要之目的是將大量的交易處理
自動化。此系統的兩種主要功能為交易記錄之保存與交
易表單之產生。
• 舉例來說, POS (Point of Sale) 系統之前檯系統、加油站
之加油作業與收銀系統, 金融機構之櫃檯系統等屬於交
易處理系統。

35
 19.4 管理資訊系統
• 管理資訊系統通常架設在交易處理系統之上, 用
來提供規劃、監督與控制企業運作所需要的管
理報表。這些報表通常按照既定的行事曆來產
生, 並以預先設定的格式呈現。
• 管理資訊系統主要之目的是提供不同層級的管
理者有關組織營運狀況不同摘述程度之報表。
該系統的兩種主要功能是交易資料之記錄保存
與摘述性報表之產生。
• POS系統之後檯系統是屬於管理資訊系統。

36
 19.4 企業資源規劃系統
• ERP是由MRP (物料需求規劃) 演變而來, 可以說ERP是
MRP的延伸版本。以往的MRP系統主要著眼於「製造
資源規劃」, 主要由「經濟訂購量」、「安全存量」、
「物料清單」 (BOM)、「工作計劃」的功能組成。
• ERP延伸原有的MRP範圍, 涵蓋企業所有活動的整合性
系統, 通常包含有財務會計、成本會計、產品配銷、生
產管理、物料管理、倉儲管理、人力資源、專案管理、
品質管理等等子系統。
• ERP 通常能及時整合與規劃分散於各據點之企業資源,
並能隨時依需求彈性的處理與展示資訊之系統。我們以
狹義的觀點來看的話, ERP系統算是一個整合與規劃企
業內部資源之系統。以廣義的觀點, ERP系統則為整合
與規劃企業內外部資源之系統 (例如包括上下游之供應
鏈管理)。

37
 19.4 決策支援系統
• 決策支援系統是設計來提供重要資訊來幫助使用者在決定決
策的一種資訊系統應用, 這些資訊的收集整理經過仔細規劃
後, 能夠在有決策需要制訂時, 能夠隨時、及時地提供給決策
者有用的資訊, 以支援決策流程。
• 決策支援系統之主要目的是支援決策者以提升其決策效率
(Efficiency) 與效能 (Effectiveness)。決策支援系統主要是支
援半結構化或非結構化之決策活動, 其主要特徵有：
1. 能以突發、自訂性或標準化的方式分析資料與產生報
表,
2. 能直接與決策者產生互動。
• 例如POS 系統之後檯系統, 除了固定式分析與報表產生外, 若
還能與使用者互動, 並依其需求分析與展示資訊, 則該系統可
稱為決策支援系統。

38
 19.4 專家系統
• 專家系統是決策支援系統的延伸。專家系統描述關
鍵性的需求, 並模擬該領域中有經驗的問題解決者、
管理者、專業人士與技術人員的專長。專家系統初
期發展的目的是用以取代人類專家, 並希望專家系
統所提供之解答或建議可達到人類專家之水準。
• 專家系統有三個主要元件：使用者介面、推理機與
知識庫。使用者介面是專家系統與使用者交談之機
制, 推理機是專家系統依使用者之要求從知識庫中
推論出結果或建議之機制, 知識庫則是系統儲存專
家知識的地方。
• 如今, 專家系統不再強調取代專家, 而是支援專家,
因此專家系統也漸成為另一種決策支援系統。

39
 19.4 高階主管資訊系統
• 高階主管資訊系統是專門設計來提供給高階管
理人員使用的決策支援系統。
• 高階主管資訊系統是針對高階主管之資訊需求
而設計, 其目的是希望高階主管能直接從電腦中
及時得到其所需之關鍵資訊, 而不需透過中介使
用者。
• 高階主管資訊系統有一些重要的特徵, 例如可過
濾、摘述關鍵資訊。一般來說, 高階主管資訊系
統之特徵與決策支援系統相同; 故高階主管資訊
系統可視為是決策支援系統的一種特例。

40
19.4 資訊系統特性

41
 課後練習
1. 試說明成功的資訊系統開發所必須把握的重要原則。
2. 以系統建置過程所涉及到的主要設計者來區分, 資訊系統
之建置策略可分成哪些不同策略？
3. 資訊系統開發要考慮4個構面是什麼？
4. 試簡要說明資訊系統開發之系統分析師所扮演的角色與
任務。
5. 試簡要說明 CMMI 軟體能力成熟度分為五等級的不同內
容為何？
6. 試說明結構化程式設計的要點與特性。
7. 試說明比較物件導向程式設計方法與結構化程式設計方
法的不同。

42
 課後練習

8. 何謂統一塑語言模UML?
9. 試簡要說明整合開發環境IDE與傳統軟體開發
環境的不同與優缺點。
10. 常用的資訊系統開發模式有哪些？
11. 何謂同步模式系統開發方法？
12. 試簡要說明資訊系統的類型, 並列舉代表性資
訊系統之種類及特性。

43