（本文由北京中基数联科技有限公司撰写，仅供学习参考使用，版权归中基数联所有，转载请标明出处。）

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]。换句话说，用户可识别是业务过程或业务过程活动中的所有内容。
基本过程识别规则是将业务过程活动拆分为满足以下条件的最小活动单元：

1.  对用户有意义：“用户可识别并满足功能用户需求”的所有内容^[8]；
2. 构成一个完整事务：“用户为完成一个基本过程的所有需求。如验证、数学运算或计算、读取或维护数据功能”；
3. 自包含：“功能用户需求不需要任何前置或后续处理步骤就可以独立完成”；
4. 使应用程序的业务处于持续状态：“过程已完全执行，功能用户需求已得到满足，无需再做任何事情”。

       “对用户有意义”相当于“对业务有意义”，即从用户的角度来看，是一切与业务目标相关的功能需求。当然，并不是说对用户没有明确意义的内容就是对业务无意义：对业务过程进行详细分析可以显示出用户可识别的更多功能需求。
       “完整事务”的概念与处理逻辑的概念相关联，即“用户要求的完成一个基本过程的特定需求。如验证、数学运算或计算、读取或维护数据功能”。这意味着，“完整事务”必须包含所有适用的处理逻辑，从用户的角度实现部分或所有业务目标。处理逻辑可以有业务过程的一个或多个处理步骤，并且包括应用程序响应消息。处理步骤确保所有维护ILF的属性都已写入。例如，在一个处理步骤中，应用程序向用户展示信息以供查看，并允许用户确认，这是一个EP的一部分，而不是一个完整的EP。
       “自包含”和“使业务处于持续状态”的概念和业务过程活动有关，它基于用户视角交付业务可识别的结果。“自包含”的活动意味着可以在不需要执行任何其他活动的前提下独立执行该活动。如果一个活动有其他可能完成或必须完成的活动作为前置任务，那么该活动则不能“自包含”，因为它依赖于前置任务功能。可以通过一个包含选择条件、检索信息、显示结果的查询功能来说明这种情况：选择条件必须是在检索信息之前的强制性前置活动，检索信息是显示结果的强制性前置活动。因此，选择条件和检索信息都不是“自包含”的，因为只有在显示结果之后才能实现业务目标。所以，“选择条件+检索信息+显示结果”的组合是“自包含的”。
       “持续状态”的概念表明，当时事务完成时，所需的业务功能已经完成，不需要后续任何步骤。所有数据处于最终状态，并满足功能用户需求。此时，系统可以禁用或关闭，且数据可用于下一次EP，如果必须重复之前的EP，则说明该EP未达到持续状态。
       识别EP的所有关键概念都可以通过业务过程相关联：EP由为业务过程提供所需步骤的活动或一组相关活动组成，其结果是最小的、有意义的、完整的和业务可识别的。
       然而，仅识别EP是不够的，还需要在识别EP之后，按照之前同样适用的规则，与已识别的其他EP相比，确保EP不会重复。基本过程的唯一性是基本过程的另一个重要概念，需要在业务过程的背景中对其加以理解。
       正如CPM中定义的，唯一性检测表明，“当与已经识别到的基本过程进行比较时，如果两个相似的基本过程满足下列条件，则把它们当作同一个基本过程：

1. 要求相同的DETs集；
2. 要求相同的FTRs集；
3. 要求相同的完成基本过程的处理逻辑。”

       此外它还指出：“一个基本过程在多个可选事件中可能包含微小的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 预约系统业务过程活动
注：如果用户或系统中止/取消流程，则流程将中断，且系统没有其他响应。
       “乘客”和“司机”是预约系统的用户。因此，预约系统业务价值由预约过程的用户视图表示，这是识别基本过程的规则之一。

       表2通过应用上述EP识别规则，对每个业务过程活动进行了分析，以识别基本过程：
       表 2 预约系统基本过程识别规则

	基本过程识别规则
