3.3 基于 UML 的需求变更评估模型（UFPA）
3.3.1 UFPA 的提出
作者在多年的软件项目开发过程中发现，当需求变更出现时，如果用户和开发人员能够进行有效的、充分的沟通和分析，进而如果能对需求变更产生的影响做出比较准确的分析和评估，那么本次需求变更就有可能被有效的控制在合理的范围内，从审核到实施再到追踪都能做到比较好的控制。
根据前面介绍的内容，传统的功能点估算需要对以下各项内容分别进行度量和加权：
· 数据功能点的估算
· 事务功能点的估算
整个识别过程相当繁琐和费时，需要开发人员投入较多的资源才能顺利实施。根据作者多年在软件开发项目中使用 UML 的实践经验，用例图描述了系统的业务逻辑、类图描述了系统的静态结构，顺序图则展示了信息的动态处理过程，它们已经基本能覆盖项目基本的功能。如果能将功能点的识别和计算过程与 UML 的设计过程结合起来，设计出一个功能点估算模型，那么对于中小软件项目来说，将能够极大的简化功能点估算过程，同时开发人员也能够进行快速学习、使用和部署。
根据以上的背景和分析，作者设计出了一个适用于中小软件项目的需求变更评估模型 UFPA（UML Based Function Point Analysis），该模型具有以下明显的优点：
一方面，该模型使用 UML 这个用户和开发人员通用的语言，能较为准确详细地将需求变更展现出来，便于用户和开发人员进行直接和深入的交流和讨论。
另外一方面，基于 UML 的功能点估算方法，能将需求变更产生的影响快速、准确的估算出来，无论是客户还是开发人员，都能够对这次变更心里有所准备，这就为后续的审核，实施，管理等活动提供了相应的依据。
3.3.2 UFPA 的设计思路
可以看出，这里关键的问题是，要设计出 UML 相关图表与功能点估算之间的一个对应关系，使得从 UML 可以较为容易的计算出相应的功能点估算的结果。有相关的论文[8]
也有各自的深入的探讨。但是这些论文往往过于理论化和抽象化，不具备可操作性，本文主要着眼于解决中小软件项目中的实际问题，由此需要设计出一套简化的、易于部署和使用的方案。作者基本的设计思路是：
首先，用例图是系统的功能描述。设计用例图可以识别出 EI 、EO 和 EQ 等候选事务，同时也可以识别出系统需要处理和保存的数据。所以就可以识别出系统的边界和范围。
其次，类图展示了系统的数据是如何被保存的。通过设计类图可以识别和估算出数据功能点。
最后，顺序图详细展示了事务是如何处理的。通过设计顺序图可以识别和估算出事务功能点。
可以看出，上述设计思路把传统的功能点计算过程与 UML 的用例图、类图和顺序图的设计和分析过程进行了结合，能够简化功能点的复杂过程，并且具有一定的可操作性。下面将根据该思路进行展开讨论。
3.3.3 UFPA 的内容
综合以上分析，作者设计的 UFPA 主要包括以下内容和步骤：
（1） 根据变更请求，设计出涉及到的用例图、类图和顺序图（2） 基于 UML 图进行功能点估算（3） 向用户反馈变更估算结果，进行修正（4） 基于上述图表，进行变更带来的代价估算（5） 向用户反馈变更代价估算，根据反馈进行修正，最终达成共识图 3-1 可以清晰的描述 UFPA 的过程：
由上图可以看出，通过 UFPA,项目各方的参与人员进行了非常多的沟通。这个过程将帮助开发人员和客户增进互相理解，提升对相关内容的认识水平。这个过程本身也是一个需求功能的再梳理过程，既可以帮助客户理清业务逻辑和功能要求的实际内容，同时也帮助开发人员更加深入的理解了客户的业务逻辑和真实的功能需求。
最重要的是在这个充分交流的基础之上，将能较为准确的估算出需求改动对整个项目造成的影响。这一点非常重要，对于客户而言，需求改动的提出往往是比较随意和模糊的，看到估算结果后，客户将会重新审视自己的改动要求，将改动限制在一个比较合理的范围内。对于开发人员来说，估算结果会直观的反应到项目进度、资源上，项目经理和变更控制委员会就能有比较可靠的依据对需求改动进行评审并做出比较合理的判断。
该模型使用的关键技术和步骤都非常直观和易于实施，便于客户和开发人员的直接深入交流，因此特别适合中小软件项目使用，并具有一定的实践意义。下面将对该模型展开论述。
3.3.4 UFPA 的评估步骤
本节将结合 3.2 章节中介绍的作者项目开发的实例，详细描述 UFPA 模型的实际评估过程。这里将以呼叫中心模块作为实际案例进行分析。
3.3.4.1 UML 图设计
根据本文的 UFPA 模型，首先设计相关的 UML 图：
§ 用例图设计
该系统主要有客户信息管理和订单管理两个子系统。初步的用例图如下图 3-2 所示：顾客信息管理子模块主要包括查询基本信息子系统、创建顾客信息子系统和修改顾客信息子系统，可设计如下图 3-3 所示：
订单管理主要包括查询、修改和新建等功能，其用例图如下图 3-4 所示：
§ 类图设计
系统的类图设计如下图 3-5 所示：
§ 顺序图设计
这里仅用新电话订单流程为例子，顺序图设计如下图 3-6 所示：
3.3.4.2 用例图功能点估算
首先可以通过用例图来估算项目的需求范围。
用例图与 EI,EO,EQ 等可以关联起来。用例图并没有更多的信息进行相应的估算，但是至少可以找出可能的事务功能，从而可以得出系统中事务的个数， 然后可以再结合类图和顺序图进行具体的分析和计算。
根据中小项目的特点，作者建议将用例图中凡是与系统外部直接进行交互的用例作为候选的事务。
本项目案例中，系统的范围就是和呼叫中心流程相关的所有功能。
根据本规则，从前面已经设计出的图 3-3 中可以看出，在顾客信息管理子系统中，有三个用例与外界进行了交互，都可以作为候选事务。
而在订单管理子系统中，从前面已经设计出的图 3-4 中可以看到也有三个用例与系统外界进行了交互，也将他们作为备选事务。
由此可以识别出系统可能的事务如下：
· 查询顾客信息
· 修改顾客信息
· 新建顾客信息
· 订单查询
· 订单修改
· 新建订单
3.3.4.3 类图的功能点估算
根据中小软件项目的特点，作者建议只考虑将存储或者使用系统需要的信息的类作为候选，同时为了处理简单化，可以将每个类计算为一个数据功能点，并将所有的类都作为内部逻辑文件 ILF 处理。
最后还需要估算复杂度。同样基于简化计算目的，把类的普通属性计算为 DET,而将复杂属性计算为 RET.
根据以上的规则，本项目案例中，类图中包括的表，前面已经设计的图 3-5 中，Product,Customer, Order, CallRecord 都可以简化成内部逻辑数据 ILF 来处理，接下来就需要估算复杂度。这里以 Customer 为例，其属性设计如下图 3-7 所示：
可以看出最后的两个属性 Picture 和 LastOrder 可以作为复杂属性，所以可以计算为2 个 RET,其余的 12 个属性都为基本类型，计算为 12 个 DET.
其他几个类的细节实现就不再赘述，下面仅仅列出计算后的 DET、RET 结果如表3-1 所示：
3.3.4.4 顺序图的功能点估算
前面提到，用例图描述了系统的业务逻辑，顺序图通常被用来描述一个用例的行为，一个用例可以包含一个或者多个事务。根据中小软件项目的特点，可以选出用例图中那些与外部进行消息交换的消息处理流程作为候选事务。
接下来就要识别各个事务的类别。
如果过程接受了输入的数据或控制信息，使用了某个内部逻辑文件或者对系统状态产生影响，则将其计算为外部输入 EI.
如果该消息处理过程向系统以外提供了经过逻辑加工的、除了检索数据或控制信息之外的信息或附加信息，则将其计算为外部输出 EO.
如果该消息处理过程向系统以外提供了未经逻辑加工的信息，则将其计算为外部查询 EQ.
根据上述规则，就能比较直观、容易的通过顺序图识别出 EI、EO 和 EQ.
最后就要进行复杂度的计算。根据中小软件项目的特点，同样进行简化处理，DET的数量可以根据消息的个数估算，FTR 数量可以根据参与的实体个数决定。
综合上述规则，结合已经设计好的用例图，本项目案例中可能的事务如下：
· 查询顾客信息
· 修改顾客信息
· 新建顾客信息
· 订单查询
· 订单修改
· 新建订单
接下来将以新建电话订单顺序图为例进行详细分析，如前面设计出的图 3-6 所示：
该处理过程主要是根据用户输入的用户信息、商品信息以及订单信息，生成新订单，并保存到系统中，因此可以将该处理流程识别为外部输入 EI.
接下来计算复杂度，新建订单的输入信息主要包括如下参数：
1） 用户姓名
2） 用户性别
3） 用户手机号码
4） 用户备用电话
5） 用户地址信息
6） 用户生日
7） 用户邮箱地址
8） 商品名称
9） 订购数量
10） 备注信息
11） 商品单价
12） 商品折扣
13） 优惠券信息
14） 订单生成时间
15） 送货地址
16） 快递公司选择
17） 支付方式
18） 是否签收
19） 备用送货地址
20） 付款方式
由此估算出该事务的 DET 为 20.另外，从顺序图中可以看出，总共有 4 个对象参与了消息传递和处理：顾客、工作人员、网站和数据库，由此可以计算出该事务的 FTR为 4.
其他子系统的顺序图的计算也类似，这里不再赘述，仅仅将识别结果总结如下表 3-4所示：
3.3.4.5 确定值调整因子
该项目案例中，根据中小软件项目的特点，作者进行了简化处理，所有的因子都取2,即中等相关。
由此 VAF 的计算如下：
