用例点方法（UseCase Point）是一种估算软件开发项目工作量和成本十分有用的模型：您可以使用它来精确指定并记录用例事务的数量。本文向您展示了怎样使用该模型来计算事务数量以估算成本。
在启动一个新的软件开发计划时，需做出的一个重要决策便是它的开发成本是多少。估算成本是系统分析员、项目管理员和软件工程师长期以来一直面临的一个问题。首先一个问题是得到项目准确的范围。系统应该能够有哪些功能？获取用例中的功能性需求，能够以一种用户和其他领域内专家理解的方式交流需求。在项目的早期计划阶段，完成一个用例模型，它包含了所有角色的列表（用户或者外部系统），以及系统中用例，它们的名字，以及一个简单的介绍。获取这些信息能够在项目的早期阶段中更容易的对系统的规模达成一致意见。
我们将会在下面介绍到的用例点方法，是一种十分有前途的估算成本方法，能够很好的配合用例方法以描述需求。它的基础是用例事务的概念，大小度量的最小单位。不幸的是，对于用例事务有很多偏离方向的假设。
在本文中，我们将会详细介绍并看它们的实际工作性能。从用例点方法的概述开始，接着是在什么分辨率下用例事务工作状态最好。我们还知道用例事务是怎样与用例相关的其他概念相联系的。我们以怎样计算它们的讨论结束本文。
使用用例点
用例点方法是一种估算软件开发活动的广泛记载的方法。但是，任何估算都不应该单独自己使用，而应该与其他方法结合使用。这里我们处理用例点。图 1 显示了主要的概念。它的基础是用例模型，它由角色和用例组成。识别的用例的数量是所谓未调整用例点计算的最重要部分。系统的规模是通过根据技术复杂性因素进行调整，获取系统技术属性估算，来从未调整的用例点处计算得来的。
一旦您对系统的规模做出了估算，那么您可以开始估算效果了。通过从团队以及其他环境下的影响中，计算环境因子（EF）。一个非常重要的环境因子是需求的稳定性。您还需要查看每一个用例点需要多少个小时（H）。最后，现在用例点模型中添加未计算的补充的效果（SE）（例如项目管理时间，集成测试等），然后估算就完成了。
用例的权重，由用户与。
根据用户点方法，对用例分配权重的标准是：
·简单用例：1 到 3 个事务，权重=5
·一般用例：4 到 7 个事务，权重=10
·复杂用例：多于 7 个事务，权重=15
因此，对用于计算事务的事务和策略的本质的估算，能极大程度的影响估算。
什么是用例事务？
事务（用例）的概念能够帮助处理不同长度以及大小的用例描述。用例描述可以简洁的书写，或者详细的书写，这取决于使用的用例模板，采用的方法，涉及到的业务背景，或者个人对 Requirements Specifier 的设置。在一个用例流程里的步骤的数量，描述了角色与系统之间的关系，也能够发生很大的改变。您可以通过检查并计算用例描述中涉及到的用例事务来检查并计算用例事务，来进行测试。如果两个测试描述拥有相同数量的独特事务，那么它们可以拥有相同的大小。
用例事务是一个“环形的路线”
Ivar Jacobson,用例的发明者，将用例事务描述成从用户到系统，再到用户的“环形路线”；在系统等待一个新的输入时事务就完成了。换句话说，在一次事务中，用户运行输入系统的一些操作。此时系统发生反应。它处理输入并将处理的结果返回给用户。当用户对结果做出反应时，一个新的事务开始了，它反过来由可以作为系统的输入。
用例事务不总是一个用例步骤
Jacobson 的话还包含了另外一层意思：用例事务并不是定义为“用例流程中的步骤”。只是对由一个“环形路线”组成的用例流程自身，这种定义