107 高普考高考三級 資訊處理 系統專案管理 考古題詳解

核心觀念

本題評量重點為物件導向系統分析與設計中的逆向工程（Reverse Engineering）​能力，即將實體程式碼（Java Source Code）抽象化還原為 UML 類別圖（Class Diagram）。核心評量觀念包含：

1. 類別結構（Class Structure）之三層表示法：

• 頂層：類別名稱（Class Name）。
• 中層：屬性區（Attributes），語法格式為 可見度 名稱 : 型態 [= 預設值] [{特性標籤}]。
• 底層：操作／方法區（Operations/Methods），語法格式為 可見度 名稱(參數名稱 : 參數型態, ...) : 回傳型態。

2. 可見度符號（Visibility）之對應：

• +：public（公有）
• -：private（私有）
• #：protected（保護）
• ~：package-private（套件私有／Java 未宣告修飾詞之預設權限）

3. 修飾詞轉換：

• Java 的 final 欄位（不可修改之變數）在 UML 中以特性標籤 {readOnly} 或 {frozen} 標記。

4. 類別間關係（Relationships）之判別：

• 一般化／繼承（Generalization）：程式碼中以 extends 呈現，圖形符號為「實線搭配指向父類別的空心三角形」。
• 關聯（Association）：類別間持有彼此的物件參考（Reference）。若兩類別互持參考，則形成雙向關聯（Bidirectional Association），應標註關聯端之角色名稱（Role Name）與多重度（Multiplicity）。

---

解題方法

進行逆向工程時，採「由單元至整體」的三步解析法：

步驟一：個別類別的屬性與方法剖析

1. Customer 類別：

• 屬性：
• name：私有字串 $\rightarrow$ - name : String
• address：私有字串 $\rightarrow$ - address : String
• phoneNumber：私有字串 $\rightarrow$ - phoneNumber : String
• carList：預設可見度（無修飾詞，即 Package-private），型態為 ArrayList<Car>。在 UML 中，此類持有其他實體物件的集合，可於屬性區標示為 ~ carList : ArrayList<Car>，亦可抽離並轉化為對 Car 的關聯線端點角色。
• 方法：無自訂方法。

2. Car 類別：

• 屬性：
• model：私有字串 $\rightarrow$ - model : String
• carPrice：私有浮點數，預設值為 $0.0$ $\rightarrow$ - carPrice : double = 0.0
• speed：保護型整數，預設值為 $0$ $\rightarrow$ # speed : int = 0
• owner：私有之 Customer 參考 $\rightarrow$ - owner : Customer（亦可轉化為對 Customer 關聯線端點之角色）。
• 方法：
• getModel：公有，無參數，回傳字串 $\rightarrow$ + getModel : String
• setModel(String model)：公有，接收字串參數，無回傳值 $\rightarrow$ + setModel(model : String) : void
• getSpeed：公有，無參數，回傳整數 $\rightarrow$ + getSpeed : int
• accelerate(int acc)：公有，接收整數參數，無回傳值 $\rightarrow$ + accelerate(acc : int) : void

3. Compact 類別：

• 繼承自 Car（extends Car）。
• 屬性：
• num_door：公有、型態為整數、初值為 $2$，且宣告為 final（常數屬性）$\rightarrow$ + num_door : int = 2 {readOnly}。
• 方法：無自訂方法。

步驟二：辨識類別間的關聯結構與多重度

1. Compact 與 Car：

• 關鍵字為 extends，屬於一般化（Generalization）。
• 連線方式：由子類別 Compact 連向父類別 Car，端點為空心三角箭頭。

2. Customer 與 Car：

• Customer 內部宣告 ArrayList<Car> carList，代表一名顧客可擁有多輛汽車（多重度為 $0..*$）。
• Car 內部宣告 private Customer owner，代表一輛汽車擁有單一車主（多重度為 $0..1$ 或 $1$）。
• 兩者構成雙向關聯（Bidirectional Association）。在關聯線兩端標記端點角色名稱（carList 與 owner）及多重度（Multiplicity），此為物件導向正規設計之標準作法。

---

核心觀念

本題測驗限制理論（Theory of Constraints, TOC）引申於專案管理領域之關鍵鏈專案管理法（Critical Chain Project Management, CCPM），由高德拉特（Eliyahu M. Goldratt）於其著作《關鍵鏈》中所提出。核心概念涵蓋：

1. 傳統要徑法（CPM）的缺失：傳統排程僅考量「工作邏輯相依性」，未納入「資源限制」，且個別工作常因估算安全時間過度，導致「學生症候群」（Student Syndrome，不到最後關頭不動手）與「帕金森定律」（Parkinson's Law，工作膨脹填滿所有可用時間），造成資源浪費與工期延宕。
2. 關鍵鏈（Critical Chain）之定義：專案排程中，同時考量「技術邏輯相依性」與「有限資源相依性」​後所決定的最長工作序列，是專案時程的最主要瓶頸（Constraint）。
3. 緩衝集中管理（Aggregated Buffer Management）：CCPM 要求將各活動原先寬鬆的預估工期壓縮至 $50\%$ 的可能工期（積極目標工期），並將抽出的安全時間集中放置於關鍵位置形成「緩衝（Buffer）」，以機率統計方式吸收變異，達成專案交期保護。

