（本文由北京中基數聯(lián)科技有限公司撰寫(xiě)，僅供學(xué)習參考使用，版權歸中基數聯(lián)所有，轉載請標明出處。）

1 引言

        功能點(diǎn)分析的難點(diǎn)是如何確定一個(gè)功能或一組相關(guān)功能是否構成一個(gè)基本過(guò)程。計數實(shí)踐手冊（CPM），v.4.3.1定義了基本過(guò)程的概念：“將功能用戶(hù)需求組合或分解為滿(mǎn)足以下所有條件的最小活動(dòng)單元：對用戶(hù)有意義；構成完整的事務(wù)；自包含，并使應用程序的業(yè)務(wù)處于持續狀態(tài)”。
       雖然這是一個(gè)相當簡(jiǎn)單的規則，但在許多情況下，FP分析師很難在實(shí)踐中正確應用。甚至在某些情況下，FP分析師應用該規則時(shí)也會(huì )有所不同。本文為FP分析師解釋和應用此基本過(guò)程規則提供了進(jìn)一步指導。
       正確應用基本過(guò)程規則的一個(gè)關(guān)鍵領(lǐng)域是在合同協(xié)議中，功能點(diǎn)（FP）對合同進(jìn)行度量和定價(jià)?？蛻?hù)和軟件服務(wù)提供商可能對基本過(guò)程（EP）的確定以及基本過(guò)程的組成或分解程度存在分歧。許多軟件服務(wù)提供商假定屏幕截圖和基本過(guò)程之間存在簡(jiǎn)單的一對一關(guān)系，但是他們并不了解基于屏幕截圖的功能需求。在這些協(xié)議中基于功能用戶(hù)需求（FUR）對項目進(jìn)行度量和定價(jià)，并且可以基于用例和屏幕截圖進(jìn)行推導。
       基本過(guò)程的分解程度可能太過(guò)粗糙，如通過(guò)截圖計算一個(gè)EP，而截圖上缺少其他或從屬EP的情況?；蛘?，識別基本過(guò)程的分解程度過(guò)于精細，導致EP計數過(guò)多，如完成一項功能需要多個(gè)步驟或截圖的情況。
       這兩種情況出現的原因都是因為沒(méi)有足夠的細節從用戶(hù)的角度來(lái)確定合適的EP。軟件服務(wù)提供商擔心項目規模的估算錯誤會(huì )為開(kāi)發(fā)功能提供不準確的成本、進(jìn)度和工作量估算。
此外，在分析基本過(guò)程的唯一性時(shí)，DETs、FTRs或處理邏輯的微小變化也可能會(huì )引起爭議。CPM 4.3.1規定，“當比較兩個(gè)基本過(guò)程時(shí)，如果它們包含不同的DETs、FTRs或處理邏輯，則將它們識別為獨立的基本過(guò)程”。
       基本過(guò)程是功能點(diǎn)中最重要的概念之一，基本過(guò)程規則的錯誤解釋和誤用會(huì )顯著(zhù)改變功能點(diǎn)計數的結果。在功能點(diǎn)計數期間識別的基本過(guò)程的數量是確定項目功能規模的重要因素。
       本文將提供基本過(guò)程概念和基本過(guò)程唯一性的相關(guān)示例，使客戶(hù)和軟件服務(wù)提供商之間就度量和定價(jià)的內容進(jìn)行更好的溝通，從而促進(jìn)基于FP的商業(yè)活動(dòng)和度量。本文所提到的示例僅用于說(shuō)明目的；每位度量分析師必須根據CPM當前版本中定義的計數規則，正確度量基本過(guò)程。
免責聲明：本文中提供的所有示例僅表示對系統的公開(kāi)解釋?zhuān)员銥橛懻摰闹黝}提供說(shuō)明，并不代表任何公司系統的真實(shí)運行情況。
 

2 目標讀者

       本文為功能點(diǎn)分析師在應用《計數實(shí)踐手冊》（CPM 4.3系列）來(lái)確定基本過(guò)程的組成提供了指導，以提高基本過(guò)程評估的一致性。
       本文的目標讀者包括需要在FPA計數期間應用基本過(guò)程識別規則的所有專(zhuān)業(yè)人員。
 

3 基本過(guò)程、用戶(hù)和業(yè)務(wù)過(guò)程

       《FPA在BPM系統項目中的應用》白皮書(shū)為在BPM環(huán)境中應用FPA方法奠定了基礎，提供了描述BPM概念和業(yè)務(wù)過(guò)程背景的材料，解釋了如何應用FPA來(lái)度量基于BPM的系統項目，并舉例說(shuō)明。
該文件指出：

•  “業(yè)務(wù)過(guò)程由一組在技術(shù)環(huán)境中協(xié)調執行的活動(dòng)組成。這些活動(dòng)共同實(shí)現了一個(gè)業(yè)務(wù)目標”。
•  “業(yè)務(wù)過(guò)程實(shí)例代表公司運營(yíng)業(yè)務(wù)中的具體案例，由活動(dòng)實(shí)例組成” 。
•  “在業(yè)務(wù)過(guò)程模型中，確定哪些活動(dòng)代表功能用戶(hù)需求，并將每個(gè)活動(dòng)組合或分解為滿(mǎn)足基本過(guò)程條件的最小活動(dòng)單元”。

       CPM將功能用戶(hù)需求（FUR）定義為“描述軟件要做什么，提供什么樣的服務(wù)的用戶(hù)需求子集”。因此，功能用戶(hù)需求（FUR）對應于定義業(yè)務(wù)過(guò)程活動(dòng)的邏輯順序，從而實(shí)現業(yè)務(wù)目標。業(yè)務(wù)過(guò)程活動(dòng)對應于交付給用戶(hù)的每項有意義的功能，負責業(yè)務(wù)過(guò)程要實(shí)現的總體目標的一部分。
       CPM將用戶(hù)定義為“在任何時(shí)候與軟件通訊或交互的任何人或事物” ，用戶(hù)角度被定義為“用戶(hù)感知的功能用戶(hù)需求” 。此外，用戶(hù)角度表示“以用戶(hù)語(yǔ)言對用戶(hù)業(yè)務(wù)需求進(jìn)行的正式描述”、“是對業(yè)務(wù)功能的描述”。因此，“用戶(hù)”和“用戶(hù)角度”的定義一起使用，說(shuō)明用戶(hù)代表業(yè)務(wù)過(guò)程的服務(wù)對象。用戶(hù)通常是與被計數的應用程序交互的人，但與應用程序交互的外部系統或設備也被視為用戶(hù)。
       術(shù)語(yǔ)“用戶(hù)可識別”的定義為“事務(wù)和數據需求是由用戶(hù)和軟件開(kāi)發(fā)人員都認同并理解的”^[6]。換句話(huà)說(shuō)，用戶(hù)可識別是業(yè)務(wù)過(guò)程或業(yè)務(wù)過(guò)程活動(dòng)中的所有內容。
