109 外交特考四等 外交行政人員資訊組 系統分析及設計與資料庫應用概要 考古題詳解

核心觀念

本題考查 NoSQL 資料庫管理系統的基本特性，以及如何將關聯式資料表的多筆資料表示為 JSON 文件。NoSQL 通常指非關聯式資料庫系統；「NoSQL」常被解釋為 Not Only SQL，強調資料庫不只限於傳統關聯式模型，並不代表完全不能使用類 SQL 查詢語言。

NoSQL 系統常見特性包括：

• 資料模型多元：可採用鍵值、文件、欄族或圖形等資料模型。
• 結構彈性：資料欄位不必一律遵循固定資料表綱要，適合處理結構多樣或變動頻繁的資料。
• 水平擴充：常以增加多台伺服器分散儲存與處理大量資料。
• 依需求取捨一致性與可用性：不同系統的交易、一致性及可用性設計各異，並非所有 NoSQL 系統都採取相同做法。

JSON（JavaScript Object Notation）以物件與陣列表示資料。物件由鍵值對組成，陣列可容納多個值或物件，適合將資料表中的多筆紀錄表示為一組文件。

解題方法

（一）說明 NoSQL 資料庫管理系統

作答時先點出它是相對於傳統關聯式資料庫的非關聯式資料庫管理系統，再說明資料模型、結構彈性及擴充方式等特點。需避免將 NoSQL 說成「沒有任何結構」或「一定不支援一致性」；實際能力依系統設計而異。

（二）將資料表轉為 JSON

每一列視為一筆紀錄，欄名轉為 JSON 物件的鍵，欄位內容轉為對應的值。由於資料表有兩筆紀錄，可用 JSON 陣列包住兩個物件：

核心觀念

本題考查將延伸 E-R 模型轉換為關聯綱要，並以 SQL DDL 表達主鍵、外來鍵、複合主鍵及完整性限制。

• PRIMARY KEY 確保資料列唯一且不可為 NULL。
• FOREIGN KEY 表達資料表間的參照關係。
• CHECK 限制金額須大於 0，並限制核准貸款金額不得超過請求金額。
• 貸款請求以「貸款者＋請求日期」識別，符合每位貸款者一天最多提出一筆請求的規則。
• 貸款核准日期 LDate 是貸款屬性，不必等於請求日期 RDate；貸款與請求的關聯應以請求識別欄位連結，而不是以日期相等作為條件。

解題方法

先依實體與識別方式決定主鍵，再由關係加入外來鍵。貸款請求的主鍵採 (BorrowerID, RDate)；貸款以 LID 為主鍵，並保存其所依據的請求識別欄位。繳款則以 (LID, NthPayment) 識別同一筆貸款中的各期繳款。

以下以標準 SQL 表示；不同資料庫系統對識別欄位型別及日期型別的名稱略有差異。

（一）Borrower 資料表

CREATE TABLE Borrower (
 ID VARCHAR(20) NOT NULL,
 name VARCHAR(100) NOT NULL,
 address VARCHAR(200) NOT NULL,
 PRIMARY KEY (ID)
);

ID 是貸款者的唯一身分識別，因此設定為主鍵。姓名與地址為必填資料。

（二）Loan Request 資料表

CREATE TABLE LoanRequest (
 BorrowerID VARCHAR(20) NOT NULL,
 RDate DATE NOT NULL,
 purpose VARCHAR(500) NOT NULL,
 RAmount DECIMAL(12,2) NOT NULL,
 PRIMARY KEY (BorrowerID, RDate),
 FOREIGN KEY (BorrowerID) REFERENCES Borrower(ID),
 CHECK (RAmount > 0)
);

複合主鍵 (BorrowerID, RDate) 同時表達「同一貸款者同一天最多一筆請求」。BorrowerID 外鍵確保每筆請求都屬於已註冊的貸款者；RDate NOT NULL 與 RAmount > 0 分別實作日期不可缺及請求金額須為正數。

（三）Loan 資料表

核心觀念

本題考查專案利害關係人（Project Stakeholders）的範圍。利害關係人是指會影響專案、受專案影響，或認為自己會受到專案影響的個人、團體或組織。常見對象包括專案經理、專案團隊、客戶、供應商，以及支持或反對專案的團體。

解題方法

