(一)螺旋式模式（Spiral model）

1988年Boehm擴充瀑布式模式、漸增模式與雛型模式為螺旋模式。螺旋模式是基於瀑布模式應用
於政府大型軟體專案之經驗，經多次修改而成。該模式之執行由三個步驟形成一週期：
（１）找出系統目標、可行之實施方案與限制；
（２）依目標與限制評估方案；
（３）由剩下之相關風險決定下一步驟該如何執行。
反覆進行直到系統開發完成為止，其中各週期之進行均強調規劃及風險評估。
(二)佈署圖（Deployment Diagrams）
起源於Booch 的處理圖，它用來說明系統各處理器、處理元件的配置、關聯，以及同一處理器內
執行處理的時程安排等。
(三)物件名稱服務（Object Name Service：ONS）
ONS架構與功能說明

國際RFID標準組織─EPCglobal於2005年十月正式通過了「物件名稱解析服務」
(Object Naming Service，ONS)的標準。此標準的誕生，也加速了EPC Network之網
路整體架構標準完整性。ONS為EPC Network的重要元件，運用在現行成熟之Internet
DNS架構，透過ONS這個名稱解析服務來解析對應此EPC碼所代表之EPC IS URL，再依
此URL關聯出產品之相關訊息資訊。

(四)電子產品碼（Electronic Product Code：EPC）

EPC 或電子產品碼，是任一物件唯一的序列識別碼。一般識別碼可編譯為EPC格式者，包含如
下：
．GTIN (全球交易品項碼Global Trade Item Number)
．GRAI (全球資產回收識別碼Global Returnable Asset Identifier)
．SSCC (裝運容器序號Serialized Shipping Container Code)
．GIAI(全球個別資產識別碼Global Individual Asset Identifier)
．CAGE/DoDAAC (美國國防部國際編碼系統US Department of Defense Internal Numbering
SYsytem)。編譯GTIN的EAN/UPC條碼可識別品項資料。而當GTIN編譯成EPC時，在識別個別
序列品項或品項(sGTIN)方面，EPC 與其情況不同。兩盒相同產品雖GTIN相同，但仍須有不同的
EPCs (sGTIN)。

(五)瀑布式模式（Waterfall model）
瀑布模式是一種系統開發的方法，該方法將系統開發的過程分成數個階段，每個階段清楚定義要
做哪些工作及交付哪些文件，各階段循序執行且僅循環一次。
Kaplan和Norton的平衡計分卡
既是一項戰略規劃工具，又是一個績效管理系統，能幫助企業貫徹執行願景與戰略。它通過以下
四個角度來衡量企業績效： 1. 財務構面。 2. 顧客構面。 3. 業務運營構面。 4. 學習與成長構面。
這四個構面並非絕對，例如非營利事業，可視實際需要加以修正。
(一)「物件」(object)是指一種實體或一種概念(concept)，它是由一組彼此相關的程序或資料所組成
的單元。其中資料可表示物件靜態的特性或動態的狀態，程序可稱為物件的運作（operation）或
方法（method），用來表示物件展現在外的行為，它告訴外界它能做什麼，以及外界該如何與該
物件進行溝通。例如描述一部噴射戰鬥機物件時，可包括：
1.特性：基地、編號、載重量⋯⋯
2.狀態：油料、高度、速度⋯⋯
3.行為：爬升、加速、投彈⋯⋯
(二)對同一 物件的抽象化描述稱之為「 別」(class)。 別是一種樣板（template），它定義了可
能包含於個別物件的運作及資料名稱。 別的定義包含三部分：
1. 別名稱（class name）
2.屬性（attributes）
3.運作（operations）
例如可定義一「飛鷹族」 別來描述同一 的噴射戰鬥機物件，在此 別中包含有基地、編號、
載重量、油料、高度、速度⋯⋯等屬性，也包含有爬升、加速、減速、投彈、讀取高度、讀取速
度⋯⋯等運作。從「飛鷹族」 別可建立「飛鷹001」、「飛鷹002」⋯⋯等不同的飛鷹族物件，
這些物件可具有不同的屬性値，但都擁有相同的運作功能。
(三)「封裝」(Encapsulation)是指將資料及作用在這些資料的運作包藏在一個 別的語法單元中，此語法單元的結構
可分為兩部分：一是定義物件外觀行為的介面(interface)部分，另一則是存放抽象化的結果及如何達成外觀行為的實
作(implementation)部分。封裝可將 別的實作細節隱藏，使其與外界環境隔離，外界只能透過物件介面中所提供的行
為來處理物件的資料，而無法逕自改變物件的資料內容，此種特性稱為「資訊隱藏」(information hiding)。例如在前
述「飛鷹族」 別的語法單元中，定義爬升至、加速、減速、投彈、讀取高度、讀取速度⋯⋯等運作為各飛鷹族物
件的外觀行為介面，而基地、編號、載重量、油料、高度、速度⋯⋯等屬性以及各運作的實際製作細節則為其實作
部份。外界只能透過飛鷹族物件介面中所提供的運作來處理物件中的資料，而無法直接改變其內容；如透過傳遞訊
息給飛鷹001物件執行「加速」或「減速」行為，可調整該物件之「速度」資料，但外界無法直接改變飛鷹001物件
的速度，且飛鷹001物件內部如何達成加速或減速效果，外界亦無從與無需得知。
一、系統分析是建立系統模型（Model）的步驟。物件導向系統分析
（Object Oriented
Analysis, OOA）是目前常用的系統分析方法，試寫出OOA的兩個塑模
（Modeling）
步驟。（20分）
答：
在OMT(Object Modeling Technique)方法中，物件導向分析主要是進行個體模型(object model)、動態
模型(dynamic model)與功能模型(functional model)之塑模，其步驟分述如下：
(一)個體模型之塑模：
1.從問題空間（problem space）導出個體 別。
2.在資料字典中描述個體的 別、屬性及關聯。
3.在 別之間加入關聯。
4.在個體或關聯上加入屬性或限定字。
5.利用繼承（inheritance）觀念來組織及簡化個體 別。
6.測試可能的存取路徑（access path）。
7.重複修正個體模型。
8.將相關的 別組成模組（module）。
⇒個體模型 = 個體圖 + 資料字典
(二)動態模型之塑模：
1.依一般作業程序來描述系統執行的情節（scenario），即事件表。
2.依據情節建立事件追蹤圖。
3.為整個系統準備一份事件流程圖（Event Flow Diagram）。
4.建立 別之狀態圖。
5.檢查被不同狀態圖共用的事件之一致性及完整性。
⇒動態模型 = 狀態圖 + 整體事件流程圖
(三)功能模型之塑模：
1.決定系統之輸入及輸出項目。
2.建立資料流程圖以表示功能相依性（functional dependencies）。
3.對每一個功能進行描述。
4.確認個體之間的限制條件。
5.描述最佳化的標準（optimization criteria）。
⇒功能模型 = 資料流程圖 + 限制條件

