110 地方特考三等 資訊處理 系統分析與設計 考古題詳解

核心觀念

本題考查企業資訊系統導入時的「系統轉換策略」。系統轉換是指將組織由現行系統移轉至新系統的過程，重點在於如何降低營運中斷、資料錯誤、使用者抗拒及新系統失敗等風險。

系統轉換可從三個面向規劃：

1. 轉換型式（conversion style）：新舊系統如何切換。
2. 轉換場所（conversion location）：先在哪些組織、分公司或營業據點導入。
3. 轉換模式（conversion model）：一次轉換整個系統，或依模組逐步轉換。

三個面向可以交互搭配，例如採用「單一據點試行＋平行轉換＋模組化導入」。

---

一、轉換型式

1. 直接轉換（Direct Conversion、Cutover 或 Big Bang）

在指定時間停止使用舊系統，立即啟用新系統。

作法：

1. 事先完成新系統測試、資料轉換與人員訓練。
2. 選定切換日及停機時段。
3. 停止舊系統。
4. 將最新資料移轉至新系統。
5. 新系統正式上線。

優點：

• 導入時間最短。
• 不需長期維護新舊兩套系統。
• 不會產生新舊系統同時運作的重複作業。
• 長期成本通常最低。

缺點：

• 轉換風險最高。
• 新系統若發生重大錯誤，整個組織的業務可能立即中斷。
• 回復舊系統困難，必須預先準備完整的備援與回復方案。
• 使用者適應壓力最大。

適用情況：

• 組織規模較小。
• 新舊系統差異不大。
• 新系統已經過充分驗證。
• 企業能接受短時間停機或具有完善備援機制。

---

2. 平行轉換（Parallel Conversion）

新舊系統在一段期間內同時運作，由使用者將相同資料輸入兩套系統，再比較兩者結果。待確認新系統穩定後，才停止舊系統。

優點：

• 風險最低。
• 新系統發生錯誤時，可使用舊系統維持營運。
• 可透過新舊系統輸出結果比對，及早發現資料或邏輯錯誤。
• 使用者有較充裕的學習與適應時間。

缺點：

• 作業量大，資料可能必須重複輸入。
• 人力成本與設備成本較高。
• 新舊系統需同步維護。
• 平行運作期間較長時，使用者容易疲勞或降低配合意願。

適用情況：

• 金融、醫療、政府核心業務等不能中斷的系統。
• 系統錯誤可能造成重大財務或營運損失。
• 新系統尚需透過實際作業進行驗證。

---

3. 試行轉換（Pilot Conversion）

先選定一個部門、分公司、工廠或營業據點導入新系統，確認運作成功後，再推廣至其他單位。

試行單位通常應具有代表性，且規模不宜過大，以便控制風險與蒐集回饋。

優點：

• 將轉換風險限制在少數單位。
• 可在正式全面推廣前發現系統缺陷。
• 能取得實際使用者意見，改善教育訓練、流程及操作介面。
• 便於建立成功案例，降低其他單位的抗拒。

缺點：

• 全面導入所需時間較長。
• 試行單位與其他單位若存在流程差異，試行結果未必能完全代表全體。
• 初期可能產生不同據點使用不同系統的整合問題。
• 需負擔試行環境及後續推廣的管理成本。

適用情況：

• 組織有多個分支機構或營業據點。
• 新系統需要在真實環境中驗證。
• 各據點業務相似，適合逐步複製導入經驗。

---

4. 分階段轉換（Phased Conversion）

將系統依功能、業務流程、部門或模組分成數個階段，逐步由舊系統轉換至新系統。

例如先導入人事模組，再導入財務模組，最後導入採購與庫存模組。

優點：

• 將大型轉換工作拆成數個較小階段，降低一次性風險。
• 每一階段完成後可吸收經驗並修正後續工作。
• 使用者能逐步學習，降低訓練壓力。
• 資源需求較容易安排。

缺點：