---

解題方法

本題為標準的觀念闡述型申論題。解題切入點應分為兩層次：

1. 破題界定：簡明點出關鍵鏈排程的核心邏輯——「去局部安全時間，採整體集中緩衝」。
2. 三項緩衝之逐項對稱剖析：針對題目要求的「專案緩衝」、「進入緩衝」、「資源緩衝」，嚴格按照​「加入時機（Placement）」​與​「加入目的（Purpose）」​雙維度平行對比陳述。
3. 答題結構設計：採條列分點，並搭配比較總結表，讓閱卷委員能於 $10$ 秒內掌握全部關鍵字（如：保護整體交期、保護關鍵鏈啟動、確保關鍵資源準時就位）。

---

選項分析（評分構面解析）

本題為高考三級申論題（非選擇題），依國家考試評分規程，閱卷評分重點拆解為三大評分向度：

1. 評分向度一：專案緩衝（Project Buffer, PB）

• 時機：位於關鍵鏈路徑的「最後一項工作之後」、專案承諾交付的「最終完成日之前」。
• 目的：作為整座專案的防波堤，吸收關鍵鏈上所有活動累積的進度延遲，確保專案整體交期承諾不被突破。

2. 評分向度二：進入緩衝（Feeding Buffer, FB，又稱接合緩衝）

• 時機：位於「非關鍵鏈路徑」銜接至「關鍵鏈路徑」的交會接合點處。
• 目的：保護關鍵鏈不受非關鍵鏈工作延宕的干擾，防止支線延遲外溢推遲關鍵鏈工作的預定啟動時程。

3. 評分向度三：資源緩衝（Resource Buffer, RB）

• 時機：設置於「關鍵鏈活動即將使用關鍵資源」之前的一定時點（實質上為排程警示訊號）。
• 目的：確保關鍵資源（稀缺設備、專業人員）在關鍵鏈活動開始時能完全就位，避免因「人等工作」或「工作等人」造成關鍵鏈停滯。

---

解題技巧

核心觀念

本題評量國際標準軟體規模度量技術——功能點分析法（Function Point Analysis, FPA），其標準由國際功能點使用者團體（IFPUG）制定，並經國際標準化組織認可為 ISO/IEC 20926。

FPA 的核心哲學是從「使用者觀點（User View）」出發，依據系統提供給使用者的業務邏輯與功能需求進行量化，而非依據程式碼行數（LOC）、資料庫實體結構或技術架構等「技術觀點（Technical View）」。其基本功能元件（Base Functional Components, BFC）劃分為兩大類、五種功能型態：

1. 資料功能類（Data Functions）：代表系統提供給使用者儲存與參照的邏輯資料需求，分為內部邏輯檔案（ILF）​與外部介面檔案（EIF）。
2. 交易功能類（Transaction Functions）：代表系統提供給使用者處理資料或控制流程的動態作業需求，分為外部輸入（EI）、外部輸出（EO）​與外部查詢（EQ）。

未調整功能點數（Unadjusted Function Points, UFP）之計算式為： $UFP = \sum_{i=1}^{5} \sum_{j=1}^{3} (W_{ij} \times C_{ij})$ 其中 $W_{ij}$ 為各功能型態在不同複雜度（低、中、高）之權重值，$C_{ij}$ 為計數數量。

---

解題方法

解答本題應採取​「系統邊界（Application Boundary）」​為軸心的結構化分析法：

1. 確立邊界與所有權：判定功能單元是位於受測系統邊界之內或之外，並釐清資料的「維護權責（Maintenance）」歸屬。
2. 區分靜態與動態：

• 靜態資料結構（Data at Rest） $\rightarrow$ 歸入資料功能（ILF、EIF）。
• 動態程序流動（Data in Motion） $\rightarrow$ 歸入交易功能（EI、EO、EQ）。

3. 辨別處理邏輯與主要意圖（Primary Intent）：

• 輸入性交易旨在「改變系統狀態或維護資料」 $\rightarrow$ EI。
• 輸出性交易依據「是否包含計算、衍生資料或狀態變更」 $\rightarrow$ 嚴格區分 EO 與 EQ。

---

功能型態深度剖析

一、資料功能類（Data Function Types）

1. 內部邏輯檔案（Internal Logical File, ILF）

• 定義：在應用程式邊界內部維護，由使用者所識別的一組邏輯上相關的資料或控制資訊。
• 主要目的：透過受測應用程式的一個或多個基本程序（Elementary Processes）來保存與維護資料。
• 判定標準：
• 群組資料必須符合使用者業務邏輯（如「客戶資料」、「訂單主檔」）。
• 該檔案必須在受測系統邊界內被維護（透過新增、修改、刪除等程序）。
• 實例：電商系統中的「會員基本資料表」、「商品目錄檔」。

