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

本題主要探討軟體開發中的「金絲雀」模式、常見的軟體架構模式、以及領域驅動設計 (DDD) 在敏捷開發中的應用與限制。

(a) 「金絲雀」模式在 IT 產業的意義

「金絲雀」模式（Canary Release）是一種軟體部署策略，源自於過去礦工會將金絲雀帶入礦坑，以偵測一氧化碳等有毒氣體。在 IT 產業中，這個概念被延伸用來描述一種循序漸進、風險可控的發布新版本軟體的方式。

• Canary Development (金絲雀開發)： 指的是在開發階段就採用類似的策略，例如，開發團隊可以先針對一小部分的用戶或功能進行測試，收集反饋後再逐步擴大。這有助於在早期發現潛在問題。
• Canary Testing (金絲雀測試)： 這是指在部署新版本的軟體到生產環境時，僅將新版本部署給一小部分的用戶（例如 1% 或 5% 的用戶），同時讓大部分用戶繼續使用舊版本。透過監控這一小部分用戶的使用情況，來評估新版本的穩定性、效能和用戶體驗。如果新版本表現良好，則逐步增加使用新版本的用戶比例；若出現問題，則可以快速回滾到舊版本，將影響範圍最小化。
• Canary Solutions (金絲雀解決方案)： 這是一個更廣泛的概念，可以指任何利用金絲雀模式來降低風險、驗證想法或收集數據的解決方案。例如，在雲端服務中，可以透過 A/B 測試、灰度發布 (Gray Release) 等方式來實現金絲雀式的服務部署和驗證。Kayenta 工具就是一個自動化金絲雀分析的例子，它能整合多種監控工具，協助判斷新版本是否可以安全地全面推廣。

核心精神都是：以小規模、受控的方式進行測試和部署，以最小化風險並最大化學習和驗證的效率。

(b) MVC, MVP, and MVVM 軟體架構模式的解釋與比較

這三種都是常見的軟體架構模式，旨在將應用程式的關注點分離 (Separation of Concerns)，特別是將使用者介面 (UI) 與業務邏輯 (Business Logic) 分開，以提高程式碼的可維護性、可測試性和可重用性。

• Model-View-Controller (MVC)

  • Model (模型)： 代表應用程式的數據和業務邏輯。它負責管理數據，包括數據的獲取、儲存、更新以及對數據變更的通知。Model 不知道 View 或 Controller 的存在。
  • View (視圖)： 負責顯示數據給使用者，並接收使用者的輸入。View 通常會監聽 Model 的變化，並在 Model 更新時自動更新自己的顯示。View 不直接與 Model 互動，而是透過 Controller。
  • Controller (控制器)： 作為 Model 和 View 之間的橋樑。它接收使用者的輸入，並根據輸入來更新 Model 或選擇要顯示的 View。Controller 協調 Model 和 View 之間的互動。
  • 優點： 關注點分離良好，易於團隊協作，Model 和 View 可重用性高。
  • 缺點： 在複雜的應用程式中，Controller 可能會變得非常龐大，難以管理。View 和 Model 之間的耦合有時會顯得不夠清晰。

• Model-View-Presenter (MVP)

  • Model (模型)： 與 MVC 中的 Model 類似，處理數據和業務邏輯。
  • View (視圖)： 負責 UI 的顯示。與 MVC 不同的是，MVP 的 View 通常是一個介面 (Interface)，它定義了如何顯示數據和接收用戶事件。View 盡可能地保持「傻瓜化」(Passive View)，只負責 UI 的呈現，不包含任何業務邏輯。View 實現了 Presenter 所需的介面。
  • Presenter (演示者)： 充當 Model 和 View 之間的經紀人。Presenter 負責從 Model 獲取數據，並將其格式化後傳遞給 View 顯示。Presenter 也負責處理來自 View 的用戶事件，並更新 Model。Presenter 和 View 之間是緊密耦合的，Presenter 持有 View 的引用（通常是介面）。
  • 優點： View 與 Model 的耦合更低，因為 View 不直接與 Model 互動。Presenter 包含了 UI 邏輯，使得 View 更容易測試（因為 View 只是介面，可以被 Mock）。
  • 缺點： Presenter 可能會變得很大，類似 MVC 中的 Controller。View 和 Presenter 之間耦合緊密。