• 導入總時間較長。
• 新舊模組並存時，介面與資料整合較複雜。
• 模組間具有相依關係時，可能出現流程銜接問題。
• 總管理成本與整合成本可能增加。

適用情況：

• 系統規模大、功能複雜。
• 各模組可清楚切割，且相依性不高。
• 組織無法一次投入足夠人力、時間及資金。

---

二、轉換場所

轉換場所是指系統先在哪些組織單位或營運據點上線。常見策略如下。

1. 全組織轉換（Organization-wide Conversion）

所有部門、分公司或營業據點在同一時間切換至新系統。

優點：

• 全組織流程與資料標準一致。
• 不需長期處理新舊系統並存及跨據點介接問題。
• 導入完成時間較短。
• 適合需要全企業即時整合的系統。

缺點：

• 影響範圍最大，整體風險最高。
• 問題一旦發生，可能同時影響所有單位。
• 教育訓練、技術支援及資料轉換工作量集中。
• 對網路、伺服器及客服支援能力要求較高。

---

2. 單一場所轉換（Single-location Conversion）

先選定一個營業據點或組織單位導入新系統，確認成功後再擴展至其他場所。

這種方式通常會與試行轉換搭配使用。

優點：

• 影響範圍小，容易控制。
• 技術及流程問題容易定位。
• 可將試行據點的經驗複製到其他據點。
• 教育訓練及現場支援較容易安排。

缺點：

• 整體導入時間較長。
• 試行場所與其他場所的作業差異可能造成推廣困難。
• 不同場所可能暫時使用不同系統，增加資料交換與管理複雜度。

---

3. 多場所分批轉換（Multiple-location Conversion）

將多個據點分成數批，依地區、規模、業務類型或準備程度依序導入。

例如先導入北部據點，再導入中部及南部據點。

優點：

• 比全組織同時導入容易控制。
• 比單一場所逐一導入更有效率。
• 可依據點特性安排不同導入順序。
• 能分散教育訓練、客服及技術支援的負荷。

缺點：

• 導入期間可能存在多套系統並存。
• 跨據點交易與資料同步較複雜。
• 批次間需要維持版本、流程及資料格式一致。
• 若前一批問題未解決，可能影響後續批次。

---

三、轉換模式

核心觀念

驗收測試（acceptance testing）是系統開發後期，由使用者、客戶或業主依據業務需求與驗收標準，確認完成的系統是否「可接受、可上線、可正式使用」的測試活動。

它與系統測試的重點不同：

• 系統測試：由開發或測試人員確認整體系統是否符合規格。
• 驗收測試：由使用者或客戶確認系統是否符合實際業務需求，能否解決工作問題。
• 驗收測試的通過：通常代表客戶接受系統成果，並作為正式上線、交付及付款的重要依據。

本題重點在於說明三件事：

1. 驗收測試的目標。
2. 驗收測試的兩個階段。
3. 測試用例如何從需求與實際作業中發展出來。

---

驗收測試的目標

一、確認系統符合使用者需求

驗收測試首先要確認系統是否完成需求分析階段所定義的功能，包括：

• 功能是否完整。
• 業務流程是否正確。
• 輸入、處理與輸出是否符合規定。
• 使用者權限是否正確。
• 報表、通知、查詢及資料交換功能是否符合工作需要。

測試的判斷依據不是開發人員主觀認為「程式可以執行」，而是系統是否符合已核准的需求規格與驗收條件。

二、確認系統可支援實際業務作業

系統即使在技術上可以執行，仍可能不符合實際工作流程。例如：

• 操作步驟過於複雜。
• 欄位名稱不符合業務用語。
• 報表內容不足以支援決策。
• 系統無法處理例外情況。
• 與既有作業或其他系統的銜接不完整。

因此，驗收測試須由實際使用者依照日常業務情境操作，確認系統能在真實工作環境中運作。

三、確認系統達到約定的品質與效能標準

驗收測試除功能外，也可確認下列非功能需求：