2. 外部介面檔案（External Interface File, EIF）

• 定義：由受測應用程式所參照（Referenced），但完全在另一個應用程式邊界內部維護，由使用者所識別的一組邏輯上相關的資料或控制資訊。
• 主要目的：存放由其他系統維護、但本系統必須讀取以支援自身業務邏輯的資料。
• 判定標準：
• 群組資料對本系統而言「只能讀取/參照，不可維護」。
• 該檔案必定是另一個系統的 ILF。
• 實例：電商系統串接中華郵政提供的「郵遞區號對照檔」、或參照外部人資系統維護的「員工代碼表」。

---

二、交易功能類（Transaction Function Types）

3. 外部輸入（External Input, EI）

• 定義：由應用程式邊界外部進入內部的一個基本程序，其處理來自外部的資料或控制資訊。
• 主要目的：維護一個或多個 ILF，或改變系統的運作行為（行為控制）。
• 判定標準：
• 資料穿越邊界進入系統。
• 處理邏輯中至少維護了一個 ILF（新增、修改、刪除資料），或者改變了系統狀態。
• 實例：使用者註冊帳號、修改收件地址、後台管理者變更系統參數。

核心觀念

本題評量敏捷軟體開發（Agile Software Development）中最核心的 SCRUM 框架。 考生應掌握 SCRUM 經典的「3-3-5 架構」：

1. 3 大角色（Roles / Accountabilities）：產品負責人（Product Owner, PO）、Scrum 專家／敏捷教練（Scrum Master, SM）、開發團隊（Development Team）。
2. 3 大工件（Artifacts）：產品待辦清單（Product Backlog）、衝刺待辦清單（Sprint Backlog）、增量（Increment）。
3. 5 大活動／事件（Events）：衝刺（Sprint）、衝刺計畫會議（Sprint Planning）、每日立會（Daily Scrum）、衝刺檢視會議（Sprint Review）、衝刺回顧會議（Sprint Retrospective）。

本題著重測驗考生對「角色權責劃分」及「常規活動運作機制」的理解，為高考《系統專案管理》與《系統分析與設計》科目的基礎必考題。

---

解題方法

1. 子題 (一) 切入點（10 分）：

• 採用「權責對稱法」進行闡述。
• 明確指出三種角色：Product Owner、Scrum Master、Development Team。
• 職責說明需切中核心區隔：PO 決定「做什麼（What）」（商業價值與需求優先權）；開發團隊決定「如何做（How）」（技術實作與工作量估算）；SM 負責「如何順暢運作（Process）」（排除障礙、僕人式領導、維護 Scrum 規範）。

2. 子題 (二) 切入點（15 分）：

• 題目要求舉出「3 種在進行中的相關活動」，平均一項配分高達 5 分。
• 建議挑選流程中最具代表性且對比強烈的 3 個會議：衝刺計畫會議（Sprint Planning）、每日立會（Daily Scrum）、以及容易形成對比的衝刺檢視會議（Sprint Review）（或衝刺回顧會議 Sprint Retrospective）。
• 每一項活動的作答結構應統一包含：目的／核心價值、與會人員、進行方式／時間箱（Timebox）、產出結果，結構工整方能拿滿 15 分。

---

選項分析

註：本題為申論題，非選擇題，無選項可供拆解。此處針對閱卷評分點與常見失分爭點進行剖析：

1. 角色替代陷阱（易失分）：

• 考生若將傳統專案管理角色「專案經理（Project Manager, PM）」、「系統分析師（SA）」或「測試工程師（QA）」列入，會被判定未理解 Scrum 精神而嚴重扣分。Scrum 團隊內沒有傳統 PM，PM 的職能被拆解分配給 PO（範圍與價值）與 SM（進度引導與阻礙排除）。

2. 活動混淆陷阱（易失分）：

• 衝刺檢視會議（Sprint Review）與衝刺回顧會議（Sprint Retrospective）性質完全不同：
• Review 是「對外、對產品」：展示可交付的軟體成果，邀請利害關係人反饋產品功能。
• Retrospective 是「對內、對團隊」：檢討團隊合作流程、工具與人際互動，尋求流程改善點。
• 若將兩者合而為一或混淆描述，該活動項目難以獲得滿分。

---

解題技巧

1. 口訣記憶法：

• 角色記「主・僕・工」：產品負責人（商業主導者）、Scrum Master（僕人式領導）、開發團隊（技術工程人員）。
• 職責劃分記「價值－流程－實作」。

2. 答題結構化：

• 子題 (一) 每位角色獨立成段，標註中英文名稱，並條列 2～3 點關鍵職責。
• 子題 (二) 每個活動標出「目的」與「內容」，切忌通篇純敘述而未見到專業名詞（如 Timebox、Product Backlog、User Story 等）。

---

【答案】

(一) SCRUM 的 3 種角色及其職責