1 概述
IFPUG 功能点分析（FPA）方法是一种成熟的软件规模度量方法，它适用于各类软件度量，如 web、C/S、数据仓库和实时软件等。本文讲述了将 CPM（计数实践手册）v4.3.1 的 FPA 规则应用于基于业务流程管理(BPM)系统项目的方法。
本文首先介绍了业务流程管理（BPM）、业务流程管理套件（BPMS）和工作流管理系统（WFMS）的概念。第 3 章从已出版的材料中汇编整理，介绍上述主题的相关内容。第 4 章解释了如何应用 FPA 来度量基于 BPM 的系统项目。第5 章列举了使用 FPA 度量 BPM 系统的相关示例。
为解决基于 BPM 的系统项目的非功能需求（技术和质量），可将本文与论文“功能点分析和软件非功能评估过程（SNAP）的集成过程”结合使用。
2 目标读者
本文的目标读者包括需要应用 FPA 来度量基于 BPM 系统项目的所有级别的专业人员和需要在项目评估、规划和控制中解释和使用度量结果的人。
3 业务流程管理概念
系统间的集成需要满足业务流程在复杂系统间的映射，这是业务流程建模实现的重要基础之一。Weske[1]曾在书中写到：“业务流程由一系列在组织和技术环境中协调执行的活动组成。这些活动共同实现一个业务目标。一个组织执行的业务流程可以与其他组织执行的业务流程交互。[...]业务流程管理包括对业务流程进行设计、管理、配置、制定和分析的概念、方法和技术。[...]业务流程管理系统是一种由显式过程设计驱动的通用软件系统，用来协调业务流程的制定。[...]业务流程实例代表公司运营业务中的具体案例，由活动实例组成。
”Weske 提出了一种业务流程生命周期的标准方法。如图 1 所示，项目团队通过以下四个阶段开发业务流程：
图1 业务流程开发生命周期
1．设计与分析。在此阶段，项目团队调研公司的组织和技术环境。基于调研结果，项目团队确定、审查并验证业务流程。然后使用特定的建模语言生成流程映射模型，以表示业务流程、规则以及与其他流程的关系[1]。
2．配置。在此阶段，项目团队将业务流程建模自动化。当使用流程管理系统(BPMS 或 WFMS)来实现业务流程时，项目团队会根据企业的组织环境和应实施的业务流程来配置流程管理系统。还可以配置组件与现有软
件集成，将应用程序数据迁移到新的平台，并自动化员工与系统之间的交互 。
3．执行。在此阶段执行业务流程。流程管理系统中的监控组件显示正在执行的业务流程实例的所有状态信息。流程监控是一种重要的机制，可提供有关业务流程实例状态的准确信息。
4．评估。在此阶段可以使用数据简化业务流程及其实现，并提出流程改进方法。
项目团队通常使用 BPMS 来促进业务流程的管理和执行。
3.1 业务流程模型和符号（BPMN）
项目团队可以使用不同的建模语言 (例如：Petri 网、EPCs、工作流网、YAWL、BPMN、BPEL 等)来描述业务流程。不同语言可以提供不同的建模视图（功能视图、动态视图、组织视图和信息视图）来帮助人们理解业务流程，或者也可以使用不同的符号来表示业务流程。
BPMI（业务流程管理联盟）开发了一套称为 BPMN 的标准，BPMN 1.0规范于 2004 年 5 月发布。在 BPMI 被纳入 OMG（对象管理组织）之后，OMG在 2011 年发布了 BPMN 2.0 标准。目前，由 OMG 在其 2.0 版本中维护 BPMN。人们通常使用BPMN进行业务流程建模，BPMN的可视化属性有助于管理人员、分析师和开发人员理解模型。
BPMN 模型由一系列图形化元素构成的图表组成，这些图形化元素使用户和开发人员能够更加了解业务流程。项目团队使用 BPMN 规范中详细描述的几个图形化元素来表示业务流程。表 1 按类别列出了主要元素。图 2 显示了主要元素的图形化表示。
表1 BPMN模型中的元素类别
图2 BPM中主要元素的图形化表示
3.2 工作流参考模型
工作流管理联盟（WFMC）是一个由工作流管理系统的供应商和用户组成的团体组织，它开发了工作流参考模型，该模型将这些元素及其交互作用标准化，以统一对工作流管理系统组件和接口的理解。所有工作流系统都包含一系列的公共组件，组件间采用一套被定义好的方法进行交互。图3 为 WFMC 标准模型。
图3 标准工作流结构
下列内容解释了工作流结构中的每个组件和接口：
-
工作流引擎：负责工作流执行服务中的执行环境。它可以控制流程（或子流程）、具有定义范围的实例及其属性的执行，这些实例可以在流程定义中解释。
-
工作流执行服务：负责激活并解释流程定义，并与外部应用程序进行交互。它由一个或多个工作流引擎组成，提供了过程实例的执行环境。
-
流程定义工具：负责工作流建模。可以使用不同的工具来分析、建模、描述和记录业务流程。接口 1 的标准为 XML 流程定义语言（XPDL）。
-
工作流客户端应用：负责用户和工作流执行服务之间的交互。接口 2 通过一组 API（WAPI）完成客户端应用程序和工作流引擎之间的交互。
-
调用应用：WFMC 假设任何特定的 WFM 实现都需要复杂逻辑来调用异构产品环境中的潜在应用程序。接口 3 简化了跨异构软件平台的应用程序调用，并提供技术信息来调用执行特定工作流活动的特定应用程序。
-
其他工作流执行服务：WFMC 假设工作流产品本质上是多样的。接口4 实现了不同工作流引擎之间的互操作性。
-
管理监控工具：通过接口 5 负责工作流的监控和管理。通过 WAPI，接口 5 可以查看工作流状态的完整视图。
工作流管理联盟（WFMC）将工作流管理系统分为两类：自治工作流管理系统和嵌入式工作流管理系统。除了数据库管理系统和消息队列中间件之外，自治工作流管理系统在没有任何附加应用软件的情况下运行。自治工作流解决方案调用（在运行时）工作流管理系统外部的应用程序系统，并在工作流参与者之间传递工作流相关数据。嵌入式工作流管理系统只有在被嵌入系统（例如，企业资源规划（ERP）系统）使用时才能发挥作用。常见的例子包括 ERP 系统、支付和结算系统。
4 在基于 BPM 的系统项目中使用 FPA
本文提出的 FPA 方法适用于使用 BPMN 建模语言的项目，也适用于使用其他建模语言的项目。本节描述了基于 BPM 系统的开发和增强计数项目的 FPA 计数过程。对于增强计数，FP 分析师应从新增业务流程、修改业务流程和删除业务流程中识别增强项目范围内的功能。
4.1 收集可用文档
在基于 BPM 的系统项目中，项目团队主要使用业务流程建模语言来描述应用程序的特性。从描述业务流程及其活动图表中识别功能用户需求。必要时，可以使用其他需求分析工具，如业务流程规范、逻辑数据模型、样本报告、伪代码和复杂项目用例等。
在设计和分析 BPM 生命周期阶段，初始业务流程模型可能是唯一可用于功能点分析的文档。在这种情况下，可以对未知功能及其细节进行假设，以确定功能规模。
表2 BPM生命周期阶段和度量
4.2 确定计数的目的、边界、范围和类型
确定基于 BPM 的系统项目的计数目的时，需要了解功能点计数的原因以及计数结果的用途。通过计数目的，可以确定计数范围。例如，计数目的是通过度量基于 BPM 的系统项目的功能规模来评估开发与 BPMS 交互的应用程序的工作量。
确定基于 BPM 的系统项目的应用程序边界时，需要考虑计数目的。在上文的示例中，不能将 BPMS 标识为不同的应用程序，因为它对于被度量应用的用户来说是透明的。像数据库管理系统（DBMS）是确保软件正确运行的必需品（通过存储、组织和管理大量数据）一样，BPMS 也是协调应用程序业务制定的必要存在。因此，BPMS 在逻辑上是应用程序的内部系统。
如果计数目的是通过度量 BPMS 的功能规模，以确定每个功能点的支持成本，则将 BPMS 标识为不同的应用程序。
确定基于 BPM 的系统项目的计数范围时，可从可用文档中确定。例如，若计数目的是估算开发基于 BPM 的系统的工作量，则将其功能纳入计数范围。
最后，根据计数目的确定计数类型。如果目的是度量基于 BPM 的系统项目的初始版本的功能规模，则计数类型为开发项目功能点计数。如果计数目的为：（I）度量将与 BPMS 集成的现有软件的功能规模；（II）度量从基于 BPM 的系统中添加、更改或删除的业务流程，则该类型为增强项目功能点计数。如果计数目的是度量基于 BPM 的系统用户的全部功能，那么类型是应用程序功能点计数。
4.3 识别数据功能
通常，在基于 BPM 的系统和 BPMS 环境中，没有特定方法识别逻辑文件。要了解 BPMS 的逻辑数据结构，应检查逻辑数据模型或查看 BPMS 的基本过程如何维护实体。以下示例展示了基于两个开源 BPMS应用程序的数据模型调研的数据功能的识别：
-
Business Process（ILF）存储来自业务流程的数据，如流程中执行的活动和活动之间的流；
-
Parameter（ILF）存储定义业务流程行为所需配置和参数化的数据；
-
Business（ILF）存储业务（事务系统）数据，以进行与 BPMS 的事务的连接；
-
Indicator（ILF）存储从业务流程中提取的指标中的数据；
-
User（ILF）存储用户数据。
图 4 表示了逻辑文件之间的关系。
图4 BPMS标准数据的逻辑组示例
4.4 识别事务功能
为识别基于 BPM 的系统的事务功能，应检查业务流程模型中的建模活动。从业务流程模型中确定哪些活动代表功能用户需求，并将该活动组成或拆分为满足基本过程标准的最小活动单元。
然后，判定所识别的基本过程是否是唯一事务功能。例如：一个业务流程中有不同角色的几个审批活动，并且 DET、FTR 和处理逻辑相同，那么识别为一个事务功能。
通过基于 BPM 的系统中的数据功能来确定事务功能的 FTR 数量（如 5.1.2中描述的公司差旅的差旅请求），以及 BPMS 可能涉及的数据功能（如 5.1.2 中描述的公司差旅的业务流程）。通过分析基于 BPM 的系统中接收或发送的跨越应用程序边界的信息来确定事务功能的 DET 数量。
5 示例
本节通过几个示例来说明基于 BPM 的系统项目的度量过程。（注：示例中有部分内容与实际计数有差异，此部分翻译内容仅供参考）
5.1 开发基于 BPM 的商务差旅系统（示例 1）
以下示例演示了基于 BPM 的系统项目的度量方法的完整应用。
图 5 的业务流程模型显示了员工出差时的业务流程。该员工与一个名为“Corporate Travel”的基于 BPM 的差旅系统进行交互，该系统控制员工的差旅请求（此过程以前是手动执行的）。
三个不同的用户与差旅系统交互：员工、一级经理和二级经理。员工和经理是公司内部用户，员工提出差旅请求，其他人审批该请求。
旅行社是公司外部的服务提供商，不与差旅系统交互。旅行社为该公司编制预算并预定所需的票券和住宿。
公司领导要求进行功能点计数，通过该差旅系统的功能规模来确定开发此系统 v1.0 的工作量。
图 5 所示活动代表功能需求。
图5 BPMN中企业差旅业务流程
表 3 为业务流程活动的简要描述。
表3 活动描述
5.1.1 确定计数的目的、边界、范围和类型
根据上述业务流程和对应描述，可以确定：
-
计数目的为通过功能点计数，计算该企业差旅系统的功能规模，以此确定开发此系统 v1.0 的工作量。
-
应用程序边界为基于 BPM 的企业差旅系统。
-
计数范围包括为构建基于 BPM 的企业差旅系统所有功能的项目活动。旅行社的活动不在差旅审批的范围内，因此不包含在计数范围内。
-
计数类型是开发项目。
5.1.2 识别数据功能
FP 分析师分析了 Corporate Travel 的逻辑数据模型后，将数据功能“差旅请求”确定为 ILF。此外，还识别了其他数据功能来表示用于差旅系统的 BPMS 数据的逻辑组（4.3 节），具体如下所述。
流程通过数据功能 User 验证用户配置文件是否具有访问和修改数据的权限。在验证过程中，流程读取数据功能 User，其中只显示与指定用户（经理或员工）相关的实例。
数据功能 Business 包含已创建、修改和最终确定的流程实例。该流程在用户每次与 BPMS 的交互中都使用数据功能 Business。
每当数据功能 Business 中的实例发生变化时，该流程都会检查数据功能Business Process，以确定下一个分配的队列，以及该变化涉及的其他业务规则。该流程在用户每次与 BPMS 的交互中使用数据功能 Business process。
总之，FP 分析师在基于 BPM 的企业差旅系统中确定了四个数据功能：（I）差旅请求（II）Business（III）Business Process 和（IV）User。FP 分析师将这些数据功能归类为 ILF，因为它们是在基于 BPM的企业差旅系统的边界内维护的。
5.1.3 识别事务功能
首先，FP 分析师对业务流程活动进行分析、识别和分类事务功能。然后确定并统计每个事务功能的 DET 和 FTR。FP 分析师通过评估图 5 所示的基于 BPM的企业差旅系统流程和用户需求，列出了如表 4 所示的事务功能。
表4 事务功能的识别和分类
#1 添加差旅请求
外部输入“添加差旅请求”维护数据功能“差旅请求”，并从数据功能“Business”中检索数据，查询请求状态，从“Business Process”中检索数据以确定如何执行活动。该事务功能有 20 个 DETs7（近似），因此 FP 分析师将其定义为高复杂性（6 个 FP）。
#2 同意差旅请求、拒绝差旅请求、更正差旅请求
FP 分析师将审批差旅请求拆分为同意差旅请求、拒绝差旅请求和修正差旅请求，因为这些是对用户有意义的最小活动单元，构成了一个完整的事务。接下来，FP 分析师将三个基本过程相互比较，并确定是否存在差异。
由于同意差旅请求、拒绝差旅请求和修正差旅请求的功能用户需求除了状态更改外，还包括与工作流中不同角色的唯一通信（见图 5）。因此，由于 DET 和处理逻辑的差异，FP 分析师将每个流程指定为唯一的基本过程。
若“审批差旅请求”的功能用户需求仅基于不同操作更新状态，则基本过程的评估结果也会有所不同。即使功能拆分为了三个基本过程，唯一性测试也会表明其拥有相同的 FTR、DET 和处理逻辑，本质上是用不同的值更新同一 ILF 中的同一字段。
#6 同意差旅
外部输入“审批差旅请求”维护数据功能“Business”，存储审批结果，从“Business Process”中检索数据以确定如何执行活动，从“差旅请求 ILF”中获取差旅请求详细信息，从“user”中确定经理的操作。考虑到该事务功能的 3 个DET（差旅请求代码、动作和消息），FP 分析师将其复杂度定义为“平均”（4 个FP）。
#7 查询审批结果
外部查询“查询审批结果”从数据功能“Business”中检索数据，检查请求的状态，从差旅请求ILF中检索差旅请求的详细信息，从“Business Process”中检索数据以确定如何执行活动。考虑到该事务功能的10个DET(近似)，FP 分析师将其复杂度定义为“平均”（4 个FP）。
#11 上级拒绝票价和住宿信息
FP 分析师先将“一级经理拒绝票价和住宿信息”和“二级经理拒绝票价和住宿信息”设定为两个基本过程，然后将两个基本过程相互比较，确定是否存在差异（见图 5）。尽管功能拆分为两个基本过程，但唯一性测试表明其拥有相同的FTR、DET 和处理逻辑，本质上是两个不同的角色在执行相同的功能。
如果各级经理的功能用户需求不同，那么对基本过程的评估结果就会不同。对于#12 和#13，FP 分析师将该过程识别为两个基本过程，因为每级经理都有与工作流中不同角色的唯一通信（见图 5）。
5.2 识别基于 BPM 系统的事务功能（示例 2）
以下示例演示了应用该方法来识别基于 BPM 系统的事务功能。
通常，在业务流程建模语言中，建模人员可以根据生命周期或个人偏好，或多或少地表达一个活动的细节。因此，对于一项活动，FP 分析师可以识别为一个、多个或没有基本过程（即内部处理、手动步骤）。
例如，在人力资源（HR）系统中，用户希望添加一名员工及其家属8。图 6和图 7 分别展示了两种级别的 BPMN 模型示例。
图6 低级业务流程建模
图7 “事务功能级”业务流程建模
表5为业务流程事务功能的识别。
表5 各级业务流程事务功能的识别和分类
图8展示了高级建模的相同活动。
图8 高级业务流程建模
FP 分析师确定高级的建模业务流程，并将活动拆分为“事务功能级别”。表6 显示了在高级建模的业务流程中对活动进行拆分的结果。
表6 各级业务流程事务功能的识别和分类
6 总结和建议
本文目的是为使用 FPA 方法度量基于 BPMS 的系统提供指导。由于该方法不依赖于所使用的技术或体系结构，因此其在基于 BPMS 的系统和 BPMS 工具的度量使用中是可行的。
通过从基于 BPMS 的软件项目中收集的功能规模和历史数据来看，还可以得出团队的生产力或开发成本等数据。在计算成本时，应考虑与 BPM 使用相关的各种成本，包括：
业务流程重新设计成本：该成本涉及以下内容：与流程参与者进行面谈；评估现有流程文件，并将收集的流程信息转化为新的流程设计。
流程建模成本：该成本受流程复杂度影响。流程规模表示业务流程活动的详细程度以及建模语言的选择。
业务流程管理技术成本：该成本表示购买或维护支持基于 BPM 的软件开发许可的成本。
流程实施成本：该成本为实施业务流程的成本。与软件开发人员和流程工程师的访谈、流程知识、流程复杂度、特定技术、流程管理平台的技术成熟度、使用流程管理平台经验、流程管理系统的可用性和产品文档质量等因素都会影响该成本。
参考文献
[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.
以上就是软件造价评估公司中基数联为您带来的“FPA 应用于基于 BPM的系统项目”所有内容，更多软件开发成本估算知识敬请关注中基数联！