• 回應時間是否符合要求。
• 同時使用者數是否達到規格。
• 資料安全與權限控管是否適當。
• 系統穩定性是否足夠。
• 備份、復原及錯誤處理是否有效。
• 可用性、易用性及維護性是否符合約定。

若需求規格訂定「查詢結果須於三秒內回傳」，則驗收測試必須以實際資料量與合理的使用者負載測試該條件，而不是只測試小筆測試資料。

四、發現上線前仍存在的缺失

驗收測試是正式交付前的重要品質閘門，可發現：

• 需求遺漏。
• 功能與流程不一致。
• 業務規則實作錯誤。
• 資料轉換錯誤。
• 介面與操作不符合使用者習慣。
• 例外及錯誤處理不完整。

測試結果通常會形成缺失清單，並依嚴重程度決定修正、延期驗收或接受系統。

五、取得客戶正式接受

驗收測試的最終目的，是提供客觀證據，讓業主或使用者判定系統是否符合交付條件。通過後通常會產生：

• 驗收測試報告。
• 缺失修正確認紀錄。
• 使用者簽署的驗收文件。
• 上線核准或系統交付紀錄。

---

驗收測試的兩個階段

驗收測試通常分為 α 測試（alpha testing） 與 β 測試（beta testing） 兩個階段。

一、α 測試（Alpha Testing）

α 測試是在開發組織或受控制的測試環境中進行，通常由開發人員、測試人員及少數使用者代表共同執行。

主要特徵

• 在開發單位或指定的受控環境進行。
• 測試環境較容易控制。
• 可使用模擬資料、測試資料及部分實際資料。
• 開發人員通常在現場，能立即協助分析與修正問題。
• 主要目的在於找出系統中尚未解決的重大缺失。

測試重點

α 測試著重於：

• 功能是否依需求運作。
• 各項業務流程是否可順利完成。
• 模組整合後是否產生錯誤。
• 系統是否能正確處理正常及異常輸入。
• 重要報表與資料是否正確。
• 重大缺失是否已排除。

例如，機關開發人事管理系統時，可邀請人事室承辦人員到測試環境，依照實際作業執行到職、調職、離職及薪資查詢流程，並記錄操作過程中的問題。

α 測試的價值

α 測試能在系統正式交付前，於可控制的環境中集中處理問題。由於開發人員在場，錯誤定位與修正速度通常較快，適合用來確認系統是否已具備進入實際使用環境的基本條件。

---

二、β 測試（Beta Testing）

β 測試是在接近正式使用的實際環境中，由實際使用者執行系統。開發人員通常不會全程直接控制測試，而是由使用者依日常工作方式使用系統並回報問題。

主要特徵

• 由實際使用者在實際或近似實際環境執行。
• 使用真實業務流程及接近正式狀況的資料。
• 使用者依平常工作方式操作，不完全依照開發人員預先安排的腳本。
• 測試環境、網路、周邊設備、作業規則及人員配置較接近正式上線狀況。
• 主要目的在於確認系統能否在實際作業環境中穩定運作。

測試重點

β 測試著重於：

• 系統是否適合使用者日常操作。
• 真實資料量是否造成效能問題。
• 使用者權限與工作分工是否正確。
• 系統與既有設備、資料庫及外部系統是否正常整合。
• 使用者是否能依系統完成完整業務流程。
• 現場是否會出現測試環境未發現的例外狀況。
• 操作說明、教育訓練及錯誤訊息是否足以支援使用者。

例如，系統先在資訊室完成 α 測試後，再交由數個實際業務單位於日常作業中試用。使用者將查詢錯誤、報表不足、操作不便及資料介接問題回報給開發團隊，這就是 β 測試的典型情形。

---

α 測試與 β 測試的比較