业务过程活动	是否对用户有意义？	是否构成一个完整事务？	是否自包含？	是否使应用程序的业务处于持续状态？
请求预约	是。请求预约是功能用户需求的一部分。	否。仅请求预约并不是一个完整事务，因为该过程还必须接收请求信息、检查可用性、获取备选日期/时间并向客户提供预订信息。这些步骤在逻辑上不能分开。	否。接收请求、检查可用性、获取备选日期/时间和提供预订信息是完成基本过程所需的所有后续处理步骤。	否。只有在提交、接收、处理请求预订信息并将其返回给客户时，才能满足完整的业务需求。
接收预约请求	是。接收预约请求是功能用户需求的一部分。	否。仅接收预约请求不是一个完整事务，因为该过程还必须请求预订、检查可用性、获取备选日期/时间并向客户提供预订信息。这些步骤在逻辑上不能分开。	否。请求预订是必须执行的前置处理步骤。检查可用性、获取备选日期/时间和提供预订信息是完成基本过程所需的所有后续处理步骤。	否。只有在提交、接收、处理请求预订信息并将其返回给客户时，才能满足完整的业务需求。
检查是否可用	是。检查是否可用是功能用户需求的一部分。	否。仅检查可用性不是一项完整事务，因为该过程还必须提交预约请求、接收请求信息、检查可用性、获取备选日期/时间并向客户提供预订信息。这些步骤在逻辑上不能分开。	否。请求预约和接收请求都是必须执行的前置处理步骤。获取备选日期/时间和提供预订信息是完成基本过程所需的所有后续处理步骤。	否。只有在提交、接收、处理请求预订信息并将其返回给客户时，才能满足完整的业务需求。
获取备选时间	是。获取备选时间是功能用户需求的一部分。	否。仅获取备选时间不是一个完整事务，因为该过程还必须提交预约请求、接收请求信息、检查可用性并向客户提供预订信息。这些步骤在逻辑上不能分开。	否。请求预约、接收请求和检查可用性都是必须执行的前置处理步骤。提供预订信息是完成基本过程所需的后续处理步骤。	否。只有在提交、接收、处理请求预订信息并将其返回给客户时，才能满足完整的业务需求。
提供预订信息	是。提供预订信息是功能用户需求的一部分。	否。仅提供预订信息不是一个完整事务，因为该过程还必须提交预约请求、接收请求信息、检查可用性并获取备选日期/时间。这些步骤在逻辑上不能分开。	否。请求预约、接收请求、检查可用性和获取备选时间都是必须执行的前置处理步骤。	否。只有在提交、接收、处理请求预订信息并将其返回给客户时，才能满足完整的业务需求。
预约流程	是。预约流程是功能用户需求的一部分。	是。处理预约信息是一个完整事务，负责接收客户的响应、记录响应并将响应返回给客户。	是。处理预约信息可以独立执行。	是。当客户接受预约信息并通知系统，系统记录预约并向客户返回通知时，就实现了完整的业务需求。
分配司机	是。分配司机是功能用户需求的一部分。	是。分配司机是一个完整事务，负责接收司机分配通知、记录司机分配并通知司机。	是。分配司机可以独立执行。	是。完成司机分配即可满足业务需求。
载客	是。载客是功能用户需求的一部分。	否。载客不是一个完整事务，因为预约系统还必须将预约记录标识为已完成。这些步骤在逻辑不能上分开。	否。完成预约请求是完成基本过程必须执行的后续步骤。	否。只有当司机向预约系统告知载客成功，并且预约系统将预约记录标识为已完成后，才能满足完整的业务需求。
完成预约请求	是。完成预约请求是功能用户需求的一部分。	否。仅完成预约请求并不是一个完整事务，因为司机还必须告知预约系统客户已被接走。这些步骤在逻辑上不能分开。	否。载客是完成基本过程必须执行的前置步骤。	否。只有当司机向预约系统告知客户已上车，并且预约系统将该预约记录标识为已完成时，才能满足完整的业务需求。

       表3列出了通过上述过程识别出的EP：
       表 3 预约系统识别到的基本过程

