基于用例点的努力估计

Question

截至目前，我已经根据经验和最近使用功能点进行了努力估算。

我正在探索UCP，请阅读这篇文章http://www.codeproject.com/KB/architecture/usecasep.aspx。然后，我根据用例点（UCP）检查了各种其他文章。我无法弄清楚它是如何工作的并且是正确的。

例如，我有一个登录功能，用户提供用户ID和密码，我检查数据库中的表以允许或拒绝登录。我定义了一个用户actor和Login作为用例。

根据UCP，我将Login用例归类为Simple，将GUI界面归类为Complex。根据UCP因子表，我得到5和3，因此总数为15.在应用技术因素和环境因素调整后，它变为7.如果我将生产率因子设为20，那么我得到140小时。但我知道最多需要30个小时以及文档和测试工作。

我在这里定义用例时做错了吗？ UCP说如果接口是GUI然后它的复杂但在这里gui很容易，所以我应该降级该因素？简单的因素是5，我应该将另一个级别定义为非常简单吗？但那我在这里不是很复杂吗？

Answer 1

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

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

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

上次我被鼓励计算功能点，这是一场闹剧，因为没有人有时间设立一个“功能点法院”，以便在难以衡量的事情上做出裁决，特别是那些没有完全陷入困境的事情。函数点计数假设的模型。

Answer 2

这是一篇关于用例点的文章 - 通过规范化用例。我认为你的方法中忽略的一个因素是生产率，它假设是基于过去的项目。如果你的生产率非常高（有中等到优秀的程序员的比例为10比1），那么20似乎是平均值。生产率可能是5，使UCP达到你认为应该接近的水平。我建议查看过去的项目，计算UCP，获得总小时数并确定你的生产力是多少。需要为个人和团队计算生产力是一个关键因素，以便能够有效地用于估算。

Answer 3

部分问题可能是您如何计算交易。根据UCP的作者，交易是从用户到系统的“往返”回到用户;当系统等待新的输入激励时，事务结束。在这种情况下，除非系统正在响应...登录可能只是一个事务，除非有几次往返系统的往返。

查看此链接以获取更多信息...

http://www.ibm.com/developerworks/rational/library/edge/09/mar09/collaris_dekker/index.html

Answer 4

首先请注意，在Ribu之前的一项工作中，他表示1 UCP的工作时间为15至30小时（详情见http://thoughtoogle-en.blogspot.com/2011/08/software-quotation.html）;

第二，很明显，当有很多用例而不是一个用例时，这种估计，如功能点，更准确。您不会考虑例如项目的启动，项目管理，环境创建等，这些都是在20小时内完成的。

Answer 5

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