基本過(guò)程識別規則是將業(yè)務(wù)過(guò)程活動(dòng)拆分為滿(mǎn)足以下條件的最小活動(dòng)單元：

1.  對用戶(hù)有意義：“用戶(hù)可識別并滿(mǎn)足功能用戶(hù)需求”的所有內容^[8]；
2. 構成一個(gè)完整事務(wù)：“用戶(hù)為完成一個(gè)基本過(guò)程的所有需求。如驗證、數學(xué)運算或計算、讀取或維護數據功能”；
3. 自包含：“功能用戶(hù)需求不需要任何前置或后續處理步驟就可以獨立完成”；
4. 使應用程序的業(yè)務(wù)處于持續狀態(tài)：“過(guò)程已完全執行，功能用戶(hù)需求已得到滿(mǎn)足，無(wú)需再做任何事情”。

       “對用戶(hù)有意義”相當于“對業(yè)務(wù)有意義”，即從用戶(hù)的角度來(lái)看，是一切與業(yè)務(wù)目標相關(guān)的功能需求。當然，并不是說(shuō)對用戶(hù)沒(méi)有明確意義的內容就是對業(yè)務(wù)無(wú)意義：對業(yè)務(wù)過(guò)程進(jìn)行詳細分析可以顯示出用戶(hù)可識別的更多功能需求。
       “完整事務(wù)”的概念與處理邏輯的概念相關(guān)聯(lián)，即“用戶(hù)要求的完成一個(gè)基本過(guò)程的特定需求。如驗證、數學(xué)運算或計算、讀取或維護數據功能”。這意味著(zhù)，“完整事務(wù)”必須包含所有適用的處理邏輯，從用戶(hù)的角度實(shí)現部分或所有業(yè)務(wù)目標。處理邏輯可以有業(yè)務(wù)過(guò)程的一個(gè)或多個(gè)處理步驟，并且包括應用程序響應消息。處理步驟確保所有維護ILF的屬性都已寫(xiě)入。例如，在一個(gè)處理步驟中，應用程序向用戶(hù)展示信息以供查看，并允許用戶(hù)確認，這是一個(gè)EP的一部分，而不是一個(gè)完整的EP。
       “自包含”和“使業(yè)務(wù)處于持續狀態(tài)”的概念和業(yè)務(wù)過(guò)程活動(dòng)有關(guān)，它基于用戶(hù)視角交付業(yè)務(wù)可識別的結果。“自包含”的活動(dòng)意味著(zhù)可以在不需要執行任何其他活動(dòng)的前提下獨立執行該活動(dòng)。如果一個(gè)活動(dòng)有其他可能完成或必須完成的活動(dòng)作為前置任務(wù)，那么該活動(dòng)則不能“自包含”，因為它依賴(lài)于前置任務(wù)功能?？梢酝ㄟ^(guò)一個(gè)包含選擇條件、檢索信息、顯示結果的查詢(xún)功能來(lái)說(shuō)明這種情況：選擇條件必須是在檢索信息之前的強制性前置活動(dòng)，檢索信息是顯示結果的強制性前置活動(dòng)。因此，選擇條件和檢索信息都不是“自包含”的，因為只有在顯示結果之后才能實(shí)現業(yè)務(wù)目標。所以，“選擇條件+檢索信息+顯示結果”的組合是“自包含的”。
       “持續狀態(tài)”的概念表明，當時(shí)事務(wù)完成時(shí)，所需的業(yè)務(wù)功能已經(jīng)完成，不需要后續任何步驟。所有數據處于最終狀態(tài)，并滿(mǎn)足功能用戶(hù)需求。此時(shí)，系統可以禁用或關(guān)閉，且數據可用于下一次EP，如果必須重復之前的EP，則說(shuō)明該EP未達到持續狀態(tài)。
       識別EP的所有關(guān)鍵概念都可以通過(guò)業(yè)務(wù)過(guò)程相關(guān)聯(lián)：EP由為業(yè)務(wù)過(guò)程提供所需步驟的活動(dòng)或一組相關(guān)活動(dòng)組成，其結果是最小的、有意義的、完整的和業(yè)務(wù)可識別的。
       然而，僅識別EP是不夠的，還需要在識別EP之后，按照之前同樣適用的規則，與已識別的其他EP相比，確保EP不會(huì )重復?；具^(guò)程的唯一性是基本過(guò)程的另一個(gè)重要概念，需要在業(yè)務(wù)過(guò)程的背景中對其加以理解。
       正如CPM中定義的，唯一性檢測表明，“當與已經(jīng)識別到的基本過(guò)程進(jìn)行比較時(shí)，如果兩個(gè)相似的基本過(guò)程滿(mǎn)足下列條件，則把它們當作同一個(gè)基本過(guò)程：

