108 司法特考三等 檢察事務官電子資訊組 系統分析 考古題詳解

核心觀念

資料流程圖（DFD）由外部實體、處理程序、資料儲存體、資料流四種元素構成。處理程序負責轉換或處理資料；資料流則表示資料在元素間的傳遞。

DFD 的基本規則是：外部實體與資料儲存體之間的資料交換，須經由處理程序；外部實體彼此之間、資料儲存體彼此之間，也不能直接連線。​此外，每個處理程序都應有輸入與輸出，且輸出須能由輸入經處理而來。

解題方法

逐一檢查每條資料流的兩端：

1. 若連線兩端都不是處理程序，檢查是否違反元素間的連線規則。
2. 若包含處理程序，檢查處理程序是否有輸入及輸出，資料流是否呈現合理的處理結果。
3. 修正時，在需要資料處理或轉換的位置加入處理程序，並以具體資料名稱描述資料流。

各小題分析

（一）外部實體直接連接資料檔

錯誤原因：​外部實體不能直接讀取或寫入資料儲存體；資料檔的存取應由處理程序負責。

正確作法：​在外部實體與資料檔之間加入處理程序。例如：「考生」送出「查詢資料」給「查詢考試資料」程序，程序讀取「考試資料檔」，再回傳「查詢結果」給考生。

（二）資料檔 A 直接連接資料檔 B

錯誤原因：​資料儲存體不能直接傳送資料給另一個資料儲存體；資料應由處理程序讀取、轉換或整理後，再寫入另一資料檔。

正確作法：​加入處理程序。例如：「成績轉檔」程序讀取「原始成績檔」，整理資料後寫入「正式成績檔」。

（三）外部實體 A 直接連接外部實體 B

錯誤原因：​外部實體之間的資料交換不屬於系統內部處理流程，不能在系統的 DFD 中直接以資料流相連。

核心觀念

本題考查 PERT 網路圖的最早完工時間與工期風險估計。

專案有平行工作時，後續工作必須等所有直接前置工作完成；因此，某工作最早開始時間是所有前置工作最早完成時間的最大值。決定專案完工時間的最長路徑稱為要徑（Critical Path）。

（一）最快完工時間

從起點開始，以第 0 天為時間起點：

任務 I 必須等 D、E、G、H 全部完成，故最早可在第 $\max(14,13,12,11)=14$ 天開始，並於第 19 天完成。

各條起點至終點路徑的工期如下：

• A－B－C－D－I：$3+2+2+7+5=19$ 天
• A－B－C－E－I：$3+2+2+6+5=18$ 天
• A－B－C－F－G－I：$3+2+2+3+2+5=17$ 天
• A－B－C－F－H－I：$3+2+2+3+1+5=16$ 天

最長路徑為 A－B－C－D－I，工期 19 天，因此這條路徑是要徑。

（二）計算延遲風險並提出較可靠的承諾

題目只提供各任務一個工期數字，足以計算第（一）題的最快完工時間，卻不足以計算工期變動的數值風險。要進行 PERT 風險估計，需為各任務補充三點工期估計：

• 樂觀時間 $a$：順利情況下的工期
• 最可能時間 $m$：一般情況下的工期
• 悲觀時間 $b$：不利情況下的工期

每項任務的期望工期與變異數為：

核心觀念

本題旨在評量考生在系統維護階段導入系統維護生命週期（System Maintenance Life Cycle, SMLC）、變更管理（Change Management）​與軟體組態管理（Software Configuration Management, SCM）​的實務制度設計能力。涉及核心觀念包含：

1. 維護請求制度化（Change Request, CR）：建立單一入口，杜絕非正式口頭需求。
2. 變更控制委員會（Change Control Board, CCB）：負責維護需求之可行性、衝擊性與優先順序審查。
3. 衝擊分析（Impact Analysis）與組態基線（Baseline）：評估改動對現行系統模組與文件的影響範圍。
4. 環境隔離與分級測試：劃分開發（Dev）、測試（Test）、正式（Prod）環境，並落實單元測試、迴歸測試（Regression Testing）與使用者驗收測試（UAT）。
5. 文件同步更新與稽核（Documentation Synchronization & Audit）：將文件更新納入上線檢核點（Gate Review），確保程式與系統規格書之一致性。

解題方法

本題為典型的「系統分析與設計實務情境題」，應採用​「問題痛點對應」結合「端到端流程設計」​的切入方式：

1. 痛點診斷：

