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

核心觀念

本題評量軟體工程中「軟體型態管理」（Software Configuration Management, SCM，亦稱軟體組態管理）的核心機制，重點在於**基準線（Baseline）與軟體型態項目（Software Configuration Item, SCI）**的生命週期控管。

1. 軟體型態項目（SCI）：專案開發過程中產生的各項工作成果（Work Products），包括需求規格書、系統架構設計書、原始碼、測試案例、使用手冊等。
2. 基準線（Baseline）：依據 IEEE 610.12 的定義，基準線是經過正式審查（Formal Review）並獲得各方共識的規格或產品，作為後續開發的基礎。未經正式變更控制程序（Formal Change Control Procedure），任何人不得片面修改已納入基準線的項目。
3. 管理目的：防止專案在多人協作或複雜環境下發生「非預期變更」、「需求蔓延（Scope Creep）」與「版本失控」，確保軟體系統的完整性、可追溯性與可重現性。

---

解題方法

本題為典型兩段式申論題，作答時切入點如下：

1. 第一問（如何透過基準線對 SCI 進行控管）：

• 應從 SCM 的四大核心活動（識別、控制、稽核、狀態回報）切入，聚焦於「變更控制機制」。
• 清楚闡述：SCI 納入基準線前（開發者可自由編輯）與納入基準線後（凍結、簽入受控庫、修改必須經過正式變更審查程序）的差異。
• 具體鋪陳變更管理標準流程：提出變更請求（CR）$\to$ 影響評估 $\to$ 變更控制委員會（CCB）審核 $\to$ 簽出修正 $\to$ 驗證與再納入新基準線。

2. 第二問（在哪些開發階段建立基準線）：

• 應對應軟體開發生命週期（SDLC）的主要里程碑或採用國際標準（如 IEEE / CMMI / 美國國防部 MIL-STD-973 標準規範）。
• 清楚列出「階段名稱」、「基準線名稱」及「所包含之關鍵 SCI 產出物」，如需求分析階段的功能基準線、架構/詳細設計階段的分配/設計基準線、測試/交付階段的產品基準線。

---

解題技巧

1. 破題關鍵（界定「受控」本質）：

• 許多考生容易將「基準線」窄化為「Git 的 Commit 或 Tag」。在國家考試中，必須拉高至專案管理層次，強調「正式技術審查（Formal Technical Review, FTR）」與「變更控制委員會（CCB）」的核准授權。

2. 答題結構化：

• 採標題化、條列化編排。第二題請繪製簡易對應表格或清晰列點，將「開發階段」、「基準線名稱」與「對應 SCI 產出物」三者嚴密對應。

3. 避免常見陷阱：

• 切忌只列出單一「發布階段」的基準線。複雜軟體專案採用漸進迭代或瀑布式里程碑，各關鍵階段結束時皆應建立對應基準線。

---

【答案】

一、透過基準線對軟體型態項目（SCI）之控管機制

在軟體型態管理中，基準線扮演「控制閥」角色。當某一 SCI 通過正式審查納入基準線後，即受到嚴密的變更管制。具體控管機制如下：

1. 型態識別與基準化（Configuration Identification & Baselining）

• 明確定義各階段應受控的 SCI（如需求規格書、設計模型、原始碼、測試計畫）。
• 每個 SCI 賦予唯一的名稱、版本識別碼（Version ID）與關係關聯。當 SCI 達到里程碑標準並通過正式技術審查（FTR）後，正式標記並凍結（Freeze），納入基準線。

2. 儲存庫分級控管（Repository Access Control）

• 建立三級型態儲存庫機制：
• 開發庫（Development / Dynamic Area）：開發人員自行修改，不受嚴格限制。

核心觀念

本題評量敏捷軟體開發方法論（Agile Software Development）中 Scrum 框架的事件（Scrum Events / Ceremonies）機制。 Scrum 的核心基於**經驗主義（Empiricism）**的三大支柱：透明（Transparency）、檢驗（Inspection）與調適（Adaptation）。在一個衝刺（Sprint）週期即將結束時，Scrum 設計了兩個連續但分工明確的活動來落實檢驗與調適：

1. Sprint Review（衝刺檢視會議）：針對「產出物（What）」進行檢驗與調適，關注產品增量、商業價值及利害關係人的回饋。
2. Sprint Retrospective（衝刺回顧會議／自省會議）：針對「團隊工作流程（How）」進行檢驗與調適，關注人際協作、工程實踐、工具與持續改善（Continuous Improvement / Kaizen）。