1. 要求相同的DETs集；
2. 要求相同的FTRs集；
3. 要求相同的完成基本過(guò)程的處理邏輯。”

       此外它還指出：“一個(gè)基本過(guò)程在多個(gè)可選事件中可能包含微小的DETs、FTRs或處理邏輯的變化”、“不要把一個(gè)基本過(guò)程的多種處理邏輯形式拆分為多個(gè)基本過(guò)程” 。
       那么如何確定何時(shí)發(fā)生“DETs、FTRs或處理邏輯的微小變化”呢? 處理邏輯以及DET和FTR能夠使EP執行業(yè)務(wù)過(guò)程目標。因此，在分析EP唯一性時(shí)，最重要的是了解預期的業(yè)務(wù)目標。當比較兩個(gè)或多個(gè)在DET、FTR或處理邏輯上有微小變化，但從用戶(hù)的角度來(lái)看滿(mǎn)足相同業(yè)務(wù)目標的類(lèi)似的EP時(shí)，所有EP作為一個(gè)唯一的EP進(jìn)行度量。例如，在分析兩個(gè)類(lèi)似EP時(shí)，檢查DET、FTR和處理邏輯的微小變化是否足以識別不同的業(yè)務(wù)目標，如果可以，則度量為不同的EP，否則認為是一個(gè)EP。
       當增強項目需要更改EP的處理邏輯、DET或FTR的某一部分時(shí)，如果該EP要實(shí)現的業(yè)務(wù)目標保持不變，則不能將受影響的EP分解為多個(gè)不同的EP。
       以下示例說(shuō)明了前文描述的所有概念。下圖為“預約系統”的業(yè)務(wù)過(guò)程，其業(yè)務(wù)目標是“乘客預約乘車(chē)”。        業(yè)務(wù)過(guò)程活動(dòng)如表1所示：
       表 1 預約系統業(yè)務(wù)過(guò)程活動(dòng)
注：如果用戶(hù)或系統中止/取消流程，則流程將中斷，且系統沒(méi)有其他響應。
       “乘客”和“司機”是預約系統的用戶(hù)。因此，預約系統業(yè)務(wù)價(jià)值由預約過(guò)程的用戶(hù)視圖表示，這是識別基本過(guò)程的規則之一。

       表2通過(guò)應用上述EP識別規則，對每個(gè)業(yè)務(wù)過(guò)程活動(dòng)進(jìn)行了分析，以識別基本過(guò)程：
       表 2 預約系統基本過(guò)程識別規則

	基本過(guò)程識別規則
業(yè)務(wù)過(guò)程活動(dòng)	是否對用戶(hù)有意義？	是否構成一個(gè)完整事務(wù)？	是否自包含？	是否使應用程序的業(yè)務(wù)處于持續狀態(tài)？
請求預約	是。請求預約是功能用戶(hù)需求的一部分。	否。僅請求預約并不是一個(gè)完整事務(wù)，因為該過(guò)程還必須接收請求信息、檢查可用性、獲取備選日期/時(shí)間并向客戶(hù)提供預訂信息。這些步驟在邏輯上不能分開(kāi)。	否。接收請求、檢查可用性、獲取備選日期/時(shí)間和提供預訂信息是完成基本過(guò)程所需的所有后續處理步驟。	否。只有在提交、接收、處理請求預訂信息并將其返回給客戶(hù)時(shí)，才能滿(mǎn)足完整的業(yè)務(wù)需求。
接收預約請求	是。接收預約請求是功能用戶(hù)需求的一部分。	否。僅接收預約請求不是一個(gè)完整事務(wù)，因為該過(guò)程還必須請求預訂、檢查可用性、獲取備選日期/時(shí)間并向客戶(hù)提供預訂信息。這些步驟在邏輯上不能分開(kāi)。	否。請求預訂是必須執行的前置處理步驟。檢查可用性、獲取備選日期/時(shí)間和提供預訂信息是完成基本過(guò)程所需的所有后續處理步驟。	否。只有在提交、接收、處理請求預訂信息并將其返回給客戶(hù)時(shí)，才能滿(mǎn)足完整的業(yè)務(wù)需求。
檢查是否可用	是。檢查是否可用是功能用戶(hù)需求的一部分。	否。僅檢查可用性不是一項完整事務(wù)，因為該過(guò)程還必須提交預約請求、接收請求信息、檢查可用性、獲取備選日期/時(shí)間并向客戶(hù)提供預訂信息。這些步驟在邏輯上不能分開(kāi)。	否。請求預約和接收請求都是必須執行的前置處理步驟。獲取備選日期/時(shí)間和提供預訂信息是完成基本過(guò)程所需的所有后續處理步驟。	否。只有在提交、接收、處理請求預訂信息并將其返回給客戶(hù)時(shí)，才能滿(mǎn)足完整的業(yè)務(wù)需求。
獲取備選時(shí)間	是。獲取備選時(shí)間是功能用戶(hù)需求的一部分。	否。僅獲取備選時(shí)間不是一個(gè)完整事務(wù)，因為該過(guò)程還必須提交預約請求、接收請求信息、檢查可用性并向客戶(hù)提供預訂信息。這些步驟在邏輯上不能分開(kāi)。	否。請求預約、接收請求和檢查可用性都是必須執行的前置處理步驟。提供預訂信息是完成基本過(guò)程所需的后續處理步驟。	否。只有在提交、接收、處理請求預訂信息并將其返回給客戶(hù)時(shí)，才能滿(mǎn)足完整的業(yè)務(wù)需求。
提供預訂信息	是。提供預訂信息是功能用戶(hù)需求的一部分。	否。僅提供預訂信息不是一個(gè)完整事務(wù)，因為該過(guò)程還必須提交預約請求、接收請求信息、檢查可用性并獲取備選日期/時(shí)間。這些步驟在邏輯上不能分開(kāi)。	否。請求預約、接收請求、檢查可用性和獲取備選時(shí)間都是必須執行的前置處理步驟。	否。只有在提交、接收、處理請求預訂信息并將其返回給客戶(hù)時(shí)，才能滿(mǎn)足完整的業(yè)務(wù)需求。
預約流程	是。預約流程是功能用戶(hù)需求的一部分。	是。處理預約信息是一個(gè)完整事務(wù)，負責接收客戶(hù)的響應、記錄響應并將響應返回給客戶(hù)。	是。處理預約信息可以獨立執行。	是。當客戶(hù)接受預約信息并通知系統，系統記錄預約并向客戶(hù)返回通知時(shí)，就實(shí)現了完整的業(yè)務(wù)需求。
分配司機	是。分配司機是功能用戶(hù)需求的一部分。	是。分配司機是一個(gè)完整事務(wù)，負責接收司機分配通知、記錄司機分配并通知司機。	是。分配司機可以獨立執行。	是。完成司機分配即可滿(mǎn)足業(yè)務(wù)需求。
載客	是。載客是功能用戶(hù)需求的一部分。	否。載客不是一個(gè)完整事務(wù)，因為預約系統還必須將預約記錄標識為已完成。這些步驟在邏輯不能上分開(kāi)。	否。完成預約請求是完成基本過(guò)程必須執行的后續步驟。	否。只有當司機向預約系統告知載客成功，并且預約系統將預約記錄標識為已完成后，才能滿(mǎn)足完整的業(yè)務(wù)需求。
完成預約請求	是。完成預約請求是功能用戶(hù)需求的一部分。	否。僅完成預約請求并不是一個(gè)完整事務(wù)，因為司機還必須告知預約系統客戶(hù)已被接走。這些步驟在邏輯上不能分開(kāi)。	否。載客是完成基本過(guò)程必須執行的前置步驟。	否。只有當司機向預約系統告知客戶(hù)已上車(chē)，并且預約系統將該預約記錄標識為已完成時(shí)，才能滿(mǎn)足完整的業(yè)務(wù)需求。

       表3列出了通過(guò)上述過(guò)程識別出的EP：
       表 3 預約系統識別到的基本過(guò)程

