基于用例点的工作量估计[关闭]答案

【问题标题】：Effort Estimation based on Use Case Points [closed]基于用例点的工作量估计[关闭]
【发布时间】：2009-06-10 02:24:57
【问题描述】：

到目前为止，我已经根据经验和最近使用功能点进行了工作量估算。

我现在正在探索 UCP，请阅读这篇文章 http://www.codeproject.com/KB/architecture/usecasep.aspx。然后，我检查了基于用例点 (UCP) 的其他各种文章。我不知道它是如何工作的，它是否正确。

例如，我有一个登录功能，用户提供用户名和密码，然后我检查数据库中的表以允许或拒绝登录。我将用户参与者和登录定义为用例。

根据 UCP，我将登录用例分类为简单，将 GUI 界面分类为复杂。根据 UCP 系数表，我得到 5 和 3，因此总数为 15。在应用技术因素和环境因素调整后，它变为 7。如果我将生产力因素设为 20，那么我将获得 140 小时。但我知道这需要最多 30 小时以及文档和测试工作。

我在这里定义用例时做错了吗？ UCP 说如果界面是 GUI，那么它就很复杂，但这里的 gui 很简单，所以我应该降级这个因素吗？简单的因素也是 5，我应该将另一个级别定义为非常简单吗？但是我不是在这里把事情复杂化了吗？

【问题讨论】：

我对UCP完全不熟悉，但是从你这里的描述来看，我突然也很害怕。这正常吗？

标签： estimation use-case ucp

【解决方案1】：

具有讽刺意味的是，典型的两框登录表单比 2 框 CRUD 表单复杂得多，因为登录表单需要安全且 CRUD 表单只需保存到数据库表（以及读取、更新和删除）。

登录表单需要决定是否重定向到哪里、如何加密保护身份验证令牌、是否以及如何缓存角色、如何或是否应对字典攻击。

我不知道这在 UCP 点数中转换为什么，我只知道我的应用程序中的登录屏幕在具有相似数量的按钮和框的表单上花费了更多时间。

上次我被鼓励计算功能点，那是一场闹剧，因为没有人有时间建立一个“功能点法庭”来对难以衡量的事情做出裁决，尤其是那些没有整齐地归入功能点计数所采用的模型。

【讨论】：

【解决方案2】：

这是一篇关于用例点的文章 - 通过规范化用例。我认为您的方法中忽略的一个因素是生产力，这应该是基于过去的项目。 20 似乎是平均水平，但是如果您的工作效率很高（众所周知，中等程序员和优秀程序员的比例为 10 比 1），则生产力可能为 5，从而使 UCP est. 接近您认为应该的水平。我建议查看过去的项目，计算 UCP，获取总工时并确定您的实际工作效率。生产力是一个关键因素，需要计算个人和团队才能有效地用于估算。

【讨论】：

【解决方案3】：

部分问题可能在于您计算交易的方式。根据 UCP 的作者，交易是从用户到系统再到用户的“往返”；当系统等待新的输入刺激时，事务就完成了。在这种情况下，除非系统响应...登录可能只是 1 次事务，除非有多次往返系统的往返行程。

【讨论】：

【解决方案4】：

首先请注意，在 Ribu 之前的工作中，他指出 1 个 UCP 的工作时间为 15 到 30 小时（有关详细信息，请参阅：http://thoughtoogle-en.blogspot.com/2011/08/software-quotation.html）；

其次，很明显，当有很多用例而不是一个用例时，这种估计也像功能点一样更准确。你没有考虑例如项目的启动、项目管理、环境的创建等，所有这些都在 20 小时内完成。

【讨论】：

【解决方案5】：

我认为您的计算有问题：“我得到 5 和 3，所以总数为 15”。 UAW 和 UUCW 必须相加，而不是相乘。

【讨论】：