业务过程活动	确定符合所有EP识别规则的基本过程
l  预约请求 l  接收预约请求 l  检查是否可用 l  获取备选时间 l  提供预订信息	这些活动单个来说都不符合全部的EP识别规则（见上表）。它们只有在组合时才满足完整的业务需求。EP由这些业务过程活动的处理逻辑组成。
预约流程	此业务过程活动符合所有EP识别规则（见上表），并构成EP。
分配司机	此业务过程活动符合所有EP识别规则（见上表），并构成EP。
l  载客 l  完成预约请求	这些活动单个来说都不符合全部的EP识别规则（见上表）。它们只有在组合时才满足完整的业务需求。EP由这些业务过程活动的处理逻辑组成。

       上述示例演示了如何将业务过程中的单个活动或步骤组成一个唯一的基本过程。当将五个活动（请求预约、接收预约请求、检查是否可用、获取备选时间和提供预订信息）的处理逻辑结合时，就可以实现业务目标并使业务处于持续状态。下图以可视化的方式表示BPM活动是如何构成每个已识别的EP的。
       注：每个“口”表示为一个唯一的EP。        缺乏业务过程模型对于识别基本过程来说是一个挑战。下面几节将探讨如何在特定场景中使用除业务流程图以外的方式识别EP。
 
 

4 基本过程和用例

       用例是需求开发和功能点分析的强大而有效的工具，它们表示“外部参与者与系统之间的交互，以达到特定的目标”，代表了用户视角。
       《计数实践手册V4.3—案例研究1》中对用例图的描述如下：

• l  参与者是用户在系统中扮演的角色。参与者可以是人、硬件设备或其他系统，由一个具有简短描述性名称的图形表示。例如：

  
人力资源部专员

• l  用例是系统为实现特定目标而需要执行的一组操作，由椭圆和简短的描述性名称表示，例如：

• l  一个参与者通过一条直线与一个用例相关联。

       FPA分析师在分析用例图以识别基本过程时需要特别注意“包含”和“扩展”两种用例关系。
       “包含”关系意味着被包含的用例不是一个独立的用例，它必须在基本用例的逻辑背景中运行。“扩展”关系意味着扩展用例是基本用例的附加步骤，这些步骤可以是可选的，也可以是强制性的。
       以下示例描述了参与者(客户)与银行账户系统的三个基本功能(提现、转账和获取银行账户对账单)之间的用例关系（图3）。
       注：下图演示了在识别基本过程时对用例图的解释，主要是讨论用例之间的“<<包含>>”和“<<扩展>>”关系。因此，有关登录/注销功能的注意事项所引用的活动的完整流程工作流不在本示例的范围内。        根据上述用例图显示，用例描述如表4所示。
       注：用例使用自由形式的文本描述，不遵循任何正式的UML规则。
       表 4 银行账户系统用例描述

用例名称	用例描述
提现	客户请求提现。银行账户系统分配请求的现金金额，系统更新账户余额并显示客户更新的账户余额。
获取银行账户对账单	客户请求银行账户对账单，银行账户系统同时显示账户对账单信息和当前银行账户余额。
转账	客户请求转账。银行账户系统将资金转移到指定账户，更新账户余额并显示客户更新的账户余额。
显示账户余额	执行“提现”、“获取银行账户对账单”或“转账”操作后，银行账户系统立即显示当前银行账户余额。
更新账户余额	银行账户系统在执行提现或转账操作后更新客户的银行账户余额。

       注：如果用户或系统中止/取消流程，则流程将中断，且系统没有其他响应。

       表5针对每个用例进行了分析，通过应用第2节“基本过程、用户和业务过程”中所述的EP识别规则来识别基本过程。
       表 5 银行账户系统基本过程识别规则

	基本过程识别规则