業(yè)務(wù)過(guò)程活動(dòng)	確定符合所有EP識別規則的基本過(guò)程
l  預約請求 l  接收預約請求 l  檢查是否可用 l  獲取備選時(shí)間 l  提供預訂信息	這些活動(dòng)單個(gè)來(lái)說(shuō)都不符合全部的EP識別規則（見(jiàn)上表）。它們只有在組合時(shí)才滿(mǎn)足完整的業(yè)務(wù)需求。EP由這些業(yè)務(wù)過(guò)程活動(dòng)的處理邏輯組成。
預約流程	此業(yè)務(wù)過(guò)程活動(dòng)符合所有EP識別規則（見(jiàn)上表），并構成EP。
分配司機	此業(yè)務(wù)過(guò)程活動(dòng)符合所有EP識別規則（見(jiàn)上表），并構成EP。
l  載客 l  完成預約請求	這些活動(dòng)單個(gè)來(lái)說(shuō)都不符合全部的EP識別規則（見(jiàn)上表）。它們只有在組合時(shí)才滿(mǎn)足完整的業(yè)務(wù)需求。EP由這些業(yè)務(wù)過(guò)程活動(dòng)的處理邏輯組成。

       上述示例演示了如何將業(yè)務(wù)過(guò)程中的單個(gè)活動(dòng)或步驟組成一個(gè)唯一的基本過(guò)程。當將五個(gè)活動(dòng)（請求預約、接收預約請求、檢查是否可用、獲取備選時(shí)間和提供預訂信息）的處理邏輯結合時(shí)，就可以實(shí)現業(yè)務(wù)目標并使業(yè)務(wù)處于持續狀態(tài)。下圖以可視化的方式表示BPM活動(dòng)是如何構成每個(gè)已識別的EP的。
       注：每個(gè)“口”表示為一個(gè)唯一的EP。        缺乏業(yè)務(wù)過(guò)程模型對于識別基本過(guò)程來(lái)說(shuō)是一個(gè)挑戰。下面幾節將探討如何在特定場(chǎng)景中使用除業(yè)務(wù)流程圖以外的方式識別EP。
 
 

4 基本過(guò)程和用例

       用例是需求開(kāi)發(fā)和功能點(diǎn)分析的強大而有效的工具，它們表示“外部參與者與系統之間的交互，以達到特定的目標”，代表了用戶(hù)視角。
       《計數實(shí)踐手冊V4.3—案例研究1》中對用例圖的描述如下：

• l  參與者是用戶(hù)在系統中扮演的角色。參與者可以是人、硬件設備或其他系統，由一個(gè)具有簡(jiǎn)短描述性名稱(chēng)的圖形表示。例如：

  
人力資源部專(zhuān)員

• l  用例是系統為實(shí)現特定目標而需要執行的一組操作，由橢圓和簡(jiǎn)短的描述性名稱(chēng)表示，例如：

• l  一個(gè)參與者通過(guò)一條直線(xiàn)與一個(gè)用例相關(guān)聯(lián)。

       FPA分析師在分析用例圖以識別基本過(guò)程時(shí)需要特別注意“包含”和“擴展”兩種用例關(guān)系。
       “包含”關(guān)系意味著(zhù)被包含的用例不是一個(gè)獨立的用例，它必須在基本用例的邏輯背景中運行。“擴展”關(guān)系意味著(zhù)擴展用例是基本用例的附加步驟，這些步驟可以是可選的，也可以是強制性的。
       以下示例描述了參與者(客戶(hù))與銀行賬戶(hù)系統的三個(gè)基本功能(提現、轉賬和獲取銀行賬戶(hù)對賬單)之間的用例關(guān)系（圖3）。
       注：下圖演示了在識別基本過(guò)程時(shí)對用例圖的解釋?zhuān)饕怯懻撚美g的“<<包含>>”和“<<擴展>>”關(guān)系。因此，有關(guān)登錄/注銷(xiāo)功能的注意事項所引用的活動(dòng)的完整流程工作流不在本示例的范圍內。        根據上述用例圖顯示，用例描述如表4所示。
       注：用例使用自由形式的文本描述，不遵循任何正式的UML規則。
       表 4 銀行賬戶(hù)系統用例描述

