110 司法特考三等 檢察事務官電子資訊組 系統分析 考古題詳解

核心觀念

本題考查軟體品質屬性中的「再使用性」與「可攜性」，重點包括：

1. 兩者的正式定義。
2. 兩者在軟體架構設計上的作用。
3. 再使用性與可攜性的差異。
4. 如何將抽象的品質屬性轉化為可觀察、可計算的度量指標。

依 ISO/IEC 25010 軟體產品品質模型：

• 再使用性屬於可維護性相關品質特性。
• 可攜性屬於產品品質特性，強調軟體跨越不同環境的能力。

雖然題目以「品質屬性」及「品質因數」描述，但答題時應掌握核心：再使用性著重「既有軟體資產能否被重複利用」，可攜性著重「軟體能否移轉至不同環境並正常運作」。

---

一、再使用性（Reusability）

1. 定義

再使用性是指軟體元件、模組、服務、類別、函式庫、框架、設計模式、測試案例或其他軟體資產，能否在同一系統的不同位置，或不同系統、不同專案中被重複使用，以減少重複開發工作。

簡言之，再使用性回答的是：

「這項軟體資產能否再次拿來使用？」

具備良好再使用性的軟體元件通常具有下列特性：

• 功能明確，責任單一。
• 模組間耦合度低。
• 介面清楚且穩定。
• 內部實作與外部使用方式分離。
• 依賴關係少。
• 文件完整。
• 測試充分。
• 可透過參數化或組態設定適應不同需求。
• 不過度依賴特定作業系統、資料庫或硬體環境。

例如，將「使用者身分驗證」設計成獨立服務，提供標準化 API，則該服務可被入口網站、行動應用程式及內部管理系統共同使用。

---

2. 再使用性的實務度量

再使用性不能只以「程式碼行數少」判斷，應同時考量使用次數、適用範圍、整合成本及重用後品質。

（1）程式碼再使用率

可用於衡量一個專案中，有多少程式碼來自既有元件。

$$\text{程式碼再使用率} = \frac{\text{再使用的程式碼量}}{\text{系統總程式碼量}} \times 100\%$$

例如：

• 系統總程式碼量：100,000 行。
• 其中 30,000 行來自既有共用函式庫或元件。

則：

$$\text{程式碼再使用率} = \frac{30,000}{100,000} \times 100\% = 30\%$$

此指標適合比較不同專案的重用程度，但不能單獨代表再使用品質。若重用程式碼整合困難、缺乏文件，實際再使用效益仍然很低。

（2）元件重用次數

計算一個元件在不同模組、不同產品或不同專案中被使用的次數。

例如某一個電子簽章元件被：

• 入口網站使用 1 次；
• 行動 App 使用 1 次；
• 內部公文系統使用 1 次。

則其跨系統重用次數為 3 次。

若以平均值表示，可計算：

$$\text{平均重用次數} = \frac{\text{所有元件的重用總次數}}{\text{元件總數}}$$

重用次數越高，通常表示元件的通用性及設計品質越佳，但仍須排除因強制共用所造成的不當耦合。

（3）重用效益或節省成本

可比較「重新開發」與「採用既有元件」所需的成本。

$$\text{成本節省率} = \frac{\text{重新開發成本}-\text{重用成本}} {\text{重新開發成本}} \times 100\%$$

例如：

• 若重新開發付款模組需 100 人日。
• 採用既有元件並進行整合需 25 人日。

則：

$$\text{成本節省率} = \frac{100-25}{100} \times 100\% = 75\%$$

此指標可反映再使用性所帶來的實際經濟效益。

（4）重用所需調整比例

若元件雖可重用，但每次都必須大量修改，則其實際再使用性不佳。

$$\text{調整比例} = \frac{\text{為適應新系統而修改的程式碼量}} {\text{原元件程式碼量}} \times 100\%$$

例如共用報表元件原有 10,000 行程式碼，移植至新系統時修改 1,500 行：

$$\text{調整比例} = \frac{1,500}{10,000} \times 100\% = 15\%$$

調整比例越低，通常表示元件的抽象化及介面設計越完善。

（5）重用後缺陷率

應觀察重用元件在新系統中的缺陷情形：

$$\text{重用元件缺陷率} = \frac{\text{重用元件相關缺陷數}} {\text{重用元件規模}}$$

規模可使用千行程式碼、功能點或模組數表示。例如以千行程式碼計算：