逐一判斷各選項是否通常會與專案發生直接關聯：若能影響專案決策或執行，或會受專案結果影響，通常可列為利害關係人；若只是範圍廣泛、未必與特定專案有直接關係的群體，則通常不列入。

選項分析

• (A) 供應商（Suppliers）：錯誤。 供應商提供專案所需的產品、服務或資源，會影響成本、時程與品質，通常是專案利害關係人。
• **(B) 一般公眾（General Public）：正確。

核心觀念

本題考查軟體工作量估算方法。**參數式模型（Parametric Models）**會運用過去已完成專案的歷史資料，找出與工作量相關的因素，再以統計方法建立估算方程式。常見形式為：

其中 $x_1, x_2, \ldots, x_n$ 是影響工作量的專案因素，例如軟體大小、複雜度、團隊經驗或工具支援程度。實務上可透過迴歸分析建立模型，例如 COCOMO。

解題方法

題幹的關鍵線索是「依據歷史資料」、「找出影響工作量的因素」及「以統計迴歸方法導出估算方程式」。這正是參數式模型的特徵：以專案參數為輸入，利用歷史資料校準模型，再估算新專案的工作量。因此選 (B)。

選項分析

核心觀念

本題考查整合測試中不同整合策略的組合方式。

• 自上而下整合測試（Top-Down Integration Testing）：由高階模組開始，逐步整合低階模組；尚未完成的低階模組以「虛擬模組（Stub）」代替。優點是較早驗證主要控制流程，缺點是低階模組與底層功能較晚測試。
• 自下而上整合測試（Bottom-Up Integration Testing）：由低階模組開始，逐步整合高階模組；尚未完成的高階模組以「測試驅動程式（Driver）」代替。優點是較早驗證底層功能，缺點是整體控制流程較晚測試。
• 三明治測試（Sandwich Testing）：同時採用自上而下與自下而上的整合方式，從高階與低階兩端往中間整合，藉此兼顧兩種方法的優點。

解題方法

題幹指出「把自上而下與自下而上整合測試組合起來」，並說明目的是克服兩者缺點、擷取兩者優點。這正是三明治測試的定義，因此選項為（C）。

判斷時可抓住關鍵詞「上、下兩端同時整合、往中間會合」：這種整合策略又稱混合式整合測試（Hybrid Integration Testing）。

選項分析

核心觀念

本題考查敏捷開發方法的常見優點。敏捷開發強調短週期、漸進式開發，並透過頻繁交付與客戶回饋，持續調整需求和軟體。敏捷宣言也重視「個人與互動」及「與客戶合作」，面對面溝通被視為有效的資訊傳遞方式。

解題方法

逐項比對選項是否符合敏捷開發的典型特性。面對面溝通、快速持續交付、漸進式開發，都是敏捷常見的做法或優點；「實施成本低」則不是敏捷方法必然具備的優點。

選項分析

• (A) 能與客戶進行面對面溝通為最有效的資訊傳遞方法：正確。 敏捷重視團隊成員與客戶之間的密切互動。面對面溝通有助於迅速釐清需求、減少誤解，符合敏捷宣言所重視的溝通方式。

核心觀念

軟體專案管理的「管理範疇」（Management Spectrum）包含四個重要面向，常稱為 4P：

• People（人員）：參與專案的人員及其組織、溝通與協作。
• Product（產品）：要建置的軟體及其目標、範圍與需求。
• Process（過程）：開發與管理專案所採用的方法、活動及工作流程。
• Project（專案）：專案的規劃、估算、排程、追蹤與控制。

「Priority（優先順序）」雖然是專案管理中常見的考量因素，但不是 4P 的標準項目。

解題方法

辨認題目所問的 4P，直接比對四個英文名稱即可：People、Product、Process、Project。選項中只有「Priority（優先順序）」不在此列，因此選擇 B。

核心觀念

本題考需求工程與軟體流程模型的辨識，關鍵在於「利害關係人辨識、確認各方獲利條件、協商互惠條件，達成雙贏」。這組概念是 雙贏螺旋模型（WinWin Spiral Model） 的核心。

雙贏螺旋模型在螺旋式開發的基礎上，將需求協商納入每一輪反覆。開發團隊辨識主要利害關係人，了解各方的「勝利條件」（win conditions），再透過協商形成各方都能接受的共識，作為後續工程工作的依據。

解題方法