用例名稱(chēng)	用例描述
提現	客戶(hù)請求提現。銀行賬戶(hù)系統分配請求的現金金額，系統更新賬戶(hù)余額并顯示客戶(hù)更新的賬戶(hù)余額。
獲取銀行賬戶(hù)對賬單	客戶(hù)請求銀行賬戶(hù)對賬單，銀行賬戶(hù)系統同時(shí)顯示賬戶(hù)對賬單信息和當前銀行賬戶(hù)余額。
轉賬	客戶(hù)請求轉賬。銀行賬戶(hù)系統將資金轉移到指定賬戶(hù)，更新賬戶(hù)余額并顯示客戶(hù)更新的賬戶(hù)余額。
顯示賬戶(hù)余額	執行“提現”、“獲取銀行賬戶(hù)對賬單”或“轉賬”操作后，銀行賬戶(hù)系統立即顯示當前銀行賬戶(hù)余額。
更新賬戶(hù)余額	銀行賬戶(hù)系統在執行提現或轉賬操作后更新客戶(hù)的銀行賬戶(hù)余額。

       注：如果用戶(hù)或系統中止/取消流程，則流程將中斷，且系統沒(méi)有其他響應。

       表5針對每個(gè)用例進(jìn)行了分析，通過(guò)應用第2節“基本過(guò)程、用戶(hù)和業(yè)務(wù)過(guò)程”中所述的EP識別規則來(lái)識別基本過(guò)程。
       表 5 銀行賬戶(hù)系統基本過(guò)程識別規則

	基本過(guò)程識別規則
用例	是否對用戶(hù)有意義？	是否構成一個(gè)完整事務(wù)？	是否自包含？	是否使應用程序的業(yè)務(wù)處于持續狀態(tài)？
提現	是。提現是功能用戶(hù)需求的一部分。	否。僅提現并不是一個(gè)完整事務(wù)，因為該過(guò)程還必須更新銀行賬戶(hù)余額并向客戶(hù)顯示銀行賬戶(hù)余額。這些步驟在邏輯上不能分開(kāi)。	否。更新銀行賬戶(hù)余額和顯示銀行賬戶(hù)余額是完成基本過(guò)程所需的后續處理步驟。	否。只有當客戶(hù)提現，系統更新客戶(hù)的賬戶(hù)余額，并且客戶(hù)收到銀行賬戶(hù)余額顯示時(shí)，才能滿(mǎn)足完整的業(yè)務(wù)需求。
獲取銀行賬戶(hù)對賬單	是。獲取銀行賬戶(hù)對賬單是功能用戶(hù)需求的一部分。	否。僅獲取銀行賬戶(hù)對賬單并不是一項完整事務(wù)，因為該過(guò)程還必須向客戶(hù)顯示銀行賬戶(hù)余額。這些步驟在邏輯上不能分開(kāi)。	否。顯示銀行賬戶(hù)余額是完成基本過(guò)程所需的后續處理步驟。	否。只有當客戶(hù)請求并接收銀行賬戶(hù)對賬單，并收到銀行賬戶(hù)余額顯示時(shí)，才能滿(mǎn)足完整的業(yè)務(wù)需求。
轉賬	是。轉賬是功能用戶(hù)需求的一部分。	否。僅轉賬并不是一個(gè)完整事務(wù)，因為該過(guò)程還必須更新銀行賬戶(hù)余額并向客戶(hù)顯示銀行賬戶(hù)余額。這些步驟在邏輯上不能分開(kāi)。	否。更新銀行賬戶(hù)余額和顯示銀行賬戶(hù)余額是完成基本過(guò)程所需的后續處理步驟。	否。只有當客戶(hù)轉賬，系統更新客戶(hù)的賬戶(hù)余額，并且客戶(hù)收到銀行賬戶(hù)余額顯示時(shí)，才能滿(mǎn)足完整的業(yè)務(wù)需求。
顯示賬戶(hù)余額	是。顯示賬戶(hù)余額是功能用戶(hù)需求的一部分。	否、僅顯示賬戶(hù)余額并不是一項完整事務(wù)，因為該過(guò)程必須先執行以下三項活動(dòng)之一：提現、轉賬、獲取銀行賬戶(hù)對賬單。這些步驟在邏輯上不能分開(kāi)。	否。三項活動(dòng)之一：提現、轉賬或獲取銀行賬戶(hù)對賬單是完成基本過(guò)程所需的前置處理步驟。	否。只有當客戶(hù)提現、轉賬或獲取銀行賬戶(hù)對賬單并收到銀行賬戶(hù)余額顯示時(shí)，才能滿(mǎn)足完整的業(yè)務(wù)需求。
更新賬戶(hù)余額	是。更新賬戶(hù)余額是功能用戶(hù)需求的一部分。	否。更新賬戶(hù)余額并不是一項完整事務(wù)，因為該過(guò)程必須先執行以下兩項活動(dòng)之一：提現或轉賬。這些步驟在邏輯上不能分開(kāi)。	否。兩項活動(dòng)之一：提現或轉賬是完成基本過(guò)程所需的前置處理步驟。	否。只有當客戶(hù)進(jìn)行提現或轉賬并收到銀行賬戶(hù)余額顯示時(shí)，才能滿(mǎn)足完整的業(yè)務(wù)需求。

       表6列出了通過(guò)上述過(guò)程識別出的EP：
       表 6 銀行賬戶(hù)系統識別到的基本過(guò)程