$$\text{缺陷密度} = \frac{\text{缺陷數}} {\text{千行程式碼數}}$$

若元件重用率很高，但每次重用都引發大量缺陷，不能認定其具備良好再使用性。

---

二、可攜性（Portability）

1. 定義

可攜性是指軟體產品或系統能否以合理的成本及努力，從一個硬體、作業系統、執行環境、資料庫、瀏覽器、雲端平台或裝置環境，移轉至另一個環境，並維持原有功能與品質。

可攜性回答的是：

「這套軟體能否搬到另一個環境繼續有效運作？」

以行動應用程式為例，可攜性可能涉及：

• Android 與 iOS 間的移轉。
• 不同手機品牌及螢幕尺寸的適應。
• 不同處理器架構的支援。
• 不同版本作業系統的相容性。
• 不同網路環境及裝置權限的處理。
• 不同後端平台、資料庫或雲端服務的移轉。
• 在不同瀏覽器或混合式 App 執行環境中的運作。

可攜性通常包括：

1. 適應性（Adaptability）：能否適應不同硬體、軟體或使用環境。
2. 可安裝性（Installability）：能否在目標環境中順利安裝、設定及部署。
3. 可替換性（Replaceability）：能否取代另一個具有相同目的的軟體產品，並在相同環境中完成相應工作。

---

2. 可攜性的實務度量

（1）支援平台覆蓋率

可計算實際支援的平台數占目標平台總數的比例。

$$\text{平台覆蓋率} = \frac{\text{通過測試且可正常運作的平台數}} {\text{目標平台總數}} \times 100\%$$

例如某行動 App 的目標環境包括：

• Android 12；
• Android 13；
• iOS 16；
• iOS 17；
• 平板裝置環境。

其中 4 種環境通過測試，則：

$$\text{平台覆蓋率} = \frac{4}{5} \times 100\% = 80\%$$

此指標越高，表示系統可支援的環境範圍越廣。

（2）移轉所需人力或時間

可記錄系統從來源環境移轉至目標環境所需的人日或工時。

例如：

• 將 App 從 Android 移轉至 iOS。
• 總移轉工作量為 120 人日。
• 原系統開發工作量為 600 人日。

可計算移轉工作比例：

$$\text{移轉工作比例} = \frac{\text{移轉所需工作量}} {\text{原系統開發工作量}} \times 100\%$$

因此：

$$\text{移轉工作比例} = \frac{120}{600} \times 100\% = 20\%$$

移轉工作比例越低，代表軟體越容易攜至新環境。

（3）安裝成功率

可在不同裝置、作業系統版本及硬體組合中執行安裝測試。

核心觀念

本題考查「軟體維護」的本質、軟體開發品質評估，以及軟體度量指標在維護活動中的應用。

軟體交付後仍需維護，並不當然表示原本的開發過程失敗。依軟體工程的一般定義，軟體維護是指軟體交付使用後，為了修正錯誤、適應環境、改善功能或預防未來問題，而對軟體進行的修改活動。

常見維護類型如下：

1. 修正性維護（Corrective Maintenance） 修正交付後發現的錯誤，例如計算錯誤、例外處理不完整、資料更新失敗。

2. 適應性維護（Adaptive Maintenance） 因應外部環境變化，例如作業系統、資料庫、硬體、法規或組織作業流程變更。

3. 完善性維護（Perfective Maintenance） 改善效能、可用性、功能或使用者體驗，例如增加報表、改善查詢速度。

4. 預防性維護（Preventive Maintenance） 降低未來維護困難，例如重構程式、改善架構、補充測試、更新技術文件。

因此，「維護次數多」與「開發品質差」不能直接畫上等號，必須分析維護的類型、原因、影響範圍、修正成本及其趨勢。

---

解題方法

本題可採取三段式論述：

1. 先明確表態：經常性維護不應一概視為原開發過程錯誤。
2. 分析何種維護屬於正常生命週期活動，何種維護反映開發缺失。
3. 提出度量指標，說明計算方式及其如何支援維護管理。

---

一、為何不能將經常性維護一概視為開發錯誤

軟體具有以下特性，使交付後維護成為正常且必要的活動：