比較項目	α 測試	β 測試
測試環境	開發單位或受控制環境	實際或近似正式環境
主要執行者	開發人員、測試人員、使用者代表	實際終端使用者
測試資料	測試資料、模擬資料、部分實際資料	接近真實的業務資料
開發人員參與程度	高，通常可在現場支援	較低，主要接收使用者回報
主要目的	找出重大缺失並確認基本可用性	確認現場適用性與正式運作能力
測試控制程度	高	較低
執行時機	較早	α 測試後、正式上線前

兩個階段的核心差異可記為：

α 測試在受控環境中驗證系統是否基本正確；β 測試在實際環境中驗證系統是否真正適用。

---

測試用例的開發方式

測試用例（test case）是針對一項功能、業務規則或品質要求所設計的具體測試情境。完整的測試用例應能說明「在什麼條件下，輸入什麼資料，執行什麼操作，應得到什麼結果」。

一、以需求規格為主要來源

測試用例必須由需求規格、功能需求、非功能需求及驗收標準發展而來。

常見來源包括：

• 使用者需求文件。
• 系統需求規格書。
• 使用案例（use case）。
• 業務流程圖。
• 資料流程圖。
• 螢幕與報表規格。
• 業務規則。
• 介面規格。
• 服務水準或效能要求。
• 合約所載的驗收條件。

每一項重要需求都應能對應到至少一個測試用例，形成需求與測試之間的可追溯關係。

可建立下列對應：

$$\text{需求} \rightarrow \text{驗收條件} \rightarrow \text{測試用例} \rightarrow \text{測試結果}$$

核心觀念

本題考查「非功能需求」（Non-functional Requirements）的分類與應用。非功能需求不是描述系統「要做哪些事情」，而是規範系統執行功能時所應具備的品質、限制條件與運作標準。

數位學習系統除了提供課程瀏覽、線上授課、作業繳交、測驗與成績查詢等功能，也必須符合下列四類非功能需求：

1. 操作需求（Operational Requirements）
2. 效能需求（Performance Requirements）
3. 安全性需求（Security Requirements）
4. 文化與政策需求（Cultural and Policy Requirements）

本題非法律條文背誦題；涉及個人資料、資訊安全、著作權與教育政策之說明，以命題當年（民國110年）法規與政策為準。

解題方法

可採「定義—系統化要求—具體例子」的方式作答：

1. 先說明非功能需求與功能需求的差異。
2. 依題目指定的四種類別逐一解釋。
3. 每一類都提出數位學習系統的實際要求。
4. 將抽象要求盡量轉化為可驗收的標準，例如反應時間、同時使用人數、可用性比例與備份時間。

如此可同時展現概念理解與系統分析能力。

一、操作需求

1. 定義

操作需求是指系統在實際操作、維護與日常運作時，使用者及管理人員所需要的操作條件。重點在於系統是否容易使用、容易維護，並能在不同設備與環境下正常運作。

2. 數位學習系統的具體要求

（1）易用性

系統介面應清楚、操作流程簡單，使教師、學生及行政人員不需長時間訓練即可使用。

例如：

• 學生能快速找到課程、教材、作業與成績。
• 教師能簡單建立課程、上傳教材及發布公告。
• 錯誤訊息應清楚說明原因及處理方式。
• 重要操作，例如繳交作業及刪除資料，應提供確認機制。

（2）設備與平台相容性

系統應支援常見的桌上型電腦、筆記型電腦、平板及手機，並相容於主流瀏覽器與作業系統。

線上課程若使用影音、互動教材與檔案下載功能，也應確保不同解析度及不同網路環境下仍能正常使用。

（3）可維護性

系統應方便管理人員進行課程管理、帳號管理、權限設定、錯誤排除與版本更新。

例如：

• 管理者能停用離校學生帳號。
• 系統能記錄錯誤日誌。
• 課程內容更新不需修改整個系統。
• 系統升級時不應影響既有課程與學習紀錄。

（4）可用性與持續運作

數位學習系統需提供適當的服務時間，尤其在上課、考試及作業截止期間，應避免任意停機。

若必須維護，應事先公告維護時間，並提供故障通報及復原流程。