業(yè)務(wù)過(guò)程活動(dòng)	確定符合所有EP識別規則的基本過(guò)程
l  提現 l  更新賬戶(hù)余額 l  顯示賬戶(hù)余額	這些活動(dòng)單個(gè)來(lái)說(shuō)都不符合全部的EP識別規則（見(jiàn)上表）。它們只有在組合時(shí)才滿(mǎn)足完整的業(yè)務(wù)需求。EP由這些業(yè)務(wù)過(guò)程活動(dòng)的處理邏輯組成。
l  獲取賬戶(hù)對賬單 l  顯示賬戶(hù)余額	這些活動(dòng)單個(gè)來(lái)說(shuō)都不符合全部的EP識別規則（見(jiàn)上表）。它們只有在組合時(shí)才滿(mǎn)足完整的業(yè)務(wù)需求。EP由這些業(yè)務(wù)過(guò)程活動(dòng)的處理邏輯組成。
l  轉賬 l  更新賬戶(hù)余額 l  顯示賬戶(hù)余額	這些活動(dòng)單個(gè)來(lái)說(shuō)都不符合全部的EP識別規則（見(jiàn)上表）。它們只有在組合時(shí)才滿(mǎn)足完整的業(yè)務(wù)需求。EP由這些業(yè)務(wù)過(guò)程活動(dòng)的處理邏輯組成。

       用例“提現”、“獲取銀行賬戶(hù)對賬單”和“轉賬”與用例“顯示銀行賬戶(hù)余額”為擴展關(guān)系，這意味著(zhù)顯示銀行賬戶(hù)余額增加了一個(gè)強制性步驟，以完成提現（以及獲取銀行賬戶(hù)對賬單和轉賬）的業(yè)務(wù)價(jià)值。
       同樣，用例“提現”和“轉賬”中包含用例“更新銀行賬戶(hù)余額”，使更新銀行賬戶(hù)余額活動(dòng)成為完成業(yè)務(wù)價(jià)值(提現和轉賬)的強制性步驟。

5 從屏幕模型感知基本過(guò)程

       在多數情況下，功能點(diǎn)分析僅通過(guò)分析屏幕截圖進(jìn)行計數。屏幕截圖是FP分析的寶貴資源，但如果不考慮要實(shí)現的業(yè)務(wù)目標，只分析截圖也可能會(huì )導致EP識別錯誤。
       以下示例描述了FP分析師僅通過(guò)可用的屏幕截圖來(lái)度量計數的場(chǎng)景。
       注：以下截圖僅用于說(shuō)明目的，不代表任何航空公司真實(shí)完整的預訂流程。
       在航空公司預訂系統航班預訂流程中，客戶(hù)可以輸入搜索條件，如“出發(fā)地”和“目的地”、“預訂類(lèi)型（單程、往返或多程）”、“行程日期”和乘客數量，如圖4所示。

圖 4 航空預訂系統搜索條件
客戶(hù)也可以通過(guò)“排序和篩選”條件來(lái)進(jìn)行航班搜索，如圖5所示。        輸入搜索條件后，系統將為行程的第一段提供匹配的航班列表，如圖6所示。        客戶(hù)查看匹配航班的列表，選擇航班的第一航段，核對所選信息，勾選接受或拒絕航班協(xié)議并進(jìn)行下一步，如圖7所示。        如果在搜索條件中選擇的預訂類(lèi)型為“往返”或“多程”，則系統將為行程的其他航段提供匹配的航班列表。圖8顯示了預訂往返航班時(shí)第二航段的可用航班選擇。        客戶(hù)為行程的所有航段選擇航班結束后，系統將顯示整個(gè)行程的行程單，如圖9所示。        客戶(hù)可以查看可用座位，如圖10所示。         客戶(hù)可以從可選座位中選擇座位，如圖11所示。         客戶(hù)可以查看行程的附加服務(wù)，如圖12所示。         客戶(hù)可以選擇并應用附加服務(wù)，如圖13所示。  
        客戶(hù)輸入乘客信息，完成“乘客信息”部分，如圖14所示。         客戶(hù)輸入付款信息，完成“付款信息”部分，如圖15所示。         然后，客戶(hù)可以查看條款并點(diǎn)擊“完成購買(mǎi)”按鈕進(jìn)行購買(mǎi)，如圖16所示。         “客戶(hù)預訂航班”業(yè)務(wù)過(guò)程可根據上述截圖進(jìn)行分析，分解為下列活動(dòng)，如表7所示。

活動(dòng)名稱(chēng)	活動(dòng)描述
輸入搜索條件	客戶(hù)提供出發(fā)地、目的地、預訂類(lèi)型、行程日期和乘客數量。
選擇排序和篩選條件	客戶(hù)可以選擇其他排序和篩選條件。
查看可用航班	系統列出符合搜索條件的可用航班。
選擇航班	客戶(hù)從可用航班列表中選擇最合適的航班?？蛻?hù)核對所選信息并選擇接受或拒絕航班協(xié)議。
選擇其它航班	如果選擇的預訂類(lèi)型為“往返”或“多程”，則根據搜索條件選擇所需航班。
查看行程單	系統顯示所有已選航班和預訂價(jià)格。
查看可選座位	客戶(hù)查看可選座位列表。
選擇座位	客戶(hù)選擇心儀座位。
查看附加服務(wù)	客戶(hù)可以查看其他附加服務(wù)。
選擇附加服務(wù)	客戶(hù)選擇并應用附加服務(wù)。
輸入乘客信息	客戶(hù)輸入乘客信息，如姓名、出生日期、聯(lián)系電話(huà)和郵箱。
輸入付款信息	客戶(hù)輸入付款信息，如信用卡號、持卡人姓名、有效期和密碼。
確認航班預訂	客戶(hù)確認航班預訂。系統處理預訂，驗證信用卡信息，并向客戶(hù)發(fā)送確認行程的通知。

注：如果用戶(hù)或系統中止/取消流程，則流程將中斷，且系統沒(méi)有其他響應。

       表8針對每個(gè)活動(dòng)進(jìn)行了分析，通過(guò)應用第2節“基本過(guò)程、用戶(hù)和業(yè)務(wù)過(guò)程”中所述的EP識別規則來(lái)識別基本過(guò)程。
表 8 航空預訂系統基本過(guò)程識別規則

	基本過(guò)程識別規則