• 使用環境會改變，例如硬體、作業系統、資料庫及網路環境更新。
• 使用者需求會改變，原有功能可能不足以支援新的業務流程。
• 軟體缺陷不一定能在有限的測試時間內全部發現。
• 軟體被實際使用後，才會暴露大量真實資料、尖峰負載及例外情境。
• 軟體必須持續符合新的安全要求、法令政策及組織管理需求。
• 維護活動也包含功能改善、效能提升及技術債清理，並非只有錯誤修正。

例如，因應新版資料庫而修改連線程式，屬於適應性維護；因使用者要求新增統計報表，屬於完善性維護。這些活動不是原開發失敗，而是軟體生命週期中的正常工作。

---

二、哪些情況可能反映原開發過程不佳

雖然維護本身不代表開發失敗，但下列情況通常可作為開發品質不佳的警訊：

1. 交付後短期內大量發生相同錯誤 可能表示需求分析、設計、程式實作或測試不足。

2. 缺陷集中於少數模組 可能表示模組設計複雜、耦合度過高，或程式碼品質不佳。

3. 每次修改都引發其他功能失效 反映回歸測試不足、模組相依性過高，或架構缺乏隔離性。

4. 維護成本遠高於預期 可能是文件不完整、程式碼可讀性低、缺乏自動化測試，或設計未考慮可維護性。

5. 錯誤反覆發生且根因未被消除 代表維護只處理表面症狀，未進行根因分析與流程改善。

6. 維護人員必須頻繁修改核心程式才能處理小幅需求 可能表示系統架構彈性不足，需求變更的影響分析能力不夠。

所以，正確的評斷方式不是單純計算維護次數，而是分析「維護原因、缺陷密度、修正時間、回歸缺陷及維護成本」等資料。

---

三、軟體維護與開發品質的正確關係

可將維護分為兩種觀察角度：

• 正常生命週期維護：因應環境、需求及技術演進而進行，屬於軟體持續運作的必要活動。
• 品質補救性維護：因交付缺陷、設計不良、測試不足或文件錯誤而進行，才較能反映原開發過程的問題。

因此，維護資料可作為評估開發品質的重要證據，但必須透過分類與度量後再作判斷。若只以維護次數作為品質指標，容易產生錯誤結論。例如，主動進行預防性維護的系統，維護次數可能較多，但長期故障率及維護成本反而較低。

---

軟體度量指標及計算方式

以下列出數種適合本題的指標。

一、缺陷密度（Defect Density）

缺陷密度用來表示軟體規模中所包含的缺陷數量，常用於比較不同模組或不同版本的品質。

公式為：

$$\text{缺陷密度} = \frac{\text{確認缺陷數}} {\text{軟體規模}}$$

若以千行程式碼（KLOC）為規模單位，公式為：

$$\text{缺陷密度} = \frac{\text{確認缺陷數}}{\text{KLOC}}$$

例如某系統共有 $12$ KLOC，交付後確認有 $18$ 個缺陷：

$$\text{缺陷密度} = \frac{18}{12} = 1.5\ \text{個缺陷/KLOC}$$

對維護活動的幫助：

• 找出缺陷密度偏高的模組，作為維護優先順序依據。
• 比較不同版本在修正後是否改善。
• 協助評估測試是否充分。
• 找出需要重構、補充測試或重新設計的區域。
• 估算未來可能的維護工作量。

核心觀念

本題考查白箱測試中的控制流程覆蓋率，重點包括：

1. 敘述覆蓋率（Statement Coverage）
2. 路徑覆蓋率（Path Coverage）
3. 控制流程圖（Control Flow Diagram, CFD）的建立
4. 不可行路徑（Infeasible Path）的判斷

一、敘述覆蓋率

敘述覆蓋率是指測試執行過的程式敘述數，占全部可執行程式敘述數的比例。

$$\text{Statement Coverage} = \frac{\text{被執行的敘述數}}{\text{全部可執行敘述數}} \times 100\%$$

本題可將各行視為控制流程節點：

• 100：輸入 studentGrade
• 200：判斷 studentGrade < 60
• 300：顯示「Fail (FL)」
• 400：顯示「Pass (PS)」
• 500：判斷 studentGrade > 90
• 600：顯示「A+」
• 700：結束

二、路徑覆蓋率

路徑覆蓋率是指測試案例實際執行過的完整控制流程路徑，占所有控制流程路徑的比例。

$$\text{Path Coverage} = \frac{\text{被測試執行的完整路徑數}}{\text{全部控制流程路徑數}} \times 100\%$$

