115 年 國立政治大學資訊管理學系碩士班資管組《管理資訊系統》

這題主要探討在日益連結、自主、共享、電動化的移動系統（Mobility Systems）發展趨勢下，如何兼顧倫理考量。這牽涉到技術發展與社會責任的平衡，需要從多個層面思考。

核心觀念： 科技倫理、系統設計、利益關係人分析。

解題思路：
首先，需要理解「移動系統」的各種可能性（連結、自主、共享、電動化）各自可能帶來的倫理挑戰。接著，思考如何透過系統設計、政策制定、使用者教育等方式，將這些倫理考量融入發展過程中。

詳細闡述：

• 連結（Connected）：

  • 可能性： 車輛之間、車輛與基礎設施之間、車輛與使用者之間的即時通訊，提升交通效率、安全及使用者體驗。
  • 倫理考量：
    • 隱私權： 大量個人數據（位置、駕駛行為、行程偏好）被收集與分享，如何保護使用者隱私不被濫用或洩漏？
    • 數據安全： 系統易受駭客攻擊，導致交通混亂、個資外洩，如何確保系統安全？
    • 數位落差： 缺乏必要設備或技術能力的使用者可能被排除在外，加劇社會不平等。
  • 對齊倫理： 實施嚴格的數據加密與匿名化政策，提供使用者數據使用權的透明化與控制權。建立強大的網路安全防護機制。設計包容性的介面與服務，考慮不同族群的需求。

• 自主（Autonomous）：

  • 可能性： 自動駕駛汽車、無人機遞送等，有望減少人為錯誤，提高運輸效率。
  • 倫理考量：
    • 責任歸屬： 發生事故時，責任應由誰承擔（駕駛、製造商、軟體開發者）？
    • 決策倫理（Trolley Problem）： 在不可避免的事故中，自動駕駛系統應如何選擇（例如，撞向行人還是保護乘客）？
    • 就業影響： 自動駕駛技術可能取代大量駕駛人員，引發失業問題。
    • 系統可靠性與安全性： 軟體錯誤或感測器故障可能導致嚴重後果。
  • 對齊倫理： 制定清晰的法律框架界定自動駕駛的責任。透過演算法設計，將倫理決策預設為盡量減少傷害，並對此決策過程進行公開討論與驗證。推動再培訓計畫，協助受影響勞工轉型。建立嚴格的測試與認證標準，確保系統在各種情境下的安全性。

• 共享（Shared）：

  • 可能性： 共享單車、共享汽車、共乘服務等，提高資源利用率，減少交通擁擠與碳排放。
  • 倫理考量：
    • 公平性與可及性： 服務是否在所有地區（包括低收入或偏遠地區）都易於取得？

這題主要探討「長尾理論」（Long-Tail Theory）的概念，以及它與推薦系統（Recommender Systems）的關聯性。同時，也要求提出處理推薦系統中「新物品」（New Items）與「新用戶」（New Users）問題的解決方案。

核心觀念： 長尾理論、推薦系統、冷啟動問題（Cold-Start Problem）。

第一部分：長尾理論與推薦系統的關聯

• 長尾理論（Long-Tail Theory）：

  • 定義： 由克里斯·安德森（Chris Anderson）提出，描述在某些市場或產品分佈中，少數熱門產品（頭部，Head）雖然銷售量或受歡迎程度很高，但大量長尾的、非熱門的產品（尾部，Tail）加起來的總市場份額，可能與熱門產品相當甚至更大。
  • 關鍵特徵： 總體需求曲線呈現「頭部」高而窄，「尾部」低而長。長尾的出現得益於網路技術的發展，降低了搜尋、儲存和分銷成本，使得原本難以接觸的利基市場得以顯現。
  • 應用場景： 電子商務（Amazon、Netflix）、串流媒體、線上內容平台等。

• 長尾理論與推薦系統的關聯：

  • 商品庫存的多樣性： 推薦系統的目標之一是幫助用戶發現他們可能感興趣但卻不知道的物品。長尾理論恰恰說明了存在大量「非熱門」但有潛在價值的物品。
  • 滿足個性化需求： 推薦系統能夠有效地連結用戶的個性化偏好與長尾中的海量物品。對於那些不喜歡大眾熱門商品的用戶，推薦系統能將他們引導至長尾中的獨特商品。
  • 商業價值： 推薦系統透過挖掘長尾中的潛在需求，可以顯著提升非熱門商品的銷售額與平台的整體利潤，實現「人人都有機會被看見」的商業模式。
  • 提升用戶體驗： 幫助用戶擺脫「選擇困難症」，在海量資訊中快速找到符合個人口味的內容，從而提高用戶滿意度和黏著度。

第二部分：推薦系統處理新物品與新用戶問題的模型與解決方案

「新物品」與「新用戶」問題，在推薦系統領域通常被稱為「冷啟動問題」（Cold-Start Problem）。這是因為推薦系統的許多演算法（如協同過濾）依賴於用戶的歷史行為或物品的歷史評價來進行推薦，而新加入的用戶或物品缺乏這些數據。

