110 高普考高考三級 資訊處理 系統專案管理 考古題詳解

核心觀念

DevOps 是結合 **Development（開發）**與 **Operations（維運）**的軟體交付方法與文化。它以跨職能合作、自動化及持續回饋，縮短軟體從需求變更到上線的時間，並提升交付品質、部署穩定性與問題復原能力。

DevOps 不只是導入某一套工具，也不等於單純「開發完成後交給維運」。其核心是讓開發、測試、資安與維運人員共同負責軟體生命週期，透過自動化流程及監控資料持續改善。

解題方法

題目分成兩部分：先說明 DevOps 的意義，再依軟體開發生命週期，說明如何落實。作答時可依「文化與協作、流程自動化、持續回饋」三項原則，逐階段交代執行方式。

一、需求與規劃

開發、維運及相關人員共同釐清需求、服務水準、容量、可用性、資安與法規要求，並將工作拆成可逐步交付的功能。將需求、程式碼、測試案例及部署設定納入版本管理，使變更可追蹤、可審查。

二、設計與開發

採用小批次、頻繁整合的開發方式，開發人員提交程式碼後，透過版本控制與程式碼審查管理變更。部署環境及基礎設施設定可採程式碼管理（Infrastructure as Code），以減少手動設定造成的環境差異。

三、建置與測試

建立持續整合（Continuous Integration, CI）流程：程式碼提交後，自動執行建置、單元測試、整合測試、程式碼品質檢查與弱點掃描。若檢查失敗，應及時通知團隊並修正，避免缺陷累積到後期。

四、發布與部署

建立持續交付（Continuous Delivery, CD）或持續部署（Continuous Deployment）流程，將通過檢查的版本自動部署至測試、預備或正式環境。

核心觀念

**完全測試（Complete Testing）**是指測試涵蓋程式所有可能的輸入、執行路徑及其組合，藉此確認程式在每種情況下都能產生正確結果，且不發生錯誤。

這個概念考查的是軟體測試的測試範圍與可行性。完全測試並不等於「測了很多案例」或「所有功能都按過一遍」；若仍有輸入值、分支或輸入組合未測，就不能稱為完全測試。

解題方法

作答時可依序說明完全測試的定義、執行方式，以及實務可行性；再用小算盤展示輸入範圍與測試組合如何快速擴大。

以具有兩個輸入欄位及四種基本運算的小算盤為例，假設每個輸入欄位都可輸入任意 32 位元浮點數，並可選擇加、減、乘、除：

1. 列出輸入與操作範圍：包括兩個數值、運算子、按鍵順序，以及清除、正負號、小數點等操作。
2. 列出特殊情況與預期結果：例如除以零、輸入超出可表示範圍的數值、負數運算、連續輸入運算子、小數精度，以及四捨五入或溢位處理。
3. 測試各種輸入與操作組合：逐一檢查輸入值、運算子及操作順序所形成的情境，並比對結果是否符合規格。
4. 檢查程式路徑與錯誤處理：例如除以零時是否顯示錯誤訊息、清除鍵是否歸零，以及輸入錯誤後是否能恢復正常計算。

這種測試必須依賴明確的規格與預期結果；若規格未定義某種輸入的處理方式，就無法判斷該情況的結果是否正確。

小算盤的完全測試範例

假設每個數值輸入欄位可接受 $10^{12}$ 種不同值，並有四種運算子。光是兩個輸入值與運算子的組合數，就有：

核心觀念

本題考查 Putnam 的軟體生命週期管理模型（SLIM）中，開發時程與總工作量呈非線性關係：時程壓縮時，工作量不是按比例增加，而是急遽上升。

在軟體規模與生產力等條件固定時，Putnam 軟體方程式可寫成：

其中，$S$ 為軟體規模、$E$ 為總工作量、$T$ 為開發時程，$C_k$ 為反映生產力與環境的係數。固定 $S$ 與 $C_k$，整理可得：

