（本文由北京中基數聯(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)單元：
-
對用戶(hù)有意義：“用戶(hù)可識別并滿(mǎn)足功能用戶(hù)需求”的所有內容[8]；
-
構成一個(gè)完整事務(wù)：“用戶(hù)為完成一個(gè)基本過(guò)程的所有需求。如驗證、數學(xué)運算或計算、讀取或維護數據功能”；
-
自包含：“功能用戶(hù)需求不需要任何前置或后續處理步驟就可以獨立完成”；
-
使應用程序的業(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ò)程：
-
要求相同的DETs集；
-
要求相同的FTRs集；
-
要求相同的完成基本過(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ē)”。
圖 1 預約系統流程圖
業(yè)務(wù)過(guò)程活動(dòng)如表1所示：
表 1 預約系統業(yè)務(wù)過(guò)程活動(dòng)
|
活動(dòng)名稱(chēng) |
活動(dòng)描述 |
|
請求預約 |
客戶(hù)向預約系統發(fā)送預約請求，提供預約數據屬性：日期、時(shí)間、起點(diǎn)和終點(diǎn)。 |
|
接收預約請求 |
預約系統接收客戶(hù)預約請求并將請求數據記錄在預約數據庫中。 |
|
檢查是否可用 |
預約系統在預約數據庫中搜索請求數據可用性。預訂系統設置“可用狀態(tài)”。如果搜索到與該請求匹配的可用日期和時(shí)間段，則設置為“是”；如果日期和時(shí)間段不可用，則將“可用狀態(tài)”設置為“否”。 |
|
獲取備選時(shí)間 |
如果可用狀態(tài)=“否”，預約系統將在預約數據庫中搜索所請求的起點(diǎn)和終點(diǎn)最近的可用日期和時(shí)間段。 |
|
提供預定數據 |
預約系統向客戶(hù)發(fā)送自動(dòng)通知，根據原始請求提供預訂數據（如果可用狀態(tài)=“是”）或提供最近的可用日期和時(shí)間段（如果可用狀態(tài)=“否”）。 |
|
預約流程 |
客戶(hù)回復預約系統，接受或拒絕預訂數據。預約系統將響應記錄在預約數據庫中。如果響應通知為“已接受”，預約系統將通知客戶(hù)有關(guān)預訂數據的詳細信息。如果響應通知為“拒絕”，預約系統將向客戶(hù)確認拒絕，流程結束。 |
|
分配司機 |
如果客戶(hù)響應通知為“已接受”，預約系統將為司機分配已確認的日期、時(shí)間、起點(diǎn)和終點(diǎn)。預約系統將預約信息記錄在預約數據庫中，并通知指定的司機。 |
|
載客 |
司機在預約的日期、時(shí)間和起點(diǎn)載客，并向預約系統發(fā)送載客確認。 |
|
完成預約請求 |
預約系統在預約數據庫中將預訂信息標記為已完成，流程結束。 |
注：如果用戶(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。
圖 2 流程圖中的基本過(guò)程識別
缺乏業(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)的完整流程工作流不在本示例的范圍內。
圖 3 銀行賬戶(hù)系統用例圖
根據上述用例圖顯示，用例描述如表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所示。
圖 5 航空預訂系統排序和篩選條件
輸入搜索條件后，系統將為行程的第一段提供匹配的航班列表，如圖6所示。
圖 6 航空預訂系統匹配航班列表
客戶(hù)查看匹配航班的列表，選擇航班的第一航段，核對所選信息，勾選接受或拒絕航班協(xié)議并進(jìn)行下一步，如圖7所示。
圖 7 航空預訂系統核對信息
如果在搜索條件中選擇的預訂類(lèi)型為“往返”或“多程”，則系統將為行程的其他航段提供匹配的航班列表。圖8顯示了預訂往返航班時(shí)第二航段的可用航班選擇。
圖 8 航空預訂系統航班選擇列表
客戶(hù)為行程的所有航段選擇航班結束后，系統將顯示整個(gè)行程的行程單，如圖9所示。
圖 9 航空預定系統行程單
客戶(hù)可以查看可用座位，如圖10所示。
圖 10 航空預訂系統可選座位展示
客戶(hù)可以從可選座位中選擇座位，如圖11所示。
圖 11 航空預訂系統座位選擇
客戶(hù)可以查看行程的附加服務(wù)，如圖12所示。
圖 12 航空預訂系統添加附加服務(wù)
客戶(hù)可以選擇并應用附加服務(wù)，如圖13所示。
圖 13 航空預訂系統應用附加服務(wù)
客戶(hù)輸入乘客信息，完成“乘客信息”部分，如圖14所示。
圖 14 航空預訂系統乘客信息
客戶(hù)輸入付款信息，完成“付款信息”部分，如圖15所示。
圖 15 航空預訂系統付款信息
然后，客戶(hù)可以查看條款并點(diǎn)擊“完成購買(mǎi)”按鈕進(jìn)行購買(mǎi)，如圖16所示。
圖 16 航空預定系統完成購買(mǎi)
“客戶(hù)預訂航班”業(yè)務(wù)過(guò)程可根據上述截圖進(jìn)行分析，分解為下列活動(dòng)，如表7所示。
表 7 航空預訂系統過(guò)程活動(dòng)
|
活動(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
以上就是軟件造價(jià)評估公司中基數聯(lián)為您帶來(lái)的“基本過(guò)程的FPA規則解釋”所有內容，更多軟件開(kāi)發(fā)成本估算知識敬請關(guān)注中基數聯(lián)！
