單元 3：系統開發 - 建構數碼世界

未來的 IT 架構師們，你們好！歡迎來到「系統開發」章節。如果覺得這聽起來很深奧，別擔心；這其實只是在探討我們開發新軟件、應用程式或複雜商業 IT 系統時，所遵循的那套井然有序的流程。

你可以把系統開發想像成蓋摩天大樓。你不能直接開始砌磚！你需要規劃、許可證、預算以及持續的測試。本章將教導你從零開始構建穩健且成功的 IT 解決方案所需的關鍵步驟和工具。理解這個流程是整個資訊科技領域的基礎。讓我們開始吧！

1. 系統開發生命週期 (SDLC) 簡介

系統開發生命週期 (Systems Development Life Cycle, SDLC) 是一套結構化的框架，定義了建立、修改或更換資訊系統時所涉及的各個階段。它確保系統能高效地構建，滿足用戶需求，並控制在預算範圍內。

SDLC 的關鍵階段

SDLC 通常分為一系列強制性的順序步驟。我們將詳細探討每一個階段，但以下是基本流程：

  1. 分析與可行性研究 (需要做什麼？我們能做到嗎？)
  2. 設計 (系統看起來如何？運作方式如何？)
  3. 實施 (構建與測試)
  4. 評估與維護 (系統運作順暢嗎？我們如何維持其運作？)

快速回顧： SDLC 就像建構 IT 系統的藍圖。它確保在施工前、施工中以及施工後，每一個環節都考慮周全。

2. 第一階段：調查、分析與可行性研究

這可以說是整個過程中最重要的階段。如果你在這裡弄錯了需求，整個系統最終將會失敗。

2.1 可行性研究 (我們能做到嗎？)

在啟動專案之前，必須進行可行性研究 (Feasibility Study)，以確定提議的系統是否切實可行。這能防止公司在不可能成功的項目上浪費資金。

我們使用助記符 TELOS 來檢查可行性的五個領域：

  • T (Technical) 技術可行性： 我們是否有必要的硬件、軟件和技術能力來構建此系統？
  • E (Economic) 經濟可行性： 系統是否符合成本效益？預期的收益（如增加利潤、節省時間）是否大於開發成本？(這通常稱為「成本效益分析」)
  • L (Legal) 法律可行性： 系統是否遵守法律法規（例如：個人資料保護、無障礙法規）？
  • O (Operational) 操作可行性： 系統在組織現有的流程和文化中是否真的可行？員工會使用它嗎？
  • S (Schedule) 時間可行性： 專案能否在要求的時間表內完成？

記憶小貼士： 想像你告訴上司：「我已經檢查過專案的 T E L O S 了，它是可行的！」

2.2 事實調查技術 (他們需要什麼？)

分析的目標是準確找出用戶的需求。在這個過程中，系統分析師就像偵探一樣，收集關於現有系統的事實以及新系統的需求。

以下是常見的事實調查技術：

  1. 訪談 (Interviews)： 與用戶、管理層和利益相關者進行面對面會議。
    • 優點： 可以進行詳細提問並即時釐清問題。
    • 缺點： 耗時；用戶可能會誇大問題。
  2. 問卷調查 (Questionnaires)： 向大量用戶發放問卷（對大型組織特別有用）。
    • 優點： 從多人收集數據的快速方法；結果容易量化。
    • 缺點： 沒有後續跟進或釐清答案的機會。
  3. 觀察法 (Observation)： 觀察用戶在現有系統中執行任務的過程。
    • 優點： 收集用戶實際在做什麼的數據，而不僅僅是他們口頭說的。
    • 缺點： 如果用戶知道自己被觀察，可能會改變行為（霍桑效應）。
  4. 文件分析 (Document Analysis)： 研究現有的手冊、表格、報告和程序。
    • 優點： 為當前的流程和數據流提供堅實、具體的證據。
    • 缺點： 文件可能過時或不完整。

重點總結： 分析定義了「做什麼」。事實調查工具有助於明確定義用戶需求，從而得出用戶需求說明書 (User Requirements Specification, URS)。

3. 第二階段：設計

設計階段將「分析階段」得出的「做什麼」轉化為「如何做」。系統分析師會為系統組件建立詳細的藍圖。

系統設計的組件
  1. 輸入設計： 數據如何輸入（例如：設計數據輸入介面、表格、驗證規則）。
  2. 輸出設計： 資訊如何呈現（例如：設計報告、螢幕佈局、摘要）。
  3. 檔案/資料庫設計： 設計數據儲存結構（例如：決定所需的資料表和欄位、數據之間的關係）。
  4. 處理/演算法設計： 指定電腦處理數據時遵循的邏輯和步驟。
  5. 使用者介面 (UI) 設計： 創建用戶與系統互動的視覺風格和感受，確保其易用性且符合無障礙要求。

你知道嗎？ 一個好的設計只需要最少的培訓，因為系統感覺直觀。而糟糕的設計會讓一個優秀的程式變得無法使用！

4. 第三階段：實施與測試

此階段涉及系統的實際創建（編碼）、設定，並在向用戶推出之前確保其運作正確。

