FPA方法功能點計數常見問題

前言

　　本文的目標讀者是從事軟件行業采用FPA功能點方法對軟件研發工作量評估的人員。列舉了一些FPA 方法實踐過程中的常見問題，有FPA 方法評估標準定義，也有實踐過程中得出的方法建議，僅供參考。

一、 幫助文檔

　　應用系統中的幫助功能通常有三種形式。

　　1、應用程序的幫助 - 此種情形下的“幫助”適用于整個應用程序，通常的形式是 GUI 系統上的“幫助”菜單。

　　2、屏幕形式的幫助 -此種情形下的“幫助”適用于基于GUI或Web 的系統中的特定屏幕。

　　3、字段形式的幫助 -此種情形下的“幫助”適用于應用程序中的特定字段。

　　4、根據FPA 方法，“幫助信息”計數為一個內部邏輯文件， 每個“幫助”計數為一個事務功能（前提是“幫助信息”是本系統維護的）。 復雜度通常為“低”。

　　5、“幫助”、“關于”經常是編碼數據或靜態頁面，通常不進行計數。

如圖所示：

二、 導航菜單

　　在web 框架系統中常見有導航菜單欄，可根據頁面布局需要或功能布局需要，此類菜單通常是可以在后端進行配置和調整的，前端通過實時查詢展現。但此類功能是一種編碼數據，通常只有菜單編號、菜單名稱、菜單鏈接、菜單序號等字段，并無實際業務含 義。在功能點計數時，不進行計數。

如圖所示：

三、 圖表

　　圖表展示和生成方式有多種：

　　1、實時查詢報表，此類報表從數據的生成到查詢展現給用戶為一個基本過程，通常計數為EQ 或 EO，無數學運算或衍生數據生成識別為EQ，否則識別為 EO。

　　2、通過批處理事先生成報表數據落地到數據庫中，在提供查詢界面展示報表數據。從基本過程來講這是兩個基本過程。批處理生成報表數據的基本過程識別為 EI，查詢展現報表數據的過程識別為EQ 或EO。此時落地存儲的報表數據庫表是否要計為內部邏輯文件？從FPA 方法論中我們知道所有的事物功能（EI/EO/EQ）都必須引用或維護內部邏輯文件或者外部接口文件。如果不計數內部邏輯文件，那么報表生成和查詢的事物功能是否不能計數？在報表實現的過程中我們發現主要的工作量是在報表生成和報表查詢的開發。標準功能當中一個邏輯文件通常對應 4~6 個基本過程，如增刪改查以及提供接口等。此時的報表數據只是一種加工后的事物數據，并非新增的邏輯文件。因此根據我們的經驗通過批處理生成報表只計數批處理生成報數據過程EI 和查詢報表數據過程EQ/EO 即可。

　　3、同一個報表既有表格、又有餅狀圖、條形圖來展現。同常表格展示的是明細數據，條形圖展現的是匯總排序，餅狀圖展現的是分類百分比。因此每個圖表所展示的字段屬性和業務需求是不一樣的。在功能點計數時，應把每個圖表單獨計數為 EQ/EO。

四、 打印、導出

　　打印和導出功能分兩種情況：

　　1、在查詢列表的基礎上進行打印、導出。此時查詢列表已單獨計數為一個EQ 或EO。打印、導出在此基礎上執行。查詢數據的處理過程可以復用。因此打印和導出可分別計數為一個獨立的事物功能EQ 或EO，但重用程度可識別為高。

　　2、直接輸入查詢數據范圍或數據類別進行導出，此時沒有查詢列表，因此導出和打印功能可分別計數為一個獨立的事物功能EQ 或EO，單重用程度可識別為低。

五、 短信碼發送

　　在一些安全性要求高的系統或系統登錄注冊過程中經常會遇到要求輸入手機號碼獲取驗證碼進行身份認證的過程。發送短信驗證碼的功能是否為一個獨立基本過程可計數功能點？答案是不可以。我們發現發送短信驗證碼并不是主要的業務目的，往往是在我們進場注冊登錄、支付、賬戶查詢的過程中需要對我們的身份做驗證或登記操作，才要求我們獲取短信碼進行驗證，缺少驗證碼驗證則無法完成我們的主要業務目的。因此短信驗證碼不是主要業務目的， 只是其他功能中的一個處理邏輯。在功能點計數時，不對該功能進行計數。

六、 審批流程

　　目前大多數系統的流程審批功能都是通過流程引擎配置實現的。

　　1、如果流程是開發人員通過配置+開發而新建、修改的。這個情況下，用戶是不能對其進行維護的。所以，這流程本身就不是ILF；用戶感知的是提交、審批、審核等事務功能，可計數，并且根據審批節點進行計數，重用程度一般為高，根據去重原則去重即可。審批節點中的同意、拒絕視為一個審批功能，為審批結果的兩種不同狀態或分支。

　　2、如果流程引擎是開放給業務用戶操作的，那么就對流程引擎自身的功能進行計數。用戶新增、修改的具體流程本身就不能計數為ILF，同理提交、審批也不計數。就像是用戶在 CRM 系統里新增、修改了一條具體的客戶信息一樣。

七、 遷移

　　遷移本身為非功能性需求，因其工作量可量化，因此除了環境準備外，本身的開發工作量可定制規則進行計數。

　　1、功能遷移，通常處理邏輯、數據字段、數據訪問方式會有變化，可識別為對原有功能的修改。

　　2、數據遷移，識別需要遷移邏輯文件的數量，每個邏輯文件的遷移對應一個EI，統計 EI 數量作為數據遷移工作功能點計數結果。從實際操作過程中有時較難以識別是否為邏輯文件，可以變相識別一個物理表為一個 EI，重用程度為中或高。

　　遷移項目評估方法僅為建議，而非IFPUG 發布的FPA 標準功能點方法中的標準。

八、 微服務架構系統

　　微服務架構是一種將單應用程序作為一套小型服務開發的方 法，每種應用程序都在其自己的進程中運行，并與輕量級機制（通常是HTTP 資源的 API）進行通信。這些服務是圍繞業務功能構建的，可以通過全自動部署機制進行獨立部署。這些服務的集中化管理已經是最少的，它們可以用不同的編程語言編寫，并使用不同的數據存儲技術。

　　在對微服務架構系統進行功能點計數時，我們首先要考慮的就是系統邊界。度量的目的是為管理服務，因此在劃分系統邊界時， 因遵從組織的管理需求和組織對系統的定義。如果組織已定義好每個IT 系統，則以組織定義的系統為邊界，采用標準功能點方法進行計數。在一個系統邊界內，有多個微服務單元，每個微服務單元均有獨立的數據庫以及微服務單元之間是采用接口的方式進行數據的訪問或傳遞，其主要工作量也集中于微服務單元之間的接口開發和邏輯處理。因此在對一個微服務系統進行功能點計數時，可將每個微服務單元劃分為小的邊界識別相應的事物功能，數據功能不在識別。因為在一個系統邊界內相同的邏輯文件有且僅有一個。

　　微服務架構系統評估方法僅為建議，而非IFPUG 發布的FPA 標準功能點方法中的標準。（北京軟件造價評估技術創新聯盟）