• Model-View-ViewModel (MVVM)

  • Model (模型)： 與 MVC 和 MVP 中的 Model 類似。
  • View (視圖)： 負責 UI 的顯示。View 與 ViewModel 之間通常透過數據綁定 (Data Binding) 和命令 (Commands) 來進行互動。View 知道 ViewModel 的存在，但 ViewModel 不知道 View 的存在。
  • ViewModel (視圖模型)： 充當 View 和 Model 之間的媒介，但更側重於為 View 準備數據。ViewModel 暴露數據給 View，並且可以接收來自 View 的命令。ViewModel 處理業務邏輯和 UI 狀態。它通常不直接持有 View 的引用，而是透過數據綁定機制與 View 互動。
  • 優點： 數據綁定大大簡化了 UI 的更新，減少了手動 DOM 操作。ViewModel 與 View 的解耦程度更高，提高了可測試性。適合使用現代 UI 框架（如 WPF, UWP, Xamarin, Vue.js, React 等）。
  • 缺點： 對於初學者來說，數據綁定的概念可能較難理解。在某些情況下，ViewModel 也可能變得龐大。

比較總結：

特性	MVC	MVP	MVVM
核心	Controller 協調 Model 和 View	Presenter 協調 Model 和 View	ViewModel 為 View 準備數據，透過數據綁定互動
View	知道 Model，透過 Controller 互動	Passive View，僅負責顯示，不處理邏輯	知道 ViewModel，透過數據綁定互動
互動	Controller 接收輸入，更新 Model/View	Presenter 接收輸入，更新 Model，更新 View	View 透過命令觸發 ViewModel，ViewModel 更新數據
解耦	Model/View 可重用，Controller 可能龐大	View/Model 解耦，Presenter/View 耦合緊密	View/ViewModel 解耦程度高，ViewModel/Model 耦合
測試	Model 易測，View/Controller 較難測	View (介面) 易測，Presenter 易測	ViewModel 易測，View 依賴數據綁定
應用	Web 框架 (Rails, Django)	Android (早期), .NET WinForms	WPF, UWP, Xamarin, Vue.js, React

(c) 在 Scrum 或 Kanban 中實施領域驅動設計 (DDD)

領域驅動設計 (DDD) 是一種軟體開發方法論，強調將開發團隊的注意力集中在核心業務領域 (Domain) 上，並將複雜的業務邏輯建模為軟體設計的核心。與敏捷方法（如 Scrum 和 Kanban）結合使用，可以提升軟體品質和對業務價值的響應速度。

核心 DDD 概念：

• Domain (領域)： 軟體所要解決的業務問題範圍。
• Ubiquitous Language (通用語言)： 在領域專家和開發團隊之間建立一套共享的、精確的詞彙，用於討論和設計系統。
• Bounded Context (限界上下文)： 將大型領域劃分為更小、更易於管理的子領域，每個子領域都有自己的通用語言和模型。
• Aggregates (聚合)： 一組相關領域物件的集合，被視為一個單一的單元，有一個根實體 (Aggregate Root) 來管理對聚合內其他物件的訪問。
• Entities (實體)： 具有唯一身份標識的物件。
• Value Objects (值物件)： 描述屬性，沒有唯一身份，由其屬性定義。
• Domain Events (領域事件)： 表示領域中發生的重要事件。

在 Scrum 中實施 DDD：

1. 產品待辦清單 (Product Backlog) 建立與細化：

   • 領域專家參與： 確保產品負責人 (Product Owner) 或其他領域專家積極參與，共同定義和細化 Product Backlog 中的 User Stories。
   • 通用語言應用： 在 User Stories 的描述、Acceptance Criteria 中，積極使用通用語言。
   • 限界上下文識別： 在 Product Backlog 中，可以開始識別不同的限界上下文，並將 User Stories 分配到相應的上下文中。
   • DDD 概念融入： 針對複雜的業務功能，Product Backlog Item 可以直接指向或描述需要 DDD 模式（如 Aggregates, Entities, Value Objects）來解決的問題。

2. Sprint 規劃 (Sprint Planning)：

   • 聚焦核心領域： 團隊應優先處理那些對業務價值影響最大的 User Stories，這些通常

本題探討「數位符徵」(Digital Affordance) 的概念，並要求提出一個結合數位符徵與「詩意棲居」(Poetic Dwelling) 的組織環境解決方案。

數位符徵 (Digital Affordance) 的定義與解釋

「數位符徵」是從心理學家 James J. Gibson 提出的「符徵」(Affordance) 概念延伸而來，並由 Don Norman 等人進一步推廣至設計領域。

