（本文由北京中基數(shù)聯(lián)科技有限公司撰寫，僅供學(xué)習(xí)參考使用，版權(quán)歸中基數(shù)聯(lián)所有，轉(zhuǎn)載請標(biāo)明出處。）
1 引言
功能點分析的難點是如何確定一個功能或一組相關(guān)功能是否構(gòu)成一個基本過程。計數(shù)實踐手冊（CPM），v.4.3.1定義了基本過程的概念：“將功能用戶需求組合或分解為滿足以下所有條件的最小活動單元：對用戶有意義；構(gòu)成完整的事務(wù)；自包含，并使應(yīng)用程序的業(yè)務(wù)處于持續(xù)狀態(tài)”。
雖然這是一個相當(dāng)簡單的規(guī)則，但在許多情況下，F(xiàn)P分析師很難在實踐中正確應(yīng)用。甚至在某些情況下，F(xiàn)P分析師應(yīng)用該規(guī)則時也會有所不同。本文為FP分析師解釋和應(yīng)用此基本過程規(guī)則提供了進(jìn)一步指導(dǎo)。
正確應(yīng)用基本過程規(guī)則的一個關(guān)鍵領(lǐng)域是在合同協(xié)議中，功能點（FP）對合同進(jìn)行度量和定價?？蛻艉蛙浖?wù)提供商可能對基本過程（EP）的確定以及基本過程的組成或分解程度存在分歧。許多軟件服務(wù)提供商假定屏幕截圖和基本過程之間存在簡單的一對一關(guān)系，但是他們并不了解基于屏幕截圖的功能需求。在這些協(xié)議中基于功能用戶需求（FUR）對項目進(jìn)行度量和定價，并且可以基于用例和屏幕截圖進(jìn)行推導(dǎo)。
基本過程的分解程度可能太過粗糙，如通過截圖計算一個EP，而截圖上缺少其他或從屬EP的情況?；蛘?，識別基本過程的分解程度過于精細(xì)，導(dǎo)致EP計數(shù)過多，如完成一項功能需要多個步驟或截圖的情況。
這兩種情況出現(xiàn)的原因都是因為沒有足夠的細(xì)節(jié)從用戶的角度來確定合適的EP。軟件服務(wù)提供商擔(dān)心項目規(guī)模的估算錯誤會為開發(fā)功能提供不準(zhǔn)確的成本、進(jìn)度和工作量估算。
此外，在分析基本過程的唯一性時，DETs、FTRs或處理邏輯的微小變化也可能會引起爭議。CPM 4.3.1規(guī)定，“當(dāng)比較兩個基本過程時，如果它們包含不同的DETs、FTRs或處理邏輯，則將它們識別為獨立的基本過程”。
基本過程是功能點中最重要的概念之一，基本過程規(guī)則的錯誤解釋和誤用會顯著改變功能點計數(shù)的結(jié)果。在功能點計數(shù)期間識別的基本過程的數(shù)量是確定項目功能規(guī)模的重要因素。
本文將提供基本過程概念和基本過程唯一性的相關(guān)示例，使客戶和軟件服務(wù)提供商之間就度量和定價的內(nèi)容進(jìn)行更好的溝通，從而促進(jìn)基于FP的商業(yè)活動和度量。本文所提到的示例僅用于說明目的；每位度量分析師必須根據(jù)CPM當(dāng)前版本中定義的計數(shù)規(guī)則，正確度量基本過程。
免責(zé)聲明：本文中提供的所有示例僅表示對系統(tǒng)的公開解釋，以便為討論的主題提供說明，并不代表任何公司系統(tǒng)的真實運行情況。
2 目標(biāo)讀者
本文為功能點分析師在應(yīng)用《計數(shù)實踐手冊》（CPM 4.3系列）來確定基本過程的組成提供了指導(dǎo)，以提高基本過程評估的一致性。
本文的目標(biāo)讀者包括需要在FPA計數(shù)期間應(yīng)用基本過程識別規(guī)則的所有專業(yè)人員。
3 基本過程、用戶和業(yè)務(wù)過程
《FPA在BPM系統(tǒng)項目中的應(yīng)用》白皮書為在BPM環(huán)境中應(yīng)用FPA方法奠定了基礎(chǔ)，提供了描述BPM概念和業(yè)務(wù)過程背景的材料，解釋了如何應(yīng)用FPA來度量基于BPM的系統(tǒng)項目，并舉例說明。
該文件指出：
-
“業(yè)務(wù)過程由一組在技術(shù)環(huán)境中協(xié)調(diào)執(zhí)行的活動組成。這些活動共同實現(xiàn)了一個業(yè)務(wù)目標(biāo)”。
-
-
“業(yè)務(wù)過程實例代表公司運營業(yè)務(wù)中的具體案例，由活動實例組成” 。
-
-
“在業(yè)務(wù)過程模型中，確定哪些活動代表功能用戶需求，并將每個活動組合或分解為滿足基本過程條件的最小活動單元”。
CPM將功能用戶需求（FUR）定義為“描述軟件要做什么，提供什么樣的服務(wù)的用戶需求子集”。因此，功能用戶需求（FUR）對應(yīng)于定義業(yè)務(wù)過程活動的邏輯順序，從而實現(xiàn)業(yè)務(wù)目標(biāo)。業(yè)務(wù)過程活動對應(yīng)于交付給用戶的每項有意義的功能，負(fù)責(zé)業(yè)務(wù)過程要實現(xiàn)的總體目標(biāo)的一部分。
CPM將用戶定義為“在任何時候與軟件通訊或交互的任何人或事物” ，用戶角度被定義為“用戶感知的功能用戶需求” 。此外，用戶角度表示“以用戶語言對用戶業(yè)務(wù)需求進(jìn)行的正式描述”、“是對業(yè)務(wù)功能的描述”。因此，“用戶”和“用戶角度”的定義一起使用，說明用戶代表業(yè)務(wù)過程的服務(wù)對象。用戶通常是與被計數(shù)的應(yīng)用程序交互的人，但與應(yīng)用程序交互的外部系統(tǒng)或設(shè)備也被視為用戶。
術(shù)語“用戶可識別”的定義為“事務(wù)和數(shù)據(jù)需求是由用戶和軟件開發(fā)人員都認(rèn)同并理解的”[6]。換句話說，用戶可識別是業(yè)務(wù)過程或業(yè)務(wù)過程活動中的所有內(nèi)容。
基本過程識別規(guī)則是將業(yè)務(wù)過程活動拆分為滿足以下條件的最小活動單元：
-
對用戶有意義：“用戶可識別并滿足功能用戶需求”的所有內(nèi)容[8]；
-
-
構(gòu)成一個完整事務(wù)：“用戶為完成一個基本過程的所有需求。如驗證、數(shù)學(xué)運算或計算、讀取或維護(hù)數(shù)據(jù)功能”；
-
自包含：“功能用戶需求不需要任何前置或后續(xù)處理步驟就可以獨立完成”；
-
使應(yīng)用程序的業(yè)務(wù)處于持續(xù)狀態(tài)：“過程已完全執(zhí)行，功能用戶需求已得到滿足，無需再做任何事情”。
“對用戶有意義”相當(dāng)于“對業(yè)務(wù)有意義”，即從用戶的角度來看，是一切與業(yè)務(wù)目標(biāo)相關(guān)的功能需求。當(dāng)然，并不是說對用戶沒有明確意義的內(nèi)容就是對業(yè)務(wù)無意義：對業(yè)務(wù)過程進(jìn)行詳細(xì)分析可以顯示出用戶可識別的更多功能需求。
“完整事務(wù)”的概念與處理邏輯的概念相關(guān)聯(lián)，即“用戶要求的完成一個基本過程的特定需求。如驗證、數(shù)學(xué)運算或計算、讀取或維護(hù)數(shù)據(jù)功能”。這意味著，“完整事務(wù)”必須包含所有適用的處理邏輯，從用戶的角度實現(xiàn)部分或所有業(yè)務(wù)目標(biāo)。處理邏輯可以有業(yè)務(wù)過程的一個或多個處理步驟，并且包括應(yīng)用程序響應(yīng)消息。處理步驟確保所有維護(hù)ILF的屬性都已寫入。例如，在一個處理步驟中，應(yīng)用程序向用戶展示信息以供查看，并允許用戶確認(rèn)，這是一個EP的一部分，而不是一個完整的EP。
“自包含”和“使業(yè)務(wù)處于持續(xù)狀態(tài)”的概念和業(yè)務(wù)過程活動有關(guān)，它基于用戶視角交付業(yè)務(wù)可識別的結(jié)果。“自包含”的活動意味著可以在不需要執(zhí)行任何其他活動的前提下獨立執(zhí)行該活動。如果一個活動有其他可能完成或必須完成的活動作為前置任務(wù)，那么該活動則不能“自包含”，因為它依賴于前置任務(wù)功能?？梢酝ㄟ^一個包含選擇條件、檢索信息、顯示結(jié)果的查詢功能來說明這種情況：選擇條件必須是在檢索信息之前的強制性前置活動，檢索信息是顯示結(jié)果的強制性前置活動。因此，選擇條件和檢索信息都不是“自包含”的，因為只有在顯示結(jié)果之后才能實現(xiàn)業(yè)務(wù)目標(biāo)。所以，“選擇條件+檢索信息+顯示結(jié)果”的組合是“自包含的”。
“持續(xù)狀態(tài)”的概念表明，當(dāng)時事務(wù)完成時，所需的業(yè)務(wù)功能已經(jīng)完成，不需要后續(xù)任何步驟。所有數(shù)據(jù)處于最終狀態(tài)，并滿足功能用戶需求。此時，系統(tǒng)可以禁用或關(guān)閉，且數(shù)據(jù)可用于下一次EP，如果必須重復(fù)之前的EP，則說明該EP未達(dá)到持續(xù)狀態(tài)。
識別EP的所有關(guān)鍵概念都可以通過業(yè)務(wù)過程相關(guān)聯(lián)：EP由為業(yè)務(wù)過程提供所需步驟的活動或一組相關(guān)活動組成，其結(jié)果是最小的、有意義的、完整的和業(yè)務(wù)可識別的。
然而，僅識別EP是不夠的，還需要在識別EP之后，按照之前同樣適用的規(guī)則，與已識別的其他EP相比，確保EP不會重復(fù)?；具^程的唯一性是基本過程的另一個重要概念，需要在業(yè)務(wù)過程的背景中對其加以理解。
正如CPM中定義的，唯一性檢測表明，“當(dāng)與已經(jīng)識別到的基本過程進(jìn)行比較時，如果兩個相似的基本過程滿足下列條件，則把它們當(dāng)作同一個基本過程：
-
要求相同的DETs集；
-
要求相同的FTRs集；
-
要求相同的完成基本過程的處理邏輯。”
此外它還指出：“一個基本過程在多個可選事件中可能包含微小的DETs、FTRs或處理邏輯的變化”、“不要把一個基本過程的多種處理邏輯形式拆分為多個基本過程” 。
那么如何確定何時發(fā)生“DETs、FTRs或處理邏輯的微小變化”呢? 處理邏輯以及DET和FTR能夠使EP執(zhí)行業(yè)務(wù)過程目標(biāo)。因此，在分析EP唯一性時，最重要的是了解預(yù)期的業(yè)務(wù)目標(biāo)。當(dāng)比較兩個或多個在DET、FTR或處理邏輯上有微小變化，但從用戶的角度來看滿足相同業(yè)務(wù)目標(biāo)的類似的EP時，所有EP作為一個唯一的EP進(jìn)行度量。例如，在分析兩個類似EP時，檢查DET、FTR和處理邏輯的微小變化是否足以識別不同的業(yè)務(wù)目標(biāo)，如果可以，則度量為不同的EP，否則認(rèn)為是一個EP。
當(dāng)增強項目需要更改EP的處理邏輯、DET或FTR的某一部分時，如果該EP要實現(xiàn)的業(yè)務(wù)目標(biāo)保持不變，則不能將受影響的EP分解為多個不同的EP。
以下示例說明了前文描述的所有概念。下圖為“預(yù)約系統(tǒng)”的業(yè)務(wù)過程，其業(yè)務(wù)目標(biāo)是“乘客預(yù)約乘車”。
圖 1 預(yù)約系統(tǒng)流程圖
業(yè)務(wù)過程活動如表1所示：
表 1 預(yù)約系統(tǒng)業(yè)務(wù)過程活動
注：如果用戶或系統(tǒng)中止/取消流程，則流程將中斷，且系統(tǒng)沒有其他響應(yīng)。
“乘客”和“司機”是預(yù)約系統(tǒng)的用戶。因此，預(yù)約系統(tǒng)業(yè)務(wù)價值由預(yù)約過程的用戶視圖表示，這是識別基本過程的規(guī)則之一。
表2通過應(yīng)用上述EP識別規(guī)則，對每個業(yè)務(wù)過程活動進(jìn)行了分析，以識別基本過程：
表 2 預(yù)約系統(tǒng)基本過程識別規(guī)則
表3列出了通過上述過程識別出的EP：
表 3 預(yù)約系統(tǒng)識別到的基本過程
上述示例演示了如何將業(yè)務(wù)過程中的單個活動或步驟組成一個唯一的基本過程。當(dāng)將五個活動（請求預(yù)約、接收預(yù)約請求、檢查是否可用、獲取備選時間和提供預(yù)訂信息）的處理邏輯結(jié)合時，就可以實現(xiàn)業(yè)務(wù)目標(biāo)并使業(yè)務(wù)處于持續(xù)狀態(tài)。下圖以可視化的方式表示BPM活動是如何構(gòu)成每個已識別的EP的。
注：每個“口”表示為一個唯一的EP。
圖 2 流程圖中的基本過程識別
缺乏業(yè)務(wù)過程模型對于識別基本過程來說是一個挑戰(zhàn)。下面幾節(jié)將探討如何在特定場景中使用除業(yè)務(wù)流程圖以外的方式識別EP。
4 基本過程和用例
用例是需求開發(fā)和功能點分析的強大而有效的工具，它們表示“外部參與者與系統(tǒng)之間的交互，以達(dá)到特定的目標(biāo)”，代表了用戶視角。
《計數(shù)實踐手冊V4.3—案例研究1》中對用例圖的描述如下：
-
l 參與者是用戶在系統(tǒng)中扮演的角色。參與者可以是人、硬件設(shè)備或其他系統(tǒng)，由一個具有簡短描述性名稱的圖形表示。例如：
人力資源部專員
-
l 用例是系統(tǒng)為實現(xiàn)特定目標(biāo)而需要執(zhí)行的一組操作，由橢圓和簡短的描述性名稱表示，例如：
-
l 一個參與者通過一條直線與一個用例相關(guān)聯(lián)。
FPA分析師在分析用例圖以識別基本過程時需要特別注意“包含”和“擴(kuò)展”兩種用例關(guān)系。
“包含”關(guān)系意味著被包含的用例不是一個獨立的用例，它必須在基本用例的邏輯背景中運行。“擴(kuò)展”關(guān)系意味著擴(kuò)展用例是基本用例的附加步驟，這些步驟可以是可選的，也可以是強制性的。
以下示例描述了參與者(客戶)與銀行賬戶系統(tǒng)的三個基本功能(提現(xiàn)、轉(zhuǎn)賬和獲取銀行賬戶對賬單)之間的用例關(guān)系（圖3）。
注：下圖演示了在識別基本過程時對用例圖的解釋，主要是討論用例之間的“<<包含>>”和“<<擴(kuò)展>>”關(guān)系。因此，有關(guān)登錄/注銷功能的注意事項所引用的活動的完整流程工作流不在本示例的范圍內(nèi)。
圖 3 銀行賬戶系統(tǒng)用例圖
根據(jù)上述用例圖顯示，用例描述如表4所示。
注：用例使用自由形式的文本描述，不遵循任何正式的UML規(guī)則。
表 4 銀行賬戶系統(tǒng)用例描述
注：如果用戶或系統(tǒng)中止/取消流程，則流程將中斷，且系統(tǒng)沒有其他響應(yīng)。
表5針對每個用例進(jìn)行了分析，通過應(yīng)用第2節(jié)“基本過程、用戶和業(yè)務(wù)過程”中所述的EP識別規(guī)則來識別基本過程。
表 5 銀行賬戶系統(tǒng)基本過程識別規(guī)則
表6列出了通過上述過程識別出的EP：
表 6 銀行賬戶系統(tǒng)識別到的基本過程
用例“提現(xiàn)”、“獲取銀行賬戶對賬單”和“轉(zhuǎn)賬”與用例“顯示銀行賬戶余額”為擴(kuò)展關(guān)系，這意味著顯示銀行賬戶余額增加了一個強制性步驟，以完成提現(xiàn)（以及獲取銀行賬戶對賬單和轉(zhuǎn)賬）的業(yè)務(wù)價值。
同樣，用例“提現(xiàn)”和“轉(zhuǎn)賬”中包含用例“更新銀行賬戶余額”，使更新銀行賬戶余額活動成為完成業(yè)務(wù)價值(提現(xiàn)和轉(zhuǎn)賬)的強制性步驟。
5 從屏幕模型感知基本過程
在多數(shù)情況下，功能點分析僅通過分析屏幕截圖進(jìn)行計數(shù)。屏幕截圖是FP分析的寶貴資源，但如果不考慮要實現(xiàn)的業(yè)務(wù)目標(biāo)，只分析截圖也可能會導(dǎo)致EP識別錯誤。
以下示例描述了FP分析師僅通過可用的屏幕截圖來度量計數(shù)的場景。
注：以下截圖僅用于說明目的，不代表任何航空公司真實完整的預(yù)訂流程。
在航空公司預(yù)訂系統(tǒng)航班預(yù)訂流程中，客戶可以輸入搜索條件，如“出發(fā)地”和“目的地”、“預(yù)訂類型（單程、往返或多程）”、“行程日期”和乘客數(shù)量，如圖4所示。
圖 4 航空預(yù)訂系統(tǒng)搜索條件
客戶也可以通過“排序和篩選”條件來進(jìn)行航班搜索，如圖5所示。
圖 5 航空預(yù)訂系統(tǒng)排序和篩選條件
輸入搜索條件后，系統(tǒng)將為行程的第一段提供匹配的航班列表，如圖6所示。
圖 6 航空預(yù)訂系統(tǒng)匹配航班列表
客戶查看匹配航班的列表，選擇航班的第一航段，核對所選信息，勾選接受或拒絕航班協(xié)議并進(jìn)行下一步，如圖7所示。
圖 7 航空預(yù)訂系統(tǒng)核對信息
如果在搜索條件中選擇的預(yù)訂類型為“往返”或“多程”，則系統(tǒng)將為行程的其他航段提供匹配的航班列表。圖8顯示了預(yù)訂往返航班時第二航段的可用航班選擇。
圖 8 航空預(yù)訂系統(tǒng)航班選擇列表
客戶為行程的所有航段選擇航班結(jié)束后，系統(tǒng)將顯示整個行程的行程單，如圖9所示。
圖 9 航空預(yù)定系統(tǒng)行程單
客戶可以查看可用座位，如圖10所示。
圖 10 航空預(yù)訂系統(tǒng)可選座位展示
客戶可以從可選座位中選擇座位，如圖11所示。
圖 11 航空預(yù)訂系統(tǒng)座位選擇
客戶可以查看行程的附加服務(wù)，如圖12所示。
圖 12 航空預(yù)訂系統(tǒng)添加附加服務(wù)
客戶可以選擇并應(yīng)用附加服務(wù)，如圖13所示。
圖 13 航空預(yù)訂系統(tǒng)應(yīng)用附加服務(wù)
客戶輸入乘客信息，完成“乘客信息”部分，如圖14所示。
圖 14 航空預(yù)訂系統(tǒng)乘客信息
客戶輸入付款信息，完成“付款信息”部分，如圖15所示。
圖 15 航空預(yù)訂系統(tǒng)付款信息
然后，客戶可以查看條款并點擊“完成購買”按鈕進(jìn)行購買，如圖16所示。
圖 16 航空預(yù)定系統(tǒng)完成購買
“客戶預(yù)訂航班”業(yè)務(wù)過程可根據(jù)上述截圖進(jìn)行分析，分解為下列活動，如表7所示。
表 7 航空預(yù)訂系統(tǒng)過程活動
注：如果用戶或系統(tǒng)中止/取消流程，則流程將中斷，且系統(tǒng)沒有其他響應(yīng)。
表8針對每個活動進(jìn)行了分析，通過應(yīng)用第2節(jié)“基本過程、用戶和業(yè)務(wù)過程”中所述的EP識別規(guī)則來識別基本過程。
表 8 航空預(yù)訂系統(tǒng)基本過程識別規(guī)則
表9列出了通過上述過程識別出的EP：
將EP識別規(guī)則應(yīng)用于與系統(tǒng)截圖相對應(yīng)的業(yè)務(wù)活動，并考慮每組截圖中要實現(xiàn)的業(yè)務(wù)價值，識別出了五個基本過程。
6 結(jié)論
本文旨在為CPM v4.3.1關(guān)于基本過程識別規(guī)則和唯一性檢測提供指導(dǎo)。本文包含的示例僅為參考，不代表任何真實系統(tǒng)或業(yè)務(wù)領(lǐng)域。
7 參考文獻(xiàn)
[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
以上就是軟件造價評估公司中基數(shù)聯(lián)為您帶來的“基本過程的FPA規(guī)則解釋”所有內(nèi)容，更多軟件開發(fā)成本估算知識敬請關(guān)注中基數(shù)聯(lián)！