• 痛點一：使用者直接找工程師口頭交辦（缺乏審核、無排程優先級、需求範疇蔓延）。
• 痛點二：未經衝擊評估即動手改 code（造成副作用、破壞既有功能、上線錯誤百出）。
• 痛點三：文件常忘了更新（造成軟體與文件脫節，增加後續維護難度）。

2. 架構化解法：

• 以標準 SMLC 程序為骨幹，將維護流程切割為：「需求提出 $\to$ 衝擊分析與審查 $\to$ 實施與測試 $\to$ 文件更新檢核 $\to$ 發布部署 $\to$ 結案驗收」。
• 針對「降低錯誤」引入環境隔離、版本控制、迴歸測試。
• 針對「文件更新」建立​「文件即程式碼（Documentation as part of Deliverable）」​之強制上線檢核機制（Checklist），未更新文件不得核准部署。

選項分析

本題為申論問答題，無選擇題選項。 評分關鍵在於能否具體指出維護程序的每個階段輸出（Artifacts）、負責角色（RACI）以及防錯機制（Control Gate），而非僅背誦模糊的 SDLC 步驟。

解題技巧

1. 破題先給架構圖或結構化流程：閱卷老師評閱 25 分大題時，最重視程序階段的完整性。利用編號清晰呈現各階段名稱、輸入、處理、輸出。
2. 關鍵字精準命中：CR（維護變更申請單）、CCB（變更控制委員會）、Impact Analysis（衝擊分析）、Regression Test（迴歸測試）、Rollback Plan（回滾復原計畫）、Configuration Baseline（組態基線）。
3. 切忌空泛談「加強宣導溝通」：公務機關資訊體系的防弊與品管，必須依賴「制度、表單、環境隔離、權限控制、稽核檢核點」，將管理措施實體化方能獲得高分。

【答案】

針對現行機關內部「口頭交辦、任意修改、上線錯誤多、文件脫節」之亂象，應導入正規之系統維護生命週期（SMLC）​與組態變更控制機制。具體流程與制度設計如下：

一、 系統維護程序之階段設計

[使用者單位] [資訊單位/CCB] [開發與測試人員] [正式環境]
 | | | |
 提出維護需求單(CR) --------> 登錄、優先級評定 | |
 | | |
 衝擊分析與可行性評估 ----> 系統修改與設計 |
 | | |
 CCB 變更審查與核可 實施單元與迴歸測試 |
 | |
 同步更新技術/操作文件 |
 | |
 審查交付物與上線簽核 <--- UAT 驗收完成與檢核表 |
 | |
 發布授權 ---------------------------------> 部署與發布
 (含 Rollback 機制)

1. 維護需求提出與登錄（Maintenance Request & Logging）

• 單一窗口化：全面終止口頭或私下聯繫修改。建置「資訊服務入口（Service Desk）」或統一填寫「系統變更需求單（Change Request, CR）」。

核心觀念

本題考資料字典與實體關聯圖（ERD）的轉換：

• 資料字典：用欄位名稱、型態、意義及組成關係，描述一份資料的結構。交易明細單可拆成交易表頭與重複出現的商品明細列。
• ERD：將資料拆成實體、屬性與關係，並標示主鍵、外鍵及關係基數。
• 資料正規化：交易表頭資料只記錄一次；商品名稱、單價與數量等明細資料逐列記錄，避免把多項商品塞在同一欄位。

解題方法

先依收據辨識欄位，再判斷資料的重複情形：

1. 日期、時間、店號、機台、序號、合計與發票號碼，各屬於一筆交易的表頭資料。
2. 商品代號、商品名稱、數量、單價與金額會隨商品列重複，屬於交易明細。
3. 店號、機台與序號共同識別一筆交易；交易明細以交易識別碼加行次識別。
4. 商品代號識別商品；同一商品可出現在多筆交易明細中。

（一）資料字典

以下採用資料字典常見符號：= 表示「由……組成」，+ 表示欄位組合，{ } 表示可重複群組，[ ] 表示選擇性資料。本收據有商品明細，因此明細群組至少出現一次。

交易明細單
 = 交易表頭 + {商品明細列} + 發票號碼

交易表頭
 = 店號 + 機台 + 序號 + 交易日期 + 交易時間
 + 總項數 + 交易合計

商品明細列
 = 行次 + 商品代號 + 商品名稱 + 數量 + 單價 + 明細金額

本題可用下列公式驗算：

（二）資料庫架構與 ERD

實體與鍵值

• 門市 STORE：店號 為主鍵。
• 收銀機 POS_TERMINAL：由 店號、機台 組成複合主鍵；店號 同時是外鍵。