---

解題方法

本題為高普考典型之雙概念對比申論題，評分關鍵在於能否精準切中兩大主軸：「執行時機（When）」與「執行目的（Why）」，並延伸對應之參與角色與產出成果。 建議解題架構採「定義與細部說明 $\rightarrow$ 關鍵構面比較表 $\rightarrow$ 結論」之三段式結構：

1. 執行時機剖析：清楚界定在 Sprint 生命週期中的精確時間點與先後次序（Review 在先，Retro 在後）。
2. 執行目的剖析：精準區分「檢驗產品（對外溝通）」與「檢驗流程（對內反思）」。
3. 綜合比較矩陣：以結構化表格整合執行時機、執行目的、參與對象、檢驗核心及產出結果，使閱卷委員一目了然。

---

選項分析（問項爭點與給分要點解析）

本題為非選擇題（問答題），閱卷評分點集中於以下兩項核心要件的完整性與精確度：

1. 執行時機（Timing）要點：

• Sprint Review：位於 Sprint 即將結束前（緊接在開發工作完成後），是 Sprint 倒數第二個正式活動。
• Sprint Retrospective：位於 Sprint 的最末端，緊接在 Sprint Review 結束之後、下一個 Sprint 開始之前，是該 Sprint 的最後一個正式活動。
• 評分盲點：若僅回答「都在 Sprint 結束時」而未點出兩者的「前後先後順序」，無法取得完整分數。

2. 執行目的（Purpose）要點：

• Sprint Review：目的在於**檢視產品增量（Product Increment）**與收集市場／業務回饋。團隊向利害關係人展示「完成（Done）」的功能，評估進度並共同調適「產品待辦清單（Product Backlog）」。
• Sprint Retrospective：目的在於檢討與優化團隊工作流程。團隊檢視上個衝刺中的「人際互動、流程、工具、完成的定義（DoD）」，發掘痛點並制定「具體改善措施」，作為下個 Sprint 執行的準據。
• 評分盲點：若混淆兩者的核心目標（例如：誤寫成在 Retrospective 中向客戶展示軟體，或在 Review 中檢討組員工作態度），屬於嚴重失分陷阱。

---

解題技巧

1. 記憶口訣：

• Review 看「產品」（What）：對外展示、拉齊認知、修訂 Backlog。
• Retro 照「鏡子」（How）：對內反省、持續改善、凝聚團隊。

2. 角色差異輔助判斷：

• Sprint Review 必須邀請**關鍵利害關係人（Key Stakeholders／客戶／業務端）**參與，是外部回饋的窗口。

核心觀念

本題測驗物件導向分析與設計（OOAD）中 UML（Unified Modeling Language）2.x 互動圖（Interaction Diagrams） 的核心語意與視覺表示法。

1. 互動圖的家族與語意等價性（Semantic Equivalence）： UML 的互動圖主要包含「循序圖（Sequence Diagram）」、「溝通圖（Communication Diagram，UML 1.x 稱為協同圖 Collaboration Diagram）」、「互動概觀圖（Interaction Overview Diagram）」與「計時圖（Timing Diagram）」。其中，循序圖與溝通圖在底層模型資訊上具備同構性（Isomorphism），表達的是同一套物件互動規格，因此在 CASE 建模工具中能夠進行無失真的雙向自動轉換。
2. 兩大圖形的本質視角差異：

• 循序圖以「時間順序（Time-oriented）」為核心視角，強調訊息傳遞發生的先後順序與物件的控制權生命週期。
• 溝通圖以「物件組織結構（Space/Structure-oriented）」為核心視角，強調參與互動之物件實體間的靜態鏈結（Link）與拓撲配置關係。

---

解題方法

本題屬於標準的「比較型申論題」，閱卷評分重點在於是否具備系統化的分類架構。答題切入策略應分為「本質共通處」與「多維度差異處」，並搭配結構化對比表呈現：

1. 相同點之論述策略： 從「分類歸屬（均屬互動圖動態模型）」、「語意模型（均描述參與物件、傳遞之訊息與呼叫順序）」以及「同構可逆性（資訊內容等價，可無失真互換）」三個層次歸納。
2. 相異點之論述策略： 從「強調焦點」、「時間軸表示法」、「控制焦點與生命期（Lifeline/Activation）」、「空間佈局彈性」以及「適用情境」五大構面切入對比。
3. 結構化表格輔助： 將文字重點提煉為高密度對比表，滿足國考閱卷委員快速採分的評分需求。