活動(dòng)名稱(chēng)	是否對用戶(hù)有意義？	是否構成一個(gè)完整事務(wù)？	是否自包含？	是否使應用程序的業(yè)務(wù)處于持續狀態(tài)？
輸入搜索條件	是。輸入搜索條件是功能用戶(hù)需求的一部分。	否。輸入搜索條件是查看可用航班的必要步驟。這些步驟在邏輯上不能分開(kāi)。	否。選擇排序和篩選條件和查看可用航班是完成基本過(guò)程所需的后續處理步驟。	否。只有當輸入搜索、排序和篩選條件，并向客戶(hù)顯示可用航班時(shí)，才能滿(mǎn)足完整的業(yè)務(wù)需求。
選擇排序和篩選條件	是。選擇排序和篩選條件是功能用戶(hù)需求的一部分。	否。選擇排序和篩選條件是查看可用航班的可選步驟。這些步驟在邏輯上不能分開(kāi)。	否。輸入搜索條件和查看可用航班分別是完成基本過(guò)程所需的前置和后續處理步驟。	否。只有當輸入搜索、排序和篩選條件，并向客戶(hù)顯示可用航班時(shí)，才能滿(mǎn)足完整的業(yè)務(wù)需求。
查看可用航班	是。查看可用航班是功能用戶(hù)需求的一部分。	否。僅查看可用航班不是一個(gè)完整事務(wù)。因為輸入搜索、排序和篩選條件是該過(guò)程的前置步驟。這些步驟在邏輯上不能分開(kāi)。	否。輸入搜索、排序和篩選條件是完成基本過(guò)程所需的前置處理步驟。	否。只有當輸入搜索、排序和篩選條件，并向客戶(hù)顯示可用航班時(shí)，才能滿(mǎn)足完整的業(yè)務(wù)需求。
選擇航班	是。選擇航班是功能用戶(hù)需求的一部分。	否。僅選擇航班不是一個(gè)完整事務(wù)。因為客戶(hù)還可以選擇其它航班，并且必須查看行程單。這些步驟在邏輯上不能分開(kāi)。	否。選擇其它航班并查看行程單是完成基本過(guò)程所需的后續處理步驟。	否。只有當客戶(hù)選擇航班、選擇其他航班并查看行程單時(shí)，才能滿(mǎn)足完整的業(yè)務(wù)需求。
選擇其它航班	是。選擇其他航班是功能用戶(hù)需求的一部分。	否。僅選擇其他航班不是一個(gè)完整事務(wù)。因為客戶(hù)必須選擇第一航段航班并查看行程單。這些步驟在邏輯上不能分開(kāi)。	否。選擇航班和查看行程單分別是完成基本過(guò)程所需的前置和后續處理步驟。	否。只有當客戶(hù)選擇航班、選擇其他航班并查看行程單時(shí)，才能滿(mǎn)足完整的業(yè)務(wù)需求。
查看行程單	是。查看行程單是功能用戶(hù)需求的一部分。	否。僅查看行程單不是一個(gè)完整事務(wù)。因為在此之前客戶(hù)還必須選擇第一航段航班和其他航班。這些步驟在邏輯上不能分開(kāi)。	否。選擇航班和選擇其他航班是完成基本過(guò)程所需的前置處理步驟。	否。只有當客戶(hù)選擇航班、選擇其他航班并查看行程單時(shí)，才能滿(mǎn)足完整的業(yè)務(wù)需求。
查看可選座位	是。查看可選座位是功能用戶(hù)需求的一部分。	是。僅查看可選座位是一個(gè)完整事務(wù)。	是。查看可選座位可獨立執行。	是。當客戶(hù)查看可選座位時(shí)，即可滿(mǎn)足全部業(yè)務(wù)需求。
選擇座位	是。選擇座位是功能用戶(hù)需求的一部分。	否。僅選擇座位不是一個(gè)完整事務(wù)。因為客戶(hù)還必須選擇附加服務(wù)、輸入乘客信息、輸入付款信息，并確認航班預訂以完成預訂。這些步驟在邏輯上不能分開(kāi)。	否。選擇附加服務(wù)、輸入乘客信息、輸入付款信息和確認航班預訂是完成基本過(guò)程所需的后續處理步驟。	否。只有當客戶(hù)選擇座位、選擇附加服務(wù)、輸入乘客信息、輸入付款信息和確認航班預訂時(shí)，才能滿(mǎn)足完整的業(yè)務(wù)需求。
查看附加服務(wù)	是。查看附加服務(wù)是功能用戶(hù)需求的一部分。	是。僅查看附加服務(wù)是一個(gè)完整事務(wù)。	是。查看附加服務(wù)可獨立執行。	是。當客戶(hù)查看附加服務(wù)時(shí)，即可滿(mǎn)足全部業(yè)務(wù)需求。
選擇附加服務(wù)	是。選擇附加服務(wù)是功能用戶(hù)需求的一部分。	否。僅選擇附加服務(wù)并不是一個(gè)完整事務(wù)。因為客戶(hù)還必須選擇座位、輸入乘客信息、輸入付款信息，并確認航班預訂以完成基本過(guò)程。這些步驟在邏輯上不能分開(kāi)。	否。選擇座位是前置處理步驟，輸入乘客信息、付款信息和確認航班預訂是完成基本過(guò)程所需的后續處理步驟。	否。只有當客戶(hù)選擇座位、選擇附加服務(wù)、輸入乘客信息、輸入付款信息和確認航班預訂時(shí)，才能滿(mǎn)足完整的業(yè)務(wù)需求。
輸入乘客信息	是。輸入乘客信息是功能用戶(hù)需求的一部分。	否。僅輸入乘客信息不是完整事務(wù)，因為客戶(hù)還必須選擇座位、選擇附加服務(wù)、輸入付款信息并確認航班預訂。這些步驟在邏輯上不能分開(kāi)。	否。選擇座位和選擇附加服務(wù)是前置處理步驟，輸入付款信息和確認航班預訂是完成基本過(guò)程所需的后續處理步驟。	否。只有當客戶(hù)選擇座位、選擇附加服務(wù)、輸入乘客信息、輸入付款信息和確認航班預訂時(shí)，才能滿(mǎn)足完整的業(yè)務(wù)需求。
輸入付款信息	是。輸入付款信息是功能用戶(hù)需求的一部分。	否。僅輸入付款信息不是一個(gè)完整事務(wù)，因為客戶(hù)還必須選擇座位、選擇附加服務(wù)、輸入乘客信息并確認航班預訂才能完成預訂。這些步驟不能在邏輯上分開(kāi)。	否。選擇座位、選擇附加服務(wù)和輸入乘客信息是前置處理步驟，確認航班預訂是完成基本過(guò)程所需的后續處理步驟。	否。只有當客戶(hù)選擇座位、選擇附加服務(wù)、輸入乘客信息、輸入付款信息和確認航班預訂時(shí)，才能滿(mǎn)足完整的業(yè)務(wù)需求。
確認航班預訂	是。確認航班預訂是功能用戶(hù)需求的一部分。	否。僅確認航班預訂不是一個(gè)完整事務(wù)，它包括選擇座位、選擇附加服務(wù)、輸入乘客信息和輸入付款信息。這些步驟不能在邏輯上分開(kāi)。	否。確認航班預訂包括選擇座位、選擇附加服務(wù)、輸入乘客信息和支付信息，這些是完成基本過(guò)程所需的前置處理步驟。	否。只有當客戶(hù)選擇座位、選擇附加服務(wù)、輸入乘客信息、輸入付款信息和確認航班預訂時(shí)，才能滿(mǎn)足完整的業(yè)務(wù)需求。