作答時抓題幹中的辨識線索即可：題目明確描述了每次反覆開始時，先辨識利害關係人、確認其獲利條件，再協商出互惠安排，最後使雙方皆滿意。這正是 WinWin Spiral Model 的標誌性流程。

題幹也特別強調，這不是單一的客戶交流活動，而是反覆進行的協商活動；因此應選擇以利害關係人協商與雙贏結果為特色的流程模型。

選項分析

• (A) 演進流程模型（Evolutionary Process Models）錯誤。 演進式流程模型的共同特徵是透過多次反覆逐步發展或修正系統，例如原型法與螺旋模型。它描述的是系統如何逐步演進，並未特別以「各利害關係人的獲利條件與協商」作為辨識核心。

核心觀念

本題考查實體關係模型（Entity-Relationship Model，ER Model）的圖形表示法。ER 圖以不同圖形表示不同構成要素：

• 矩形表示實體類型（Entity Type）。
• 菱形表示實體類型之間的關係（Relationship）。
• 橢圓形表示屬性（Attribute）。

解題方法

題幹問的是「實體類型與實體類型間的關係」使用何種圖形表示。依 ER 圖的標準符號，先分辨題目問的是實體、關係或屬性：實體以矩形表示，實體間的關係以菱形表示，屬性則以橢圓形表示。因此應選菱形。

核心觀念

決策表（Decision Table）以表格整理系統的條件組合及其對應的處理動作或輸出結果。在軟體測試中，測試者依據需求規格設計不同條件組合，再檢查系統是否產生正確結果。測試重點在於系統的外部輸入、規則與可觀察輸出，不必檢視程式內部的控制流程或程式碼，因此屬於黑箱測試。

解題方法

判斷測試類型時，先看測試案例的來源與觀察重點：

• 若依需求規格、條件與預期結果設計測試案例，檢查功能輸出，屬於黑箱測試。
• 若依程式結構、分支、路徑或程式碼設計測試案例，屬於白箱測試。

決策表描述的是「條件成立時，系統應採取何種動作」，可用來完整檢查規則組合及其結果，故本題選黑箱測試。

選項分析

• (A) 白箱測試（White-Box Testing）錯誤。 白箱測試須掌握程式內部結構，常以敘述、分支或路徑涵蓋率檢查程式邏輯。決策表本身依需求條件與預期結果建立，不以程式碼結構為依據。

核心觀念

本題考軟體組態管理（Software Configuration Management, SCM）系統的四項元素。組態管理系統用來管理軟體生命週期中的變更，常見的元素包括：

• 元件元素（Component Elements）：受組態管理的軟體項目，例如程式碼、文件與測試案例。
• 過程元素（Process Elements）：規範組態管理活動如何執行，例如變更控制與版本管理流程。
• 建構元素（Construction Elements）：支援軟體建置、整合與發布的工具或機制。
• 人員元素（Human Elements）：執行、管理或核准組態管理活動的人員及其職責。

因此，題目問「除了元件元素外，哪一項不屬於組態管理系統元素」，關鍵是辨認上述四項分類中的非成員。

解題方法

先記住組態管理系統的四元素：元件、過程、建構、人員。將選項逐一比對後，可見 A、C、D 都在四元素之列；「資訊元素」不在這組分類中，故選 B。

核心觀念

本題考查軟體專案風險管理中的 RMMM 計畫。RMMM 是四個英文詞的縮寫：

• Risk：風險
• Mitigation：減輕風險
• Monitoring：監測風險
• Management：管理風險

計畫通常記錄風險分析結果，以及如何減輕、監測與管理各項風險。

解題方法

題幹已指出第一個 R 代表 Risk（風險），因此只要辨認其餘三個 M 的標準原意：Mitigation、Monitoring、Management。選項中不屬於這三者的詞，就是答案。

選項分析

核心觀念

本題考 CMMI 的階段式表示法中，各成熟度等級所包含的關鍵流程領域（Key Process Areas, KPAs）。第二級為「已管理（Managed）」，著重建立專案層級的管理與控制；需求發展則屬於第三級「已定義（Defined）」。

第二級的關鍵流程領域包括：需求管理、專案規劃、專案監控、供應商協議管理、度量與分析、流程與產品品質保證，以及組態管理。

解題方法

逐一比對選項與第二級的關鍵流程領域清單。凡屬於第二級清單者，即不是題目所問；不在清單中的流程領域，便是正解。

