使用用例点估算软件成本：直接使用用例事务记录
用例点方法（UseCase Point）是一种估算软件开发项目工作量和成本十分有用的模型：您可以使用它来精确指定并记录用例事务的数量。本文向您展示了怎样使用该模型来计算事务数量以估算成本。
启动一个新的软件开发计划时，需做出的一个重要决策便是它的开发成本是多少。估算成本是系统分析员、项目管理员和软件工程师长期以来一直面临的一个问题。首先一个问题是得到项目准确的范围。系统应该能够有哪些功能？获取用例中的功能性需求，能够以一种用户和其他领域内专家理解的方式交流需求。在项目的早期计划阶段，完成一个用例模型，它包含了所有角色的列表（用户或者外部系统），以及系统中用例，它们的名字，以及一个简单的介绍。获取这些信息能够在项目的早期阶段中更容易的对系统的规模达成一致意见。
我们将会在下面介绍到的用例点方法，是一种十分有前途的估算成本方法，能够很好的配合用例方法以描述需求。它的基础是用例事务的概念，大小度量的最小单位。不幸的是，对于用例事务有很多偏离方向的假设。
在本文中，我们将会详细介绍并看它们的实际工作性能。从用例点方法的概述开始，接着是在什么分辨率下用例事务工作状态最好。我们还知道用例事务是怎样与用例相关的其他概念相联系的。我们以怎样计算它们的讨论结束本文。
用例点方法是一种估算软件开发活动的广泛记载的方法。 1但是，任何估算都不应该单独自己使用，而应该与其他方法结合使用。 2这里我们处理用例点。图 1 显示了主要的概念。 3它的基础是用例模型，它由角色和用例组成。识别的用例的数量是所谓未调整用例点计算的最重要部分。系统的规模是通过根据技术复杂性因素进行调整，获取系统技术属性估算，来从未调整的用例点处计算得来的。
一旦您对系统的规模做出了估算，那么您可以开始估算效果了。通过从团队以及其他环境下的影响中，计算环境因子（EF）。一个非常重要的环境因子是需求的稳定性。您还需要查看每一个用例点需要多少个小时（H）。最后，现在用例点模型中添加未计算的补充的效果（SE）（例如项目管理时间，集成测试等），然后估算就完成了。
图 1 ：用例点方法的主要概念
用例的权重，由用户与。
根据用户点方法，对用例分配权重的标准是：
- 简单用例：1 到 3 个事务，权重=5
- 一般用例：4 到 7 个事务，权重=10
- 复杂用例：多于 7 个事务，权重=15
因此，对用于计算事务的事务和策略的本质的估算，能极大程度的影响估算。
  |