• 符徵 (Affordance)： 指的是一個物體或環境所提供的、可被使用者感知並利用的「行動機會」。例如，一個門把的形狀和位置，就「提供」了握住並轉動以開門的符徵。符徵不是物體的屬性，而是物體與使用者之間的關係。
• 數位符徵 (Digital Affordance)： 則是數位產品、介面或系統所提供的、可被使用者感知並利用的「數位行動機會」。它描述了數位物件如何「邀請」或「促使」使用者進行特定的互動。數位符徵存在於數位介面設計中，影響使用者如何感知和使用數位工具。
  • 可感知性 (Perceivability)： 好的數位符徵應該讓使用者能夠輕易地感知到可以進行哪些互動。例如，按鈕的視覺設計（顏色、陰影、形狀）暗示了它可以被點擊。
  • 可用性 (Usability)： 符徵提供的行動機會應該是使用者可以實際執行且有意義的。
  • 情境性 (Contextual)： 數位符徵的意義和可用性也取決於使用者的技能、目標和所處的數位或實體情境。

例如：

• 一個清晰的「下載」按鈕，提供使用者點擊以下載文件的符徵。
• 超連結的下劃線和顏色，提供使用者點擊以導向新頁面的符徵。
• 社交媒體上「讚」或「分享」的圖標，提供使用者表達認同或擴散內容的符徵。

「詩意棲居」(Poetic Dwelling) 的概念

「詩意棲居」源自哲學家 Martin Heidegger 的概念，強調人與環境之間的一種深刻、有意義、情感上連結的共存狀態。它不僅僅是物理上的存在，更是一種精神上的歸屬感、安全感和對生活品質的追求。在數位環境中，這意味著數位空間不僅能滿足功能性需求，還能提供情感上的連結、個人表達的空間，以及一種令人愉悅、能啟發靈感的體驗。

組織環境中結合「數位符徵」與「詩意棲居」的解決方案

情境設定： 一個大型企業的內部知識管理平台。

目標： 創建一個既能高效支持員工獲取和分享知識（數位符徵），又能讓員工感受到歸屬感、被重視，並能從中獲得啟發和愉悅（詩意棲居）的數位環境。

解決方案：

1. 打造直觀且具啟發性的知識探索介面 (數位符徵)：
   • 視覺化知識圖譜： 使用互動式的知識圖譜 (Knowledge Graph)，讓員工可以透過視覺化的方式探索不同知識點之間的關聯。節點的大小、顏色、連接線的粗細都可以設計成「符徵」，提示知識點的熱度、重要性或關聯強度，引導使用者進行深入探索。
   • 個性化推薦引擎： 根據員工的職位、興趣、過去的貢獻和瀏覽記錄，提供個性化的知識推薦。

本題探討了網路中立性、賽局理論在資訊系統研究中的應用，以及 SQL 查詢。

(a) 網路中立性 (Net Neutrality)

• 網路中立性是什麼？
  網路中立性是指網際網路服務供應商 (ISP) 必須平等對待所有網際網路流量，不得對特定網站、應用程式或服務進行封鎖、節流 (throttling) 或提供優先通道 (paid prioritization)。簡單來說，就是 ISP 不能歧視或偏袒任何網路內容或服務提供者。

• 支持 Netflix 還是 SK Broadband？
  這個問題的立場可以從不同角度分析：

  • 支持 Netflix：

    • 用戶權益： Netflix 作為內容提供者，希望其服務能被平等傳輸，用戶能以最佳體驗觀看。網路中立性保障了用戶的選擇權，不會因為 ISP 的商業考量而影響其觀看品質。
    • 創新與競爭： 網路中立性有助於新創公司和小型內容提供者與大型公司公平競爭，因為它們的服務不會因為 ISP 的「收費」或「封鎖」而處於劣勢。
    • 開放網路原則： 維護網路的開放性，防止 ISP 成為網路內容的守門人。

  • 支持 SK Broadband (或 ISP 的立場)：

    • 基礎設施投資： ISP 投入巨資建設和維護網路基礎設施。他們認為，消耗大量頻寬的內容提供者（如 Netflix）應當對其產生的網路流量成本做出貢獻，以支持 ISP 的基礎設施升級和營運。
    • 網路管理： ISP 需要管理網路擁塞，確保整體網路的穩定性。在網路流量高峰期，他們可能需要有能力對高流量服務進行適當的流量整形或管理。
    • 商業模式創新： ISP 也希望探索新的商業模式，例如與內容提供者合作，提供優質內容傳輸的保證。

  我的立場： 我會支持網路中立性。
  理由如下：

  1. 用戶體驗與選擇權： 網路中立性是保障用戶能夠自由、平等地訪問所有網路內容的基石。用戶不應因為 ISP 的商業利益而犧牲其觀看品質或選擇權。
  2. 促進創新與公平競爭： 網路的開放性是數位經濟發展的動力。如果 ISP 可以對流量進行差別對待，將會扼殺創新，使大型平台壟斷優勢加劇，小型創業者難以進入市場。
  3. 避免 ISP 成為審查者： 如果 ISP 可以控制哪些內容傳輸更快、哪些更慢，他們就擁有巨大的權力，可能被濫用來限制言論自由或推廣自身利益相關的內容。