選項分析

• (A) 需求管理（Requirements Management）：屬於第二級關鍵流程領域，負責管理專案需求，並維持需求與專案計畫、工作成果之間的一致性，因此不是答案。

核心觀念

本題考查程式碼審查（Code Review）與程式碼檢查（Code Inspection）的執行方式差異。兩者都是透過閱讀程式碼找出缺陷的靜態檢測活動；依本題採用的分類，審查可由個人進行，檢查則由團隊共同執行。

解題方法

抓住兩者的參與人數與組織方式即可判斷：個人檢視程式碼屬於審查；檢查則是有明確角色分工、由多人組成團隊執行的正式活動。因此，最主要差異是「一個人」與「團隊」的區別。

選項分析

• (A) 主持人（Moderator）不同：錯誤。 主持人是正式檢查常見的角色，但本題要比較的是審查與檢查的主要差異，不是主持人的身分或是否由不同人擔任。

核心觀念

本題考 ER 圖（Entity Relationship Diagram）的基數與參與限制。烏鴉腳表示「多」；圓圈表示「可以為零」，短線表示「至少一個」。符號要從連接的實體端解讀其對面實體的數量。

解題方法

圖中「課程」端標示短線加烏鴉腳，表示每位學生至少選一門課，且可選多門；「學生」端標示圓圈加烏鴉腳，表示每門課可以沒有學生選，也可以有多位學生選。因此：

• 每位學生選課數：$1$ 至多門
• 每門課的選修學生數：$0$ 至多位

選項分析

核心觀念

本題考查第二正規化（2NF）：資料表須先符合第一正規化，且每個非主鍵欄位都必須完全依賴整個候選鍵，不能只依賴複合鍵的一部分。若欄位只依賴複合鍵中的部分欄位，就有部分相依，應拆表。

依題目資料，訂單明細以「訂單編號＋書號」識別，因此採用複合鍵：

解題方法

先依欄位所描述的對象，判斷其依賴關係：

• 訂單編號決定業務員編號、負責業務員及客戶名稱。同一張訂單的各筆明細，這些資料相同。
• 書號決定書籍名稱。
• 訂單編號與書號共同決定該筆明細的數量。

因此，原表有兩種部分相依：

• 部分欄位只依賴「訂單編號」。
• 「書籍名稱」只依賴「書號」。

套用第二正規化後，可拆成三個表：

1. 訂單資料表：訂單編號、業務員編號、負責業務員、客戶名稱。
2. 書籍資料表：書號、書籍名稱。
3. 訂單明細表：訂單編號、書號、數量。

核心觀念

本題考查 SQL 的分組彙總與分組條件篩選：

• COUNT(*) 用來計算每個群組中的資料筆數。
• GROUP BY 學號 將選課表依學號分組，代表逐一計算每位學生的選課筆數。
• HAVING 用來篩選分組彙總後的結果；WHERE 則在分組前篩選個別資料列，不能直接用來篩選 COUNT(*) 這類彙總結果。

解題方法

題目要找「選修 2 科及 2 科以上的學生學號」，可依序拆解：

1. 以學號分組，讓每位學生各自形成一組。
2. 用 COUNT(*) 計算每組的選課資料筆數。
3. 以 HAVING COUNT(*) >= 2 保留選課筆數至少為 2 的分組。

因此，正確的查詢架構是：

SELECT 學號，COUNT（*） FROM 選課表 GROUP BY 學號 HAVING COUNT（*）>=2

選項分析

核心觀念

預存程序（Stored Procedure）是預先儲存在資料庫中的一組 SQL 指令或程式邏輯，可由應用程式呼叫執行。將常用的資料異動或查詢操作集中管理，通常有助於提升執行效率、控制資料存取，以及重複使用程式邏輯。

但「資料安全性」與「資料機密性」並非同一概念。預存程序可藉由限制使用者直接存取資料表、改以授權呼叫程序，協助控制資料的存取權限；它本身則不等同於加密，也不能單獨確保資料內容不被未授權者得知。

解題方法

題目問「何者不是預存程序的優點」，可逐項辨認哪些敘述是預存程序常見的功能或效益，再區分「存取控制」與「保密」：

