1 概述

      IFPUG 功能點分析（FPA）方法是一種成熟的軟件規(guī)模度量方法，它適用于各類軟件度量，如 web、C/S、數(shù)據(jù)倉庫和實時軟件等。本文講述了將 CPM（計數(shù)實踐手冊）v4.3.1 的 FPA 規(guī)則應(yīng)用于基于業(yè)務(wù)流程管理(BPM)系統(tǒng)項目的方法。

     本文首先介紹了業(yè)務(wù)流程管理（BPM）、業(yè)務(wù)流程管理套件（BPMS）和工作流管理系統(tǒng)（WFMS）的概念。第 3 章從已出版的材料中匯編整理，介紹上述主題的相關(guān)內(nèi)容。第 4 章解釋了如何應(yīng)用 FPA 來度量基于 BPM 的系統(tǒng)項目。第5 章列舉了使用 FPA 度量 BPM 系統(tǒng)的相關(guān)示例。

     為解決基于 BPM 的系統(tǒng)項目的非功能需求（技術(shù)和質(zhì)量），可將本文與論文“功能點分析和軟件非功能評估過程（SNAP）的集成過程”結(jié)合使用。

 

2 目標(biāo)讀者

       本文的目標(biāo)讀者包括需要應(yīng)用 FPA 來度量基于 BPM 系統(tǒng)項目的所有級別的專業(yè)人員和需要在項目評估、規(guī)劃和控制中解釋和使用度量結(jié)果的人。

 

3 業(yè)務(wù)流程管理概念

       系統(tǒng)間的集成需要滿足業(yè)務(wù)流程在復(fù)雜系統(tǒng)間的映射，這是業(yè)務(wù)流程建模實現(xiàn)的重要基礎(chǔ)之一。Weske[1]曾在書中寫到：“業(yè)務(wù)流程由一系列在組織和技術(shù)環(huán)境中協(xié)調(diào)執(zhí)行的活動組成。這些活動共同實現(xiàn)一個業(yè)務(wù)目標(biāo)。一個組織執(zhí)行的業(yè)務(wù)流程可以與其他組織執(zhí)行的業(yè)務(wù)流程交互。[...]業(yè)務(wù)流程管理包括對業(yè)務(wù)流程進(jìn)行設(shè)計、管理、配置、制定和分析的概念、方法和技術(shù)。[...]業(yè)務(wù)流程管理系統(tǒng)是一種由顯式過程設(shè)計驅(qū)動的通用軟件系統(tǒng)，用來協(xié)調(diào)業(yè)務(wù)流程的制定。[...]業(yè)務(wù)流程實例代表公司運營業(yè)務(wù)中的具體案例，由活動實例組成。
       ”Weske 提出了一種業(yè)務(wù)流程生命周期的標(biāo)準(zhǔn)方法。如圖 1 所示，項目團(tuán)隊通過以下四個階段開發(fā)業(yè)務(wù)流程：

圖1 業(yè)務(wù)流程開發(fā)生命周期

 

 

      1．設(shè)計與分析。在此階段，項目團(tuán)隊調(diào)研公司的組織和技術(shù)環(huán)境。基于調(diào)研結(jié)果，項目團(tuán)隊確定、審查并驗證業(yè)務(wù)流程。然后使用特定的建模語言生成流程映射模型，以表示業(yè)務(wù)流程、規(guī)則以及與其他流程的關(guān)系[1]。

      2．配置。在此階段，項目團(tuán)隊將業(yè)務(wù)流程建模自動化。當(dāng)使用流程管理系統(tǒng)(BPMS 或 WFMS)來實現(xiàn)業(yè)務(wù)流程時，項目團(tuán)隊會根據(jù)企業(yè)的組織環(huán)境和應(yīng)實施的業(yè)務(wù)流程來配置流程管理系統(tǒng)。還可以配置組件與現(xiàn)有軟

件集成，將應(yīng)用程序數(shù)據(jù)遷移到新的平臺，并自動化員工與系統(tǒng)之間的交互 。

      3．執(zhí)行。在此階段執(zhí)行業(yè)務(wù)流程。流程管理系統(tǒng)中的監(jiān)控組件顯示正在執(zhí)行的業(yè)務(wù)流程實例的所有狀態(tài)信息。流程監(jiān)控是一種重要的機(jī)制，可提供有關(guān)業(yè)務(wù)流程實例狀態(tài)的準(zhǔn)確信息。

      4．評估。在此階段可以使用數(shù)據(jù)簡化業(yè)務(wù)流程及其實現(xiàn)，并提出流程改進(jìn)方法。

