107 高普考高考二級 工業工程 系統分析與設計(包括人因工程) 考古題詳解
第 一 題25 分
您的工作單位將導入一套新系統,在決定新系統的實施日期,通常應考慮哪些因素?
登入後即可作答並保存紀錄。
核心觀念
本題評量系統發展生命週期(SDLC)中「系統實施與轉換(System Implementation and Conversion)」的排程決策能力。決定新系統實施日期(Cutover Date / Go-Live Date)並非單純取決於軟體開發是否完成,而是涉及組織營運衝擊、技術就緒度、人因工程與風險管理的整合性決策。在工業工程與系統分析領域中,必須以「整體系統(人、機、作業環境)」的視角,追求系統轉換對常態營運干擾最小化、使用者適應最佳化與轉檔失敗風險最低化。
解題方法
本題屬申論題型,答題切忌雜亂條列。應採用結構化分類法,從「營運週期與業務負荷」、「技術與系統就緒度」、「人因工程與組織調適」、「轉換策略與支援資源」、「風險應變與外部制約」五大構面切入論述:
- 營運週期與業務負荷(Business Operations & Cycle):分析組織作業節奏,避免業務尖峰期。
- 技術與資料就緒度(Technical & Data Readiness):確認系統測試、資料轉檔(Data Migration)與基礎設施的完成度。
- 人因工程與組織調適(Human Factors & Organizational Readiness):評估操作人員的學習曲線、心智負荷(Mental Workload)、抗拒心理與教育訓練成效。
- 轉換策略與支援能力(Cutover Strategy & Support Availability):配合轉換方式(直接、平行、前導、分階段)評估專案團隊與外部廠商支援人力。
- 風險應變與緩衝時間(Contingency & Buffer Time):考量系統回溯(Rollback)機制所需的非作業時間窗口。
選項分析
本題為高考二級之申論題,並無選項。評分關鍵在於能否跳脫純資訊技術角度,展現「工業工程」重視的營運排程優化及「人因工程」重視的人員負荷與人機介面調適。若僅回答「程式寫完、測試通過」,無法取得高分;必須完整論述組織營運與使用者心理/生理限制。
擬答內容
決定新系統實施日期時,應綜合考量下列五大關鍵面向與具體因素:
一、 營運週期與業務負荷因素
- 避開業務尖峰期(Business Peak Avoidance): 新系統剛上線時常伴隨操作生疏與非預期系統異常。若選在業務旺季(如電商促銷期、製造業交貨高峰期),將造成嚴重的營運中斷與營收損失。應選擇業務淡季或離峰時段實施。
- 會計與結算週期節點(Accounting & Financial Closing Cycles): 財務、會計與 ERP 類系統應避免選在月底、季底或年底結帳期間上線;理想的實施時機通常為新會計年度開始或月初,利於帳務期初開帳、對帳與資料切齊。
二、 技術驗證與資料就緒因素
- 驗收測試與缺陷收斂(Acceptance Testing & Bug Fixing): 確認使用者驗收測試(UAT)、整合測試及壓力測試皆已通過,且無重大(Critical/High)等級系統缺陷未解決。
- 資料清洗、轉檔與驗證(Data Migration & Validation): 舊系統轉入新系統之歷史資料與靜態主檔(Master Data)必須完成清理、轉換、匯入與平衡驗證;轉檔作業所需工時必須精確估算,以決定轉換窗口(Cutover Window)的長度。
- 軟硬體基礎設施與資安就緒(Infrastructure & Security): 包含伺服器承載能力、網路頻寬、備份還原機制及資安弱點掃描均已確認無虞。
三、 人因工程與組織就緒因素(Human Factors & Change Management)
- 使用者學習曲線與熟練度(Learning Curve & Proficiency):
第 二 題25 分
請簡要說明系統開發模式中螺旋模式(Spiral Model)之進行步驟。
登入後即可作答並保存紀錄。
核心觀念
本題評量系統開發生命週期(SDLC)中螺旋模式(Spiral Model)的架構與運作程序。 螺旋模式由學者貝姆(Barry Boehm)於 1988 年提出,其核心精神為「風險驅動」(Risk-Driven)與「反覆漸進」(Iterative & Evolutionary),結合了「瀑布模式」(Waterfall Model)的系統化與階段控制,以及「雛型模式」(Prototyping Model)快速釐清需求的彈性。
在二維座標平面上,螺旋模式以向外擴展的螺旋線表示系統開發歷程:
- 角度(Angular Dimension):代表系統在開發流程中所經歷的各個步驟與進展。
- 半徑(Radial Dimension):自原點向外延伸的距離,代表隨著反覆進行所累積的成本與工作量。
解題方法
回答本題應採取「宏觀架構 四大象限步驟 循環演進機制」的三段式論述:
- 先界定螺旋模式以「四大象限(Four Quadrants)」為一次完整反覆(Iteration)的基礎。
- 依序深入說明每一步驟的工作內涵、交付成果與重點技術(如風險分析、雛型建造)。
- 補充說明循環終止條件與適用情境,展現工業工程系統分析所強調的風險控制與專案管理完整性。
選項分析
本題為簡答申論題,非選擇題,故無個別選項可供正誤分析。評分焦點在於能否精確寫出四大象限的標準名稱及其循序運作之核心任務。
解題技巧
- 記憶口訣:「標、險、開、審」
- 標(第一象限):確定目「標」、方案與限制。
- 險(第二象限):評估與化解風「險」(此為得分關鍵,務必強調雛型法)。
- 開(第三象限):「開」發與驗證該層次產品。
- 審(第四象限):「審」查並規劃下一階段。
- 常見盲點與失分陷阱:
- 誤將螺旋模式寫成傳統瀑布模式的步驟(如僅寫需求分析、系統設計、程式撰寫、測試),遺漏核心的「風險評估」與「反覆循環」特性。
- 未說明螺旋的「每一圈」都對應一個更具體、更完整的系統層次(從概念需求、規格、架構到可運作軟體)。
- 版面加分技巧:若在國考實體試卷作答,建議搭配簡潔的「四象限十字圖」輔助說明,標明累積成本軸與各象限名稱,閱卷老師能一眼看出架構完整性。
【答案】
第 三 題25 分
結構化與物件導向之分析與設計,在實作上有哪些重要的差異?
登入後即可作答並保存紀錄。
核心觀念
本題旨在評量考生對資訊系統開發兩大經典典範——結構化分析與設計(Structured Analysis and Design, SAD)與物件導向分析與設計(Object-Oriented Analysis and Design, OOAD)在軟體工程實務落地上之核心哲學與實作差異的掌握程度。
- 結構化分析與設計(SAD):
- 核心哲學:以「功能」或「程序(Process)」為核心,採用由上而下功能分解(Top-Down Functional Decomposition),將資料(Data)與處理程序(Process)分離看待。
- 實作本質:將大問題逐層切割為子常式(Subroutines)或函式(Functions),以全域或區域資料結構為運算標的。
- 物件導向分析與設計(OOAD):
- 核心哲學:以「實體責任(Responsibility)」為核心,將真實世界實體抽象化為「物件(Object)」,將資料(屬性,Attributes)與操作(方法,Methods)封裝為一體。
- 實作本質:透過封裝(Encapsulation)、繼承(Inheritance)與多型(Polymorphism),以訊息傳遞(Message Passing)驅動協同合作。
解題方法
高考二級申論題評分首重系統性架構與實務洞察。解答切入點不可僅停留在「名詞定義」或「塑模圖形不同」,必須緊扣題目要求的「實作上(Implementation)的重要差異」,從以下五大維度逐一橫向對比、縱向深化:
- 系統視角與思考模式(哲學面)
- 塑模產出與階段過渡(過渡性)
- 程式碼模組化與架構實踐(編程面)
- 軟體複用性與變更衝擊控制(維護面)
- 開發生命週期之適配度(製程面)
選項分析
本題為高考二級申論題(非選擇題),無選項分析。以下針對上述五大實作關鍵維度進行深入對比分析:
一、 實作差異綜合比較表
| 比較構面 | 結構化分析與設計(SAD) | 物件導向分析與設計(OOAD) |
|---|---|---|
| 思考焦點 | 程序導向(Process-Oriented),資料與處理分離 | 責任導向(Responsibility-Oriented),狀態與行為合一 |
| 分析塑模工具 | 資料流程圖(DFD)、實體關聯圖(ERD)、資料字典(DD) | UML(使用案例圖、類別圖、循序圖、活動圖等) |
| 設計與實作過渡 | 存在顯著語意鴻溝(Semantic Gap),轉換規則模糊 | 無縫過渡(Seamless Transition),概念具同構性(Isomorphism) |
| 程式碼架構 | 函式庫、模組(Module)、副程式、全域/區域變數 | 類別(Class)、物件(Object)、介面(Interface)、封裝存取權限 |
| 複用機制(Reuse) | 函式層級複用(Function/Subroutine Libraries) | 類別繼承、介面實作、設計模式(Design Patterns)、元件複用 |
| 變更衝擊(Ripple Effect) | 高;資料結構變更常波及大量相依函式 | 低;透過封裝隱藏細節,變更影響侷限於類別內部 |
| 生命週期契合度 | 瀑布模型(Waterfall Model)等序列式線性生命週期 | 敏捷(Agile)、反覆漸增式(Iterative & Incremental)模式 |
二、 實作重要差異之深入剖析
1. 系統視角與組織架構:處理與資料的關係
- 結構化(SAD):實作上將「做什麼事(演算法/函式)」與「被處理的資料(檔案/全域資料結構)」獨立分開。程式碼通常由主程式呼叫次級模組,次級模組再呼叫基礎函式,資料藉由參數傳遞或全域變數存取。
- 物件導向(OOAD):實作上將屬性與行為封裝於類別之中,資料僅能透過物件公開的介面進行操作。系統由一群互相傳遞訊息的自治物件構成,模組邊界清晰,大幅降低模組間的耦合度。
2. 階段轉換的連貫性:語意落差(Semantic Gap)的有無
- 結構化(SAD):從分析階段的 DFD(以泡泡表示處理邏輯)過渡到設計階段的結構圖(Structure Chart,以階層樹表示控制呼叫),需要依賴「轉換分析(Transform Analysis)」或「交易分析(Transaction
第 四 題25 分
請說明「防呆設計」的定義,並舉兩例說明。
登入後即可作答並保存紀錄。
核心觀念
本題測驗「人因工程(Human Factors Engineering)」與「品質管制/精實生產(Lean Production)」中針對人為失誤(Human Error)的工程防制對策。核心觀念包含:
- 源起與定義:源自日本豐田生產系統(TPS)工程師新鄉重夫(Shigeo Shingo)提出的「Poka-Yoke(ポカヨケ,防錯/防呆)」。其核心精神為「人必然會犯錯,但系統不應允許失誤演變成缺陷」。
- 人因防錯層次:透過硬體形狀、機構配置、電氣控制或操作介面的「限制(Constraints)」與「強迫功能(Forcing Functions)」,使操作者即使注意力不集中或缺乏經驗,也能「不可能做錯」(預防發生),或「一旦做錯系統立即中斷並警示」(防止缺陷流出)。
- 機制分類:主要分為「管制型(Control Type,強制停止或無法執行)」與「警告型(Warning Type,感測異常並發出警訊)」。
解題方法
本題為國家考試標準的「名詞解釋+實例說明」申論題型,答題應採取三層結構:
- 嚴謹定義:不可僅以通俗口語回答「防止傻子犯錯」,必須從人因工程的角度,結合人為失誤本質、設計干預手法與系統目標(追求零缺點、減輕認知負荷)作學術化定界。
- 作用機制說明:說明防呆的兩大基本功能(預防發生型 vs. 偵測警示型),展現理論深度。
- 實例列舉:挑選具代表性且機制分明的範例(建議一例為「物理幾何限制/排除」,另一例為「邏輯順序/互鎖機構」),逐一剖析其「防範之失誤型態」與「具體工程機制」。
解題技巧
- 名詞加分術語:作答時帶入唐·諾曼(Don Norman)人因設計的「強迫功能(Forcing Functions)」與「互鎖(Interlocks)」,或新鄉重夫之「源流檢驗(Source Inspection)」,能讓閱卷委員一眼看出非門外漢。
- 舉例陷阱迴避:避免舉出「作業標準書(SOP)」、「標語貼紙」或「彈出確認對話框」等仰賴人員主觀注意力的軟性措施;真正的防呆設計必須具備機械或系統邏輯的不可逆性與強制性。
- 篇幅配置原則:定義佔分約 ,兩實例各佔約 。舉例時務必寫出「若無防呆會發生何種錯誤」與「防呆如何藉由物理/邏輯阻斷錯誤」。