用例	是否对用户有意义？	是否构成一个完整事务？	是否自包含？	是否使应用程序的业务处于持续状态？
提现	是。提现是功能用户需求的一部分。	否。仅提现并不是一个完整事务，因为该过程还必须更新银行账户余额并向客户显示银行账户余额。这些步骤在逻辑上不能分开。	否。更新银行账户余额和显示银行账户余额是完成基本过程所需的后续处理步骤。	否。只有当客户提现，系统更新客户的账户余额，并且客户收到银行账户余额显示时，才能满足完整的业务需求。
获取银行账户对账单	是。获取银行账户对账单是功能用户需求的一部分。	否。仅获取银行账户对账单并不是一项完整事务，因为该过程还必须向客户显示银行账户余额。这些步骤在逻辑上不能分开。	否。显示银行账户余额是完成基本过程所需的后续处理步骤。	否。只有当客户请求并接收银行账户对账单，并收到银行账户余额显示时，才能满足完整的业务需求。
转账	是。转账是功能用户需求的一部分。	否。仅转账并不是一个完整事务，因为该过程还必须更新银行账户余额并向客户显示银行账户余额。这些步骤在逻辑上不能分开。	否。更新银行账户余额和显示银行账户余额是完成基本过程所需的后续处理步骤。	否。只有当客户转账，系统更新客户的账户余额，并且客户收到银行账户余额显示时，才能满足完整的业务需求。
显示账户余额	是。显示账户余额是功能用户需求的一部分。	否、仅显示账户余额并不是一项完整事务，因为该过程必须先执行以下三项活动之一：提现、转账、获取银行账户对账单。这些步骤在逻辑上不能分开。	否。三项活动之一：提现、转账或获取银行账户对账单是完成基本过程所需的前置处理步骤。	否。只有当客户提现、转账或获取银行账户对账单并收到银行账户余额显示时，才能满足完整的业务需求。
更新账户余额	是。更新账户余额是功能用户需求的一部分。	否。更新账户余额并不是一项完整事务，因为该过程必须先执行以下两项活动之一：提现或转账。这些步骤在逻辑上不能分开。	否。两项活动之一：提现或转账是完成基本过程所需的前置处理步骤。	否。只有当客户进行提现或转账并收到银行账户余额显示时，才能满足完整的业务需求。

       表6列出了通过上述过程识别出的EP：
       表 6 银行账户系统识别到的基本过程

业务过程活动	确定符合所有EP识别规则的基本过程
l  提现 l  更新账户余额 l  显示账户余额	这些活动单个来说都不符合全部的EP识别规则（见上表）。它们只有在组合时才满足完整的业务需求。EP由这些业务过程活动的处理逻辑组成。
l  获取账户对账单 l  显示账户余额	这些活动单个来说都不符合全部的EP识别规则（见上表）。它们只有在组合时才满足完整的业务需求。EP由这些业务过程活动的处理逻辑组成。
l  转账 l  更新账户余额 l  显示账户余额	这些活动单个来说都不符合全部的EP识别规则（见上表）。它们只有在组合时才满足完整的业务需求。EP由这些业务过程活动的处理逻辑组成。

       用例“提现”、“获取银行账户对账单”和“转账”与用例“显示银行账户余额”为扩展关系，这意味着显示银行账户余额增加了一个强制性步骤，以完成提现（以及获取银行账户对账单和转账）的业务价值。
       同样，用例“提现”和“转账”中包含用例“更新银行账户余额”，使更新银行账户余额活动成为完成业务价值(提现和转账)的强制性步骤。

5 从屏幕模型感知基本过程

       在多数情况下，功能点分析仅通过分析屏幕截图进行计数。屏幕截图是FP分析的宝贵资源，但如果不考虑要实现的业务目标，只分析截图也可能会导致EP识别错误。
       以下示例描述了FP分析师仅通过可用的屏幕截图来度量计数的场景。
       注：以下截图仅用于说明目的，不代表任何航空公司真实完整的预订流程。
       在航空公司预订系统航班预订流程中，客户可以输入搜索条件，如“出发地”和“目的地”、“预订类型（单程、往返或多程）”、“行程日期”和乘客数量，如图4所示。

图 4 航空预订系统搜索条件
客户也可以通过“排序和筛选”条件来进行航班搜索，如图5所示。        输入搜索条件后，系统将为行程的第一段提供匹配的航班列表，如图6所示。        客户查看匹配航班的列表，选择航班的第一航段，核对所选信息，勾选接受或拒绝航班协议并进行下一步，如图7所示。        如果在搜索条件中选择的预订类型为“往返”或“多程”，则系统将为行程的其他航段提供匹配的航班列表。图8显示了预订往返航班时第二航段的可用航班选择。        客户为行程的所有航段选择航班结束后，系统将显示整个行程的行程单，如图9所示。        客户可以查看可用座位，如图10所示。         客户可以从可选座位中选择座位，如图11所示。         客户可以查看行程的附加服务，如图12所示。         客户可以选择并应用附加服务，如图13所示。  
        客户输入乘客信息，完成“乘客信息”部分，如图14所示。         客户输入付款信息，完成“付款信息”部分，如图15所示。         然后，客户可以查看条款并点击“完成购买”按钮进行购买，如图16所示。         “客户预订航班”业务过程可根据上述截图进行分析，分解为下列活动，如表7所示。