1. 處理新物品（New Items）的解決方案：

• 基於內容的推薦（Content-Based Filtering）：

  • 模型： 利用物品本身的屬性（如電影的類型、演員、導演；商品的類別、品牌、規格；文章的主題、關鍵字）來進行推薦。
  • 解決方案： 當新物品出現時，只要能提取其內容特徵，就可以將其推薦給與這些特徵相似的用戶。例如，一部新上映的科幻電影，可以推薦給過去喜歡科幻電影的用戶。
  • 優點： 不受用戶行為數據限制，適用於新物品。
  • 缺點： 推薦結果可能不夠多樣化，用戶容易被侷限在已知的興趣範圍內，難以發現全新的興趣。

• 混合推薦（Hybrid Approaches）：

  • 模型： 將基於內容的推薦與其他方法（如協同過濾）結合。
  • 解決方案： 對於新物品，初期可以主要依賴內容特徵進行推薦。隨著物品獲得越來越多的用戶互動數據，再逐步引入協同過濾等方法。
  • 優點： 結合了不同方法的優勢，能更有效地處理冷啟動問題。

這題探討在數位商業環境中，組織如何整合不同技術元件以建立獨特的系統，並詢問定義「元件效能如何貢獻於整體系統效能」的「合成函數」（Synthesis Function）可能有哪些主要形式。

核心觀念： 系統整合、效能評估、函數模型、關鍵績效指標（KPI）。

解題思路：
首先，需要理解「合成函數」在此情境下的意義，即它是一個數學或邏輯模型，用來描述單一元件的效能如何影響或決定整體系統的效能。接著，思考在不同類型的系統整合中，元件之間的關係可能呈現哪些數學或邏輯上的組合方式。

詳細闡述：

「合成函數」 $S(c_1, c_2, ..., c_n)$ 描述了 $n$ 個技術元件 $c_1, c_2, ..., c_n$ 的效能（performance）如何組合，以產生整體系統效能 $S$。這裡的效能可以是指速度、準確性、穩定性、成本效益等任何可量化的指標。

以下是合成函數可能採取的幾種主要形式：

1. 加法模型 (Additive Model)：

   • 形式： $S = w_1 \cdot P(c_1) + w_2 \cdot P(c_2) + ... + w_n \cdot P(c_n)$
   • 說明： 總體系統效能是各個元件效能的加權總和。 $P(c_i)$ 代表元件 $c_i$ 的效能值，而 $w_i$ 是權重，表示該元件效能對整體系統的影響力大小。
   • 應用情境： 當元件的貢獻是獨立且可疊加的。例如，一個網站的總體載入速度，可能部分取決於伺服器回應速度、部分取決於前端渲染速度、部分取決於網路傳輸速度。這些因素在一定程度上可以獨立加總來估算總體速度。
   • 優點： 簡單直觀，易於計算和理解。
   • 缺點： 忽略了元件之間的交互作用（Interactions）。

2. 乘法模型 (Multiplicative Model)：

   • 形式： $S = P(c_1) \cdot P(c_2) \cdot ... \cdot P(c_n)$ （或帶有權重 $S = P(c_1)^{w_1} \cdot P(c_2)^{w_2} \cdot ... \cdot P(c_n)^{w_n}$）
   • 說明： 總體系統效能是各個元件效能的乘積。這種模型常用於表示「瓶頸效應」（Bottleneck Effect），即任何一個元件效能極低，都可能嚴重拖累整體系統。
   • 應用情境： 許多流程的總體效率是所有步驟中最低效率步驟的函數。例如，生產線的產出速度，取決於最慢的那個工站；一個軟體系統的響應時間，可能受限於最慢的資料庫查詢。
   • 優點： 能有效模擬瓶頸現象，體現了元件之間相互依賴和制約的關係。
   • 缺點： 當某個元件效能為零時，整體系統效能也為零，可能過於極端；對數值變化較敏感。

3. 最大值/最小值模型 (Max/Min Model)：

   • 形式：

這題要求為一個大學餐廳開發的行動應用程式（Mobile Application）繪製「用例圖」（Use Case Diagram）和「資料流程圖」（Data Flow Diagrams, DFDs），並說明設計邏輯所需的假設。這是一個典型的系統分析與設計問題，考察對使用者需求、系統功能、資料流動的理解。

核心觀念： 系統分析、用例圖、資料流程圖、系統設計假設。

解題思路：

1. 理解需求： 仔細分析題目中描述的餐廳應用程式功能：訂單處理、收據生成、廚房溝通、管理報告。
2. 識別參與者（Actors）： 確定與系統互動的主要使用者角色。
3. 繪製用例圖： 根據功能需求，識別並繪製主要的用例（Use Cases），並連接參與者。
4. 繪製資料流程圖： 選擇一個或多個關鍵用例（如訂單處理），描繪資料在系統內部的流動路徑，包括資料來源、去向、處理過程以及儲存。通常會從 Level 0 DFD 開始，然後可能擴展到 Level 1 DFD。
5. 闡述設計假設： 思考為了完成圖示和設計，需要做出的合理假設。