完整路徑必須從程式進入點開始，經過各項判斷與敘述，最後抵達程式結束點。

路徑覆蓋率比敘述覆蓋率嚴格。即使所有敘述都曾被執行，也不代表所有判斷組合形成的路徑都被測試。

---

解題方法：建立控制流程圖

本程式的控制流程如下：

 [100] Input(studentGrade)
 |
 v
 [200] studentGrade < 60 ?
 / \
 是 / \ 否
 v v
 [300] display "Fail" [400] display "Pass"
 \ /
 \ /
 v v
 [500] studentGrade > 90 ?
 / \
 是 / \ 否
 v v
 [600] display "A+" [700] End
 |
 v
 [700] End

因此，第一個判斷有兩種分支：

• studentGrade < 60：執行第 300 行
• studentGrade >= 60：執行第 400 行

第二個判斷也有兩種分支：

• studentGrade > 90：執行第 600 行
• studentGrade <= 90：直接至第 700 行

---

兩個測試案例的執行結果

測試案例一：studentGrade = 55

執行流程為：

$$100 \rightarrow 200 \rightarrow 300 \rightarrow 500 \rightarrow 700$$

判斷結果：

• $55 < 60$，所以執行第 300 行，顯示「Fail (FL)」
• $55 > 90$ 為否，因此不執行第 600 行
• 最後至第 700 行結束

測試案例二：studentGrade = 95

執行流程為：

$$100 \rightarrow 200 \rightarrow 400 \rightarrow 500 \rightarrow 600 \rightarrow 700$$

判斷結果：

• $95 < 60$ 為否，所以執行第 400 行，顯示「Pass (PS)」
• $95 > 90$，所以執行第 600 行，顯示「A+」
• 最後至第 700 行結束

---

敘述覆蓋率計算

全部可執行節點為：

$$\{100,200,300,400,500,600,700\}$$

共 $7$ 個節點。

兩個測試案例合併後，執行過的節點為：

$$\{100,200,300,400,500,600,700\}$$

共執行 $7$ 個節點，因此：

$$\text{Statement Coverage} = \frac{7}{7} \times 100\% = 100\%$$

結論

這兩個測試案例已涵蓋所有程式敘述，因此敘述覆蓋率為：

$$\boxed{100\%}$$

---

路徑覆蓋率計算

依控制流程圖直接列舉，形式上的路徑共有四條：

路徑一

$$100 \rightarrow 200 \rightarrow 300 \rightarrow 500 \rightarrow 700$$

條件為：

$$studentGrade < 60 \quad\text{且}\quad studentGrade \leq 90$$

可由 studentGrade = 55 執行。

路徑二

$$100 \rightarrow 200 \rightarrow 300 \rightarrow 500 \rightarrow 600 \rightarrow 700$$

條件為：

$$studentGrade < 60 \quad\text{且}\quad studentGrade > 90$$

此路徑不可能發生，因為同一數值不可能同時小於 $60$ 且大於 $90$。

路徑三

核心觀念

本題考查系統品質屬性中的「可靠度」與「安全性」，以及如何將抽象的品質要求轉換成疫苗接種線上預約系統中可實作、可測試的需求。

一、可靠度（Reliability）

可靠度是指系統在指定環境、指定條件及指定期間內，持續執行所要求功能且不發生失效的能力。

可表示為：

$$R(t)=P(T>t)$$

其中：

• $R(t)$：系統運作至時間 $t$ 仍未失效的機率。
• $T$：系統發生失效的時間。

可靠度重點在於「正確運作且不失效」。常見相關指標包括：

• 平均故障間隔時間（MTBF）
• 平均修復時間（MTTR）
• 可用性（Availability）

在簡化假設下：

$$Availability=\frac{MTBF}{MTBF+MTTR}$$

可靠度與可用性相關，但不完全相同。可靠度偏重系統在一段期間內不發生失效；可用性則同時考慮系統故障後能否迅速恢復服務。

二、安全性（Security）

安全性是指系統保護資料、資源及服務，使其不被未經授權的存取、使用、竄改、洩漏、破壞或中斷的能力。

安全性的核心通常包括：

