💻 綜合學習筆記：系統生命週期 (9626 A Level IT)
歡迎來到第 16 單元！這是 A Level 的核心概念，說明一個新的 IT 系統從簡單的構思到正式運作與維護的完整流程。想像一下建造一座摩天大樓：你不能只是開始堆磚塊，而是需要精細的規劃、設計與測試。
理解系統生命週期 (System Life Cycle, SLC) 至關重要，因為它能幫助專案經理在預算內按時交付高品質的系統。讓我們一步一步來拆解它！
16.1 系統的定義與階段
什麼是系統？
在 IT 領域中，系統 (System) 是由多個元件組成的集合，它們共同運作以實現一個共同的目標。
- 硬體系統 (Hardware system)：伺服器、顯示器和網絡電纜等元件協同工作。
- 軟體系統 (Software system)：程式與應用程式協同工作（例如：大型會計軟體包）。
- 最常見的情況是硬體與軟體的結合，再加上使用它們的人員與程序（例如：網上銀行系統）。
系統生命週期 (SLC) 的核心階段
SLC 描述了開發新系統的階段。雖然存在不同的模型，但基本階段通常遵循此順序：
- 分析 (Analysis)（了解問題）
- 設計 (Design)（規劃解決方案）
- 開發與測試 (Development and Testing)（建構系統並修復錯誤）
- 實施 (Implementation)（將新系統投入使用）
- 文件編寫 (Documentation)（撰寫手冊）
- 評估 (Evaluation)（檢查是否符合需求）
- 維護 (Maintenance)（保持系統運作並進行改進）
在較舊的模型（如瀑布式）中，這些階段的關係是順序性的，但在現代方法（如敏捷開發）中，它們經常重疊或重複。
16.2 第一階段：分析 – 了解需求
分析階段是讓你精確找出新系統必須做什麼的階段。你是在定義問題，而不是在解決問題。
研究現況的方法
分析師如何收集關於現有系統（如果有的話）和用戶需求的資訊？（記憶口訣：QIDO）
- 問卷調查 (Questionnaires)：適合快速從大量用戶收集數據。
優點：便宜、快速。缺點：回應率低，無法釐清答案。 - 訪談 (Interviews)：與關鍵利益相關者（用戶、經理）進行面對面討論。
優點：詳細，可釐清模糊的答案。缺點：耗時，可能產生訪談偏差。 - 觀察 (Observation)：觀察員工使用現有系統的情況，以了解任務實際上是如何執行的（而不僅僅是手冊上規定的方式）。
優點：能精確捕捉現有流程。缺點：員工在被觀察時工作方式可能會改變（霍桑效應）。 - 文件分析 (Document Analysis)：審查現有的文件、表格、報告和手冊。
目的：了解目前使用的輸入與輸出，並識別數據流向。
規範的內容與目的
分析階段的結果是產出詳細的規範文件：
- 用戶需求規格書 (URS)：
目的： 描述用戶希望系統達到什麼目標。它是非技術性的，專注於功能性（它做什麼）和非功能性需求（速度、安全性）。 - 系統規格書 (SRS)：
目的： 將 URS 轉譯為詳細的技術文件，概述建構系統所需的硬體、軟體和網絡需求。 - 設計規格書 (Design Specification)：
目的： 詳細說明系統將如何建構，包括模組結構、數據儲存方法、輸入/輸出格式和測試程序。這是給程式設計師的藍圖。
⛔ 常見錯誤： 不要混淆 URS（用戶想要什麼）與設計規格書（程式設計師將如何建構它）。
16.3 第二階段：設計 – 藍圖
在此階段，我們設計系統的結構，包括數據如何流動、如何儲存，以及介面看起來如何。
系統處理與數據流動
設計師使用圖表來說明結構與數據移動：
1. 系統流程圖 (System Flowcharts)： 使用標準符號（見課程大綱附錄）顯示整個系統內的作業流程，包括手動流程與硬體元件（例如：透過鍵盤輸入、在伺服器上處理、輸出至磁碟）。
2. 數據流圖 (Data Flow Diagrams, DFDs)： 顯示數據如何在系統中移動，不依賴於所使用的硬體或軟體。它們只專注於數據本身。
- 0 級（背景級）： 將整個系統顯示為單一處理程序，並說明其與外部實體（源頭/目的地）的主要輸入與輸出。
- 1 級： 將 0 級處理程序拆分為 3-7 個主要子程序，並顯示內部的數據儲存。
- 2 級： 將 1 級中的單一處理程序拆分為更詳細的細節。
數據儲存設計
保留數據的結構至關重要：
- 資料庫 (Databases)： 通常用於需要關係的複雜結構化數據（請回顧第 10 單元）。
- 檔案 (Files)： 用於臨時儲存或批次處理的簡單文字檔案或結構化檔案。
輸入表單與輸出報告
設計必須精確說明用戶將如何與系統互動：
- 輸入螢幕配置： 必須包含清晰的標題、說明、邏輯流程，以及適當的數據收集表單。重要的是，它們必須包含專為驗證與檢查 (Validation and checking) 數據而設計的欄位（例如：下拉式選單、存在性檢查）。
- 輸出螢幕配置： 資訊在螢幕上呈現的方式（例如：儀表板、表格）。
- 列印輸出配置： 指定紙本報告（例如：發票、月結單）的版面配置，確保易讀性與專業性。
16.4 第三階段：開發與測試 – 建構與檢查
此階段涉及編寫程式碼，並嚴格檢查系統是否符合需求。
測試計劃與測試數據
測試計劃 (Test plan) 是必不可少的；它詳細說明了要進行的測試、預期結果以及成功的標準。
- 需求與目的： 確保系統符合規範，並在預期和非預期的情況下運作無誤。
- 測試計劃內容： 測試案例列表、測試數據、預期結果與所需資源。
測試數據類型：
- 正常數據 (Normal Data)： 有效範圍內典型的預期數據（例如：年齡範圍為 18-65，輸入 30）。
- 極端數據 (Extreme Data)： 有效範圍邊界上的數據（例如：輸入 18 或 65）。
- 異常數據 (Abnormal Data)： 無效數據，旨在測試錯誤處理（例如：輸入 100 或 "apple"）。
測試類型
我們使用不同的方法來捕捉不同類型的錯誤：
1. Alpha 與 Beta 測試
- Alpha 測試： 在系統發布給公眾之前，由內部員工/開發人員進行。專注於尋找主要的 Bug 和崩潰問題。
- Beta 測試： 由真實環境中一大群外部真實用戶進行。專注於可用性、性能以及 Alpha 測試遺漏的小問題。
2. 白箱與黑箱測試
- 白箱測試 (White Box Testing)： 測試人員完全了解系統的內部結構、程式碼與邏輯。他們設計測試是為了專門檢查程式碼中的所有路徑與迴圈。（由開發人員執行）。
- 黑箱測試 (Black Box Testing)： 測試人員對內部運作完全不了解。他們純粹基於規範（輸入與輸出）來測試系統。（由獨立測試人員或用戶執行）。
不同測試類型的優點：
- 測試確保了強健性、安全性以及對規範的遵循。
- Beta 測試提供了寶貴的真實世界回饋，從而改善用戶體驗 (UX)。
16.5 第四階段：實施 – 上線
實施是將新系統投入實際使用並取代舊系統的過程。
系統實施方法
方法的選擇在很大程度上取決於組織的風險承受能力。別擔心，這些概念都很直觀！
- 直接轉換 (Direct Changeover)：
描述： 立即停止舊系統，新系統完全接手。
適用性： 低風險應用（例如：簡單的網站更新），或舊系統已無法使用時。
優點： 便宜、快速。缺點：若新系統失敗，風險極高。 - 平行運作 (Parallel Running)：
描述： 舊系統與新系統同時執行一段時間。數據會輸入到兩者中。
適用性： 高風險應用（例如：薪資或銀行系統）。
優點： 風險極低；如果新系統失敗，舊系統可作為備份。缺點：昂貴（雙重數據輸入）、耗時。 - 階段式實施 (Phased Implementation)：
描述： 系統逐一模組或逐一部門地引入。
適用性： 具有獨特元件的大型複雜系統（例如：人力資源、會計和庫存模組）。
優點： 員工培訓是循序漸進的；更容易隔離錯誤。缺點：過程緩慢；舊模組與新模組之間可能存在相容性問題。 - 試點實施 (Pilot Implementation)：
描述： 新系統先由一小群用戶或在一個地點（試點）使用。一旦成功，再全面推廣。
適用性： 多分部組織（例如：連鎖超市先在一家門市測試新收銀系統）。
優點： 錯誤僅限於小範圍；培訓先集中在少數用戶。缺點：試點組可能會感到被挑出；延遲了全球部署。
16.6 第五與第六階段：文件編寫與評估
文件編寫：為什麼需要它？
文件對於未來的維護和用戶採用至關重要。
1. 需求與設計文件：
- 包括 URS、系統規格書與設計規格書。
- 需求： 提供系統目標與結構的歷史記錄。
2. 技術文件：
- 內容： 程式碼、流程圖、DFD、硬體安裝細節、檔案結構（數據字典）。
- 需求： 供程式設計師和工程師用於維護和未來的升級。
3. 用戶文件：
- 內容： 教學課程、常見問題解答 (FAQs)、故障排除指南、錯誤訊息指南。
- 需求： 幫助終端用戶正確操作系統。
4. 行銷文件：
- 內容： 推廣材料、功能清單、定價。
- 需求： 向潛在客戶銷售產品。
評估：檢查成功與否
實施後，系統會經過評估，以查看是否達到最初的目標。
評估涉及評估以下項目：
- 效率： 處理數據速度是否夠快？
- 易用性： 用戶介面是否直觀？
- 適當性： 是否實現了最初預期的用途？
評估技術：
- 對照規格書檢查： 最終系統是否符合 URS 中列出的所有要點？
- 滿足用戶需求： 新系統是否解決了用戶最初的問題？
- 用戶回饋： 透過問卷或訪談收集關於可用性和滿意度的客觀意見。
16.8 軟體開發方法
SLC 可以使用各種模型來實施。所選模型的影響範圍包括靈活性、速度與成本。
1. 瀑布模型 (Waterfall Model)
- 階段/流程： 嚴格的順序流程（分析 -> 設計 -> 開發 -> 測試 -> 實施）。一個階段必須完成才能開始下一個階段。
- 優點： 易於管理，階段清晰，適合需求固定的中小型簡單專案。
- 缺點： 極度僵化；開發開始後，若要回頭更改需求非常困難。
2. 迭代/增量模型 (Iterative/Incremental Models)（如敏捷開發）
- 階段/流程： 系統在小型的重複週期（迭代）中開發。每個週期交付系統的一小部分（增量）。
- 敏捷開發 (Agile)： 一種專注於快速交付可運作軟體，並與客戶持續協作的理念。
- 優點： 客戶回饋整合得早且頻繁；對於變更的需求具有高度靈活性。
- 缺點： 缺乏最終完整的整體文件；存在範圍蔓延（Scope Creep，專案不斷擴大）的風險。
3. 快速應用程式開發 (RAD)
- 階段/流程： 專注於快速迭代與深度用戶參與。大量使用原型工具與自動化程式碼生成器來加快開發速度。
- 優點： 交付極快；因持續參與而獲得高用戶滿意度。
- 缺點： 需要高技能的開發人員與特定的工具；可能為了速度而犧牲系統品質。
16.9 原型法 (Prototyping) – 構建樣板
原型 (Prototype) 是系統的工作模型，通常專注於用戶介面，有助於在最終系統建立前釐清需求。
原型類型
- 演進式 (Evolutionary)： 原型不斷被精煉與擴展，直到成為最終的運作系統。
必要性： 用於初始需求模糊的專案。 - 增量式 (Incremental)： 最終系統的不同部分（增量）被開發為獨立的原型，然後合併。
必要性： 用於元件可獨立建構的大型系統。 - 拋棄式 (Throwaway)： 原型快速建立只是為了釐清需求，隨後被拋棄。最終系統根據學到的經驗教訓從零開始建立。
必要性： 防止在複雜的最終系統中做出拙劣的設計選擇。 - 快速原型 (Rapid)： 建立快速模型的通用術語，通常專注於速度而非完整功能。
原型法的優點： 降低風險；用戶可提早測試可用性；更好的需求收集。缺點： 用戶可能將原型誤認為最終系統；如果原型被拋棄，時間可能會被浪費。
16.10 第七階段：維護 – 保持系統活力
維護發生在系統的整個生命週期中。這不僅僅是修復問題，還包括改進系統。
維護類型 (四個 P 與 C)
維護是必要的，因為系統總是會遇到變化、錯誤或改進的機會。
- 更正性維護 (Corrective Maintenance)：
為什麼需要： 修復測試階段未發現的 Bug 或錯誤。（例如：報告總計計算錯誤。）
如何執行： 除錯 (Debugging) 與套用修補程式。 - 適應性維護 (Adaptive Maintenance)：
為什麼需要： 更改系統以適應新環境或符合新法律/法規。（例如：更新系統以在新作業系統上執行，或遵循新的稅率。）
如何執行： 修改與環境互動的系統元件。 - 完善性維護 (Perfective Maintenance)：
為什麼需要： 根據用戶回饋提高系統的效率、可用性或性能。（例如：讓程式執行速度更快或提高選單的清晰度。）
如何執行： 優化程式碼、重新設計模組。 - 預防性維護 (Preventive Maintenance)：
為什麼需要： 透過預防未來問題的變更來增加系統的可靠性與壽命。（例如：重構混亂的程式碼或改善文件編寫。）
如何執行： 審查與重組內部程式碼模組。
我們已經涵蓋了 IT 系統的整個旅程！請確保你能定義、描述並比較這些階段中所有方法的優缺點。