項目團(tuán)隊通常使用 BPMS 來促進(jìn)業(yè)務(wù)流程的管理和執(zhí)行。

 

3.1 業(yè)務(wù)流程模型和符號（BPMN）

      項目團(tuán)隊可以使用不同的建模語言 (例如：Petri 網(wǎng)、EPCs、工作流網(wǎng)、YAWL、BPMN、BPEL 等)來描述業(yè)務(wù)流程。不同語言可以提供不同的建模視圖（功能視圖、動態(tài)視圖、組織視圖和信息視圖）來幫助人們理解業(yè)務(wù)流程，或者也可以使用不同的符號來表示業(yè)務(wù)流程。

      BPMI（業(yè)務(wù)流程管理聯(lián)盟）開發(fā)了一套稱為 BPMN 的標(biāo)準(zhǔn)，BPMN 1.0規(guī)范于 2004 年 5 月發(fā)布。在 BPMI 被納入 OMG（對象管理組織）之后，OMG在 2011 年發(fā)布了 BPMN 2.0 標(biāo)準(zhǔn)。目前，由 OMG 在其 2.0 版本中維護(hù) BPMN。人們通常使用BPMN進(jìn)行業(yè)務(wù)流程建模，BPMN的可視化屬性有助于管理人員、分析師和開發(fā)人員理解模型。

      BPMN 模型由一系列圖形化元素構(gòu)成的圖表組成，這些圖形化元素使用戶和開發(fā)人員能夠更加了解業(yè)務(wù)流程。項目團(tuán)隊使用 BPMN 規(guī)范中詳細(xì)描述的幾個圖形化元素來表示業(yè)務(wù)流程。表 1 按類別列出了主要元素。圖 2 顯示了主要元素的圖形化表示。

 

表1 BPMN模型中的元素類別

圖2 BPM中主要元素的圖形化表示

3.2 工作流參考模型

     工作流管理聯(lián)盟（WFMC）是一個由工作流管理系統(tǒng)的供應(yīng)商和用戶組成的團(tuán)體組織，它開發(fā)了工作流參考模型，該模型將這些元素及其交互作用標(biāo)準(zhǔn)化，以統(tǒng)一對工作流管理系統(tǒng)組件和接口的理解。所有工作流系統(tǒng)都包含一系列的公共組件，組件間采用一套被定義好的方法進(jìn)行交互。圖3 為 WFMC 標(biāo)準(zhǔn)模型。

 

圖3 標(biāo)準(zhǔn)工作流結(jié)構(gòu)
 

下列內(nèi)容解釋了工作流結(jié)構(gòu)中的每個組件和接口：

 

4 在基于 BPM 的系統(tǒng)項目中使用 FPA

       本文提出的 FPA 方法適用于使用 BPMN 建模語言的項目，也適用于使用其他建模語言的項目。本節(jié)描述了基于 BPM 系統(tǒng)的開發(fā)和增強(qiáng)計數(shù)項目的 FPA 計數(shù)過程。對于增強(qiáng)計數(shù)，F(xiàn)P 分析師應(yīng)從新增業(yè)務(wù)流程、修改業(yè)務(wù)流程和刪除業(yè)務(wù)流程中識別增強(qiáng)項目范圍內(nèi)的功能。

4.1 收集可用文檔

      在基于 BPM 的系統(tǒng)項目中，項目團(tuán)隊主要使用業(yè)務(wù)流程建模語言來描述應(yīng)用程序的特性。從描述業(yè)務(wù)流程及其活動圖表中識別功能用戶需求。必要時，可以使用其他需求分析工具，如業(yè)務(wù)流程規(guī)范、邏輯數(shù)據(jù)模型、樣本報告、偽代碼和復(fù)雜項目用例等。

      在設(shè)計和分析 BPM 生命周期階段，初始業(yè)務(wù)流程模型可能是唯一可用于功能點分析的文檔。在這種情況下，可以對未知功能及其細(xì)節(jié)進(jìn)行假設(shè)，以確定功能規(guī)模。
 

