核心觀念

本題考查可衡量組織價值（Measurable Organizational Value, MOV）的定義與用途。MOV 是資訊系統專案預期為組織創造的價值，必須能以明確指標衡量，並與組織策略及系統目的相連。它不是系統功能清單，也不等同於專案是否如期、如預算完成。

MOV 的常用描述面向包括：

• 影響範圍（Area of impact）：要影響組織或利害關係人的哪一面向。
• 價值（Value）：預期創造何種價值，例如提升健康知識、增加會員參與或提高營收。
• 衡量指標（Metric）：如何判斷價值是否實現。
• 目標值（Target）：指標要達到的具體程度。
• 時間範圍（Time frame）：何時達成或評估。

好的 MOV 應明確、可衡量、可達成，並具備清楚的衡量期限。題目未提供社團會員數、基準值或預算，因此下列數值設定為合理的專案目標假設；實際規劃時應先盤點基準資料，再與社團確認目標。

解題方法

先把「向社會大眾推廣健康意識」拆成可驗證的成果：會員是否增加、健康資訊是否被閱讀、會員的健康知識或行動是否改善，以及健康食品販售是否帶來可持續的收入。再為各成果指定指標、目標值與期限。

系統功能如會員註冊、健康資訊推播、商品瀏覽與購買，是達成 MOV 的手段；功能上線本身不代表組織價值已經實現。

（一）MOV 定義與表格描述

**系統 MOV：**自網站正式上線日起 12 個月內，透過會員服務與健康資訊推廣，使會員規模及參與度提升，並使會員健康知識有所增進；同時建立可信、可持續的健康食品銷售收入，以支持社團持續推廣健康意識。

上述指標同時衡量健康推廣成果與營運可持續性。商品銷售收入是支持社團使命的手段，不能取代健康知識與會員參與等使命指標；商品推廣內容也應以正確、可信的健康資訊為前提。

（二）MOV 對系統生命週期的主導作用

1. 主導系統規劃

核心觀念

本題考查軟體設計中兩項相互關聯的品質觀點：耦合（Coupling）與內聚（Cohesion）。題目聚焦於耦合，重點是元件彼此依賴的程度，以及如何透過低耦合設計，降低維護成本並提升再利用性。

耦合是指系統中不同模組、類別或元件之間的依賴程度。若一個元件必須了解另一個元件的內部資料、實作細節或運作流程才能完成工作，兩者的耦合程度便較高；若元件只依賴穩定、明確的介面，彼此內部變更不會輕易牽動對方，則耦合程度較低。

一般設計原則是降低耦合、提高內聚。耦合描述元件「彼此之間」的依賴，內聚則描述單一元件「內部各項職責」的關聯性。

解題方法

本題分兩部分作答：

1. 第（一）題先定義耦合，說明它衡量的是元件間依賴程度。
2. 第（二）題以「只依賴必要資訊」為主軸，分別連結迪米特法則與封裝，再推論低耦合對維護及再利用的好處。

不必列舉完整的耦合分類；把「依賴程度」及「依賴對象的內部細節或介面」說清楚，即能切中題旨。

（一）何謂 Coupling？（10 分）

耦合是系統中兩個或多個模組、類別或元件之間的依賴關係及依賴強度。當一個元件的設計、資料或實作方式會影響另一個元件的運作，兩者即存在耦合。

耦合程度越高，通常表示元件間依賴越緊密；其中一個元件改變時，較容易造成其他元件需要配合修改。耦合程度越低，則表示元件間界線較清楚，彼此主要透過明確介面互動，對內部實作細節的依賴較少。

（二）迪米特法則、封裝與耦合對維護及再利用的影響（15 分）

1. 迪米特法則（Law of Demeter）

迪米特法則可概括為：**一個物件只應與其直接的「朋友」交談，不應沿著其他物件逐層取得更深層物件，再呼叫其方法。**朋友通常包括自身、方法參數、自己建立的物件，以及自身所持有的直接成員物件。

例如，若程式以 a.getB.getC.doWork 操作深層物件，呼叫端便同時依賴 a、B 與 C 的物件結構。

第三題

核心觀念

本題考查軟體逆向工程（Software Reverse Engineering, SRE）的定義、工具的輸入與產出，以及如何運用逆向分析支援敏捷開發與系統維護。答題時可依序說明「從既有軟體還原資訊」、「把分析成果回饋開發流程」，最後指出工具產出品質不佳時，如何降低後續維護風險。

SRE 是分析既有軟體，以辨識其元件、結構、設計與行為，並將這些資訊整理成較高抽象層次描述的過程。它通常由實作細節推回設計與架構，並不等同於直接修改或重建系統。

SRE 工具的典型輸入與產出如下：

工具產出是依輸入與分析規則推導出的模型或文件，不應直接視為完整且正確的系統規格；仍須由熟悉業務與系統的人員確認。