1. 機密性（Confidentiality）：只有經授權者才能查看資料。
2. 完整性（Integrity）：資料只能由合法程序正確修改，且不得遭到未授權竄改。
3. 可用性（Availability）：合法使用者在需要時可以使用系統服務。
4. 身分鑑別（Authentication）：確認使用者身分。
5. 授權（Authorization）：確認使用者是否有權執行特定操作。
6. 可追蹤性與責任歸屬（Accountability）：保留操作紀錄，以便追查責任。
7. 不可否認性（Non-repudiation）：使使用者無法否認自己曾進行的合法操作。

可靠度主要處理系統本身的錯誤、故障與異常；安全性主要處理未授權行為與惡意攻擊。兩者都可能影響系統可用性，因此在系統設計時必須同時考量。

解題方法

本題適合採用以下切入方式：

1. 先分別定義可靠度與安全性。
2. 將疫苗預約系統的重要業務流程列出。
3. 從「系統故障時仍能正確服務」的角度，說明可靠度功能需求。
4. 從「防止未授權存取及保護個人資料」的角度，說明安全性需求。
5. 每項需求使用「系統應……」的形式，並盡量加入可驗證的條件。

疫苗接種預約系統涉及民眾身分資料、聯絡資料、接種資格、預約時段及接種紀錄，因此除了基本功能正確外，也特別重視尖峰流量、交易一致性、個人資料保護及操作稽核。

疫苗接種線上預約系統的可靠度功能需求

可靠度功能需求是指系統為維持正確服務、處理異常及避免資料遺失所必須具備的功能。

一、預約資料必須正確且一致

系統應確認民眾符合接種資格、疫苗種類及預約條件後，才建立預約資料。

例如：

• 不得將不符合資格者建立為有效預約。
• 預約成功後，民眾的名額、時段及預約狀態必須一致。
• 使用者重複送出相同預約請求時，不得產生兩筆預約。
• 取消預約後，名額必須正確釋回。

二、避免同一名額被重複預約

在多人同時搶訂最後一個名額時，系統應使用交易控制、鎖定機制或其他一致性控制，確保一個名額只能被一位民眾成功取得。

其要求可表示為：

$$\text{成功預約人數} \leq \text{可提供名額}$$

系統不得因同時交易而出現超額預約、重複扣除名額或預約狀態不一致。

三、交易應具備完整性

建立預約時，至少涉及下列操作：

1. 檢查可預約名額。
2. 建立民眾預約資料。
3. 扣除可用名額。
4. 回傳預約成功訊息。

上述操作應具有交易一致性。若其中一項失敗，系統應回復整筆交易，避免出現「民眾收到成功通知但資料未建立」或「名額已扣除但沒有預約紀錄」的情形。

四、具備錯誤處理與重試功能

系統發生暫時性網路錯誤、資料庫連線異常或外部服務無回應時，應：

• 顯示清楚且不誤導使用者的錯誤訊息。
• 對可恢復的暫時性錯誤進行有限次數重試。
• 避免重試造成重複預約。
• 將失敗請求記錄，供管理人員追蹤。
• 在服務恢復後能繼續處理未完成工作。

五、具備備份與故障復原能力

系統應定期備份預約資料、名額資料及操作紀錄。發生伺服器故障、資料庫損毀或意外中斷時，應能由備份資料復原服務。

可進一步訂定：

• RTO（Recovery Time Objective）：系統中斷後，最長允許多久恢復服務。
• RPO（Recovery Point Objective）：故障發生時，最多可接受遺失多久以前的資料。

例如，要求系統於 30 分鐘內恢復服務，且資料遺失不得超過最近 5 分鐘，即屬可測試的可靠度需求。

六、支援尖峰流量與服務降級

疫苗開放預約時可能產生大量同時連線，系統應：

• 具備足夠的併發處理能力。
• 使用佇列、流量控制或負載平衡避免伺服器崩潰。
• 在部分服務異常時，維持查詢、取消預約等核心功能。
• 不因非核心功能失效而使整個預約服務停止。

七、通知功能不得影響預約交易

預約成功後，系統可能透過電子郵件、簡訊或 App 發送通知。通知服務失敗時，不應使已完成的預約交易回復或遺失。

系統應保存待發送通知，並於服務恢復後重新發送，同時避免同一通知重複寄送。

八、可靠度需求應可量化驗證

良好的需求不只寫「系統要穩定」，而應具體訂定：

• 系統可接受的故障率。
• 尖峰時段的最大同時使用者數。
• 預約成功回應時間。
• 系統允許的服務中斷時間。
• 備份頻率及資料復原時間。