二、在資料流（Data Flow Diagram）模型中，包含背景圖（Context

Diagram）及O－圖（O－Diagram）。（每小題10分，共20分）
㈠試說明此兩者之關係。
㈡何種元素符號（Element Symbol）不可能出現在背景圖（Context
Diagram）中，
並說明其原因。
答：
(一)在階層化的資料流程圖中，出現在最頂層的資料流程圖稱為背景圖(context diagram)或概圖，亦俗稱太陽圖，它只
包含一個圓圈（處理），用來代表整個系統，其周圍透過輸入輸出資料流與外界個體相 接，用來描述系統的輸出
入介面及所處之環境。在背景圖之下，用來描述整個系統所包含之主要功能的資料流程圖，即為O-圖(O-diagram)，
亦稱為第0圖，O-圖為背景圖之子輩圖，背景圖則為O-圖之父輩圖。O-圖中可包含多個圓圈（處理），每一個處理代
表系統的一個主要功能。
(二)在背景圖中不可能出現控制處理(control process)的虛線圓圈，因為背景圖中只能包含一個代表整個系統的圓圈
（處理）。控制處理代表即時系統的控制中心，應該包含在O-圖中或O-圖下面的資料流程圖中。
㈠請圖示並說明繼承（Inheritance）之概念。（6分）
答：指類別之間的關係，在此關係中，某類別之資料結構與行為何供其關係中之類別分
享。
繼承之特性可利用Generalization與Sepcialization的原則。來建立Superclass或Subclass。一
般化Generalization是找出某一概念比另一概念更普遍的行為或特徵，亦即辨別一類別比另
一類別更具一般性，具有較高一般性的類別，我們稱為父類別Superclass。反之，特殊化
Specialization是辨別一類別比另一類別更具有專門性，它是用來建立子類別Subclass的原
則。
㈡請說明同名異式（Polymorphism）之概念。（5分）
答：意指「多種型式」，簡稱「多型」，即在不同的物件（或類別）中，利用相同名稱的
操作，以不同的方式處理資料。指相同名稱的副程式或是函數，但是針對不同的物件卻有
不同的功能。
㈢請說明超荷（Overload）之概念。（5分）
答：又稱靜態多型，類別可依參數的資料型態、個數不同，而進行其相對映的操作。
不論是函式成員或建構子， 可以同名但不同參數列個數，此為多載 ( Overload )
㈣請舉出二個可支援UML表達與MDA轉換之CASE工具。（6分）
Ameos
Eclipse IDE + UML2
(一)在物件導向的觀念中我們以物件屬性來描述物件的特性，諸如人的身高、體重、髮色、膚色...等；然後利用物件
方法來對應物件的行為能力，像是人會走路、跑步、吃飯、喝水 等。在物件導向的觀念中，二者的結合對應了
完整的真實世界活動，也讓傳統分析方法中將行為處理能力，與描述資料屬性能力的各自偏頗可以有效結合在一
起。
(二)系統建置成本是指開發過程中所發生的成本，包括需求分析與初步設計成本、細部設計成本、編碼與單元測試成
本、整合測試成本。而一個資訊系統被建置完成後，若要能成功的為組織創造效益，則必須要讓組織可以真正導
入、並落實使用。
而總持有成本便是指組織獲得資訊系統後，可以利用資訊系統為組織創造預期效益的過程中所發生的成本，它經常
必須在系統建置成本之外，再加上轉換成本、裝置成本、訓練成本、風險考量成本 等系統建置之外的考量成
本。因此在組織決定是否建置資訊系統時，不應只著眼考量建置成本，而應將獲得使用資訊系統產生效益的過程中
所發生的總持有成本進行考量，決定是否或採用哪種資訊系統。
(三)JAD是一種用來發掘企業需求，並藉能利用短時間快速確定企業的資訊系統需求的方法。透過此法可以在幾天內
將企業與資訊系統相關之作業人員、主管、企業高層、技術人員...等聚集在一起，透過討論共同決定企業的資訊系統
需求。然而為了讓與會人員可以清楚的凝聚需求與確認需求，便常需要利用雛型方法，快速建立雛型讓與會人能測
試雛型以驗證需求。
RAD是一種可以快速利用已存在的程式開發元件，減少程式撰寫時間、快速建立雛型的開發工具，可以在JAD的過程
中用來協助建立雛型，協助JAD快速凝聚企業資訊系統需求。
(四)α測試也就是驗證測試，驗證測試在一個模擬的環境中以模擬的資料來執行系統，一般而言，Alpha測試是在開發
單位由開發人員與測試的使用者共同進行的測試。而β測試有時也稱為確認測試，是在一個真實的環境中以實際的資
料來執行系統。我們在系統測試中通常會先進行α測試以驗證資訊系統符合使用者與設計說明書所期望之功能，然後
再進行β測試，以確認效能滿足、方法及程序有效率、復原與備份作業工作正常，期望透過這些測試讓資訊系統可以
在未來正確運作。

答：
由題意顯示「資料傳遞溝通平台」包括了讓承辦人員進行災害資料處理，並在資料處理之後，可
以依照各項分類進行通報社會處、勞工局、地方稅務局......等單位以利業務銜接。而根據這樣的陳
述，此系統可能面臨如下的安全問題：
(1)人員安全：由於資訊系統必須要有人員輸入資料，因此人員的身分檢核、業務執行的許可
等問題若沒有妥善考量，均會使得系統面臨損壞或錯誤。
(2)實體安全：由於系統的運作必須仰賴網路設備、機器設備，因此若相關設備遭受天然或人為之
破壞，均會使得系統功能停頓，因此為了讓系統得以正常運作，實體安全問題不容忽視。
(3)網路安全：因為必須通報其他系統，因此必須樣仰賴網路傳輸的作業，而這也會引起網路安全
的相關問題，像是網路入侵、竄改 等安全問題。
(4)資料安全：此外因為相關資料必須被保存以利業務稽核、追蹤，所以資料安全問題也是不可忽
視的。