解題方法

本題可採「定義與資訊轉換 → 開發流程應用 → 品質風險與治理」的順序作答：

1. 第一小題說明 SRE 是由既有實作推回較高層次的設計或系統知識，再交代工具的輸入與產出。
2. 第二小題把 SRE 產出的結構、相依與文件資訊，連結至敏捷開發的短週期需求、優先排序、迭代實作及快速回饋。
3. 第三小題指出自動分析產出可能不完整、不正確或已過時，並提出驗證、版本管理、追蹤與持續更新措施。

此架構能涵蓋題目要求，也能清楚呈現 SRE 工具如何支援開發，而非把工具本身當成敏捷開發的替代品。

(一) SRE 的意義、工具輸入與產出（10 分）

SRE 是針對既有軟體進行系統性分析，從程式、資料、介面及執行行為中萃取資訊，推知其內部結構、設計決策、元件關係與功能行為，並將資訊重組為較容易理解、維護或再利用的表示方式。其核心方向是由低階實作資訊，推回較高階的設計與架構資訊。

SRE 工具常見功能包括：

1. 靜態分析：不執行程式，檢查程式碼的語法結構、模組、類別、函式及相依關係。
2. 動態分析：執行程式並觀察呼叫、資料流、效能或錯誤行為，以補足靜態分析無法掌握的執行情境。
3. 關係與模型建置：產生呼叫圖、相依圖、資料模型、控制流程或架構視圖。
4. 文件化：將分析結果整理為圖表、清單或可搜尋文件，供設計、開發與維護人員使用。

工具輸入可分為兩類：

• 軟體成品：原始程式碼、執行檔、函式庫、組態檔、資料庫綱要、API 或介面定義。
• 輔助資訊：測試案例、執行紀錄、部署資訊、既有設計文件及業務規則。

工具的產出包括程式與模組結構、相依關係、呼叫路徑、資料流、資料庫與介面模型、架構文件，以及待確認的缺陷、重複程式碼或高風險區域。產出可作為團隊理解既有系統的依據，並供需求分析、估算、測試設計及改版規劃使用。

(二) 運用 SRE 工具讓系統開發更敏捷（10 分）

敏捷開發強調短週期交付、持續回饋、跨職能合作與快速因應變更。SRE 工具可降低理解既有系統所需的時間，讓團隊在有限迭代中更快確認影響範圍、選擇工作項目並驗證改動。

1. 快速掌握既有系統 在新團隊接手、系統改版或新增功能前，使用工具產生模組、資料、介面與相依視圖，協助團隊建立共同的系統認知，減少仰賴少數資深人員口述或逐檔閱讀程式碼。

2. 支援待辦事項排序與估算 將需求連結至受影響的模組、資料表與介面，協助產品負責人與開發團隊辨識影響範圍、技術依賴及高風險工作，據以拆分工作項目、安排先後順序並估算工作量。

3. 促進小步修改與分階段交付 透過呼叫圖、相依圖及資料流分析，找出功能邊界與受影響元件，使團隊能把大型修改拆成可於單一迭代完成、測試及交付的小變更，降低一次性大幅改動的風險。

核心觀念

本題考 UML 系統分析中三類模型的分工，以及如何從使用者的商務流程出發，以使用案例為中心，逐步建立行為描述與物件模型。

• Functional Model（功能模型）：描述系統提供哪些功能，以及功能執行的流程。
• Structural Model（結構模型）：描述系統中的類別、責任與靜態關係。
• Behavioral Model（行為模型）：描述物件或活動如何隨時間互動，以及事件發生的順序。

UML 分類時，應依圖形主要回答的問題判斷：功能模型回答「系統做什麼」；結構模型回答「系統由什麼構成」；行為模型回答「事情如何發生、物件如何互動」。

（一）模型歸屬

（二）發展過程與重複發展的原因

1. 從使用者商務流程辨識使用案例

分析先從使用者的商務流程與工作目標開始，了解參與者（Actor）希望藉由系統完成哪些工作。分析者據此辨識系統邊界、參與者及使用案例（Use Case），並以使用案例表達系統應提供的功能。

使用案例應反映使用者要達成的目標，而不是直接羅列畫面或程式功能。商務流程提供需求背景，使用案例則聚焦在參與者與系統之間的互動。

2. 撰寫 UCD 的 Flow of Events

每個使用案例以 UCD 描述，重點是 Flow of Events，通常包括：

• 前置條件與觸發事件。
• 主要成功流程：參與者與系統依序採取的動作。
• 替代流程與例外流程：例如驗證失敗、資料不存在或使用者取消。
• 後置條件：用例完成後系統狀態或業務結果。

Flow of Events 將商務流程轉化為可分析的系統互動步驟，並作為後續功能模型、行為模型及結構模型的共同依據。

3. 由流程建立 AD 與分析類別