表2 BPM生命周期階段和度量

4.2 確定計數(shù)的目的、邊界、范圍和類型

      確定基于 BPM 的系統(tǒng)項目的計數(shù)目的時，需要了解功能點計數(shù)的原因以及計數(shù)結(jié)果的用途。通過計數(shù)目的，可以確定計數(shù)范圍。例如，計數(shù)目的是通過度量基于 BPM 的系統(tǒng)項目的功能規(guī)模來評估開發(fā)與 BPMS 交互的應(yīng)用程序的工作量。

      確定基于 BPM 的系統(tǒng)項目的應(yīng)用程序邊界時，需要考慮計數(shù)目的。在上文的示例中，不能將 BPMS 標(biāo)識為不同的應(yīng)用程序，因為它對于被度量應(yīng)用的用戶來說是透明的。像數(shù)據(jù)庫管理系統(tǒng)（DBMS）是確保軟件正確運行的必需品（通過存儲、組織和管理大量數(shù)據(jù)）一樣，BPMS 也是協(xié)調(diào)應(yīng)用程序業(yè)務(wù)制定的必要存在。因此，BPMS 在邏輯上是應(yīng)用程序的內(nèi)部系統(tǒng)。

      如果計數(shù)目的是通過度量 BPMS 的功能規(guī)模，以確定每個功能點的支持成本，則將 BPMS 標(biāo)識為不同的應(yīng)用程序。

      確定基于 BPM 的系統(tǒng)項目的計數(shù)范圍時，可從可用文檔中確定。例如，若計數(shù)目的是估算開發(fā)基于 BPM 的系統(tǒng)的工作量，則將其功能納入計數(shù)范圍。

     最后，根據(jù)計數(shù)目的確定計數(shù)類型。如果目的是度量基于 BPM 的系統(tǒng)項目的初始版本的功能規(guī)模，則計數(shù)類型為開發(fā)項目功能點計數(shù)。如果計數(shù)目的為：（I）度量將與 BPMS 集成的現(xiàn)有軟件的功能規(guī)模；（II）度量從基于 BPM 的系統(tǒng)中添加、更改或刪除的業(yè)務(wù)流程，則該類型為增強(qiáng)項目功能點計數(shù)。如果計數(shù)目的是度量基于 BPM 的系統(tǒng)用戶的全部功能，那么類型是應(yīng)用程序功能點計數(shù)。

 

4.3 識別數(shù)據(jù)功能

     通常，在基于 BPM 的系統(tǒng)和 BPMS 環(huán)境中，沒有特定方法識別邏輯文件。要了解 BPMS 的邏輯數(shù)據(jù)結(jié)構(gòu)，應(yīng)檢查邏輯數(shù)據(jù)模型或查看 BPMS 的基本過程如何維護(hù)實體。以下示例展示了基于兩個開源 BPMS應(yīng)用程序的數(shù)據(jù)模型調(diào)研的數(shù)據(jù)功能的識別：

圖4 BPMS標(biāo)準(zhǔn)數(shù)據(jù)的邏輯組示例
 

4.4 識別事務(wù)功能

       為識別基于 BPM 的系統(tǒng)的事務(wù)功能，應(yīng)檢查業(yè)務(wù)流程模型中的建模活動。從業(yè)務(wù)流程模型中確定哪些活動代表功能用戶需求，并將該活動組成或拆分為滿足基本過程標(biāo)準(zhǔn)的最小活動單元。

       然后，判定所識別的基本過程是否是唯一事務(wù)功能。例如：一個業(yè)務(wù)流程中有不同角色的幾個審批活動，并且 DET、FTR 和處理邏輯相同，那么識別為一個事務(wù)功能。

       通過基于 BPM 的系統(tǒng)中的數(shù)據(jù)功能來確定事務(wù)功能的 FTR 數(shù)量（如 5.1.2中描述的公司差旅的差旅請求），以及 BPMS 可能涉及的數(shù)據(jù)功能（如 5.1.2 中描述的公司差旅的業(yè)務(wù)流程）。通過分析基于 BPM 的系統(tǒng)中接收或發(fā)送的跨越應(yīng)用程序邊界的信息來確定事務(wù)功能的 DET 數(shù)量。

 