而為了解決這些安全問題，可以分別利用ISO 27001建議措施來協助提升各種安全控管。

人員安全 1. 減低人為錯誤、竊取、欺騙及濫用設施之風險，確保使用者有
資訊安全威脅的意識。
2. 聘僱與解雇人員都必須遵從資安考量與相關作業程序。
實體安全 1. 避免未經授權的存取、破壞與影響組織之實體設備。
2. 避免對於資訊和處理設施的破壞與竊取。
3. 各種設備的安全保護與使用管理。
網路安全 1. 確保資訊處理與通訊的完整性及可用性。
2. 確保資訊在網路上的安全及保護支援的基礎設施。
3. 作業相互稽核。
4. 利用稽核日誌進行管控。
資料安全 建立資料庫備援、災害回覆的機制，並時時演練流程，以保證業
務可以永續正常運行。
UML：一種利用13個不同的圖表工具來執行物件導向系統分析∕設計的工具，包含有使用者的案
例圖、類別圖、活動圖、循序圖、狀態圖、元件圖、通訊圖、部署圖 等常用圖形。
Use Case Diagram：一種描述系統中主要角色如何透過行為與系統互動的圖形。
DFD：在結構化分析中描述資料如何在外部實體與處理間移動的圖形。
流程分析：為一種透過解構系統作業流程需求的分析、設計方法！
JAD：一種透過群體會議來確認使用者需求的方法。與其他使用者需求確認方法不同的是JAD包
括了使用者與
系統分析師之外的部分，例如：使用部門的主管、系統相關使用人員、開發部門的主管、專
家 等，以利快速地做出較正確的需求發現及確認。
Prototyping：一種可以快速發展企業粗略系統的方法，通常利用簡單、快速的使用者需求提出來
建立系統雛型，並將雛型供使用者測試，利用測試結果來調整系統的修正，直到使用者確認系統
功能為止。
資料分析：一種用來定義出企業資料庫需求的系統分析模式，其產出大半包含著資料庫的規格。
ERD：透過資料所描述的實體和關係的觀點來描述企業的資料，並可以利用正規化技巧建立較有
效率的企業實體與實體間資料關係的系統分析工具。
Use Case Diagram→UML，Use Case Diagram與UML作為一組，是因為Use Case Diagram是UML常用的
分析、設計工具之一，Use Case Diagram圖可以在需求分析階段作為了解使用者需求的工具，並在
系統分析、設計階段藉由精煉來協助系統作更加精確的系統開發。
DFD→流程分析，流程分析為一種透過解構系統作業流程需求的分析、設計方法，DFD為流程分析
模式中用
來分解作業流程的工具，分析人員可以藉由分解的方式將系統問題，由全部至細微的方式來將流
程解構至足以協助撰寫程式碼(或單一模組)的階段。
JAD→Prototyping，JAD又稱為JRP(Joint Requirements Planning)，是一種利用群組會議來替代訪談的，
以了解問
題、分析問題、確認問題的需求分析方法；在JAD中經常需要利用雛型法(prototyping)來快速建立
解決問題的雛型，以在短暫的會議期間(3~5天)可以一定程度的確認解決問題的系統方向。
ERD→資料分析，資料分析的系統分析模式又稱為資訊工程法，此法與流程分析不同點在於以企業
資料需求
為出發點來進行需求分析；此法中所使用的資料需求分析工具就是實體關係圖，其中利用實體來
表示系統中的物件及其屬性，利用關係來說明實體之間在系統中的作用。
(一)CASE工具是為了能幫助系統開發團隊更有效能的發展系統所產生的自動化工具，一個CASE實
際上是以CASE貯藏庫為核心，貯藏協助系統開發有用及可重複使用的系統元素，再輔以包括繪
圖、字典、設計、品質管理、文件製作、程式碼產生、測試等工具，讓系統開發團隊可以結合這
些CASE簡便工具，再輔以順向工程、逆向工程等方式加強開發效率。
CASE的發生情境是在早期SDLC開發方法面臨了開發週期長，導致使用者的需求無法及時滿足，
因此便有透過自動化概念來協助提升系統分析階段工作效率的想法，因此CASE工具便為了系統分
析階段提供一些方法。其中文件製作工具、繪圖工具便被用來協助解決傳統SDLC分析階段的缺
失，在CASE中的繪圖工具與文件製作工具可以協助系統分析人員自動化的產生相關的文件，讓系
統擁有者、使用者、設計者等相關人員可以儘早分享系統分析階段的產出，也能儘早進行溝通以
確認分析階段的結果，並且因為自動化的協助讓分析階段的時間可以縮短許多，提升系統開發的
時效。
此外，CASE工具可以利用逆向工具來協助解決缺乏文件的陳舊系統改善時之分析階段工作，當陳
舊的系統如果並非全部功能都無法使用，只需要做某些功能的替換或改善時，CASE的逆向工具方
法可以將陳舊系統的原始碼轉換成設計規格、再轉換成分析文件。如此一來，分析人員便可以僅
進行需要修改功能的分析，而不需要將全系統所有的分析文件重新製作，因此也可以提升陳舊系
統改善、修改的分析階段效率。
當然，CASE中還包括了字典工具、設計工具來協助系統開發的設計階段作業，字典工具可以自動
化方式產出說明文件和規格書、設計工具則可以協助自動建立輸出、輸入的規格。另外再協助程
式碼撰寫與測試階段，CASE提供了程式碼產生工具將程式碼的撰寫自動化，也提供了測試工具來
產生測試計畫與測試草稿，加速系統開發的測試階段作業。而CASE中提供的自動化工具，可以協
助快速的建立雛型，在系統開發的需求分析階段，自然能幫助進行需求確認或需求發掘。其實最
重要的CASE概念之一，便是為了加速SDLC冗長的開發週期，而這樣的冗長有一部份是來自於間
段的銜接，CASE的順向工具則是解決此一問題的最佳方法。
(二)流程分析主要是以資料流程圖為塑模的工具將企業流程分解為階層架構的模組，雖然流程分
析藉由資料流程圖的建置過程逐步分解的產出結果，但是在確認進入設計階段前仍然需要進行資
料流程圖的外部一致性與內部一致性問題的檢查，來確認資料流程圖的正確程度。這包括了：
1.資料流程圖中每個資料流、處理程序和資料儲存皆有名稱，而且均已在資料字典定義。
2.確認每個處理程序是否還有低層次的資料流程圖對應，如果沒有變應該有處理規格(像是結構化
英文)來描述處理程序的行為。
4.確認每個資料儲存是否在實體關係圖中有對應，否則就可能造成不一致的情形。
5.確認資料流程圖是否平衡，是否上、下層間的資料流、資料儲存與外部實體有不對應。
6.檢查資料流程圖是否出現重複的、多餘的處理。
7.檢查資料流程圖中的處理與檔案是否出現僅有輸出或僅有輸入的不合理情形。
8.最後檢查資料流程圖編號的對應關係。
除此之外，在資料流程圖進入設計階段之前還需要檢查是否出現多餘或短缺的資料流。而資料流
程圖可能發生的概念性錯誤是無法由圖形看出的，所以必須仰賴系統發展人員與使用者共同審視
問題方能找出錯誤來改善之。
最後利用資料分析法中的資料流程圖進行分析工作，主要是要建立一個有效率的模組設計，然而
分析產出的結果可能並非如此，這時應該考量利用內聚力的檢測測試最低層的資料流程圖是否符
合內聚力的要求；並透過耦合力的檢測來測試模組間的耦合力是否滿足系統的建議。
資料分析是以實體關係圖為塑模的工具，藉由資料所描述的實體和關係的觀點來獲取企業系統所
需的資料，雖然藉由實體關係圖的建構可以藉由獲得資料庫的需求來建立資料庫設計，但是這樣
的資料庫需求可能僅是具備結構上的特性，並非可以是設計時好的資料庫結構。因為在資料分析
所產生的初步實體關係圖中可能包含以下的問題，造成結果的不一致：
1.資料模型並不是簡單的。描述特定實體的資料屬性應該只描述此一實體。
2.資料模型發生重複的現象。這表示每一個資料屬性，除了外鍵之外，應只描述至多一個實體。
3.好的資料模型對未來的需求應該有擴充、調整的彈性。這表示企業應能隨著企業的發展來擴充
資料庫，因此必須建立一個可以隨企業需求改變調整資料結構而不至於影響現行系統中程式的資
料庫結構。
上述的狀況在實際操作時便會發生插入資料異常、刪除資料異常與更改資料異常的情況，對於解
決這樣的問題，資料分析的方法便是利用正規化的過程來解決這些結果的不一致。
如果由資料分析與流程分析來看，兩者雖然切入的觀點不同，但是分析企業的需求應該是要能一
致的，也就是說在資料模型中的每個實體應要能在流程分析的模型中有相對應的資料儲存，如果
這樣的情況無法被達成，那顯然的表示企業問題的分析出現瑕疵。要解決這樣的問題，應該可以
建立一個資料對處理的CURD表，將流程分析模型中的處理項目與資料分析中的實體屬性作一個
對應，分別以C(create)、U(update)、R(read)、D(delete)來表示對應的狀況，經此對應可以檢查資料
模型與流程模型中的不一致情況。
此外，面對資料模型與流程模型在流程處理與資料儲存對應不一致的問題，也發生在過往的流程
分析會以報表產出為主要對象，因此導致不一致的狀況。像這樣的情形則可以企業流程再造，先
行思考企業資料需求並利用流程再造將舊有流程打破，重新思考協助企業創造價值的新流程，如
此可以重新設計的企業流程減少資料分析與流程分析不一致的情況。
(一)合作圖（Collaboration diagram）
是從Booch的物件互動圖與Rumhaugh的物件導向資料流程圖改進而成，該圖主要表
達相關物件間之連結結構，並能同時展現物件間的資料流程、控制流程與訊息傳遞
的活動。因此，合作圖是一個巨觀的總流程，能同步表達資料的產生與資料轉變的
過程，以改進傳統資料流程圖只著重資料流的缺點。
(二)專家系統（Expert system）
初期發展的目的是用以模仿人類專家解決特定問題的能力，並希望專家系統所提供
之解答或建議可達到人類專家之水準。此外，希望系統很容易開發，使得非資訊專
業人員只要接受簡單之訓練，便能開發其所需之專家系統。專家系統有三個主要元
件，使用者介面、推理機與知識庫。
(三)程序內聚力（Procedural cohesion）
指模組內具有多個功能或處理多件事情，這些功能必須按照一定的順序來執行，且
不共用資料，這些功能群集在一個模組內僅為了確保它們的執行順序，則這模組具
有程序內聚力。
(四)因果圖（Cause-and-effect diagram）
 定義：因果圖又叫石川圖或魚骨圖，是表示質量特性與原因關係的圖
 作圖要點：(1)明確需要分析的質量問題或確定需要解決的質量特性(如：Solder paste
CpK 低)
(2)召集同該質量問題有關的人員參加“諸葛亮會”集思廣益,各抒己見。
(3)向右畫一條帶箭頭的主幹線將質量問題寫在圖的右邊，一般按5M1E分類，
然後圍繞各大原因逐級分析展開到能採取措施為止。
(4)記錄有關事項。
(五)環境圖（Context diagram）
用來表達系統所在之環境及其與環境間之關係，這包括與系統有關之外部實體及系
統與外部實體間之互動，例如資訊之輸出／入與處理封。綜言之，環境圖可表達系
統之巨觀範圍，其重要內容有：
（１）與系統互動之外部實體；
（２）系統從環境中所接受的資訊或刺激；
（３）系統所產生及輸出給環境之資訊；
（４）系統與環境之界限等，以幫助我們瞭解系統所存在之環境及兩者互動之關係。
環境圖之表示符號
元素 表示符號

