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