• 可能的擔憂與台灣的解決方案：

  • 擔憂：

    • 網路品質下降： 如果 ISP 無法從高流量內容提供者那裡獲得足夠的回報，可能影響其對基礎設施的投資意願，長期來看可能導致網路整體品質下降。
    • 內容提供者成本轉嫁： ISP 可能會將對內容提供者的收費壓力，轉嫁到用戶身上（例如提高訂閱費用）。
    • 監管的模糊性： 如何界定「公平」的流量管理與「歧視性」的流量管理，以及如何有效監管，是一個挑戰。

  • 台灣的解決方案建議：
    台灣目前實施的是相對寬鬆的網路中立性原則，NCC（國家通訊傳播委員會）有相關規範，但對於 ISP 的「網路管理」和「付費優先」的界線仍有討論空間。

    1. 明確法規定義與界線：
       • 強化網路中立性法規： 參考國際上較為嚴格的網路中立性法規，明確定義 ISP 不得進行的行為，例如：禁止封鎖、限制或降速特定內容服務；限制 ISP 採取「付費優先」的商業模式。
       • 定義「合理網路管理」： 允許 ISP 在必要時進行網路管理，但必須符合透明、非歧視、且有助於整體網路穩定性的原則。例如，在網路擁塞時，對所有高流量服務進行同等程度的速率限制，而非針對特定服務。
    2. 建立透明度機制：
       • ISP 資訊公開： 要求 ISP 定期公開其網路流量管理政策、使用的技術、以及與內容提供者的合作協議。
       • 用戶監測工具： 推廣或開發用戶端工具，讓用戶可以自行檢測其網路連線的實際速度和延遲，並與 ISP 的承諾進行比對。
    3. 鼓勵 ISP 與內容提供者協商：
       • 促進公平協商： 在保障網路中立性的前提下，鼓勵 ISP 與大型內容提供者（如 Netflix）進行商業協商，尋找互利的合作模式，例如 CDN 節點部署、流量交換等，以分攤網路壓力。但此類協商的結果不得損害用戶權益或其他小型內容提供者的利益。
    4. 加強監管與執法：
       • NCC 角色： NCC 應扮演積極的監管者角色，主動監測市場動態，受理用戶申訴，並對違規 ISP 進行嚴格處罰。
       • 消費者保護： 加強對消費者的網路中立性教育，讓用戶了解自己的權利。

  總結台灣的解決方案： 台灣應在現有基礎上，進一步強化網路中立性法規的明確性與執行力，要求 ISP 提高營運透明度，並在保障用戶權益和網路開放性的前提下，尋求 ISP 與內容提供者之間更為健康的商業合作模式。

(b) 資訊系統 (IS) 研究中的賽局理論 (Nash Equilibrium) 應用

• 研究問題舉例：
  研究問題： 在電子商務平台中，買家和賣家之間資訊不對稱所導致的「逆向選擇」(Adverse Selection) 問題，如何透過平台設計（例如信譽評級系統、押金機制）來達到一個接近納許均衡的穩定狀態，從而提升平台的整體交易效率和用戶信任度？

• 為何重要？

  1. 解決資訊不對稱問題： 許多資訊系統的應用，如電子商務、線上拍賣、共享經濟平台、線上社交網絡等，都面臨買賣雙方資訊不對稱的問題。例如，在二手車交易中，賣家比買家更了解車況；在線上評價中，消費者難以判斷評價的真實性。這會導致「檸檬市場」(Lemons Market) 現象，即高品質產品被劣質產品驅逐，整體市場效率降低。
  2. 提升平台設計與策略： 賽局理論，特別是納許均衡的概念，提供了一個分析參與者（買家、賣家、平台本身）之間策略互動的框架。透過分析不同平台設計（如：
     • 信譽系統 (Reputation Systems)： 如何設計評分機制、累積信譽值、以及如何防止刷分行為，使其能真實反映賣家品質。
     • 押金或保證金機制 (Deposit/Escrow Mechanisms)： 如何設定押金金額，使其足夠約束不良行為，同時又不至於過度增加守約者的成本。