系統

外部實體

處理與資料流

使用個案圖：引用Jacobson的方法，從使用者觀點描述系統的行為者與系統間之互動行為
關係。
從內部的觀點來看，使用個案可描述系統做什麼（What）。從外部觀點來看，它可描述行
為者與系統如何互動（How）。
類別圖：引用Booch與Rumbaugh方法，主要用以表示系統存在之物件型態（或稱類别）及
各物件型態間的靜態資料結構與邏輯關係，也表達類別之屬性、操作與類別間連結之限制
等。
循序圖：結合Booch互動圖與Rumbaugh的訊息追蹤圖而成，主要用以描述系統運作時物件
間的互動行為，且著重以時間之先後順序為主軸，以表達物件間的訊息傳遞與處理程序。
活動圖：是狀態圖的一種變異，該圖表達涉及於執行某一作業行為中之活動。一個活動圖
描述一群循序與同步的活動，一個活動狀態表示一個工作流程步驟或一個運算的執行活
動。
部署圖：起源於Booch的處理圖，它用來說明系統各處理器、處理元件的配置、關聯，以
及同一處理器內執行處理的時程安排等。
比較結構化、物件導向與元件導向等方法之差異。
差異
（１）分析與設計各階段使用不同模型，使分析與設計間存在一道源溝。並難以察覺潛在
的不穩定因素。
分析：資料構面﹣＞實體關係圖（ERD）為主要工具
　　　處理（功能）﹣＞資料流程圖（DFD）為主要工具
結 設計：使用資料庫模型、模組結構圖
構 （２）資料與處理分開。
（３）處理（功能）導向(Process(function)-Oriented)：分析設計時，主要考量系統所要完
化 成的功能或處理。
（４）由上而下設計。
（５）易學難用。
（６）資料（Data）是被動的，程式取得資料，處理後再回存。