• 有關執行效率、權限管理、模組化重用，通常屬於預存程序的優點。
• 若敘述表示預存程序能直接達成資料機密性，則混淆了權限控制與資料保密。

選項分析

(A) 提高執行效率：正確。 預存程序預先儲存在資料庫中，可減少應用程式與資料庫間反覆傳送 SQL 指令的負擔；

核心觀念

本題考查軟體模組設計中的兩項重要原則：內聚力（cohesion）與耦合力（coupling）。

• 內聚力：衡量同一模組內各項功能彼此關聯的程度。模組內的功能若都圍繞單一、明確的目的，內聚力就高，模組也較容易理解與維護。
• 耦合力：衡量不同模組之間依賴與牽連的程度。模組間依賴越少，耦合力越低，修改某一模組時較不容易影響其他模組。

良好的模組設計原則是：高內聚力、低耦合力。

解題方法

先分別判斷題目所問的兩項原則：

1. 模組內部的功能應緊密圍繞同一目的，因此追求高內聚力。
2. 模組與模組之間應減少不必要的依賴，因此追求低耦合力。

兩者合併後，符合「高內聚力及低耦合力」的選項為 (C)。

核心觀念

本題考查 UML 類別之間的關係。**相依（Dependency）**表示一個類別在某項功能中使用另一個類別；若被使用類別的定義或行為改變，使用它的類別可能也需要調整。

解題方法

題幹的關鍵是「使用到其他類別」以及「被使用類別的改變可能影響使用它的類別」。這正是相依關係的特徵，因此選擇相依（Dependency）。

選項分析

• (A) 相依（Dependency）—正確。 表示使用者類別依賴被使用類別提供的服務或定義；被使用者的變更可能造成使用者也須修改。UML 通常以虛線箭頭表示，箭頭由使用者指向被使用者。
• **(B) 一般化（Generalization）—錯誤。

核心觀念

本題考 UML 中用來描述物件間互動的圖。互動圖（interaction diagram）呈現物件之間傳遞訊息、協作完成工作的情形；常見類型包括順序圖（Sequence Diagram）與合作圖（Collaboration Diagram，後稱溝通圖 Communication Diagram）。

解題方法

先辨認各圖描述的重點：

• 順序圖：以生命線和訊息呈現物件互動，並強調訊息發生的時間順序。
• 合作圖／溝通圖：呈現參與互動的物件及其連結，並以訊息標示彼此如何協作。
• 狀態圖：描述單一物件或系統的狀態，以及事件觸發的狀態轉換。
• 部署圖：描述執行環境中的硬體節點，以及軟體成品如何部署其上。

核心觀念

本題考查資料庫並行控制中的「不乾淨讀取（Dirty read）」。當一個交易讀取另一個尚未提交（未交付）的交易所寫入資料，便發生不乾淨讀取；若後者最後回復（rollback），前者讀到的內容就不是已確認的資料。

不乾淨讀取屬於「未交付相依（uncommitted dependency）」，也稱為「暫時更新問題（temporary update problem）」。它描述的是交易之間因讀取未提交資料而產生的相依性。

解題方法

將題目中的術語與定義配對即可：Dirty read 的關鍵是「讀取尚未提交的資料」，而題目列出的「未交付相依」正是指這種情形，因此選 A。

選項分析

核心觀念

本題考查三層式架構（3-tier architecture）的標準分層名稱。典型三層式架構依系統職責分為：

1. Presentation Tier（呈現層）：負責使用者介面與資訊呈現，並接收使用者輸入。
2. Business Logic Tier（商業邏輯層）：負責執行業務規則、處理應用程式邏輯。
3. Data Tier（資料層）：負責資料的儲存、查詢與管理，通常由資料庫系統支援。

三層式架構的重點是把呈現、業務處理與資料管理分開，使各層職責明確，便於維護與擴充。

解題方法

先辨認三層架構的三項標準職責：呈現、業務邏輯、資料；再檢查各選項是否各自包含這三層。

其中，Application Tier 有時可作為應用程式處理層的概括名稱，但題目列出的標準名稱組合應為 Presentation Tier、Business Logic Tier、Data Tier。

選項分析

• (A) Client Tier、Application Tier、Data Tier：錯誤。 Client Tier 常用來指用戶端或用戶端環境，並非此處標準的 Presentation Tier 名稱；Application Tier 雖可泛指應用程式處理層，但此選項未明確列出 Business Logic Tier，名稱組合不符題目所問的標準三層。