4.1 測試策略

測試對於在系統上線前發現並修正錯誤 (Bugs) 至關重要。

  • 模組/單元測試 (Module/Unit Testing)： 測試程式碼的個別部分（模組），確保它們能獨立運作。
  • 整合測試 (Integration Testing)： 測試不同的模組在連結時是否能正確協作。
  • 系統測試 (System Testing)： 將整個系統視為一個整體進行測試，查看是否符合分析階段指定的所有要求。
  • 驗收測試 (Acceptance Testing/User Testing)： 由未來用戶（客戶）進行的測試，確保系統符合他們的需求並準備好部署。如果驗收測試失敗，系統將退回進行修正。

    • 起初覺得困難別擔心： 想像測試汽車。單元測試就是分別檢查引擎、煞車和方向盤。整合測試是檢查煞車是否能確實讓輪子停下來。系統測試就是開著整台車檢查性能。驗收測試則是買家進行最後的試駕！

    4.2 安裝與轉換方法

    測試完成後，新系統必須取代舊系統（遺留系統，Legacy System）。有四種主要的方法來完成這項工作：

    1. 直接轉換 (Direct Changeover/Plunge)： 立即關閉舊系統，並啟用新系統。
      • 優點： 最便宜、最快捷。
      • 缺點： 風險最高。如果新系統失敗，沒有備份方案。
    2. 平行運行 (Parallel Running)： 舊系統和新系統同時運行一段時間。
      • 優點： 風險極低。可以比較數據，如果新系統失敗，舊系統仍在運作。
      • 缺點： 需要雙倍工作量，營運成本高（員工必須將數據輸入兩套系統）。
    3. 階段式實施 (Phased Implementation)： 分區塊或分模組地引入新系統。
      • 優點： 讓用戶有時間慢慢適應，並提供時間修復每個階段的錯誤。
      • 缺點： 可能會很緩慢，且新舊部分之間的整合可能很複雜。
    4. 試點運行 (Pilot Running)： 新系統先在組織中的某個特定部門或分支機構試行。
      • 優點： 如果發生問題，影響僅限於小範圍。在全面推廣前能提供極佳的用戶反饋。
      • 缺點： 試點部門的員工壓力很大。

    避免常見錯誤： 平行運行是指同時運行「兩套系統」。階段式運行是指每次只實施「新系統的一個部分」。

    5. 第四階段：評估與維護

    最後階段確保系統在其生命週期內持續滿足組織的需求。

    5.1 評估

    系統安裝後，會進行正式評估，根據原始的用戶需求說明書 (URS) 和分析階段設定的初步目標來檢查其性能。

    主要的問題包括：

    • 系統是否滿足了功能需求？
    • 系統是否足夠可靠且快速？
    • 系統是否易於使用且易於維護？
    5.2 維護類型

    系統一旦投入使用，始終需要維護以保持其相關性並確保無誤。

    1. 更正性維護 (Corrective Maintenance)： 修復系統上線後發現的錯誤和漏洞。(如果測試徹底，這類維護發生的頻率應較低。)
    2. 適應性維護 (Adaptive Maintenance)： 修改系統以應對環境變化，例如新的作業系統、新的法律要求或業務政策變更。
    3. 完善性維護 (Perfective Maintenance)： 根據用戶反饋改善系統性能、可用性或效率（例如：加快報告生成速度、優化螢幕佈局）。

    重點總結： 維護是一個連續的循環。它通常會回到分析階段，定義升級所需的新要求。

    6. 系統開發方法論

    SDLC 定義了步驟，但方法論 (Methodology) 定義了執行這些步驟的*順序*和*方式*。

    6.1 瀑布模型 (Waterfall Model - 傳統方法)

    瀑布模型是一種順序性的線性設計過程。每個階段必須在開始下一個階段之前完全完成並存檔。它嚴格地向下流動，就像瀑布一樣。

    類比： 嚴格按照原始藍圖建造房屋。

    • 優點： 易於管理，文件清晰，適用於需求已固定且不太可能變更的專案。
    • 缺點： 非常不靈活。如果在設計或實施階段後期發現需求錯誤，回頭修復分析階段的代價非常昂貴且困難。用戶反饋通常接收得太晚。
    6.2 迭代/演進模型 (Iterative/Evolutionary - Agile 方法)

    迭代模型（如 Agile 敏捷方法）將開發過程拆分為小型、快速的循環（迭代）。快速建立一個小版本的系統，進行測試並交由用戶審查，然後重複此過程以添加更多功能。

    類比： 烘焙蛋糕時，每加入一種重要配料後就試吃一次，允許在最終產品完成前進行調整。

    • 優點： 靈活性高，需求可以輕易更改，持續的用戶反饋確保最終產品精準滿足需求，用戶能很快獲得一個可運作的系統（儘管只是基礎版）。
    • 缺點： 需要客戶強有力的溝通和參與。文件有時可能會過於倉促或不完整。預計總時間和成本可能比較困難。

    快速回顧：
    瀑布模型： 剛性，適用於明確的需求，順序步驟。
    敏捷模型： 靈活，適用於變動的需求，使用循環/迭代。