（１）在分析、設計、程式設計與資料庫均使用幾乎一致的類別模型，使得分析與設計間
之源溝不再存在，以及階段轉移非常平順。分析與設計幾乎是同一件工作。
物 （２）以物件（資料）導向(Object(Data)-Oriented)：以系統執行時所要處理的資料也就物
件 件為中心來考量系統。
導 （３）資料與處理均封裝（Encapsulation）於物件之內。
（４）由下而上設計。
向 （５）難學易用。
（６）再用性。
優缺點
結構化 物件導向

優 （１）化整為零，把複雜的東西切割成細 （１）分析與設計間使用相同模型，源溝消
點 項。 失且移轉平順。
（２）容易學習。 （２）開發時間較短。
主功能容易達成，初期發展迅速。 （３）容易維護。
（４）降低成本。
（５）擴充性佳。
（６）適應性強
（７）提升品質。
（８）概念簡單。
（９）功能強大提高軟體開發的生產力
（Productivity）。
（１０）軟體再用（Reusability）
 結構化 物件導向

缺 （１）合成時會發生無法預期的狀況。 （１）由於物件導向是屬於較新的技術，以
點 （２）系統建構於系統功能之上，功能一旦 致「導入時」組織成員抗拒。
有變更，修改必須付出很高的成本，且負責 （２）技術人員缺乏。
度也會提高。 （３）物件程式執行速度較慢。
（３）分析與設計間存在一道鴻溝。
（４）實體關係圖（ERD）轉換成資料庫模
型時，會產生“語意的喪失“。
（５）與「企業運作過程」（business
process）沒有一致的直接對應（direct
mapping）關係。
（６）在面對大系統時，會大幅增加工作複
雜度。
（７）編碼時，設計的結果又要再受資料庫
系統與程式語言的限制。
（８）難以進行反向工程（reverse
engineering）

軟體測試用來促進鑑定軟體的 正確性、完整性、安全性、和品質的過程。
白盒測試(White-box Testing)，
軟體測試的主要方法之一，也稱結構測試、邏輯驅動測試或基於程序本身的測試。測試者了解待
測試程序的內部結構、演算法等信息，這是從程序設計者的角度對程序進行的測試。
黑盒測試
這種測試不需要了解軟體的內部構造，是從用戶的角度對程序進行的測試，只知道程序的輸入
（將測試數據輸入軟體）、輸出（確認輸出結果是否正確）和系統的功能就可以，因此被稱為黑
盒測試。
測試的階段
單元測試
集成測試
系統測試
系統測試主要包括功能測試、界面測試、可靠性測試、易用性測試、性能測試。 功能測試主要針
對包括功能可用性、功能實現程度（功能流程&業務流程、數據處理&業務數據處理）方面測試。
回歸測試

模 年 基本設／適用情況 主要特徵
式 代

19711.使用者需求可完整且清楚地描述。 1.開發階段有清楚的定義，把整個問題範
2.解決問題之知識（例如模式或方法） 圍分解成若干個子問題，各子問題之開發
漸
可得到。 可依序以瀑布模式進，亦可平行進行再整
增
3.軟硬體之技術與支援沒問題。 合。
模
2.強調先有完整的設計與規劃，再進行編
式
碼。
3.開發週期反覆地進行。
模 年 基本設／適用情況 主要特徵
式 代

19771.使用者需求無法完整且清楚地描述。 1.系統開發階段無清楚之分野，且開發週
雛 2.解決問題之模式或方法無法立即得 期反覆地進行。
型 到。 2.不強調先有完整的設計與規劃再進行編
模 3.軟硬體之技術與支援不確定。 碼。
式 3.強調快速的完成雛型且盡早使用，以作
為雙方需求溝通與學習的工具。

同 19931.使用者需求可完整且清楚地描述。 1.將開發工作分割並同時進行。
步 2.有足夠的人力參與。 2.整合及系統測試不可分割，且各功能組
模 3.團隊間有良好的溝通、資訊交換與專 都要執行。
式 案管理。

Ra 1998上述各情況均可。 1.上述各情況之綜合。
tio 2.強調反覆與漸增的開發，及各開發週期
nal 之規劃與風險評估。
統 3.強調流程、工作產出與專案管理。
一
流
程
模
式

（a）樂觀時間（optimistic time），（m）最可能時間 （most likely time），（b）

悲觀時間（pessimistic time）
期望時間
（a+4m+b)/6
答：
SDLC Prototype