---

選項分析

本題為高考三級申論題（非選擇題），針對題目所要求的「循序圖」與「溝通圖」之關鍵要素進行深入分析與比較：

一、 相同點（Similarities）

1. 模型語意完全等價：兩者皆描述一群物件為了完成某個特定使用案例（Use Case）或操作目標，彼此之間所發送的訊息序列。任何能以循序圖表達的訊息交換，皆可 100% 映射至溝通圖，反之亦然。
2. 基本組成元素相同：兩者皆包含參與互動的「物件實體（Objects/Lifelines）」、「關聯鏈結（Links）」與「訊息呼叫（Messages，含同步呼叫、非同步呼叫、回傳值及引數）」。
3. 同屬動態行為視圖：兩者皆屬於 UML 行為模型下的互動視圖，著眼於系統執行期的動態行為，而非編譯期的靜態類別結構。

二、 相異點（Differences）

比較維度	循序圖（Sequence Diagram）	溝通圖（Communication Diagram）
UML 1.x 舊稱	Sequence Diagram	協同圖／合作圖（Collaboration Diagram）
核心強調焦點	時間順序（Time-oriented）	結構關聯（Structure-oriented）
時序表示方式	隱含於垂直維度（由上而下自然代表時間流逝），序號非必要。	必須依賴巢狀序號標註（如 1, 1.1, 1.2, 2）來強制表達執行先後次序。
生命線（Lifeline）	物件下方具備明確的垂直虛線，清楚標記存活時段。	無生命線；

核心觀念

本題測驗關聯式資料庫管理系統（RDBMS）中「資料完整性限制（Data Integrity Constraints）」的核心定義與運作機制。主要聚焦於關聯式模型（Relational Model）中最關鍵的兩大結構性限制：

1. 實體完整性（Entity Integrity Constraint）：規範單一資料表內「主鍵（Primary Key, PK）」的有效性，確保每一筆實體記錄皆具備獨一無二的識別能力。
2. 參照完整性（Referential Integrity Constraint）：規範跨資料表間「外鍵（Foreign Key, FK）」與「主鍵／候選鍵（Candidate Key）」的對應關係，確保資料關聯的一致性，防止懸置參照（Dangling References）。

---

解題方法

本題為標準的申論型名詞解釋與觀念闡述題。高分作答的切入架構應掌握「四層展開法」：

1. 核心定義與規則：精準寫出該限制在關聯式模型中的數學與邏輯規範。
2. 對應之鍵值機制：指出實體完整性對應主鍵（PK），參照完整性對應外鍵（FK）。
3. 設計目的與效益：說明此限制要解決什麼問題（如識別實體、防止孤兒資料）。
4. 具體實例與違反處置：透過簡短資料表欄位舉例，並說明 DBMS 在面對更新（UPDATE）或刪除（DELETE）時的處理策略。

---

選項分析

本題為申論題（非選擇題），無選項可供逐一分析。在國家考試中，評分委員著重於考生能否清楚界定「主鍵不可為空值」與「外鍵值之兩大合法狀態」，答題時應避免混淆兩者的適用對象與允許的值域狀態。

---

解題技巧

1. 記憶口訣：

• 「實體看主鍵，唯一且非空。」
• 「參照看外鍵，存在或是空。」

2. 常見扣分陷阱：

• 誤以為「外鍵絕對不可為空值（NULL）」：除非欄位被明確定義為 NOT NULL，否則在關聯式理論中，外鍵允許為 NULL（代表該實體目前尚未與父表建立關聯）。
• 只寫出定義，未說明「違反限制時的處置」：在參照完整性中，補充外鍵限制動作（CASCADE、RESTRICT / NO ACTION、SET NULL、SET DEFAULT）是奪取滿分的關鍵。

---

【答案】

一、實體完整性限制（Entity Integrity Constraint）

1. 定義與規則： 在關聯式資料庫中，任何基底關聯（Base Relation）的主鍵（Primary Key）所包含之任一屬性（Attribute），其值絕不能為空值（NOT NULL），且所有記錄之主鍵組合值必須具備唯一性（Unique）。