（5）無障礙與輔助操作

系統應考慮身心障礙學生的使用需求，例如：

• 影片提供字幕。
• 圖片提供替代文字。
• 介面可使用鍵盤操作。
• 色彩對比足夠。
• 支援螢幕報讀軟體。
• 語音及文字教材可相互搭配。

二、效能需求

1. 定義

效能需求是指系統在特定工作量與使用環境下，對反應速度、處理能力、容量、可用性及擴充能力所提出的要求。

效能需求應盡量量化，避免只使用「快速」「穩定」等無法驗收的模糊用語。

2. 數位學習系統的具體要求

（1）反應時間

系統應在合理時間內完成使用者要求，例如：

• 一般頁面查詢應於數秒內回應。
• 成績查詢不應因資料量增加而長時間等待。
• 線上測驗送出答案後，系統應立即顯示儲存結果。
• 直播課程的影音延遲應控制在可接受範圍內。

（2）同時使用人數與吞吐量

疫情期間可能有大量學生同時登入、觀看直播、下載教材及進行測驗，因此系統應規定：

• 可同時登入的使用者人數。
• 可同時觀看直播的人數。
• 每秒可處理的登入、查詢或答案提交筆數。
• 尖峰時段可接受的錯誤率。

例如，可要求系統在一萬名學生同時進行測驗時，仍能正確接收答案並保存作答紀錄。

（3）容量需求

系統需估算並支援：

• 使用者帳號數量。
• 課程及教材數量。
• 影音檔案與作業檔案容量。
• 歷年成績與學習歷程保存年限。
• 同時產生的測驗及報表數量。

容量設計不足，會造成儲存空間耗盡、檔案無法上傳或系統服務中斷。

（4）可擴充性

當使用人數增加、課程數量擴大或新增直播功能時，系統應可透過增加伺服器資源、資料庫容量或網路頻寬提升處理能力，而不必全面重建。

（5）可用性與可靠性

系統應訂定服務可用性目標，例如全年服務可用率、故障復原時間及資料復原點。

常見指標包括：

• 可用性比例（Availability）
• 平均故障間隔時間（MTBF）
• 平均修復時間（MTTR）
• 復原時間目標（RTO）
• 復原點目標（RPO）

可用性可表示為：

$$Availability=\frac{MTBF}{MTBF+MTTR}$$

其中，$MTBF$ 越高代表系統越不容易故障，$MTTR$ 越低代表故障後越快恢復。

三、安全性需求

1. 定義

安全性需求是指系統保護資料、使用者、設備及服務，使其免於未經授權的存取、竄改、洩漏、破壞與中斷。

其核心可由資訊安全三要素說明：

• 機密性（Confidentiality）：只有獲授權者能存取資料。
• 完整性（Integrity）：資料未遭未授權竄改。
• 可用性（Availability）：合法使用者需要時能使用系統。

2. 數位學習系統的具體要求

（1）身分驗證

系統應確認使用者身分，例如：

• 帳號密碼登入。
• 多因素驗證。
• 學校單一登入。
• 登入失敗次數限制。
• 可疑登入通知。

核心觀念

本題考查使用者介面設計中的「導覽設計」。導覽是指系統提供使用者在不同畫面、功能、內容與操作層級間移動的方法，目的在於讓使用者隨時知道：

1. 目前位於系統何處。
2. 可以前往哪些位置。
3. 如何到達目標功能。
4. 如何返回上一層或回到起點。
5. 操作完成後系統目前的狀態為何。

導覽設計通常結合資訊架構、互動設計與可用性原則，重點不只是安排選單位置，也包括功能分類、名稱、層級、路徑、目前位置提示及返回機制。

---

解題方法

本題可採「導覽設計原則＋常見錯誤」的對照方式作答。先說明良好導覽應具備的設計原則，再指出違反這些原則時會產生的錯誤，答案即能完整涵蓋題意。

---

一、導覽設計的原則