優點 1.技術成熟，廣受使用。 (1)可為使用者發展出更完整、準確及友善的使用者介面。
2.問題及錯誤容易回溯。 (2)可幫使用者找出他們原先所不知道的需求。
3.發展過程結構化，適合複雜性 (3)使用者對於認可一個他們可以試用的系統，將比認可一個
的專案。 只存在紙上的系統更有信心。
4.容易維護。 (4)使用者對於任何他們曾幫忙建立的系統，較能有正面的態
度傾向它。
(5)此種方法可降低整個軟體發展的成本和風險，因為它能有
效地將後期發展階段的需求和範圍改變成本減到最少。
(6)在資訊收集期間有利用原型法進行需求分析的系統，將有
較低的維護成本，因為已降低了不確定性，所以錯誤和遺漏
皆可較少。
(7)演化成最終系統的原型，其維護成本通常不高，因為以第
四代語言撰寫的系統將比用第三代語言撰寫的系統更容易修
改。
(8)可消除生命週期中的「死限症候群」。
 SDLC Prototype

缺點 1.較無法適切地反應使用者需求 (1)使用者可能不願投資原型法要求他們付出時間和精力。
之變更。 (2)當原型演化成最終系統，其執行效率可能較差，需要花費
2.開發失敗的風險較大。 大量的記憶體，並且較難與系統的其他部分協調執行。
3.必須花許多時間在系統分析和 (3)為了改進執行效率，通常由第四代語言撰寫的原型系統，
設計上，可能製作出過多的文
必須再以第三代語言重新撰寫。
件。
4.容易產生死限症候群。 (4)原型設計法通常較不適於需要複雜演算法來處理的系統，
5.使用者參與的程度少，僅在分 如以下三 系統
析和測試階段而已。 a.系統軟體
如作業系統、資料庫管理系統，因其技術面之困難度遠大於
分析面之困難度。
b.即時控制系統
如捷運控制系統、航空控制系統，因其重點在於滿足嚴格的
績效限制。
c.嵌入型系統（embedded system）
因此種系統沒有直接的使用者介面。
(5)原型系統缺乏有效的評估準則，品質低的問題相當嚴重。
(6)缺乏原型的自動化工具。

適用時 1.系統使用者對需求相當清楚。 1.使用者需求無法完整且清楚地描述。

機 2.開發者具有相當經驗，並對系 2.解決問題之模式或方法無法立即得到。
統程序相當了解。 3.軟硬體與技術支援不確定。
3.系統需求在未來變動不會很
大。
4.人力、財力、時間較為充裕。

㈠雛型法（Prototyping）
先針對使用者需求較清楚的部分或資訊人員較能掌握之部分，依分析、
設計與實施等步驟快速開發雛型。開發過程中，強調盡早以雛型作為使
用者與資訊人員需求溝通與學習之工具，雙方透過雛型之操作與回饋，
以釐清、修改及擴充需求，並藉以修改與擴充雛型。反覆此一步驟直到
系統符合雙方約定為止。
 透過使用者的初始需求快速發展原型系統
 透過原型系統的使用回饋確認使用者需求
 進一步根據使用者需求修正並擴充系統
 重複進行以符合使用者需求並完成系統
㈡快速應用發展法（Rapid Application Development）
使用RAD工具來提昇快速發展的可能，RAD工具本身即為一群由精熟設人員開發完備的許多雛
型，可讓設計者依需求加以適時的調配，以符合開發的需求。
㈢聯合應用設計法（Joint Application Design）
透過一個三到五天的會議，讓開發者與顧客能夠快速有效而且深入地檢討需求並取得共
識。JAD具體結果是產生完整的需求文件。它的步驟為；範圍界定、關鍵人員的熟悉、會
議準備、會議進行、文件產生。
㈣物件導向發展法（Object-Oriented Development）
又有OMT,Jacobson,OOSE,RUP模式等方法，原則上即是透過將需求具體化模組化對映到真實的狀
態下，以分類，封裝、繼承、超荷等物件導向手段來完備系統能力。
㈤元件導向發展法（Component-based Development）
元件是將已經具體化的物件，進一步發展成許多可供直接運用的子元件，較之物件開發更接拆實
際的狀況，發展者只要依據實際的狀況進行調整元件即能完備。
㈠請說明RUP模式的動態面把軟體開發依序分成那四個主要階段及每個階段須完成的重要
里程碑是什麼？（16分）
答：
1.Inception Phase初始階段
建立一個可理解的、完整的系統需求與範圍，降低企業風險，詳細構想出建構系統所需的企
業個案，取得所有參與專案人員對推展該專案的認同。
2.Elaboration Phase詳述階段
處理主要的技術工作（例如設計、實施、測試、系統結構等），並以實際可執行的程式編輯
來探討主要的技術風險（例如資源主張（Resource Contention）、績效與資料安全等風險）。
3.Construction Phase建構階段
建構一個初步可運作的系統版本，繼續演化幾個內部版本以確保系統是可用的及滿足使用者
的需求。最後完成一個具有完整功能的系統版本，這包括安裝與支援文件及訓練教材等。
4.Transition Phase轉移階段
依使用者回饋精調系統、組態、安裝與可用性等議題，並將系統產品移交用戶使用，包括備
份、培訓、支援、維護等。
㈡請說明RUP模式的靜態面主要處理那六項軟體開發的核心工作流程（Workflow）？（12
分）
企業塑模、需求、分析與設計、實作、測試、配置。

(一)網站已成為企業在數位世界的展示櫥窗，它的品質關係著企業的形象，其互動服務的深度代
表企業對顧客的承諾與尊重。一個好的企業網站所創造的衍生商業價值是無可計量的，相反的，
一個粗製網站，它所產生的負面效應也絕對會超乎所節省的建置成本。 商務網站歸結而言是統整
過的美化版交易功能介面，除了功能要明確易用外，它尚存在著增進交易的角色伴演，所以除了
功能外，美觀及趣味性均是網站設計的考量要素！
(二)網站設計應包括的重要品質指標
1.良好的網站企劃：適切規劃網站的主題、對象和內容。
2.視覺風格的表現：引人入勝的網頁視覺設計。
3.豐富的網頁內含：充實網頁內容所需的資料。
4.純熟的網頁設計技巧：善用各種網頁編寫軟體製作多媒體、動態之互動網頁。
5.Internet技術的應用：提供電子商務網站所需之交易安全機制。
6.廣告與宣傳：運用各種方式為企業網站進行宣傳，吸引消費者。
7.網頁的維護更新：依需要隨時或定時進行網頁之維護與更新。