活动名称	活动描述
输入搜索条件	客户提供出发地、目的地、预订类型、行程日期和乘客数量。
选择排序和筛选条件	客户可以选择其他排序和筛选条件。
查看可用航班	系统列出符合搜索条件的可用航班。
选择航班	客户从可用航班列表中选择最合适的航班。客户核对所选信息并选择接受或拒绝航班协议。
选择其它航班	如果选择的预订类型为“往返”或“多程”，则根据搜索条件选择所需航班。
查看行程单	系统显示所有已选航班和预订价格。
查看可选座位	客户查看可选座位列表。
选择座位	客户选择心仪座位。
查看附加服务	客户可以查看其他附加服务。
选择附加服务	客户选择并应用附加服务。
输入乘客信息	客户输入乘客信息，如姓名、出生日期、联系电话和邮箱。
输入付款信息	客户输入付款信息，如信用卡号、持卡人姓名、有效期和密码。
确认航班预订	客户确认航班预订。系统处理预订，验证信用卡信息，并向客户发送确认行程的通知。

注：如果用户或系统中止/取消流程，则流程将中断，且系统没有其他响应。

       表8针对每个活动进行了分析，通过应用第2节“基本过程、用户和业务过程”中所述的EP识别规则来识别基本过程。
表 8 航空预订系统基本过程识别规则

	基本过程识别规则