5 示例

      本節(jié)通過幾個示例來說明基于 BPM 的系統(tǒng)項目的度量過程。（注：示例中有部分內(nèi)容與實際計數(shù)有差異，此部分翻譯內(nèi)容僅供參考）

5.1 開發(fā)基于 BPM 的商務(wù)差旅系統(tǒng)（示例 1）

      以下示例演示了基于 BPM 的系統(tǒng)項目的度量方法的完整應(yīng)用。

      圖 5 的業(yè)務(wù)流程模型顯示了員工出差時的業(yè)務(wù)流程。該員工與一個名為“Corporate Travel”的基于 BPM 的差旅系統(tǒng)進(jìn)行交互，該系統(tǒng)控制員工的差旅請求（此過程以前是手動執(zhí)行的）。

      三個不同的用戶與差旅系統(tǒng)交互：員工、一級經(jīng)理和二級經(jīng)理。員工和經(jīng)理是公司內(nèi)部用戶，員工提出差旅請求，其他人審批該請求。

      旅行社是公司外部的服務(wù)提供商，不與差旅系統(tǒng)交互。旅行社為該公司編制預(yù)算并預(yù)定所需的票券和住宿。

      公司領(lǐng)導(dǎo)要求進(jìn)行功能點計數(shù)，通過該差旅系統(tǒng)的功能規(guī)模來確定開發(fā)此系統(tǒng) v1.0 的工作量。

      圖 5 所示活動代表功能需求。

   圖5 BPMN中企業(yè)差旅業(yè)務(wù)流程
 

表 3 為業(yè)務(wù)流程活動的簡要描述。

表3 活動描述
 

5.1.1 確定計數(shù)的目的、邊界、范圍和類型

根據(jù)上述業(yè)務(wù)流程和對應(yīng)描述，可以確定：

5.1.2 識別數(shù)據(jù)功能

      FP 分析師分析了 Corporate Travel 的邏輯數(shù)據(jù)模型后，將數(shù)據(jù)功能“差旅請求”確定為 ILF。此外，還識別了其他數(shù)據(jù)功能來表示用于差旅系統(tǒng)的 BPMS 數(shù)據(jù)的邏輯組（4.3 節(jié)），具體如下所述。

     流程通過數(shù)據(jù)功能 User 驗證用戶配置文件是否具有訪問和修改數(shù)據(jù)的權(quán)限。在驗證過程中，流程讀取數(shù)據(jù)功能 User，其中只顯示與指定用戶（經(jīng)理或員工）相關(guān)的實例。

    數(shù)據(jù)功能 Business 包含已創(chuàng)建、修改和最終確定的流程實例。該流程在用戶每次與 BPMS 的交互中都使用數(shù)據(jù)功能 Business。

    每當(dāng)數(shù)據(jù)功能 Business 中的實例發(fā)生變化時，該流程都會檢查數(shù)據(jù)功能Business Process，以確定下一個分配的隊列，以及該變化涉及的其他業(yè)務(wù)規(guī)則。該流程在用戶每次與 BPMS 的交互中使用數(shù)據(jù)功能 Business process。

    總之，F(xiàn)P 分析師在基于 BPM 的企業(yè)差旅系統(tǒng)中確定了四個數(shù)據(jù)功能：（I）差旅請求（II）Business（III）Business Process 和（IV）User。FP 分析師將這些數(shù)據(jù)功能歸類為 ILF，因為它們是在基于 BPM的企業(yè)差旅系統(tǒng)的邊界內(nèi)維護(hù)的。

 

5.1.3 識別事務(wù)功能

    首先，F(xiàn)P 分析師對業(yè)務(wù)流程活動進(jìn)行分析、識別和分類事務(wù)功能。然后確定并統(tǒng)計每個事務(wù)功能的 DET 和 FTR。FP 分析師通過評估圖 5 所示的基于 BPM的企業(yè)差旅系統(tǒng)流程和用戶需求，列出了如表 4 所示的事務(wù)功能。

 

表4 事務(wù)功能的識別和分類

 

