系統取得、敏捷交付與 UX
題面來自台大官方試卷；解析與逐項自評標準（rubric）為本站依已複查來源整理的非官方內容，策略申論容許有條件且有證據的替代論點。
考古題證據邊界： 考古題只證明此範圍曾出現；題面均為申論或開放題，答案非官方，課程練習採 rubric self-review，絕不進自動計分或完整模擬考。
第一次接觸也沒關係
這堂先懂這些詞
先記住白話意思，不必急著背英文。看到正文時，再把正式名稱接回來。
自建／採購／委外／訂閱服務
也會看到：build、buy、outsource、SaaS分別是自己開發、買現成軟體、請外部廠商執行，以及按期訂閱雲端軟體。
- 生活例子：
- 自己煮、買調理包、請外燴、訂月費餐盒。
- 別搞混：
- 委外只轉移執行，不會把需求與治理責任一起丟掉。
Scrum
也會看到：Scrum framework用短週期、透明檢查與調整來處理複雜工作的敏捷框架。
- 生活例子：
- 每兩週完成可試用的小改版，再依回饋調整。
- 別搞混：
- 不是一套固定瀑布流程，也不是每天站會的別名。
單元／整合／系統／使用者驗收測試
也會看到：unit testing、integration testing、system testing、UAT依序檢查小零件、零件介面、整套系統，以及業務是否願意接受。
- 生活例子：
- 先測水龍頭、再測整段水管、再測全屋供水，最後由屋主驗收。
- 別搞混：
- 全部技術測試通過仍可能做錯需求。
使用者體驗
也會看到：UX、User Experience人在使用產品前、中、後的整體感受與完成目標的容易程度。
- 生活例子：
- 網路購票是否找得到班次、看得懂價格並順利付款。
- 別搞混：
- 不只是畫面漂亮。
逐項自評標準
也會看到：rubric、評分規準把好答案拆成一條條可以自行確認的要點，幫你檢查論證是否完整。
- 生活例子：
- 像交報告前用清單確認有定義、理由、例子和限制。
- 別搞混：
- 它不是官方標準答案，也不代表勾選後就取得正式分數。
以 6 題已核對題面為範圍證據，建立「定義→機制→條件與權衡→案例」的申論骨架。所有答案與 rubric 均為非官方自評材料，不提供單一標準論點或自動計分。
先抓住這幾件事
- 比較 build、buy、outsource 與 SaaS
- 解釋敏捷角色與產出物
- 用測試、需求與 UX 降低交付風險
先想像這個場景
餐廳裝修與試營運
自建、採購或委外各有責任邊界；開幕前要逐層測試設備、動線與顧客體驗。
先別急著背名詞，花十秒想一想：
如果兩個組織買了同一套技術，結果會必然相同嗎？先列出至少兩個會改變結果的條件，再往下對照。
把故事換成管理語言
| 生活中的角色 | 對應到 | MIS 概念 |
|---|---|---|
| 決定自行施工、買套裝或委託承包商 | Build/buy/outsource/SaaS sourcing decision | |
| 本週施工清單與每天同步阻礙 | Sprint Backlog 與 Daily Scrum | |
| 先測單一設備，再測整體動線與店主驗收 | Unit、integration、system/UAT testing | |
| 顧客試走、觀察迷路與等待點 | User-centered design 與 usability evaluation |
題目出現這些字，先想到
- 先界定題目名詞與分析單位。
- 再寫出因果機制，不只列工具名稱。
- 補上適用條件、風險與替代方案。
- 最後用題目案例驗證，並指出比喻或主張的限制。
1.系統取得先比較策略與內部能力
系統取得（system acquisition）的四種基本選擇：Build（自行開發）提供最大的客製化和控制權，但需要技術團隊和時間；Buy（套裝軟體/COTS）加快導入速度，但需要接受標準流程，客製化增加維護成本；Outsource（委外開發）轉移執行責任但不轉移管理責任，需要明確的 SLA 和驗收標準；SaaS（軟體即服務）以訂閱制使用雲端軟體，快速導入、低前期投資，但長期 TCO 可能更高且有供應商依賴風險。 選擇的核心判斷依據是 strategic uniqueness（策略獨特性）：如果這個系統是企業的核心差異化來源（例如 Netflix 的推薦演算法），自建可以保護競爭優勢。如果是 commodity 功能（例如人資薪資計算、電子郵件），Buy 或 SaaS 通常更經濟。但這不是二選一：很多中大型企業用 hybrid 策略——核心系統自建、周邊系統 SaaS、特定模組委外。 TCO（Total Cost of Ownership）分析是考試高頻考點。TCO 不只是授權費或訂閱費，還包括：implementation（導入費用：顧問、資料遷移、整合）、training（培訓費用）、customization（客製化）、maintenance（維護與升級）、opportunity cost（導入期間的營業損失）、exit cost（未來轉換供應商的成本）。很多企業只看前期成本而忽略長期維護和退出成本，導致 TCO 估計偏低。 考試提醒：不要只寫「應該用 SaaS」或「應該自建」，要列出判斷依據（strategic uniqueness、能力、成本、風險）和條件限制。
- 四種取得方式：Build（控制最大）、Buy（導入最快）、Outsource（轉移執行）、SaaS（低前期投資）
- 選擇依據是 strategic uniqueness：核心差異化傾向自建，commodity 傾向 Buy/SaaS
- TCO 不只是授權費：還包括導入、客製化、培訓、維護、退出成本
- Outsource 轉移執行但不轉移管理責任——需要明確 SLA 和驗收標準
- Hybrid 策略（核心自建 + 周邊 SaaS）是中大型企業的常見選擇
2.Scrum 是經驗式框架，不是職稱清單
Scrum 是最廣泛使用的敏捷框架，它基於「經驗主義」（empiricism）——承認無法在專案開始前就知道所有需求和風險，所以用短迭代（Sprint，通常 2-4 週）來逐步學習和調整。Scrum 的三大支柱是：Transparency（所有人看到相同的資訊，例如公開的 Sprint Backlog 和 Burndown Chart）、Inspection（定期檢視進度和產出，例如 Sprint Review）、Adaptation（根據檢視結果調整計劃，例如 Sprint Retrospective 改善流程）。 Scrum 定義了三個角色：Product Owner（PO）對「做什麼」負責——管理 Product Backlog（按商業價值排列的需求清單），決定每個 Sprint 做哪些 item。Scrum Master（SM）對「框架是否有效運作」負責——排除團隊的阻礙（impediments），協助團隊和組織理解 Scrum 的原則。Developers 對「如何做」和「完成可用的產品增量」負責——他們自組織（self-managing），自行決定如何完成 Sprint Backlog 中的 item。 五個 Events 構成 Scrum 的節奏：Sprint（時間箱）、Sprint Planning（決定本 Sprint 目標和工作項目）、Daily Scrum（每天 15 分鐘同步進度和阻礙，不是主管彙報會）、Sprint Review（向 stakeholders 展示成果、蒐集反饋）、Sprint Retrospective（團隊回顧如何改善流程）。每個 event 都服務於 inspection-adaptation 循環。 Definition of Done（完成定義）是品質的最低門檻——一個 item 必須滿足 DoD 才能算完成。DoD 通常包括：程式碼已 code review、通過自動化測試、文件已更新、部署到 staging 環境驗證。如果 DoD 不夠嚴格，就會產生 undone work（技術債），在未來造成問題。 考試常見：比較 Scrum 與 Waterfall、分析 Scrum 角色的責任邊界、辨識 Scrum 反模式。
- Scrum 三支柱：Transparency、Inspection、Adaptation——承認不確定性，用短迭代學習
- PO 對「做什麼」負責（商業價值排序），SM 對「框架運作」負責，Developers 對「怎麼做」負責
- Daily Scrum 是團隊同步，不是主管點名——15 分鐘，focus on impediments
- Sprint Review 不是 demo show——是蒐集 stakeholder feedback 來調整 Product Backlog
- Definition of Done 是品質門檻——不夠嚴格會累積 undone work（技術債）
3.測試層級回答不同風險
軟體測試的目的不是證明「沒有 bug」（那是不可能的），而是在可接受的成本內降低交付風險。不同的測試層級回答不同的問題：Unit test 問「這個函數的邏輯正確嗎？」，Integration test 問「這兩個模組的介面相容嗎？」，System test 問「整個系統從頭到尾跑得通嗎？」，UAT（User Acceptance Test）問「這是使用者要的東西嗎？」。 Test pyramid 模型建議底層多（unit test：快速、便宜、穩定、容易定位問題）、中層適中（integration test）、頂層少（E2E test：慢、脆弱、難定位問題但最接近使用者行為）。反轉的 ice cream cone 模式（大量 E2E、少量 unit）會導致回饋週期長、維護成本高、失敗時難以定位根因。 一個考試常考但考生容易搞混的區分是 verification vs validation：Verification 問「Are we building the product right?」——程式碼是否正確實現了規格書的要求。Validation 問「Are we building the right product?」——我們做出來的東西是否真的是使用者需要的。測試主要處理 verification，而 validation 需要使用者參與（UAT、usability test、beta test）。一個完美通過所有測試的系統，如果需求本身是錯的，仍然是一個沒用的系統。 缺陷的修復成本與發現時間成正比——需求階段發現的問題可能只需要修改文件，上線後才發現的相同問題可能需要修改系統、資料遷移和使用者重新培訓。所以「測試越早開始越好」不只是口號，是有經濟邏輯的。 考試提醒：答題時區分各層測試的目的和適用場景，不要只列名稱。解釋為什麼 unit test 在底層、什麼問題它抓不到（介面問題、系統整合問題、需求偏差）。
- 各層測試回答不同問題：unit 看邏輯、integration 看介面、system 看端到端、UAT 看業務可接受性
- Test pyramid：底層多（unit, 快且便宜）、頂層少（E2E, 慢且脆弱）
- Verification（做對了嗎？）vs Validation（做對的東西了嗎？）是高頻考點
- 缺陷修復成本與發現時間成正比——早發現便宜，晚發現代價高
- 測試通過不代表需求正確——通過所有測試但需求錯了，系統仍然沒用
4.需求與估算隨資訊增加而細化
需求表達有多種工具，各有適用場景：User story（作為〈角色〉，我想要〈目標〉，以便〈價值〉）強調使用者視角和商業價值，適合敏捷開發的需求溝通，但它不是詳細規格，需要搭配 acceptance criteria 和 conversation 才完整。Use case 由 Jacobson 提出，詳細描述 actor 與系統的互動流程（主要流程、替代流程、例外流程），適合需要精確規格的場景。兩者不是互斥的——user story 適合初期溝通和優先排序，use case 適合需要詳細規格的高風險功能。 估算（estimation）是預測而非承諾。Cone of uncertainty 指出：專案初期的估算誤差可能是 4 倍（即實際成本可能是估算的 0.25x 到 4x），隨著專案進展和資訊增加，誤差範圍會收窄。所以好的估算不是給一個精確數字，而是給一個 range 並標明 uncertainty。 常用估算方法：(1) Function Point Analysis（FPA）——從使用者可見功能（external inputs/outputs、inquiries、internal files、external interfaces）計算功能點，再乘以生產力係數得到工時。FPA 是需求導向的，不依賴技術選擇。(2) COCOMO II——根據程式碼規模（KLOC 或 function points）、scale factors（前例、彈性、團隊凝聚力、process maturity、架構風險解決程度）和 cost drivers 估算工時。(3) Story points（敏捷）——相對估算，用 Fibonacci 數列（1, 2, 3, 5, 8, 13）表示相對大小和複雜度。Story points 不是時數——它們衡量的是不確定性和複雜度，不是工作量。 考試常見：比較不同估算方法的適用條件、分析為什麼估算常常偏低（optimism bias, scope creep, unknown unknowns）。
- User story 適合溝通和排序，Use case 適合詳細規格——兩者互補不互斥
- 估算是預測不是承諾——好的估算給 range 和 uncertainty，不是精確數字
- Cone of uncertainty：專案初期估算誤差可達 4 倍，隨資訊增加而收窄
- FPA 是需求導向（不依賴技術），COCOMO 是規模導向，Story points 是相對複雜度
- Story points 不是時數——它衡量不確定性和複雜度，不應拿來當績效指標
一起搭作答骨架
範例 1：如何回答「系統取得、敏捷交付與 UX」的比較題？
- 定義比較軸與分析單位。
- 各寫一條作用機制。
- 加入至少兩項條件或風險。
- 用案例與指標驗證。
所以作答主軸是：可接受的答案不只一種；關鍵是條件透明、概念正確、推論可追蹤，並能說明限制。
範例 2：題目要求提出建議時，如何避免只列 buzzwords？
- 先指出要改善的問題。
- 說明建議如何改變流程、資訊或激勵。
- 指定責任人與衡量方式。
- 補上失敗訊號與替代方案。
所以作答主軸是：建議應包含 action、mechanism、metric 與 risk，而不是只寫「導入 AI／雲端／平台」。
這裡最容易寫偏
- 把工具名稱當成因果解釋
- 沒有說明分析層級與前提
- 只寫單一立場，不處理權衡
- 把非官方參考解析當唯一標準答案
- 引用時事卻沒有日期與來源邊界
換你快速判斷
先用自己的話說出定義、機制、條件與取捨，再展開答案。
1系統取得與成本估算：答題時先定義什麼？
先界定 系統取得與成本估算 的分析單位、核心機制與適用條件。
MIS 概念不能只背名詞；定義後必須說明它如何改變資訊、協調、成本、能力或風險。
2系統取得與成本估算：完整申論至少要補哪三類內容？
機制、條件／權衡、可觀察指標與限制。
以「主張→因果機制→成立條件→案例／指標→限制」自我檢查，合理替代論點亦可接受。
3Scrum 與敏捷交付：答題時先定義什麼？
先界定 Scrum 與敏捷交付 的分析單位、核心機制與適用條件。
MIS 概念不能只背名詞；定義後必須說明它如何改變資訊、協調、成本、能力或風險。
4Scrum 與敏捷交付：完整申論至少要補哪三類內容？
機制、條件／權衡、可觀察指標與限制。
以「主張→因果機制→成立條件→案例／指標→限制」自我檢查，合理替代論點亦可接受。
5測試層級與品質風險：答題時先定義什麼？
先界定 測試層級與品質風險 的分析單位、核心機制與適用條件。
MIS 概念不能只背名詞；定義後必須說明它如何改變資訊、協調、成本、能力或風險。
6測試層級與品質風險：完整申論至少要補哪三類內容？
機制、條件／權衡、可觀察指標與限制。
以「主張→因果機制→成立條件→案例／指標→限制」自我檢查，合理替代論點亦可接受。
7需求表達與使用者體驗：答題時先定義什麼？
先界定 需求表達與使用者體驗 的分析單位、核心機制與適用條件。
MIS 概念不能只背名詞；定義後必須說明它如何改變資訊、協調、成本、能力或風險。
8需求表達與使用者體驗：完整申論至少要補哪三類內容？
機制、條件／權衡、可觀察指標與限制。
以「主張→因果機制→成立條件→案例／指標→限制」自我檢查，合理替代論點亦可接受。
最後用考古題自評
請先完成自己的申論，再依非官方解析和逐項自評標準檢查；不使用 A–E 假選項或虛假分數。
開始本課申論自評參考來源
- Management Information Systems: Managing the Digital Firm, 17th Edition — Kenneth C. Laudon; Jane P. Laudon
- The Scrum Guide (2020) — Ken Schwaber; Jeff Sutherland
- 10 Usability Heuristics for User Interface Design — Jakob Nielsen