---

A. 設計邏輯與必要假設

在繪製圖示之前，我們需要先提出一些基本假設，這些假設將指導我們的設計：

1. 參與者角色假設：

   • 顧客 (Customer)： 餐廳的學生與教職員，他們是應用程式的主要使用者，負責下訂單、付款。
   • 餐廳員工 (Restaurant Staff)： 包括服務人員（接收訂單、確認訂單）和廚房人員（接收訂單、準備餐點）。
   • 餐廳管理者 (Restaurant Manager)： 負責查看報告、管理菜單、處理設定等。
   • 系統 (System)： 指的是開發中的行動應用程式本身，它是一個處理資訊的邏輯實體。

2. 功能性假設：

   • 訂單處理 (Order Processing)： 顧客能夠瀏覽菜單、選擇餐點、加入購物車、提交訂單、並進行線上支付。系統會將訂單發送到廚房。
   • 收據生成 (Receipt Generation)： 訂單確認後，系統自動生成電子收據，並可供顧客查看或下載。
   • 廚房溝通 (Kitchen Communication)： 廚房員工能夠接收到新的訂單，更新訂單狀態（如準備中、已完成）。
   • 管理報告 (Management Reporting)： 管理者能夠獲取關於銷售額、熱銷商品、訂單量等數據的報告。
   • 菜單管理 (Menu Management)： 管理者可以新增、修改、刪除菜單項目及其價格、描述、圖片等。
   • 用戶管理 (User Management)： 系統需要管理顧客和員工的帳戶。

3. 技術與環境假設：

   • 行動應用程式平台： 應用程式將部署在常見的行動平台（如 iOS, Android）。
   • 後端伺服器： 存在一個後端伺服器來處理業務邏輯、資料儲存與 API 服務。
   • 資料庫： 存在一個資料庫來儲存菜單、訂單、用戶、報告等資料。
   • 支付閘道： 系統需要與一個或多個線上支付服務整合。
   • 網路連線： 顧客、員工和管理者需要穩定的網路連線才能使用應用程式。
   • 硬體： 廚房需要有接收訂單的裝置（如平板電腦或顯示器）。

---

B. 用例圖 (Use Case Diagram)

graph TD
    actor Customer
    actor RestaurantStaff
    actor RestaurantManager

    subgraph University Restaurant App
        UC1[Place Order]
        UC2[View Menu]
        UC3[Make Payment]
        UC4[View Receipt]
        UC5[Receive Order]
        UC6[Update Order Status]
        UC7[Generate Reports]
        UC8[Manage Menu]
        UC9[Manage Users]
    end

    Customer --|> UC1
    Customer --|> UC2
    Customer --|> UC3
    Customer --|> UC4

    UC1 ..> UC2 : include
    UC1 ..> UC3 : include
    UC1 ..> UC4 : include
    UC1 ..> UC5 : extend (e.g., for kitchen staff)

    RestaurantStaff --|> UC5
    RestaurantStaff --|> UC6

    RestaurantManager --|> UC7
    RestaurantManager --|> UC8
    RestaurantManager --|> UC9
    RestaurantManager --|> UC2 : (for menu preview)

    UC5 ..> UC6 : include

用例圖說明：

• 參與者 (Actors)：

  • Customer: 顧客（學生、教職員）
  • RestaurantStaff: 餐廳員工（前台服務、廚房人員）
  • RestaurantManager: 餐廳管理者

• 用例 (Use Cases)：

  • View Menu: 瀏覽菜單
  • Place Order: 下訂單 (包含選擇餐點、加入購物車)
  • Make Payment: 進行支付
  • View Receipt: 查看收據
  • Receive Order: 廚房接收訂單
  • Update Order Status: 更新訂單狀態（如「準備中」、「已完成」）
  • Generate Reports: 生成管理報告
  • Manage Menu: 管理菜單（增刪改查）
  • Manage Users: 管理用戶（可能包括顧客和員工帳戶）

• 關係 (Relationships)：

  • --|>: 關聯 (Association)
  • ..> include: 包含 (Include) - 表示一個用例的功能一定包含另一個用例的功能。例如，下訂單 (Place Order) 必定包含瀏覽菜單 (View Menu)、進行支付 (Make Payment) 和查看收據 (View Receipt)。
  • ..> extend: 擴展 (Extend) - 表示一個用例的功能在特定條件下可以擴展到另一個用例。這裡用 Place Order 擴展到 Receive Order，表示下單成功後，廚房才會收到訂單。

---

C. 資料流程圖 (Data Flow Diagrams - DFDs)

我們將繪製一個 Level 0 DFD (上下文圖) 和一個 Level 1 DFD (核心功能，例如訂單處理)。

Level 0 DFD (Context Diagram)：