活动名称	是否对用户有意义？	是否构成一个完整事务？	是否自包含？	是否使应用程序的业务处于持续状态？
输入搜索条件	是。输入搜索条件是功能用户需求的一部分。	否。输入搜索条件是查看可用航班的必要步骤。这些步骤在逻辑上不能分开。	否。选择排序和筛选条件和查看可用航班是完成基本过程所需的后续处理步骤。	否。只有当输入搜索、排序和筛选条件，并向客户显示可用航班时，才能满足完整的业务需求。
选择排序和筛选条件	是。选择排序和筛选条件是功能用户需求的一部分。	否。选择排序和筛选条件是查看可用航班的可选步骤。这些步骤在逻辑上不能分开。	否。输入搜索条件和查看可用航班分别是完成基本过程所需的前置和后续处理步骤。	否。只有当输入搜索、排序和筛选条件，并向客户显示可用航班时，才能满足完整的业务需求。
查看可用航班	是。查看可用航班是功能用户需求的一部分。	否。仅查看可用航班不是一个完整事务。因为输入搜索、排序和筛选条件是该过程的前置步骤。这些步骤在逻辑上不能分开。	否。输入搜索、排序和筛选条件是完成基本过程所需的前置处理步骤。	否。只有当输入搜索、排序和筛选条件，并向客户显示可用航班时，才能满足完整的业务需求。
选择航班	是。选择航班是功能用户需求的一部分。	否。仅选择航班不是一个完整事务。因为客户还可以选择其它航班，并且必须查看行程单。这些步骤在逻辑上不能分开。	否。选择其它航班并查看行程单是完成基本过程所需的后续处理步骤。	否。只有当客户选择航班、选择其他航班并查看行程单时，才能满足完整的业务需求。
选择其它航班	是。选择其他航班是功能用户需求的一部分。	否。仅选择其他航班不是一个完整事务。因为客户必须选择第一航段航班并查看行程单。这些步骤在逻辑上不能分开。	否。选择航班和查看行程单分别是完成基本过程所需的前置和后续处理步骤。	否。只有当客户选择航班、选择其他航班并查看行程单时，才能满足完整的业务需求。
查看行程单	是。查看行程单是功能用户需求的一部分。	否。仅查看行程单不是一个完整事务。因为在此之前客户还必须选择第一航段航班和其他航班。这些步骤在逻辑上不能分开。	否。选择航班和选择其他航班是完成基本过程所需的前置处理步骤。	否。只有当客户选择航班、选择其他航班并查看行程单时，才能满足完整的业务需求。
查看可选座位	是。查看可选座位是功能用户需求的一部分。	是。仅查看可选座位是一个完整事务。	是。查看可选座位可独立执行。	是。当客户查看可选座位时，即可满足全部业务需求。
选择座位	是。选择座位是功能用户需求的一部分。	否。仅选择座位不是一个完整事务。因为客户还必须选择附加服务、输入乘客信息、输入付款信息，并确认航班预订以完成预订。这些步骤在逻辑上不能分开。	否。选择附加服务、输入乘客信息、输入付款信息和确认航班预订是完成基本过程所需的后续处理步骤。	否。只有当客户选择座位、选择附加服务、输入乘客信息、输入付款信息和确认航班预订时，才能满足完整的业务需求。
查看附加服务	是。查看附加服务是功能用户需求的一部分。	是。仅查看附加服务是一个完整事务。	是。查看附加服务可独立执行。	是。当客户查看附加服务时，即可满足全部业务需求。
选择附加服务	是。选择附加服务是功能用户需求的一部分。	否。仅选择附加服务并不是一个完整事务。因为客户还必须选择座位、输入乘客信息、输入付款信息，并确认航班预订以完成基本过程。这些步骤在逻辑上不能分开。	否。选择座位是前置处理步骤，输入乘客信息、付款信息和确认航班预订是完成基本过程所需的后续处理步骤。	否。只有当客户选择座位、选择附加服务、输入乘客信息、输入付款信息和确认航班预订时，才能满足完整的业务需求。
输入乘客信息	是。输入乘客信息是功能用户需求的一部分。	否。仅输入乘客信息不是完整事务，因为客户还必须选择座位、选择附加服务、输入付款信息并确认航班预订。这些步骤在逻辑上不能分开。	否。选择座位和选择附加服务是前置处理步骤，输入付款信息和确认航班预订是完成基本过程所需的后续处理步骤。	否。只有当客户选择座位、选择附加服务、输入乘客信息、输入付款信息和确认航班预订时，才能满足完整的业务需求。
输入付款信息	是。输入付款信息是功能用户需求的一部分。	否。仅输入付款信息不是一个完整事务，因为客户还必须选择座位、选择附加服务、输入乘客信息并确认航班预订才能完成预订。这些步骤不能在逻辑上分开。	否。选择座位、选择附加服务和输入乘客信息是前置处理步骤，确认航班预订是完成基本过程所需的后续处理步骤。	否。只有当客户选择座位、选择附加服务、输入乘客信息、输入付款信息和确认航班预订时，才能满足完整的业务需求。
确认航班预订	是。确认航班预订是功能用户需求的一部分。	否。仅确认航班预订不是一个完整事务，它包括选择座位、选择附加服务、输入乘客信息和输入付款信息。这些步骤不能在逻辑上分开。	否。确认航班预订包括选择座位、选择附加服务、输入乘客信息和支付信息，这些是完成基本过程所需的前置处理步骤。	否。只有当客户选择座位、选择附加服务、输入乘客信息、输入付款信息和确认航班预订时，才能满足完整的业务需求。

表9列出了通过上述过程识别出的EP：

业务活动	确定符合所有EP识别规则的基本过程
l  输入搜索条件 l  选择排序和筛选条件 l  查看可用航班	这些活动单个来说都不符合全部的EP识别规则（见上表）。它们只有在组合时才满足完整的业务需求。EP由这些业务过程活动的处理逻辑组成。
l  选择航班 l  选择其他航班 l  查看行程单	这些活动单个来说都不符合全部的EP识别规则（见上表）。它们只有在组合时才满足完整的业务需求。EP由这些业务过程活动的处理逻辑组成。
l  查看可选座位	此业务过程活动符合所有EP识别规则（见上表），并构成EP。
l  查看附加服务	此业务过程活动符合所有EP识别规则（见上表），并构成EP。
l  选择座位 l  选择附加服务 l  输入乘客信息 l  输入付款信息 l  确认航班预订	这些活动单个来说都不符合全部的EP识别规则（见上表）。它们只有在组合时才满足完整的业务需求。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