截至目前，我已经根据经验和最近使用功能点进行了工作量估算。
我现在正在探索 UCP，请阅读这篇文章http://www.codeproject.com/KB/architecture/usecasep.aspx。然后，我检查了基于用例点 (UCP) 的其他各种文章。我无法弄清楚它是如何工作的以及它是否正确。
例如，我有一个登录功能，用户提供用户名和密码，然后我检查数据库中的表以允许或拒绝登录。我将用户参与者和登录定义为用例。
根据 UCP，我将登录用例分类为简单，将 GUI 界面分类为复杂。根据 UCP 系数表，我得到 5 和 3，因此总数为 15。在应用技术因素和环境因素调整后，它变为 7。如果我将生产力因素设为 20，那么我将获得 140 小时。但我知道它最多需要 30 小时以及文档和测试工作。
我在这里定义用例时做错了吗？UCP 说如果界面是 GUI，那么它就很复杂，但这里的 gui 很简单，所以我应该降级这个因素吗？简单的因素也是 5，我应该将另一个级别定义为非常简单吗？但是我不是在这里把事情复杂化了吗？
具有讽刺意味的是，典型的两框登录表单比 2 框 CRUD 表单复杂得多，因为登录表单需要安全且 CRUD 表单只需保存到数据库表（以及读取、更新和删除）。
登录表单需要决定是否重定向到哪里，如何加密保护身份验证令牌，是否以及如何缓存角色，如何或是否处理字典攻击。
我不知道这在 UCP 点中转换为什么，我只知道我的应用程序中的登录屏幕在具有相似数量的按钮和框的表单上花费了更多时间。
上次我被鼓励去计算功能点，那是一场闹剧，因为没有人有时间建立一个“功能点法庭”来对难以衡量的事物做出裁决，尤其是那些没有完全符合模型的假设功能点计数。
这是一篇关于用例点的文章 - 通过规范化用例。我认为您的方法中忽略的一个因素是生产力，这应该是基于过去的项目。20 似乎是平均水平，但是如果您的工作效率很高（众所周知，中等和优秀程序员的比例为 10 比 1），那么生产力可能是 5，从而使 UCP est. 接近您认为应该的水平。我建议查看过去的项目，计算 UCP，获取总工时并确定您的实际工作效率。生产力是一个关键因素，需要计算个人和团队才能有效地用于估计。
部分问题可能是您如何计算交易。根据 UCP 的作者，交易是从用户到系统再到用户的“往返”；当系统等待新的输入刺激时，事务就完成了。在这种情况下，除非系统正在响应...登录可能只是 1 次事务，除非有多次往返系统的往返行程。
查看此链接以获取更多信息...
http://www.ibm.com/developerworks/rational/library/edge/09/mar09/collaris_dekker/index.html
首先请注意，在 Ribu 之前的工作中，他表示 1 UCP 的工作时间为 15 到 30 小时（有关详细信息，请参阅：http ://thoughtoogle-en.blogspot.com/2011/08/software-quotation.html ） ;
其次，很明显，当有很多用例而不是一个用例时，这种估计也像功能点一样更准确。例如，您没有考虑在 20 小时内完成的项目启动、项目管理、环境创建等。
我认为您的计算有问题：“我得到 5 和 3，所以总数为 15”。UAW 和 UUCW 必须相加，而不是相乘。