表9列出了通過(guò)上述過(guò)程識別出的EP：

業(yè)務(wù)活動(dòng)	確定符合所有EP識別規則的基本過(guò)程
l  輸入搜索條件 l  選擇排序和篩選條件 l  查看可用航班	這些活動(dòng)單個(gè)來(lái)說(shuō)都不符合全部的EP識別規則（見(jiàn)上表）。它們只有在組合時(shí)才滿(mǎn)足完整的業(yè)務(wù)需求。EP由這些業(yè)務(wù)過(guò)程活動(dòng)的處理邏輯組成。
l  選擇航班 l  選擇其他航班 l  查看行程單	這些活動(dòng)單個(gè)來(lái)說(shuō)都不符合全部的EP識別規則（見(jiàn)上表）。它們只有在組合時(shí)才滿(mǎn)足完整的業(yè)務(wù)需求。EP由這些業(yè)務(wù)過(guò)程活動(dòng)的處理邏輯組成。
l  查看可選座位	此業(yè)務(wù)過(guò)程活動(dòng)符合所有EP識別規則（見(jiàn)上表），并構成EP。
l  查看附加服務(wù)	此業(yè)務(wù)過(guò)程活動(dòng)符合所有EP識別規則（見(jiàn)上表），并構成EP。
l  選擇座位 l  選擇附加服務(wù) l  輸入乘客信息 l  輸入付款信息 l  確認航班預訂	這些活動(dòng)單個(gè)來(lái)說(shuō)都不符合全部的EP識別規則（見(jiàn)上表）。它們只有在組合時(shí)才滿(mǎn)足完整的業(yè)務(wù)需求。EP由這些業(yè)務(wù)過(guò)程活動(dòng)的處理邏輯組成。

將EP識別規則應用于與系統截圖相對應的業(yè)務(wù)活動(dòng)，并考慮每組截圖中要實(shí)現的業(yè)務(wù)價(jià)值，識別出了五個(gè)基本過(guò)程。
 

6 結論

本文旨在為CPM v4.3.1關(guān)于基本過(guò)程識別規則和唯一性檢測提供指導。本文包含的示例僅為參考，不代表任何真實(shí)系統或業(yè)務(wù)領(lǐng)域。
 

7 參考文獻

[1]  IFPUG, Function Point Analysis (FPA), CPM v4.3.1, Part 1, section 5.5.2.1
[2]  IFPUG, Function Point Analysis (FPA), CPM v4.3.1, Part 2, page 7-11
[3]  Baklizky, D. FPA Applied to BPM-Based System Projects (vsn 1.0 2018-02-15), Page 3,” 3. Concepts of Business Process Management”, URL: http://tiny.cc/1ghsuz 
[4]  Baklizky, D. FPA Applied to BPM-Based System Projects (vsn 1.0 2018-02-15), Page 11,”4.4 Identify Transactional Functions”, URL: http://tiny.cc/1ghsuz 
[5]  IFPUG, Function Point Analysis (FPA), CPM v4.3.1, Part 1 Page 5 - ISO/IEC 14143-1:2007
[6]  IFPUG, Function Point Analysis (FPA), CPM v4.3.1, Part 1 Page 8 - ISO/IEC 14143-1:2007 
[7]  IFPUG, Function Point Analysis (FPA), CPM v4.3.1, Part 2 Page 3-2
[8]  IFPUG, Function Point Analysis (FPA), CPM v4.3.1, Part 2 Page 7-5
[9]  IFPUG, Function Point Analysis (FPA), CPM v4.3.1, Part 1 Page 7
[10]  IFPUG, Function Point Analysis (FPA), CPM v4.3.1, Part 1 Page 7 - ISO/IEC 14143-1:2007
[11]  IFPUG, Function Point Analysis (FPA), CPM v4.3.1, Part 1 Page 3 - ISO/IEC 14143-1:2007
[12]  IFPUG, Function Point Analysis (FPA), CPM v4.3.1, Part 1 Pages 14, 15 - ISO/IEC 14143-1:2007 
[13]  Techopedia, Use Case, Last Update: Sept 2014, URL: http://tiny.cc/7ghsuz 
[14]  IFPUG, Case Study 1 Part 1 – Analysis - Using Counting Practices Manual Release 4.3, section 2.9 Use Case Diagrams, page 24