|
事务（用例）的概念能够帮助处理不同长度以及大小的用例描述。用例描述可以简洁的书写，或者详细的书写，这取决于使用的用例模板，采用的方法，涉及到的业务背景，或者 个人对 Requirements Specifier 的设置。在一个用例流程里的步骤的数量，描述了角色与系统之间的关系，也能够发生很大的改变。您可以 通过检查并计算用例描述中涉及到的用例事务来检查并计算用例事务，来进行测试。如果两个测试描述拥有相同数量的独特事务，那么它们可以拥有相同的大小。
Ivar Jacobson，用例的发明者，将用例事务描述成从用户到系统，再到用户的“环形路线”；在系统等待一个新的输入时事务就完成了。 4换句话说，在一次事务中，用户运行输入系统的一些操作。此时系统发生反应。它处理输入并将处理的结果返回给用户。当用户对结果做出反应时，一个新的事务开始了，它反过来由可以作为系统的输入。
Jacobson 的话还包含了另外一层意思：用例事务并不是定义为“用例流程中的步骤”。只是对由一个“环形路线”组成的用例流程自身，这种定义才成立。尽管一些书写用例的方法将它描述成叙述用例事务的另一种方法，但毕竟它不是标准的方式。 5
有些作者建议“用户运行的刺激源的存在性就是定义事务的部分”。 6尽管一次事务总是从一个刺激源开始（就是用户进行了一项触发系统反应的操作），刺激源本身并不是完整的事务。假设您拥有一个以下的用例描述：
用户选择一个 X。
...
（n）用户提交。
...
现在还不清楚系统是否对步骤（1）和（n）中刺激源作出了反应，或者系统是否对步骤（1）或者步骤（n）分别作出。因此，两个刺激源可以组成一个或者两个事务。它并不取决于刺激源，而是取决于刺激源和回应的组合。
在 Web 上进行的许多次讨论中，您可以找到定义为“一系列要么完全执行，要么一点也不执行的活动”的用例事务。 7。该定义听起来像是数据库管理系统中的一个事务性机理，如果它没有正常运行的话该步骤可以返回。在我们的经验中，这不是在一个用例描述中将一片内容与另一片内容隔离起来的方法。它也行会激发一个想法，也就是事务在一定程度上与数据库中的读写操作相关。但是，在一个环形路线中，系统根本不用查询数据库也是可能的。这个过程中数据库也行根本不会涉及到，或者数据来自系统以外。因此得出用例事务一定会与数据库中的事务联系起来的结论是不合适的。
用例事务中的系统可能会在一步完成。表面上，我们可能会得出用例事务只是一个系统步骤。但是，一个系统步骤并不是描述用例事务的一个较好的基础，因为它取决于对您计算的多少步骤的描述。而且，系统本身并没有多少涉及到 Actor 与系统之间的联系。换句话说，您的估算应该基于“环形的”事务，而不是系统步骤。
用例事务的“环形路线”方法，在估算用户界面复杂性方面显示出其价值。一个范例就是工作入口项目，在这个项目中可以设计出一个工作设计机器。在基于用例模型（Survey）的早期估算中，工作搜索界面被认为是简单的；用户可以从一系列的下拉菜单中选择搜索项，然后进行选择。但是，在用于产生用例描述的用户界面中，，如果系统可以对已作出的选择进行回应，并更改后续下拉菜单中内容的话，那么可以预见应用的可用性会得到提高。换句话说，本来应该是一个的事务现在变成了两个。
这里是用例配置的第一个草稿：
该段文字扩展如下：
这里您可以看到两个“环形路线”。将用例配置当作证明，查看调整初始估算后的合理性变得容易起来。
如果用例事务是一个紧跟系统回应的刺激源，那么它十分能够计算成一个事务？例如，如果我从我的键盘上敲入一个“K”，那么这就是一个刺激源，然后系统会通过在屏幕上显示一个能组成“K”的像素点来回应这个刺激源。所以，我们以前推荐的定义是不是太狭隘了？
不，不是这样的。它显示您理解用例事务时，应该与用例事务本身被理解保持同一个层次。现在，您可能对输入字母这种操作不感兴趣，当字母出现在屏幕上的，您就会觉得这是理所当然的；您不需要在系统中构建什么东西来产生结果。但是，如果您的内容是描述键盘模型与图形化反应器，这样一个用例事务是十分合理的。
| |
|
既然您已经看到了决定什么是以及什么不是用例事务的清晰解释，让我们检查在用例中计算事务的一些挑战。如上面所述，用例的权重是由它所包含的用例事务的数量所决定的，但是，什么时候系统对刺激源的反应会计算成不同的？
让我们通过检查上面介绍过的工作入口的搜索流程开始。如果用户在寻找一个“Java”类型的工作，他选择了 Java，然后系统会在数据库中搜索这种类型的所有工作。当用户寻找一个“.Net”类型的工作，它选择了 .Net。然后系统会搜索数据库来找到该类型的所有工作。这两种是不是不同的事务？当然不是。用例配置本身是抽象的或者通用的，在这个意义上您不要对不同的搜索项期待不同的流程。这只不过是安装过程中的一点不同。但是，您可以对一个使用预定义类型或者自由格式文本的搜索期待不同的流程。
另一方面，处理例外是一个灰色的区域。假设您有了带有七个区域的输入屏幕，它们中的所有都有不同的限制。您有一个日期区域，一个邮政编码，一个输入区域，以及等等。每一个检查可能会在单独的流程中得到描述，因此被计算成可能不止一个事务。您可以选择的是，提供一个通用的流程。它预假设有一个可以容易处理的例外种类的框架。在这种情况下，您应该将该流程计算成一个事务。
使用当作环形路线的用例事务，可以在用例中随处可见。因为一个用例配置至少有一个基本流程，它也至少应该有一个事务。没有事务的流程是没有意义的，因为系统在没有刺激源时什么都不会做，用户在没有弄清系统的反应之前也不会提供任何刺激源。
几乎一直都会有描述处理例外的流程（因此，“例外的流程”）。每一个例外流程都至少含有一个事务。这点也适用于一个可选择的流程；对于每一个可选择的流程都应该有至少一个流程。很可能您需要查看基本流程，以查看可选择流程中事务的刺激源；这取决于处理用例的特定指定原则。
它给了您一个任何用例配置中用例事务最小数量的指示：流程中至少应该有以下数量的事务。 8
如果您拥有识别用例事务的能力，您是否需要对它们平等的重视？我们的策略是显示它们中的，每一个与事务（如果可以应用的话），但是有些时候并不计算它们的权重。我们的策略要比直接忽略它们更加直接。如果需要的话，调整原始的估算也十分的容易。
通过这种方式，您就能够看出框架的价值。如果用例计算十个事务的话，但是它们中只有三个值得处理，另外三个遵循框架，该用例是普通的而不是复杂的。表 1 中显示了一个例子。
| 用例 | # 事务 | # 计算 | 原因 | UC 权重 |
| 1 申请工作 | 4 | 3 | 简单 | |
| 2 找工作 | 3 | 3 | 简单 | |
| 3 评估申请 | 10 | 7 | 框架 | 平均 |
是不是没有办法解释一个用例业务暗含的系统步骤与只有一步系统步骤之间的差异？您的直觉告诉您构建 6 个系统步骤要比构建 1 个需要更大的努力。实际上，我们完全赞成。但是，您不应该试着通过计算系统步骤，而应该通过隔离另外系统步骤涉及到的功能性，来解决这些小问题。如果您拥有大量的功能性，那么可能它就是用例本身。注意不要将任何堆积的功能发展成“用例”的状态。这将会是功能性降级。但是应用如下的规则：后续的用例必须拥有一个清晰的目标，这符合至少一个投资者的利益（并不一定与用户相似）。 9
一个范例可以是用例“产生年平均”。在这个用例的过程中，会生成一些报告，代表一个特定投资者的利益。生成每一个报告的过程中，会涉及到一些系统步骤。为每一个报告定义单独的用例，能够帮助您找到合适的投资者，而不用打扰其他的投资者。通过这种方式，我们就能够提供更加保险的估算了。
如果用例使用在缺乏用户交流的情况之下（在这方面我们有较好的经验），那么您怎样将业务的概念转化成一个环形路线。坦白来说，在这里它并不适用。您需要其他的方式来估算这种用例的权重。而且，这是由专家估算来完成的。表 2 显示了它们是怎样在扩展卡中显示的。
| 用例 | # 业务 | # 计算 | 原因 | UC 权重 |
| 1 申请工作 | 4 | 3 | 简单 | |
| 2 找工作 | 3 | 3 | 简单 | |
| 3 评估应用性 | 10 | 7 | 框架 | 平均 |
| 4 读取文件到数据库中 | -- | -- | 专家估算 | 复杂性 |
如果批任务要比一个复杂的用例还要大，那么它应该还有不止一个目标，因此该工作可以分解成更多的用例，每一个用例都能够服务于至少一个投资者的利益。这种机理能够适用于任何用例，这些用例要比实际上还要复杂许多（见于表 2）。如果您不能找到一个好的原因，去分解一个批任务，您可以转化成图 1 中提到的“补充性效果”类型。
一些作家看到了用例点方法中的困难之处，因为在 8 个业务的复杂用例与 16 个业务之间，没有什么不同之处。在我们的经验中，由超过 12 个业务组成的用例，能够满足不止一个目标。所以，它们是问题性用例模型的标志。换句话说，如果您拥有超过 12 个业务的用例，那么考虑一个新的用例就是值得的。 10
在写下所有的用例配置后，计算业务就变得简单起来。另一方面，估算是在项目的早期进行预测的。在这里，您只有用例模型，以及每一个用例的简单介绍。为了展望组成用例的流程，以及涉及到的用例事务，您需要经验的帮助。如果您没有这个经验，不要犹豫去咨询拥有类似系统和背景工作经验的同事。通过创建如表 2 所示 的扩展单来开始，并填入展望的事务。这将会形成管理用例范围的基础，您就能解释哪些用例需要比用户预料的那样更多的事务。
| |
|
为了对软件性能估算应用用力点方法，对它的基本组成有良好的了解是十分重要的。用例业务的概念是这样一种成分，它最好与一个环形路线结合，从用户启动的刺激源到系统的反应都是如此。如果系统等待进一步的刺激源的话，业务就算完成了。
与这个概念结合，我们需要对怎样以及什么时候计算业务作出一些建议。它更像是一种艺术，而不是一门科学，与常识和经验一起应用这些推荐，可与帮助您作出更有效的努力，并评价项目早期的成本。