(一)Web Service為已獲得IBM、Microsoft、Sun Microsystems、HP、Oracle等廠商所共同支持的網路

服務，其以XML、SOAP、HTTP等業界標準為基礎，以軟體元件的方式透過網路提供服務與資
訊；它可透過Internet讓每個企業組織能與商業夥伴公司內的應用系統加以整合，共享及交換必要
的資訊，亦能將整個產業環節中各廠商獨立且相異的IT系統，結合成為一個大型供應鏈(Supply-
Chain)應用系統。
(二)最基本的Web Service平台是XML加HTTP，HTTP是一個在網際網路上行之多年且廣泛使用的通
訊協議，XML則是一種標籤語言，我們可以用它來撰寫特定的語言，以描述用戶端與服務之間的
互動關係，而在Web Service後端，XML格式的訊息會被轉換成對中間元件的呼叫，而傳回的結果
也會被轉換成XML格式。但若是要建構一個完整的Web Service平台，就必需再加上SOAP、WSDL
與UDDI，以擴充其功能，同時保持簡單性和普遍性。
(三) Web service的架構如下：
Web service主要成員角色有：
1. Service：Service是一種應用程式，提供者將它公佈於Internet上提供服務。
2. Web Service Provider：從架構面來看Service provider，它是提供服務及服務本身的執行環境。
3. Web Service Requester：某種Client或應用程式，在Internet上搜尋、使用Web Service。
4. Web Service Registry(Broker)：是一種儲存Web Service資訊的環境，讓Service Provider註冊公佈
Service的資訊；讓Service Requester搜尋服務，並取得和Web Service溝通的相關資訊。
(四) Web Service運作行為如下：
1.描述：要讓Web Service Requester知道Web Service提供服務的內容，以及和其溝通的方式，需要
有一種描述Web Service的語言。
2.發佈：透過某種註冊機制將Web Service的描述資訊登錄於某個公開的Web Service Registry。
3.尋找：Service Requester向Web Service Registry送出Query訊息，取得Web Service的Binding資訊。
4.組裝：根據取得之Web Service描述資訊，建構一個連結到該Web Service的代理程式。
5.呼叫：透過Internet傳遞適當訊息參數，呼叫該Web Service。
6.整合：整合其他Web Services建構出自己的應用程式或是新的Web Service。
(一)所謂企業智慧(BI)是指將與企業運作有關的重要性資訊收集整理，用來管理目前和將來的商業
運作環境的一個過程。換言之，企業智慧乃是將企業內部所掌握的資料與資訊，做進一步分析之
後，一方面針對企業所面臨的環境相關資訊，另一方面則整理內部重要資訊，將兩者彙整應用，
產生出有助於公司策略性及關鍵性決策的精華。
(二)企業智慧的分析主要包括：
1.環境掃瞄：企業外部環境的變化會急速影響企業的營運與獲利，外部環境的演化也會造成不同
的市場趨勢；因此，企業必須隨時掌握相關資訊，根據總體環境的變化，蒐集相關有用的資訊，
分析並預測市場的趨勢走向，進而幫助企業研擬解決問題的方法，提供最佳的決策建議。
2.產業競爭智慧：在產業競爭及企業競爭力方面，Porter指出影響廠商競爭態勢的因素有五項：
(1)現有競爭者的威脅、
(2)潛在進入者的威脅、
(3)替代性商品的威脅、
(4)供應商的議價能力、及
(5)購買者的議價能力等，前三項統稱企業競爭智慧，第四項稱為供應商智慧，第五項則稱為客戶
智慧。
3.企業管理智慧：在當前競爭日益激烈的商業環境中，企業對能提升經營績效之創新管理智慧的
需求更形殷切；企業管理智慧如何發揮其效用，必須有一套強大的工具來幫助分析企業管理智慧
是否有用，平衡計分卡(Balance Score Card)就是一套企業管理智慧的衡量體系。
(三)企業智慧系統的IT架構主要包括：
(1)資料倉儲(Data Warehouse)：儲存企業的內部資料與外部資料，構成企業智慧系統的基礎；
(2)資料分析技術：包括OLAP及資料探勘(Data Mining)等，可將資料轉換成實用的企業資訊；
(3)前端主管決策支援系統(EIS)：依特定需求提供關鍵性資訊給決策者，提升決策績效。此IT架構
如下圖所示：
(一)軟體能力成熟度整合模式CMMI的主要內容架構中包括以下組件：流程領域、特定目標、特定
執行方法、一般目標、共通特性、一般執行方法、典型的工作產品、細部執行方法、專業領域強
化、一般執行方法詳細說明與參考資料。此架構如下圖所示：
(二)CMMI之認證共分為五級：
第一級：初始(Initial)
在成熟度第1級中，流程通常是混亂的。組織通常沒有提供穩定的環境維持流程。
第二級：已管理(Managed)
成熟度第2級中，專案建立組織的基礎，藉由將基本專案管理與供應商管理執行方
法制度化，成為所需能力的有效率採購者。專案定義供應商策略、建立專案計畫，
以及監督與控制專案，以確保產品或服務如期交付。
第三級：已定義(Defined)
成熟度第3級，流程被適當地描述特徵與瞭解，並說明於標準、程式、工具與方
法。
第四級：數量化管理(Quantitatively Managed)
成熟度第4級，組織與專案針對品質與流程績效建立量化目標，並使用它們當做管
理流程的準則。
第五級：最佳化(Optimizing)。
成熟度第5級，組織根據流程變異的共同原因的量化瞭解，持續改善它的流程。