1. 符合使用者的工作流程

導覽結構應依照使用者的任務、工作流程與認知方式設計，而不是只依照系統內部的程式模組或資料表分類。

例如，使用者要「申請出差」，常見流程是：

$$填寫申請資料 \rightarrow 上傳附件 \rightarrow 送出申請 \rightarrow 查詢審核狀態$$

導覽應配合這種工作順序安排，使使用者能直接完成任務。

2. 分類清楚、名稱易懂

選單項目應依功能或內容建立合理分類，分類之間要具有互斥性，避免同一功能同時出現在多個不相關的位置。

功能名稱應使用使用者熟悉的語言，例如「查詢訂單」、「修改個人資料」，不宜只使用內部術語，如「交易物件維護」、「主檔管理」。

3. 保持一致性

不同畫面的導覽位置、名稱、圖示、操作方式與視覺樣式應保持一致，包括：

• 主選單在各畫面使用相同位置。
• 相同功能使用相同名稱。
• 相同圖示代表相同意義。
• 返回、首頁、登出等功能具有一致的操作方式。
• 導覽階層與畫面標題保持一致。

一致性可降低使用者重新學習的負擔，也能減少誤操作。

4. 讓使用者知道目前位置

系統應清楚呈現使用者目前所在的位置與所在功能，例如：

• 顯示目前畫面的標題。
• 標示主選單中的目前項目。
• 使用麵包屑導覽（breadcrumb）。
• 顯示目前所在的資料夾或階層路徑。

例如：

「首頁 ＞ 會員中心 ＞ 訂單查詢 ＞ 訂單明細」

如此可避免使用者迷失在多層畫面中。

5. 提供清楚的方向與返回機制

導覽應讓使用者容易前往下一步，也能返回上一層、首頁或主要功能區。常見設計包括：

• 返回上一頁。
• 返回上一層。
• 回到首頁。
• 回到主選單。
• 提供取消操作。
• 提供完成後的下一步指引。

返回功能必須符合使用者預期，不能因返回而遺失尚未儲存的資料。

6. 控制導覽層級與深度

選單階層不宜過深，否則使用者需要反覆點選才能到達目標功能。設計時應在「選項數量」與「層級深度」之間取得平衡。

若一層放置過多項目，會增加辨識困難；若切分成過多層級，則會增加操作次數與迷失風險。常見做法是將相關功能群組化，並以清楚的分類名稱降低每層的複雜度。

7. 提供可見性與即時回饋

使用者執行導覽操作後，系統應立即顯示狀態變化，例如：

• 選單項目呈現反白或選取狀態。
• 顯示載入中。
• 顯示目前頁碼。
• 顯示已展開或收合的選單。
• 顯示無法前往的原因。
• 以訊息告知操作成功或失敗。

可見性與回饋能使使用者知道系統確實收到操作，不會因缺乏反應而重複點擊。

8. 優先呈現常用功能

高頻率、重要或關鍵任務應放在明顯且容易到達的位置；低頻率功能可放在次要選單或進階設定中。

此原則能降低使用者完成主要任務所需的步驟，提升操作效率。

9. 支援不同使用情境

導覽應考量不同裝置、螢幕尺寸、使用者能力與操作環境，例如：

• 在行動裝置上提供適合觸控的選單。
• 觸控按鈕應具有足夠大小與間距。
• 鍵盤使用者可以利用 Tab 鍵操作。
• 導覽不能只依賴顏色傳達狀態。
• 選單展開、焦點與目前位置應具備適當的視覺提示。
• 對螢幕閱讀器使用者提供適當的結構與標籤。

10. 保留使用者控制權

使用者應能自由移動、返回、取消或離開目前流程，不應被系統強迫沿著單一路徑操作。

對於可能造成資料遺失的離開、返回或切換操作，系統應先提醒使用者儲存資料或確認是否放棄變更。

---

二、導覽設計常犯的錯誤

1. 使用不清楚或過度專業的名稱