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