與SOA相關的Web服務的標準主要有：
■ XML - 一種標記語言，用於以文檔格式描述消息中的數據。
■ HTTP （或HTTPS） - 客戶端和服務端之間用於傳送信息而發送請求/回復的
協議。
■ SOAP(Simple Object Access Protocol) - 在計算機網絡上交換基於XML的消息的協
議，通常是用HTTP。
■ WSDL(Web Services Description Language) （Web服務描述語言） - 基於XML的描
述語言，用於描述與服務交互所需的服務的公共接口，協議綁定，消息
格式。
 ■ UDDI(Universal Description, Discovery, and Integration) （是統一描述、發現和集
成） - 基於XML的註冊協議，用於發佈WSDL並允許第三方發現這些服務。

慎選委外廠商、明確提出規格與需求及編列合理的預算等問題。
慎選委外廠商：如能選到良好的廠商，則資訊委外已成功了一半。關鍵在於如何
選到優良的廠商？雖然目前政府採購法規定資訊委外服務可以透過評選的方式選擇
優良廠商，但是如果參與投摽的廠商素質不佳，評選出來的結果亦然，故重要的是
要了解委外廠商的生態，平常與優良廠商維持良好的互動關係，主動邀請優良廠商
參與投標，以增加評選對象的選擇性。
明確提出規格與需求：機關辦理資訊委外，並不是什麼都不必做，只要等著廠商
幫您服務即可。若能事先下功夫，把規格及需求更明確的表達出來，則越能規範及
要求廠商所提供的服務，廠商也能明確規劃所要投入的資源，較能精確預估成本及
開發時程，提高成功的機會。
編列合理的預算：資訊系統開發係屬智慧財產之創作，且業務單位的需求日趨複
雜，成本估算不易，造成機關與廠商間認定不一。若單以價格取向，一味壓低價
格，致使廠商無法得到合理的報酬，自然無法孕育成長，提供更好的服務。因此，
應編列合理的預算，以提昇軟體品質為導向，創造雙贏的軟體委外環境。

(一)白箱測試（white-box test）是指將受測對象視為「開放箱」（open box），俗稱「白箱」（white box），其內部

結構與邏輯皆已得知，可執行模組內的所有敘述及所有控制路徑，以檢查受測對象能否順序運作。
(二)黑箱測試（black-box test）是指將受測對象視為「密閉箱」（closed box），俗稱「黑箱」（black box），即其內
容無所得知，測試的重點在檢查每一種輸入資料能否確定接收，且輸出結果是否與預期的結果一致。
(三)一般而言，單元測試與整合測試皆採用白箱測試，而系統測試與驗收測試皆採用黑箱測試。因為單元測試需了解
受測程式單元的內部程式邏輯，方能對所有敘述及所有控制路徑進行測試；整合測試則必須了解系統或子系統中所
有程式模組之間的控制結構，才能逐步進行各模組之整合及測試工作，故這兩種皆需採用白箱測試方式進行測試。
而系統測試主要是由系統開發人員針對整體系統的功能和效能需求進行測試，驗收測試則是由顧客針對各項使用者
需求規格進行測試，兩者均只就系統的輸入與預期結果進行驗證，無需考慮系統的內部細節，故採用黑箱測試方式
進行測試。
答：三種常見的需求擷取方式如下：
(一)訪談
訪談是使用最廣且最有效的一種方法，它是由系統分析師與實際工作人員或有關主管面對面討論系統的作業情形與
需求等。在專案一開始，系統分析師往往要花很多時間與使用者面談他們的工作，包括作業內容、處理流程、處理
規則與所涉及之資訊、人員或部門等。藉由訪談的過程，系統分析師可搜集到許多系統相關需求，並可觀察到人們
的肢體語言、情緒和他們對現行系統之觀感等。訪談可分為開放式訪談（Open Interview）與結構化訪談（Structured
Interview）。
(二)問卷調查
訪談方法雖然較易獲取所需資料，但因每次面談都須系統分析師親自主持，甚為費時費力。倘若企業機構組織龐
大，系統使用者人數眾多並且分散各地，使用面談方法蒐集資料將十分困難，在此情況下宜以「問卷調查」方法取
而代之。一般來說，問卷調查適合於大型企業或公眾資訊系統之設計，因為它所涉及的作業範圍或對象太廣，系統
分析師無法逐一親自調查，故利用問卷方式來蒐集使用者需求較為可行。
(三)開會討論
開會討論是一種很有效的需求擷取方法，它可讓所有相關的使用者與系統開發人員齊聚一堂，將所知道的事實、觀
念說出，讓所有與會人員一起相互溝通意見，如此較容易獲得正確的資料，因為縱使有不正確的意見或觀念，經由
眾人研究亦能加以修正。此外，同時多人集合在一起，自由奔放腦力，將所知道的「事實」與「觀念」盡量地發
表，亦可發揮腦力激盪（Brainstorming）的效果。
三、(一)無線射頻辨識系統（Radio Frequency Identification：RFID），
可取代傳統條碼系統於不同的應用領域中，請比較兩者之優缺點。（15
分）
表〈三〉RFID 與一般傳統條碼的比較表
 RFID 傳統條碼

資料傳輸物質 無線電波 光電效應

資料性質 數位資訊（固定/可變動） 數位資訊（固定）

讀取方式 不需特定方向與光線 直視標籤

讀取速度 快，可同時讀取多組標籤 慢，一次只能讀取一筆資料

讀取 距離長〈0~10 公尺〉 短〈0~50 公分〉

寫入距離 距離較短 無法重寫

可儲存資料量 可達~M bits 一維：50Bytes；二維：

2，361Bytes

資訊安全性 可加密/可防改寫 無

耐污性 佳 低

價錢 逐進下降 趨近於零

穿透性 強 無法穿透

仿製 難 易

資料來源：ＲＦＩＤ產業資料庫 http://www.u-rfid.com.tw/〈檢索日期 97.09.17〉

(二)試簡述RFID系統的定位能力可以應用在那些領域？請舉例說明之。
（15分）
自動化倉儲，圖書館管理、軍品管理，由於它的成本高，距離沒有GPS遠
所以僅適合小區域特定物件的記錄。
四、資訊系統分析階段，產生之文件包括系統設計規劃書與系統功能需
求說明書，試述 其內容包括那些項目？請扼要說明之。（20分）
答：
系統設計規劃書：版本及變更記錄、專案目標與範圍、專案排程、資
源、風險管理、資料管理規劃，附錄相關說明文件

功能需求說明書：