#1 添加差旅請求

     外部輸入“添加差旅請求”維護(hù)數(shù)據(jù)功能“差旅請求”，并從數(shù)據(jù)功能“Business”中檢索數(shù)據(jù)，查詢請求狀態(tài)，從“Business Process”中檢索數(shù)據(jù)以確定如何執(zhí)行活動。該事務(wù)功能有 20 個 DETs7（近似），因此 FP 分析師將其定義為高復(fù)雜性（6 個 FP）。

#2 同意差旅請求、拒絕差旅請求、更正差旅請求

    FP 分析師將審批差旅請求拆分為同意差旅請求、拒絕差旅請求和修正差旅請求，因為這些是對用戶有意義的最小活動單元，構(gòu)成了一個完整的事務(wù)。接下來，F(xiàn)P 分析師將三個基本過程相互比較，并確定是否存在差異。

    由于同意差旅請求、拒絕差旅請求和修正差旅請求的功能用戶需求除了狀態(tài)更改外，還包括與工作流中不同角色的唯一通信（見圖 5）。因此，由于 DET 和處理邏輯的差異，F(xiàn)P 分析師將每個流程指定為唯一的基本過程。

    若“審批差旅請求”的功能用戶需求僅基于不同操作更新狀態(tài)，則基本過程的評估結(jié)果也會有所不同。即使功能拆分為了三個基本過程，唯一性測試也會表明其擁有相同的 FTR、DET 和處理邏輯，本質(zhì)上是用不同的值更新同一 ILF 中的同一字段。

#6 同意差旅

    外部輸入“審批差旅請求”維護(hù)數(shù)據(jù)功能“Business”，存儲審批結(jié)果，從“Business Process”中檢索數(shù)據(jù)以確定如何執(zhí)行活動，從“差旅請求 ILF”中獲取差旅請求詳細(xì)信息，從“user”中確定經(jīng)理的操作?？紤]到該事務(wù)功能的 3 個DET（差旅請求代碼、動作和消息），F(xiàn)P 分析師將其復(fù)雜度定義為“平均”（4 個FP）。

#11 上級拒絕票價和住宿信息

    FP 分析師先將“一級經(jīng)理拒絕票價和住宿信息”和“二級經(jīng)理拒絕票價和住宿信息”設(shè)定為兩個基本過程，然后將兩個基本過程相互比較，確定是否存在差異（見圖 5）。盡管功能拆分為兩個基本過程，但唯一性測試表明其擁有相同的FTR、DET 和處理邏輯，本質(zhì)上是兩個不同的角色在執(zhí)行相同的功能。

    如果各級經(jīng)理的功能用戶需求不同，那么對基本過程的評估結(jié)果就會不同。對于#12 和#13，F(xiàn)P 分析師將該過程識別為兩個基本過程，因為每級經(jīng)理都有與工作流中不同角色的唯一通信（見圖 5）。

 

5.2 識別基于 BPM 系統(tǒng)的事務(wù)功能（示例 2）

     以下示例演示了應(yīng)用該方法來識別基于 BPM 系統(tǒng)的事務(wù)功能。

    通常，在業(yè)務(wù)流程建模語言中，建模人員可以根據(jù)生命周期或個人偏好，或多或少地表達(dá)一個活動的細(xì)節(jié)。因此，對于一項活動，F(xiàn)P 分析師可以識別為一個、多個或沒有基本過程（即內(nèi)部處理、手動步驟）。

    例如，在人力資源（HR）系統(tǒng)中，用戶希望添加一名員工及其家屬8。圖 6和圖 7 分別展示了兩種級別的 BPMN 模型示例。

圖6 低級業(yè)務(wù)流程建模

 

圖7 “事務(wù)功能級”業(yè)務(wù)流程建模
 

 表5為業(yè)務(wù)流程事務(wù)功能的識別。

表5 各級業(yè)務(wù)流程事務(wù)功能的識別和分類
 

圖8展示了高級建模的相同活動。

圖8 高級業(yè)務(wù)流程建模

     FP 分析師確定高級的建模業(yè)務(wù)流程，并將活動拆分為“事務(wù)功能級別”。表6 顯示了在高級建模的業(yè)務(wù)流程中對活動進(jìn)行拆分的結(jié)果。

 

 

表6 各級業(yè)務(wù)流程事務(wù)功能的識別和分類

 

 