核心觀念

本題考查資料倉儲（Data Warehouse）與線上分析處理（OLAP）的用途，以及資料倉儲、資料市集和資料庫正規化之間的差異。

資料倉儲是整合來自不同來源、經整理後供分析與決策使用的資料集合，重視跨來源整合、歷史資料及支援管理決策。OLAP 則是在資料倉儲或類似分析資料庫上進行多維度查詢與分析的技術，可協助使用者取得整合性的決策資訊。

解題方法

先辨認題目描述的是「日常交易處理」還是「決策分析」：

• OLTP（線上交易處理）處理訂單、付款、庫存異動等日常業務交易。
• OLAP（線上分析處理）分析彙整資料，支援報表、趨勢分析與決策。

再檢查資料倉儲的設計目的：它通常以分析與查詢效率為主，常採用維度模型及反正規化設計；資料市集則通常是針對特定部門或主題建立的局部資料集合。

選項分析

核心觀念

本題測驗專案管理與系統開發時程規劃中的**關鍵路徑法（Critical Path Method, CPM）與工作相依性（Dependency）**分析：

1. 工作相依關係（Precedence Relationship）：若工作 $Y$ 必須在工作 $X$ 完成後才能開始（即 $X \to Y$），表示兩者存在循序先後限制；若工作之間無先後相依關係，則在資源充足的假設下可以平行作業（Parallel Execution）。
2. 專案最短完工天數：專案要完全結束，必須等待所有工作鏈（路徑）皆執行完畢。因此，專案最少所需的總工期取決於「耗時最長的路徑」，此路徑即為關鍵路徑（Critical Path），其長度公式為： $\text{專案完工總天數} = \max(\text{各平行路徑之工期總和})$

解題方法

步驟一：分析工作相依性與平行路徑

根據題目描述，整理各項工作的先後順序：

• 路徑一（$A \to C$）：$C$ 必須在 $A$ 完成之後才能開始，形成循序相依鏈。
• 路徑二（$B \to E$）：$E$ 必須在 $B$ 完成之後才能開始，形成另一組循序相依鏈。
• 工作 $D$：題目未提及 $D$ 與其他任何工作有先後相依限制，因此 $D$ 為獨立工作，可於專案一開始即與其他工作平行展開。

步驟二：計算各路徑所需工期

• 路徑一（$A \to C$）工期： $\text{天數} = \text{天數}(A) + \text{天數}(C) = 3 + 7 = 10 \text{ 天}$
• 路徑二（$B \to E$）工期： $\text{天數} = \text{天數}(B) + \text{天數}(E) = 7 + 6 = 13 \text{ 天}$
• 工作 $D$ 工期： $\text{天數} = \text{天數}(D) = 5 \text{ 天}$

核心觀念

本題考查專案風險的因應策略。風險可依「發生機會」與「衝擊程度」評估；發生機會小、但衝擊大的風險，雖不常發生，一旦發生仍可能造成重大損失，因此應優先採取風險轉移（Risk Transfer），將部分損失或責任轉由第三方承擔，例如投保、外包或訂定契約責任。

解題方法

先辨認風險特性：低發生機率、高衝擊。此類風險通常不必為了消除風險而全面改變專案方向，而是透過保險或契約安排，降低風險發生後由專案自行承受的損失。據此選擇「風險轉移」。

選項分析

• (A) 防災（Hazard Prevention）：著重預防危害發生，並非此題所指的典型風險因應策略；也未直接處理低機率、高衝擊風險造成的重大損失。

核心觀念

V-Model（V 模型）是瀑布式開發模型的延伸，將開發階段與測試階段配對，使測試規劃能在需求與設計階段同步展開。V 字左側是需求分析與系統設計等開發活動，右側是相對應的測試活動；底部通常是程式撰寫與單元測試。

判斷這題的關鍵是分清兩組概念：

• Verification（驗證）：確認工作成果是否符合規格，即「我們是否正確建構產品？」（Are we building the product right?）
• Validation（確認）：確認完成的產品是否滿足使用者需求，即「我們是否建構了正確的產品？」（Are we building the right product?）

解題方法

先記住 V 模型兩側的對應關係：左側由高階需求逐步細化到程式設計，右側則由單元測試逐步整合、驗收到系統層級。

常見對應如下：