因此，若原定工期為 $T_0$、原工作量為 $E_0$，縮短後的工期為 $T_1$，則：

解題方法與計算

原專案工期為 2 年，即 24 個月。以原工作量 $E_0$ 為基準，分別代入縮短後工期：

例如，若原規劃需要 100 人月，按模型估算，22 個月約需 142 人月，20 個月約需 207 人月，12 個月約需 1,600 人月。這些是模型在固定軟體規模與生產力假設下的相對估計，並非保證能以增加人力達成的工期。

可行性與技術、管理處理

22 個月： 相較原定 24 個月，只縮短 2 個月，模型估計工作量約增加 42%。若專案範圍穩定，且尚有調整流程、優先排序與支援資源的空間，實務上可能可行；但仍須評估關鍵路徑、依賴關係與品質風險，不能只按比例增加人數。

核心觀念

**軟體演進（Software Evolution）**是指軟體交付使用後，因應使用者需求、組織流程、法規、技術環境或缺陷修正而持續修改與發布新版本的活動。軟體並非交付後就固定不變；若實際環境持續改變，系統也必須演進，才能繼續滿足使用者需求。

**軟體演進定律（Laws of Software Evolution）**是 Lehman 與 Belady 根據長期軟體系統的演進現象歸納出的經驗法則，主要說明系統變更、複雜度、品質、成長與團隊活動之間的關係。這些定律是經驗觀察，不是每個系統都必然精確符合的數學公式。以下列出八項常見定律。〔Lehman 軟體演進定律整理]〕

軟體演進定律

1. 持續變更定律（Continuing Change） 若一個系統在真實環境中持續使用，卻不持續調整，它會逐漸失去實用性。需求與環境會改變，因此軟體也必須修改，才能維持對使用者的價值。

2. 複雜度增加定律（Increasing Complexity） 系統經過多次修改後，結構與相依關係容易變得複雜。若不投入重構、簡化架構等工作，後續修改會愈來愈困難，錯誤風險也會增加。

3. 自我調節定律（Self-Regulation） 軟體演進的整體趨勢，例如版本成長與變更活動，常呈現一定程度的規律性，並非完全任意。管理者可觀察歷史資料與回饋，協助規劃後續演進。

4. 組織穩定度守恆定律（Conservation of Organizational Stability） 長期演進系統的平均開發活動量，通常會受組織可投入的人力、資源與工作能力限制。單靠不斷增加需求，無法無限提高團隊的交付速度。

5. 熟悉度守恆定律（Conservation of Familiarity） 每一版本的變更規模，受到團隊對系統的熟悉程度所限制。若一次變更過多，團隊較難理解其影響，也較難可靠地完成設計、實作與驗證。

6. 持續成長定律（Continuing Growth） 為維持使用者滿意度，系統通常需要持續增加功能或改善能力，以回應新的需求。若系統長期不成長，可能逐漸無法支援使用者的工作。

7. 品質下降定律（Declining Quality） 若系統未能持續適應環境變化，或未管理其內部結構，使用者感受到的品質會逐漸下降。這可能表現在可靠性、效能、可維護性或使用便利性上。

8. 回饋系統定律（Feedback System） 軟體演進是多層次的回饋控制過程，需持續取得使用者、維運人員、測試與開發團隊的回饋，據以決定變更內容並驗證結果。

解題方法

本題分成兩部分作答：

• 先說明軟體交付後仍須因應環境與需求改變而持續修改，再列舉至少三項定律並解釋其意涵。
• 再比較開發團隊與演進團隊採用不同方法時，兩種流程對交接成果的要求有何落差。

答第二部分時，應聚焦在方法所產生的文件、測試、程式結構與工作流程，以及這些成果能否支援接手團隊的演進工作。題目所述兩種交接落差與軟體演進課程常見的 handover problems 相符。〔軟體演進課程教材]〕

兩種團隊方法不一致的影響