6 總結(jié)和建議

     本文目的是為使用 FPA 方法度量基于 BPMS 的系統(tǒng)提供指導(dǎo)。由于該方法不依賴于所使用的技術(shù)或體系結(jié)構(gòu)，因此其在基于 BPMS 的系統(tǒng)和 BPMS 工具的度量使用中是可行的。

    通過從基于 BPMS 的軟件項目中收集的功能規(guī)模和歷史數(shù)據(jù)來看，還可以得出團(tuán)隊的生產(chǎn)力或開發(fā)成本等數(shù)據(jù)。在計算成本時，應(yīng)考慮與 BPM 使用相關(guān)的各種成本，包括：

    業(yè)務(wù)流程重新設(shè)計成本：該成本涉及以下內(nèi)容：與流程參與者進(jìn)行面談；評估現(xiàn)有流程文件，并將收集的流程信息轉(zhuǎn)化為新的流程設(shè)計。

    流程建模成本：該成本受流程復(fù)雜度影響。流程規(guī)模表示業(yè)務(wù)流程活動的詳細(xì)程度以及建模語言的選擇。

    業(yè)務(wù)流程管理技術(shù)成本：該成本表示購買或維護(hù)支持基于 BPM 的軟件開發(fā)許可的成本。

    流程實施成本：該成本為實施業(yè)務(wù)流程的成本。與軟件開發(fā)人員和流程工程師的訪談、流程知識、流程復(fù)雜度、特定技術(shù)、流程管理平臺的技術(shù)成熟度、使用流程管理平臺經(jīng)驗、流程管理系統(tǒng)的可用性和產(chǎn)品文檔質(zhì)量等因素都會影響該成本。

 

參考文獻(xiàn)

[1] WESKE, M. Business Process Management: Concepts, Languages, Architectures. Springer, 1st edition. 2007.

[2] Figure: Life cycle for business process development. WESKE, M. Business Process Management: Concepts, Languages, Architectures. Springer, 1st edition. 2007.

[3] OMG ， 2011. OBJECT MANAGEMENT GROUP. FORMAL/2011-01-03:Business Process Model and Notation. 2011. 508 p. Available at: <goo.gl/hMR8u3>. Accessed: 03/28/2016. 

[4] Figure: Standard BPM Architecture. WESKE, M. Business Process Management: Concepts, Languages, Architectures. Springer, 1st edition. 2007. 

[5] iProcess Blog. Process for Corporative Travels. Available at: < goo.gl/krCrb2 >. 2013. Accessed in 02/18/2016.

[6] MILI H.; JAOUDE G. B.; LEFEBVRE É; TREMBLAY G.; PETRENKO A. , “Business process modeling languages,” ACM Comput. Surv., vol. 43, no. 1, pp. 1–56, Nov. 2010. 

[7] ROSPOCHER, M.; CHIARA GHIDINI; SERAFINI, L. An ontology for the Business Process Modelling Notation. Formal Ontology in Information Systems.p.133 – 146, 2014. Available at: < goo.gl/gAHQzK>.

[8] Workflow Management Coalition, The Workflow Reference Model, document no TC00-1003, January 1995, Available at:<goo.gl/LVutK1>. 

[9] MUTSCHLER B.; REICHERT M. Understanding the Costs of Business Process Management Technology, Business Process Management. v.444, p.157 – 194, 2013, Available at:<https://goo.gl/XgdGNo>.

[10] Figure: Main elements in BPMN. Australian Government. Available at:<https://goo.gl/kNmNb1> . Accessed in 06/21/2016. 

[11] HARMON, P. The State of the BPM Market – 2016. Available at:<https://goo.gl/DCng3I> . Accessed in 06/21/2016.

[12] Workflow Management Coalition, Embedded and Autonomous Workflow Management Systems, March 2000, Available at: <https://goo.gl/MZu5mH>. Accessed in 06/27/2016.

[13] IFPUG – International Function Point Users Group (2010) Function Point Counting Practices Manual, release 4.3.1. Westerville, Ohio, 2010. 

[14] BONITASOFT. Bonita BPM. Available at: < https://goo.gl/jzL2kY>. Accessed in 01/02/2017.

[15] PROCESSMAKER INC. ProcessMaker Workflow & BPM Software Suite. Available at: <https://goo.gl/3iruhr >. Accessed in 01/02/2017.