（本文由北京中基数联科技有限公司撰写，仅供学习参考使用，版权归中基数联所有，转载请标明出处。）
1 引言
功能点分析的难点是如何确定一个功能或一组相关功能是否构成一个基本过程。计数实践手册（CPM），v.4.3.1定义了基本过程的概念：“将功能用户需求组合或分解为满足以下所有条件的最小活动单元：对用户有意义；构成完整的事务；自包含，并使应用程序的业务处于持续状态”。
虽然这是一个相当简单的规则，但在许多情况下，FP分析师很难在实践中正确应用。甚至在某些情况下，FP分析师应用该规则时也会有所不同。本文为FP分析师解释和应用此基本过程规则提供了进一步指导。
正确应用基本过程规则的一个关键领域是在合同协议中，功能点（FP）对合同进行度量和定价。客户和软件服务提供商可能对基本过程（EP）的确定以及基本过程的组成或分解程度存在分歧。许多软件服务提供商假定屏幕截图和基本过程之间存在简单的一对一关系，但是他们并不了解基于屏幕截图的功能需求。在这些协议中基于功能用户需求（FUR）对项目进行度量和定价，并且可以基于用例和屏幕截图进行推导。
基本过程的分解程度可能太过粗糙，如通过截图计算一个EP，而截图上缺少其他或从属EP的情况。或者，识别基本过程的分解程度过于精细，导致EP计数过多，如完成一项功能需要多个步骤或截图的情况。
这两种情况出现的原因都是因为没有足够的细节从用户的角度来确定合适的EP。软件服务提供商担心项目规模的估算错误会为开发功能提供不准确的成本、进度和工作量估算。
此外，在分析基本过程的唯一性时，DETs、FTRs或处理逻辑的微小变化也可能会引起争议。CPM 4.3.1规定，“当比较两个基本过程时，如果它们包含不同的DETs、FTRs或处理逻辑，则将它们识别为独立的基本过程”。
基本过程是功能点中最重要的概念之一，基本过程规则的错误解释和误用会显著改变功能点计数的结果。在功能点计数期间识别的基本过程的数量是确定项目功能规模的重要因素。
本文将提供基本过程概念和基本过程唯一性的相关示例，使客户和软件服务提供商之间就度量和定价的内容进行更好的沟通，从而促进基于FP的商业活动和度量。本文所提到的示例仅用于说明目的；每位度量分析师必须根据CPM当前版本中定义的计数规则，正确度量基本过程。
免责声明：本文中提供的所有示例仅表示对系统的公开解释，以便为讨论的主题提供说明，并不代表任何公司系统的真实运行情况。
2 目标读者
本文为功能点分析师在应用《计数实践手册》（CPM 4.3系列）来确定基本过程的组成提供了指导，以提高基本过程评估的一致性。
本文的目标读者包括需要在FPA计数期间应用基本过程识别规则的所有专业人员。
3 基本过程、用户和业务过程
《FPA在BPM系统项目中的应用》白皮书为在BPM环境中应用FPA方法奠定了基础，提供了描述BPM概念和业务过程背景的材料，解释了如何应用FPA来度量基于BPM的系统项目，并举例说明。
该文件指出：
-
“业务过程由一组在技术环境中协调执行的活动组成。这些活动共同实现了一个业务目标”。
-
-
“业务过程实例代表公司运营业务中的具体案例，由活动实例组成” 。
-
-
“在业务过程模型中，确定哪些活动代表功能用户需求，并将每个活动组合或分解为满足基本过程条件的最小活动单元”。
CPM将功能用户需求（FUR）定义为“描述软件要做什么，提供什么样的服务的用户需求子集”。因此，功能用户需求（FUR）对应于定义业务过程活动的逻辑顺序，从而实现业务目标。业务过程活动对应于交付给用户的每项有意义的功能，负责业务过程要实现的总体目标的一部分。
CPM将用户定义为“在任何时候与软件通讯或交互的任何人或事物” ，用户角度被定义为“用户感知的功能用户需求” 。此外，用户角度表示“以用户语言对用户业务需求进行的正式描述”、“是对业务功能的描述”。因此，“用户”和“用户角度”的定义一起使用，说明用户代表业务过程的服务对象。用户通常是与被计数的应用程序交互的人，但与应用程序交互的外部系统或设备也被视为用户。
术语“用户可识别”的定义为“事务和数据需求是由用户和软件开发人员都认同并理解的”[6]。换句话说，用户可识别是业务过程或业务过程活动中的所有内容。
基本过程识别规则是将业务过程活动拆分为满足以下条件的最小活动单元：
-
对用户有意义：“用户可识别并满足功能用户需求”的所有内容[8]；
-
-
构成一个完整事务：“用户为完成一个基本过程的所有需求。如验证、数学运算或计算、读取或维护数据功能”；
-
自包含：“功能用户需求不需要任何前置或后续处理步骤就可以独立完成”；
-
使应用程序的业务处于持续状态：“过程已完全执行，功能用户需求已得到满足，无需再做任何事情”。
“对用户有意义”相当于“对业务有意义”，即从用户的角度来看，是一切与业务目标相关的功能需求。当然，并不是说对用户没有明确意义的内容就是对业务无意义：对业务过程进行详细分析可以显示出用户可识别的更多功能需求。
“完整事务”的概念与处理逻辑的概念相关联，即“用户要求的完成一个基本过程的特定需求。如验证、数学运算或计算、读取或维护数据功能”。这意味着，“完整事务”必须包含所有适用的处理逻辑，从用户的角度实现部分或所有业务目标。处理逻辑可以有业务过程的一个或多个处理步骤，并且包括应用程序响应消息。处理步骤确保所有维护ILF的属性都已写入。例如，在一个处理步骤中，应用程序向用户展示信息以供查看，并允许用户确认，这是一个EP的一部分，而不是一个完整的EP。
“自包含”和“使业务处于持续状态”的概念和业务过程活动有关，它基于用户视角交付业务可识别的结果。“自包含”的活动意味着可以在不需要执行任何其他活动的前提下独立执行该活动。如果一个活动有其他可能完成或必须完成的活动作为前置任务，那么该活动则不能“自包含”，因为它依赖于前置任务功能。可以通过一个包含选择条件、检索信息、显示结果的查询功能来说明这种情况：选择条件必须是在检索信息之前的强制性前置活动，检索信息是显示结果的强制性前置活动。因此，选择条件和检索信息都不是“自包含”的，因为只有在显示结果之后才能实现业务目标。所以，“选择条件+检索信息+显示结果”的组合是“自包含的”。
“持续状态”的概念表明，当时事务完成时，所需的业务功能已经完成，不需要后续任何步骤。所有数据处于最终状态，并满足功能用户需求。此时，系统可以禁用或关闭，且数据可用于下一次EP，如果必须重复之前的EP，则说明该EP未达到持续状态。
识别EP的所有关键概念都可以通过业务过程相关联：EP由为业务过程提供所需步骤的活动或一组相关活动组成，其结果是最小的、有意义的、完整的和业务可识别的。
然而，仅识别EP是不够的，还需要在识别EP之后，按照之前同样适用的规则，与已识别的其他EP相比，确保EP不会重复。基本过程的唯一性是基本过程的另一个重要概念，需要在业务过程的背景中对其加以理解。
正如CPM中定义的，唯一性检测表明，“当与已经识别到的基本过程进行比较时，如果两个相似的基本过程满足下列条件，则把它们当作同一个基本过程：
-
要求相同的DETs集；
-
要求相同的FTRs集；
-
要求相同的完成基本过程的处理逻辑。”
此外它还指出：“一个基本过程在多个可选事件中可能包含微小的DETs、FTRs或处理逻辑的变化”、“不要把一个基本过程的多种处理逻辑形式拆分为多个基本过程” 。
那么如何确定何时发生“DETs、FTRs或处理逻辑的微小变化”呢? 处理逻辑以及DET和FTR能够使EP执行业务过程目标。因此，在分析EP唯一性时，最重要的是了解预期的业务目标。当比较两个或多个在DET、FTR或处理逻辑上有微小变化，但从用户的角度来看满足相同业务目标的类似的EP时，所有EP作为一个唯一的EP进行度量。例如，在分析两个类似EP时，检查DET、FTR和处理逻辑的微小变化是否足以识别不同的业务目标，如果可以，则度量为不同的EP，否则认为是一个EP。
当增强项目需要更改EP的处理逻辑、DET或FTR的某一部分时，如果该EP要实现的业务目标保持不变，则不能将受影响的EP分解为多个不同的EP。
以下示例说明了前文描述的所有概念。下图为“预约系统”的业务过程，其业务目标是“乘客预约乘车”。
图 1 预约系统流程图
业务过程活动如表1所示：
表 1 预约系统业务过程活动
注：如果用户或系统中止/取消流程，则流程将中断，且系统没有其他响应。
“乘客”和“司机”是预约系统的用户。因此，预约系统业务价值由预约过程的用户视图表示，这是识别基本过程的规则之一。
表2通过应用上述EP识别规则，对每个业务过程活动进行了分析，以识别基本过程：
表 2 预约系统基本过程识别规则
表3列出了通过上述过程识别出的EP：
表 3 预约系统识别到的基本过程
上述示例演示了如何将业务过程中的单个活动或步骤组成一个唯一的基本过程。当将五个活动（请求预约、接收预约请求、检查是否可用、获取备选时间和提供预订信息）的处理逻辑结合时，就可以实现业务目标并使业务处于持续状态。下图以可视化的方式表示BPM活动是如何构成每个已识别的EP的。
注：每个“口”表示为一个唯一的EP。
图 2 流程图中的基本过程识别
缺乏业务过程模型对于识别基本过程来说是一个挑战。下面几节将探讨如何在特定场景中使用除业务流程图以外的方式识别EP。
4 基本过程和用例
用例是需求开发和功能点分析的强大而有效的工具，它们表示“外部参与者与系统之间的交互，以达到特定的目标”，代表了用户视角。
《计数实践手册V4.3—案例研究1》中对用例图的描述如下：
-
l 参与者是用户在系统中扮演的角色。参与者可以是人、硬件设备或其他系统，由一个具有简短描述性名称的图形表示。例如：
人力资源部专员
-
l 用例是系统为实现特定目标而需要执行的一组操作，由椭圆和简短的描述性名称表示，例如：
FPA分析师在分析用例图以识别基本过程时需要特别注意“包含”和“扩展”两种用例关系。
“包含”关系意味着被包含的用例不是一个独立的用例，它必须在基本用例的逻辑背景中运行。“扩展”关系意味着扩展用例是基本用例的附加步骤，这些步骤可以是可选的，也可以是强制性的。
以下示例描述了参与者(客户)与银行账户系统的三个基本功能(提现、转账和获取银行账户对账单)之间的用例关系（图3）。
注：下图演示了在识别基本过程时对用例图的解释，主要是讨论用例之间的“<<包含>>”和“<<扩展>>”关系。因此，有关登录/注销功能的注意事项所引用的活动的完整流程工作流不在本示例的范围内。
图 3 银行账户系统用例图
根据上述用例图显示，用例描述如表4所示。
注：用例使用自由形式的文本描述，不遵循任何正式的UML规则。
表 4 银行账户系统用例描述
注：如果用户或系统中止/取消流程，则流程将中断，且系统没有其他响应。
表5针对每个用例进行了分析，通过应用第2节“基本过程、用户和业务过程”中所述的EP识别规则来识别基本过程。
表 5 银行账户系统基本过程识别规则
表6列出了通过上述过程识别出的EP：
表 6 银行账户系统识别到的基本过程
用例“提现”、“获取银行账户对账单”和“转账”与用例“显示银行账户余额”为扩展关系，这意味着显示银行账户余额增加了一个强制性步骤，以完成提现（以及获取银行账户对账单和转账）的业务价值。
同样，用例“提现”和“转账”中包含用例“更新银行账户余额”，使更新银行账户余额活动成为完成业务价值(提现和转账)的强制性步骤。
5 从屏幕模型感知基本过程
在多数情况下，功能点分析仅通过分析屏幕截图进行计数。屏幕截图是FP分析的宝贵资源，但如果不考虑要实现的业务目标，只分析截图也可能会导致EP识别错误。
以下示例描述了FP分析师仅通过可用的屏幕截图来度量计数的场景。
注：以下截图仅用于说明目的，不代表任何航空公司真实完整的预订流程。
在航空公司预订系统航班预订流程中，客户可以输入搜索条件，如“出发地”和“目的地”、“预订类型（单程、往返或多程）”、“行程日期”和乘客数量，如图4所示。
图 4 航空预订系统搜索条件
客户也可以通过“排序和筛选”条件来进行航班搜索，如图5所示。
图 5 航空预订系统排序和筛选条件
输入搜索条件后，系统将为行程的第一段提供匹配的航班列表，如图6所示。
图 6 航空预订系统匹配航班列表
客户查看匹配航班的列表，选择航班的第一航段，核对所选信息，勾选接受或拒绝航班协议并进行下一步，如图7所示。
图 7 航空预订系统核对信息
如果在搜索条件中选择的预订类型为“往返”或“多程”，则系统将为行程的其他航段提供匹配的航班列表。图8显示了预订往返航班时第二航段的可用航班选择。
图 8 航空预订系统航班选择列表
客户为行程的所有航段选择航班结束后，系统将显示整个行程的行程单，如图9所示。
图 9 航空预定系统行程单
客户可以查看可用座位，如图10所示。
图 10 航空预订系统可选座位展示
客户可以从可选座位中选择座位，如图11所示。
图 11 航空预订系统座位选择
客户可以查看行程的附加服务，如图12所示。
图 12 航空预订系统添加附加服务
客户可以选择并应用附加服务，如图13所示。
图 13 航空预订系统应用附加服务
客户输入乘客信息，完成“乘客信息”部分，如图14所示。
图 14 航空预订系统乘客信息
客户输入付款信息，完成“付款信息”部分，如图15所示。
图 15 航空预订系统付款信息
然后，客户可以查看条款并点击“完成购买”按钮进行购买，如图16所示。
图 16 航空预定系统完成购买
“客户预订航班”业务过程可根据上述截图进行分析，分解为下列活动，如表7所示。
表 7 航空预订系统过程活动
注：如果用户或系统中止/取消流程，则流程将中断，且系统没有其他响应。
表8针对每个活动进行了分析，通过应用第2节“基本过程、用户和业务过程”中所述的EP识别规则来识别基本过程。
表 8 航空预订系统基本过程识别规则
表9列出了通过上述过程识别出的EP：
将EP识别规则应用于与系统截图相对应的业务活动，并考虑每组截图中要实现的业务价值，识别出了五个基本过程。
6 结论
本文旨在为CPM v4.3.1关于基本过程识别规则和唯一性检测提供指导。本文包含的示例仅为参考，不代表任何真实系统或业务领域。
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
以上就是软件造价评估公司中基数联为您带来的“基本过程的FPA规则解释”所有内容，更多软件开发成本估算知识敬请关注中基数联！
